The original plan made at the end of March of working on the Sah data validation framework and form processing framework didn't happen. In April and May I released fewer CPAN distributions due to vacation.
In May and June a majority of my Perl hacking time is spent around the transaction specification in Rinci and Riap, plus a framework/generator for creating functions that support undo/transaction, because writing such functions directly has become too complex and error prone. I have completed the specification, and converted a few Setup modules to using it (the rest will follow). A demo script has also been created and blogged about.
Bitcard is an open single-sign-on web-authentication service. It’s free for both users and web sites. It is used by most perl.org services.
Ideally I would like to use one account for all perl services. If I click “login” on blogs.perl.org, cpan, … a small disclaimer that bitcard is used in the background would suffice.
PS: after proofreading this post I’d like to make sure no one feels offended. So don’t!
Some of you witnessed me last August standing in front of the great Perl congregation at YAPC::EU and talking a lot of steamy hot air out of my mouth. More precisely how nice it would be to have a DSL for GUI creation like Rebol has it. I just turned hulky green (but without the muscles) of envy when I saw how much less syntax they need to define GUI. Especially if you use the super verbose Wx. (But it looks just better :) ). As I currently do a lot for the rewrite of Kephra, make him most modern, super mighty, tight and duper I found myself currently writing some helper modules that might serve as a basis of that DSL I call GCL - GUI Creation Language.
I will speak again about it, but since there will be no other track beside it, I can give now away some of the wow points. What I created just the last days (last commit) is a sizer class that has several advantages.
Specifically, I want to look at every instance of META_MERGE in Makefile.PL in every distribution in BackPAN. I can easily program this task with my DPAN stuff since I already have a way to crawl CPAN and look in every distribution. That would take a couple of days to go through 250,000 files (although maybe I should try this with Archive::Extract::Libarchive, which speeds up the main bottleneck in this technique.
I thought about GitPAN for a few seconds, but I want to search things that are not in HEAD, too.
In my first blog I described why I wrote a new debugger for Perl and how the rewrite helps me add cool features more easily. Here I'll start to describe the cool features of this debugger. To my knowledge, all of the features described below are not in perl5db.
As mentioned in the last blog, this debugger follows gdb conventions. One implication then is that commands follow the gdb names and thus are no longer limited to one (or two) characters. But you may think well won't it be cumbersome typing in those extra characters? No, and for several reasons. First, the debugger has command aliases, which is a way to give a debugger command name an alias. And many of the aliases given by default are single letters. For example T is an alias for the gdb command backtrace. Of course, you are free to change or remove aliases. To see a list of aliases in effect type alias
Today I'm changing a bunch of code which uses ref() (specifically, code which checks whether something is a coderef: ref($foo) eq 'CODE') to use reftype() instead. reftype() works with blessed coderefs. And I will be encountering blessed coderefs quite a bit since my function wrapper (Perinci::Sub::Wrapper) marks its generated wrapper code by blessing them. I'm not even sure how that would be useful, but I'd still like to know if some function has been wrapped.
I have been putting off this for months (more than a year?) simply because I'm lazy. Personal technical debt, you may say.
Come to think of it: Having to use Scalar::Util, List::Util, List::MoreUtils, etc for seemingly basic functions is a sign of Perl's age, but also a sign of how serious Perl is when it comes to backwards compatibility. We aren't that bad too, remember that poor Python users need to be this verbose when it comes to basic stuffs, like from os import getenv; home = getenv('HOME').
We are happy to announce that PetaMem supports YAPC::Europe 2012 as a silver sponsor.
The PetaMem Group stands for substantial competence in human language
technologies, namely natural language processing and natural language
understanding. Our systems cover all areas from language
identification over machine translation to discourse systems (virtual
agents) and are used worldwide by top-profile corporations as well as
governmental institutions.
We consider Perl not just a programming language. For us, it is the
key technology responsible for the performance and success of our
systems. Designed by a linguist and applied in computational
linguistics, Perl allows us to declass those competitors who are not
using it.
I've been thinking about the way I write Perl subroutines and methods as compared to some other Perl programmers, and I've decided to write a post about it.
To make my subroutines and methods more reusable, extensible, and maintainable, I make them receive a hash reference as their only argument and return a hash reference. This has multiple benefits.
First, the parameters going into the subroutine are named when passed in, and these names are used to identify them inside the subroutine. This means that new parameters can be added with keys in the hash, a very minimal change. The same is true of the return hash. Using keys in a hash is far simpler to maintain than using positions in a list. I've spent enough time wrestling with indexed parameters in subroutines that I never use lists of parameters in code that I expect to use more that once (which is basically all of it).
It was a pain to debug clang -faddress-sanitizer instrumented executables, because variable values were not visible, though they should be. It was caused by wrong stack realignment, triggered by -faddress-sanitizer, but it really was a clang bug.
Despite of what's expressed in this blog post, I am generally responsive (as can be seen from my RT track record) and willing to be cooperative (or rather, not really willing to be uncooperative). I even often do the opposite of what I wrote below. It's just that sometimes you need to vent.
On people suggesting to use File::Spec (or Path::Class) everytime... Have using hard-coded "/" failed these days (on platforms that I care about)? Why do I have to subject myself to the verbose file('a', 'b', 'c') or even the masochistic File::Spec->catfile('a', 'b', 'c'), when 'a/b/c' works? The platforms which do not use "/" path separator are either old, dying, rare, or all of those. And new platforms being written won't even dream of not obeying the /. It's already becoming the overwhelming majority that assuming it works everywhere is the best practical approach.
On the other hand, issues like case-sensitivity or encoding in filesystems are still very real and common...
My major interest is in parsing theory.
But,
according to Google Analytics,
most of my web hits are for a side interest.
A few years ago I discovered
the
Lost Morgenstern Document,
an account of
Kurt Gödel's citizenship hearing which had
gone missing for so long there was doubt it had
ever existed.
Einstein was at the hearing and
Einstein's fame,
plus the fact it's a good yarn,
make the Lost Morgenstern Document
a matter of fairly wide interest.
This post is about another Gödel document
which recently surfaced.
This document does not make a good yarn.
In fact, in terms of reading difficulty,
it ranges from the moderately hard to the low-grade cryptographic.
But the
Rucker Notes
are considerably more important
than the Lost Morgenstern Document.
I’ve been writing programs in Perl since about 1999. Wow, that’s a long time now. That was way back when I was studying Computer Science and working for the IT department of the University I went to. I still write Perl programs these days, at my current job, where we call it Application Development.
Since I like Perl development a lot, and I like learning about Perl, I figure I might like writing about Perl too. So that’s what I’m thinking of doing in this blog. I hope some of you find it interesting and useful. After all these years of experience, I might have something to say that you might find useful and/or interesting, especially if you are starting out with programming and/or Perl coding.
This is the first part of what will be several parts. The next part may be more interesting to a general audience: what are some of the cool new features of the debugger? But since I am assuming we are all geeks here, I want to talk about some of the geeky aspects first. And be warned -- there are much more geeky things I'd like to talk about. This then constitutes then the more general and less involved geeky aspects...
I should say at the outset that I did this with a lot of trepidation. The Perl debugger that comes with Perl is venerable and has a long history. In fact, one of the 3 or 4 things that attracted me to Perl4 over the competition at the time — the Korn or Bourne Shell — was its debugger. And over the years various features have been added to the standard Perl debugger that make it very powerful.
People should write (more) books on CPAN instead. Here are some ideas.
1) The best of CPAN. A curated list of modules, picked by the editor. I would prefer a task-oriented organization. Every mention of modules should also at least mentions its maintenance status (is it actively maintained? is the author responsive? bug queue? are bugs getting fixed?), performance characteristics, strong points, drawbacks, interface. Tasks doable by Perl's builtins and core modules can be mentioned too, although the editor should not dwell too much on those.
2) Creating and maintaining your own CPAN. minicpan, Pinto, carton?, ... Potential reader base include Perl shops and corporate users.
3) Definitive guide to Acme::. Fun things, stories behind the modules, (mostly) useless tricks employed by the modules. I want to a fun, entertaining, light read. Should be 100 pages or less. In the age of ebooks, could perhaps sell for $5-$10? I'd buy it.
4) The worst of CPAN :) A bit like #3 in spirit, but more "coding horror" style.
Deven Corzine is revitalizing the Advanced Perl Users group on LinkedIn, and I've volunteered to help. We're going through all of the join requests to approve everything we can, delete the obvious spam and HR requests, and figure out what to do with the rest.
But, besides clearing out the backlog, I want to quadruple the number of members in the group by the end of summer (which is sooner than Christmas). We have 250 members right now. I want that to be 1,000.
LinkedIn is essentially a trust network that relies on connections and recommendations for other people to get a quick read on strangers. That's amplified with controlled groups, such as Advanced Perl Users group on LinkedIn, which is set up so "new members will only be approved if an existing member is willing to personally vouch for the new member". Deven's intent is to have a group of serious Perl programmers who we'd want to hire ourselves.
I’ve been writing tests for a web service in which one of the methods would occasionally take an inordinate amount of time. The amount of time was inconsistent and it would be useful to capture some timing data to provide the vendor. But, I didn’t want to litter my test files with code to calculate the elapsed time. Eventually, the bugs would be worked out and the timing information would just be noise.
So I wanted to somehow hook into the test framework itself to give me the timing data.
I am happy to announce that Galileo CMS is now available from CPAN! This project has been my on-train side-project, but its come a long way in a short time. The most exciting thing for me is that its entirely installable from CPAN. To try it out, simply do
$ cpanm Galileo
$ galileo setup
$ galileo daemon
of course, you can also run it using the servers provided by Mojolicious, or using your favorite psgi-compliant server (as long as they support websockets).
Authorized users edit pages using markdown with a live-preview. All updates to pages, menus and users are sent via websockets. Styling is courtesy of Twitter’s Bootstrap library.
Is including Changes information in main module's POD a good idea?
You bet. Typing "man Foo" or "perldoc Foo" beats having to go to search.cpan.org or metacpan.org and search for Foo and click some more. Or having to download the distribution, extract the tarball, and viewing the Changes file.
Well, actually, it's a good idea as long as module authors don't have to do it manually.
UPDATE 2012-09-07: I changed my mind :) After creating an alias chg to a command that views Changes in my local repositories, and chgr to cpan-listchanges, I no longer find Changes in the POD appealing. So all I needed was an easy access to Changes.
The first issue of the Perl Weekly was sent out on 1st August 2011. Almost a year ago.
In case you don't know what it is: It is a weekly e-mail with a curated collection of links to the most intersting, Perl-related articles of the previous week. As seen by myself.
I wrote about it several times on this forum, but I think this might be a good opportunity to mention it again. There was also a suggestion that people should brag about the stuff they build. I totally agree.
If you are already a subscriber, let me thank you for your support!
If you are not yet a subscriber, let me invite you to check out the web site, the archive and to subscribe to the Perl weekly newsletter.
