I've updated five of my CPAN reviews, adding new modules and updating where new versions of modules have been released.
I've added the ability to comment at the end of each review, using disqus. Following a suggestion from Ben Bullock, module names in the summary table now link to the review section for the module, and there's a separate link for the module's doc.
In the last blog, I started describing features that are new in Devel::Trepan that aren't in perl5db. Here I will continue with one more: the evaluation aspects of the debugger REPL (read, eval, and print loop).
By default, when you type something that isn't a debugger command the debugger just tries to evaluate the string you gave it. If what you typed was really a mistyped debugger command you might get a weird error message. For example:
Unquoted string "stp" may clash with future reserved word ...
If you don't want this behavior, you can turn off "auto eval". And here is what happens then:
(trepanpl): set auto eval off(trepanpl): stp
** Undefined command: "stp". Try "help".
By the way, bold and underline really is what you get in the debugger if the terminal you are using supports underlining and bold.
Now let's go back and type some Perl commands to be evaluated and let us see what happens.
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.
In July I released several modules to add Log::Any logging to various things: Log::Any::For::LWP, Log::Any::For::DBI, Log::Any::For::Builtins. Now displaying detailed logging is just a single line away.
Some other things which I worked on during this period:
There are a couple of indicators I take into account when evaluating perl modules.
- Update frequency and date of last update
- Usually I look at the source and check for existance of test files.
- The next step would be to check cpantesters results.
- Some cpan authors are known for writing quality code
- Also helpful sometimes are the cpan ratings.
I just wanted to submit ratings for some of the modules I really like but “failed” to do so because apparently it requires a bitcard login.
Q: What is bitcard and why can’t I use my PAUSE login?
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.
How can we make a Perl code search so I can grep all of CPAN? I would have done this with the now-dead Google Code Search, which used to make this part of world's information and universally accessible and useful.
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
I knew this day was coming.
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').
EDIT: Damn you, Murphy's Law. Turns out ref() has one nicety reftype() lacks:
ref(undef); # ''
reftype(undef); # undef
Because I took advantage of this, now I have to clean a bunch of undef warnings due to the change to reftype() (yes, basically have to, due to Moo/strictures).