I like the Perl debugger a lot. I use it daily, since understanding code by seeing it execute is much better than guessing at what it does based on its API. I do however seldomly use the actual command line debugger module, but instead use the Perl debugger built into Komodo IDE because it streamlines a lot of the busywork that is necessitated by having a debugger bound to a terminal:
When I started Excel::Writer::XLSX I had, more or less, a clean slate to start with. So I chose to use perl 5.10.
It was mainly because I wanted to use the defined-or operator //. There were other reasons as well but Excel::Writer::XLSX is an API heavy module and, although it may sound trivial, defined-or saved me a lot of time.
I also wanted to use some of the other Modern Perl features. In fact I would really have liked to have used perl 5.14 but I thought that was probably a step too far.
Perl 5.10 isn't exactly new. It came out around the same time that Excel 2007 and the xlsx format came out. So, I thought that it was reasonable to use a recent perl for a module targeting a recent file format.
The talk submission process for YAPC::NA 2012 closes on March 15th. After that time we’ll finish building out the schedule with the talks that have been submitted. So if you’d like your talk considered, please submit it today.
The editor that came with MacOS Perl (for Mac OS 9 and below) was able to save your script as a droplet -- that is, an application that you could run by dropping files onto it. When your script got control, the paths to the dropped files were in @ARGV
Under Mac OS X you can get this functionality by wrapping your Perl script in an Apple Script. The following example assumes you want to wrap a Perl script named droplet.PL in an application called PerlDroplet. It works because a Mac OS X application bundle is simply a directory whose contents are known to the system.
Run the Script Editor, which is found in /Applications/AppleScript/
Paste the text of the Apple Script as it appears below into the editor.
Save the script as an Application Bundle named PerlDroplet.
Copy your Perl script to directory PerlDroplet.app/Contents/Resources/.
Yes, this will work if you move PerlDroplet somewhere else.
A while ago I did some comparison on serialization and logging modules, and I hope to do or see comparison on others. Here are some of them:
PID files. About a decade ago I wrote Proc::PID_File, including fork() handling, it does the job pretty well but I ended up abandoning it in favor of Proc::PID::File because I don't have time to maintain it and I hated the name. Turns out that there are several other modules pertaining to PID files like Piddy, Pid::File::Flock, IPC::PidStat, even Unix::PID (which is not recommended). The comparison article should discuss what issues surround managing PID files and also mention other means to detect program instances, like locking DATA filehandle (forgot which module does this).
INI files. Tried several INI modules in the past, not satisfied with any of them. Used Config::IniFiles in the end, but recently wrote another implementation (unfinished). A comparison article could be helpful.
Command-line-argument processing. Have always used Getopt::Long, heavily used App::Options a few years ago, now settling with my own module. Recently there have been some new development efforts like MooseX::GetOpt, Moo::Getopt, and App::Rad.
As a few of my previous posts have implied, I am attempting to reinvigorate the Zoidberg Perl shell. Much of the work of getting it back to a functional state has already been done at my GitHub repo. I have a bigger post coming on why this is cool and even another with some examples, but for now I have a question:
Is an AutoSplit/AutoLoader mechanism helpful on modern hardware? I mean Moose/MOP (and many other projects) are huge and doesn’t use it. In fact it seems that very few modules depend on it.
Now, I understand that AutoLoader has some cool uses for causing subs to spring into existance. In the context of Zoidberg, though, I only care about its use to defer loading infrequently used subs.
To test some things, I created a branch in which I naively removed these bits, and lo and behold, with only one missing my (see AutoLoader Considered Harmful), the tests all pass and a quick run seems fine.
So I fairly call the question: should I leave AutoLoader in, or pull it?
brian d foy will be giving a talk at YAPC::NA 2012 described as:
A modulino is a module that also can act like a script. This talk explores how a typical command-line invocation of the script, with switches and standard input and output, can connect with a module’s interface without sacrificing flexibility.
Since I’ve never used MT before I signed up to blogs.perl.org, it’s only recently that I found that MT does have some spam settings, which unfortunately are not turned on or default to the most conservative value. Along with other settings, you can reduce the number of spam comments being posted/notified to you.
You can increase spam detection aggressiveness (Preferences → Spam). By default this is set to 0 which allows many spams to pass through. I set this now to 5 which seems to be okay (so far only 2 spams after a couple of days).
You can disallow anonymous comments (Preferences → Comments → Setup Registration) or at least require email verification. By default anonymous comments are turned on and email verification is not required.
You can use CAPTCHA! (Preferences → Comments). By default this is off, and unfortunately when I tried to turn it on (either using MT’s own CAPTCHA or reCaptcha), no image is displayed and yet all comments got rejected with the message “Text entered is not correct”. I guess this is currently a bug.
I noticed today that my firefox has been really slow lately.
I use a firefox plugin named
vimperator
which provides vim-like keybindings for firefox.
I have it configured it to store 5000 command history entries, which is considerably more than the default (500).
It has always been in the back of my mind that this might come back to bite me one day.
So today I decided to check how many entries have so far been saved in the history file.
I easily found that the history is stored in a json file located at ~/.vimperator/info/default/history-command.
Running wc (word count) wouldn't help because all the data is stored on one line.
I noticed that the file simply contains a serialized json array.
To determine the size of this array, I used
App::p
and whipped up this simple one-liner:
Steffen Mueller will give a talk at YAPC::NA 2012 described as:
Booking.com is the world’s leading online travel agent for hotel reservations. It is a wildly successful enterprise that was built with Perl at its heart. The company’s IT team runs millions of lines of Perl code on thousands of servers.
In this presentation, we will outline how we migrate(d) one of the world’s biggest users of Perl across 14 stable releases of Perl from 5.8.5 to 5.14.2, why we did that, what bit us, and what we learned from it.
One of the common gotchas with Test::NoWarnings is that the warnings are collected up and displayed in one go at the end of the script.
While this is strictly speaking the correct time to show them and has the least likelihood to result in a collision with some other test module resulting in an explosion, it makes debugging test scripts much more difficult.
Since I took over Test::NoWarnings a number of people have asked me to “fix” this problem.
After much thought, I’ve decided to leave Test::NoWarnings default behaviour the way it is and show everything at the end.
Instead I’ve added a specific debugging aid in the form of an :early pragma.
use Test::NoWarnings 1.04 ':early';
The :early pragma explicitly turns on emitting warnings at the time they occur instead of gathering them until the end.
GitHub is a great place to host open-source projects and expose them to a wide community of developers, so it's not surprising that more and more Perl modules are making it their home.
One of the features of GitHub is that it checks if a repository has a README file in its root directory, and displays it on the home page of the repository. This makes the README file a good place to introduce your project to the public.
GitHub also understands a number of markup languages, such as Markdown and Textile, and if the README file is in one of these formats, it will be transformed into nicely formatted HTML. One of the supported formats is POD, which means that the standard documentation of a Perl module can be used as its README file and serve as the repository's home page (much like on CPAN).
This is the first of a series of posts that will detail
a Marpa-based "Ruby Slippers"
approach to parsing liberal
and defective HTML.
As an example, let's look at a
few lines
taken more or less at random
from the middle
of the perl.org
landing page.
That page is exactly 400 lines long.
Here is line 200 and some lines
lines to either side of it.
</td>
<td>
<div class="module">
<a href="http://www.perlfoundation.org/">
<img alt=""
src="http://mc-cdn.pimg.net/images/icons/onion.vee5cb98.png"
width="45" height="45" />
</a>
<h4>
<a href="http://www.perlfoundation.org/">The Perl Foundation</a>
</h4>
<p>
The Perl Foundation is dedicated to the advancement
of the Perl programming language through open discussion,
collaboration, design, and code.
For readability, I've rearranged
the whitespace, but otherwise the above is untouched.
My more-or-less-random extract is part of a table, and captures the
end tag of one cell and the beginning of another.
Now that Perl's builtin functions can directly operate on hashrefs and arrayrefs (I'm already starting to dread having to write push @{$foo->{bar}} instead of just push $foo->{bar}, but I'll be stuck with 5.10 for at least a couple more years), it chuckles me a bit imagining a future where beginners only use and know about scalars, and not arrays/hashes. Where they just need to memorize $ as the variable prefix. And where % and @ are nowhere to be found in baby Perl.
Among the issues with this would include the many special variables like @_, @INC and %INC, %ENV, %SIG and so on. We can provide some abstraction like self or MooseX::Declare for @_. With Moose et al, we already don't need to muck with @ISA directly.
Another would be list assignment, but I don't think beginners use it much.
Wouldn't it be cute? Albeit a bit pointless maybe. I can do away with context in Perl, but for now I like being able to have $thing, @thing, and %thing at the same time. Or do I?
A very tiny handful of you may know that I was trying to push YAPC::Cuba. Later I expanded the idea to be a more general open source conference in Cuba as that would likely be a better fit. Sadly, it appears that it's not to be (or at least, not to be through me). There was a fair amount of excitement at the idea from those I spoke with. Quite a few said they wanted to be involved and would contribute time and effort to it, but as is often the case with volunteers, time is at a premium and dedicating volunteer time to a long-shot opportunity is understandably low on their priority list.
And of those who I spoke with who said they wouldn't attend? They were invariably not US citizens. They expressed concern about repercussions from the US government for attending a conference they were legally allowed to attend.
Isn't that sad? People are afraid of the US and it kills the chance to have an interesting conference at a time when it seems perfect for Cuba and the world to be talking.
Net::SSH2 (ssh client library based off libssh2) now has agent support, something that i've been wanting for a while and had just sat down to write. Very happy it had already been done! Thanks fellas!
