gogod's perlbrew module allows one to perform some simple admin tasks so you don't need to have root access. After having installed it a few times over the last couple versions, I created a quick script to install and run the init on installation.
The output of the install contains all the info you need. (I guess this also adds a dependency of not only curl for installation but also grep and tee but they are found on most *nixs anyway.)
curl -L http://xrl.us/perlbrewinstall | \
sh | \
tee perlbrew_install.log | \
grep "bin/perlbrew init" | \
sh > perlbrew_init.log
In the future, watch for blogs entries as I attempt to create a development environment for perl on HudsonJenkins.
Stricture helps me catch some typos by requiring predeclaration of variables (e.g. using the lexical my()). But it doesn't warn me about my stupidity. In this month alone, I have been bitten by two episodes of sloppy refactoring, where I left an extra 'my' on an inner block, something like:
my $foo = blah();
...
for (...) {
my $foo = ...;
...
# we lost what we've done to the inner $foo
}
Of course, -w and 'use strict' didn't help me here. -w only warns about the second 'my' if done in the same scope. And so around half an hour were spent chasing these two silent bugs. I guess a critic policy could be written for this sort of thing, e.g. forbidding two lexical declaration inside the same sub. And discipline yourself to keep paragraphs of code relatively short.
I am as much a Javascript developer as a Perl developer, and that is primarily because of the striking similarities the languages share, one of the most useful of which is the concept of closures.
Having private(hidden) data, and public accessors/mutators has always been one of the key reasons people use the object oriented paradigm. Perl however, being the flexible language that it is, does not provide any direct way to hide the data in your objects. One of the solutions to this problem is inside-out objects (and I think it is a very elegant solution too.)
But, when I want to write lesser code, and don't really want to use all of Perl's OO functionality, I simply use closures.
Here's how,
Exporting can be achieved through several routes. You can do it manually through typeglob manipulation, or you can use one of several modules that do it for you. One of the most proliferated, and common is the Exporter.pm module. More recently there have been some advances in the form of Sub::Exporter and similar improved exporting tools.
Exporter.pm is good in that it has a simple interface, is found in any perl installation, and is proven to get the job done. On the other hand it shows it's age; You specify exports in a package variable, and it can be difficult to work in custom import() logic.
Node programming is really interesting since makes possible to realize
a program even if you have no idea about programming.
Think about genetic researchers, for example.
They need to focus on protein chains, not on what is a package.
Maybe they can do an extra effort and say the world "variable" or "string"
or even "regular expression" and that makes them proud, but they don't care about inheritance.
They want things working and they need Perl ...
but if you say Strawberry they think about yogurth, not about Windows.
There are a lot of visual programming languages (VVVV, Puredata, Max/Msp)
but normally they target artists and interaction designers.
I saw a lot of vjs and musicians do really complex programs
with those softwares, and they never wrote a line of code.
This is my effort to provide a node interface that brings Perl power
to people who don't know the Perl language.
It is called PNI and stands for Perl Node Interface: it is at a very early stage but I would like to share it with this great community as well .
Any feedback/help is welcome, point your browser to PNI blog for more info .
We've just accepted our third round of talks for YAPC::NA::2011 in Asheville, NC! As always, just because your talk has not been accepted yet it does not mean that it will not be.
This also marks the last of our early acceptances. You now have just seven days to submit a talk for YAPC::NA::2011. We have roughly half of the talks we need, so please start submitting everything you can think of (toss rubber band airplanes around an auditorium, tell tales of undead email messages haunting your family, anything!).
I've just released a new version of WWW::Mechanize::Firefox, appropriating a new function of WWW::Mechanize, ->click_button. I used that occassion to also change the XPath queries sent by W:M:F to Firefox to be somewhat slimmer by changing queries for the element type from a global "OR" to a local test for the node name:
The old query to look for a <BUTTON> or <INPUT type="submit"> was
//button
|
//input[@type = "submit" ]
The new query is
//*[local-name(.) = "button" or (local-name(.) = "input" and @type="submit")]
If you're like me, over the years you'll have had your todo lists scattered over multiple programs and places. First a simple text file with homebrewn format, then various Windows programs, then various Linux GUI programs, then back to Notepad and joe/gedit/kate, then various apps on cellphones, then pencil & paper (due to cellphones keep getting lost/stolen), then some cloud apps, then todo.txt, then finally org-mode. And if you're anything like me or many others, you'll find that org-mode is *it*.
I'm now in the (long, boring) process of consolidating everything in Org. For todo lists, contact lists, and even long documents and all journals/diaries. I've written a preliminary version of Org::Parser to help automate stuffs via the command line. It only supports the basic stuffs at the moment but has been able to parse all my *.org files.
Marpa's core algorithm does no system calls.
It is almost 100% pointer twiddling.
There is no floating point, and very little integer arithmetic.
It's as if it was made to order to show C in its very best light.
I expected converting the Perl implementation
to C to improve speed by two orders of magnitude,
and first results are close -- the speedup for the code
converted to C is 95 to 1.
The code converted to C remains wrappered in Perl.
The Perl wrapper handles the I/O,
the user interface, and roughly the last third of the core algorithm.
This last part of the core algorithm I have yet to rewrite in C.
When I moved from OpenBSD to FreeBSD a year ago, I also had to move the email being handled by my server. As things were a bit different, I added a "Just-in-case" MailDir for one of my users so that no matter what else happened to the rest of their procmailrc, they'd have a backup copy.
Flash forward a year.
Yeah, you guessed it... we never turned that off. It's been accumulating spam at the rate of a few messages a second. For a year. I couldn't figure out why my 80GB of freespace a year ago was now dangerously under 15GB.
The MailDir/new directory was 2.5GB. Not the contents. The directory itself! I tried an "ls", realizing after a few minutes that ls would want to load the entire list of names into memory, then sort them, then dump out. Ouch.
I'm still blogging five days a week, but obviously not here. That's largely because my new daughter is forcing me to choose where I spend my time and I can't blog too much about what I do lest I reveal trade secrets. So, just to keep my hand in, here's an ugly little "80% hack" that lets me find bugs like mad in OO code. I should really combine this with my warnings::unused hack and start building up a tool find find issues in legacy code.
A goal of the MyCPAN work was to start with an existing Perl distribution and work backward to the MiniCPAN that would re-install the same thing. I hadn't had time to work on that part of the project until this month.
The first step I've had for awhile. I've created a database of any information I can collect about a file in the 150,000 distributions on BackPAN. There are about 3,000,000 candidate Perl module or script files. That includes basics such as MD5 digest of the file, the file size, the Perl packages declared in the file, and the package versions.
The next step is what I've been doing this week: collect the same information on the files in a Perl installation, which is much easier to do. There's not wacky distribution stuff involved.
I had always been interested in writing a simple LISP interpreter. Well, had some free time today, and thought, why not create a parser that can return the results of mathematical expressions that are entered as LISP expressions. Nothing fancy, but here is a class that can take in a file containing math expressions and return the results of each line as an array.
John Carmack, co-founder of id Software: "I actually think that Direct3D is a rather better API today. ... Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns. Direct3D handles multi-threading better, and newer versions manage state better."
Also from article: "While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, they usually have to be implemented via extensions, rather than the main API.".
It also serves to de-couple dependency checking and the workflow execution engine from the rest of your program (with the caveat that your program may need to interpret the output from make(1).)
(And if you squint hard enough, make(1) appears to have the sequencing property of a monad.)
Seth Godin has an interesting take on "____ is dead" in his blog post, "Bring me stuff that's dead, please". To paraphrase him, no real work is done until an innovation is dead. So the next time you hear that Perl is dead, just laugh it off and get back to work. I know that I will.
I've written a couple articles on encapsulation
issues in perl OO, especially with regards to
home-grown versus full-framework OO.
I am told that finding my own solutions to
get the behavior I want may lead to poor
(dirty, unreliable) code when a better solution
could come through a framework such as Moose.
I rolled my own perl OO for Nama, a multitrack audio recording app I've written. However,
I'm ready to consider introducing an OO framework for the
sake of learning, code quality, testing and maintenance.
Provided that I can find satisfactory ways to solve my problems.
Here's a laundry list of (just two) OO features that I'd
need or want to implement in a Mooselike framework.
One is short and simple to describe, the other will
take several paragraphs.
By far my most popular module on CPAN has to be Facebook::Graph, and this is an interesting week for Facebook::Graph, so I thought I'd post a little blog about it.
For anyone who may have been affacted by the upgrade to LWP, the situation should now be resolved. David has put in place a 3rd party verified SSL certificate on the Metabase server, so all submissions should now be able to resolve certificate authenticity.
If you have implemented any short term fixes, you may need to remove them, before accepting the new certificate.
We now return you to your scheduled programming :)
