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 :)
This release continues down the path of improvements, bug fixes and translations. The changed release process seems to have improved the translations committed to Padre prior to release, which is a big win for Padre in the multilingual stakes. The efforts of the translators are greatly appreciated by the Padre team, and I'm sure all speakers of a language other than English when they see their Perl IDE of choice in their native language.
Working on a large project, and Padre is certainly that, you appreciate the efforts of those who contribute a lot and those who contribute a little, it all makes a big difference. What we don't always see is the persistence of some of the contributors to actually make a big difference in the ultimate release that makes it to CPAN.
I've had the pleasure of exchanging several
emails with Dave Rolsky, author of a
new OO tutorial on the subject of whether to introduce treating objects as the underlying hash reference.
He says he won't include even one example because
"it really doesn't send the right message. My revisions to perlobj will explain how to implement accessors using the object as a hash reference."
I was shocked, because I find I need to visualize my
object's data structures. Also, in several cases, reading
or writing attributes directly allows me to implement some
needed functionality.
I spent a good few hours today attempting to use the MailboxGUID returned from the WMI Exchange provider to search for the associated Active Directory account, using the msExchMailboxGuid attribute.
Here's two functions I came up with in the end. One to convert MailboxGUID to something that a search on msExchMailboxGuid will like:
We've decided we're gonna start releasing Dancer under codenames that relate to people who've worked on the release.
This release (1.3020) we've seen the continued (and blessed!) involvement of a one "Michael G. Schwern". To some of you he might just be a "mike" or "michael" (or perhaps "the schwern"), but none of us in the core knew Schwern personally before his involvement with Dancer, and this came as a very welcomed and pleasant surprise.
Considering the storm of issues and pull requests done by Schwern, we decided the next version should be named after him, hence "The Schwern Cometh". :)
The latest version is only a week-or-so of development but carries the following statistics:
6 contributors
6 bug fixes
12 features and enhancements
10+ issues closed
I really do see this as exceptional work. Other than Schwern I also want to thank Naveed Massjouni and Maurice Mengel for their contributions to this release (and any previous release!).
In the near future we'll also unveil the most elaborate hooks subsystem in the micro web framework world. I already know whose names will be splashes on that release. :)
If you're an existing CPAN Tester, and have recently upgraded LWP, you may have noticed that your report submissions have been failing. The reason being that LWP::UserAgent now requires that any https protocol request, needs to verify the certificate associated with it. With the Metabase having a self-signed certificate, this doesn't provide enough verification and so fails.
In the short term if you don't need to update LWP (libwww-perl), refrain from doing so for the time being. For those that have already done so, or have recently built test machines from a clean starting point, you will either need to wait until we have put a long term solution in place, or may wish to look at a solution from Douglas Wilson. Douglas has created a "hypothetical distribution", which you can see via a gist.
Others have also blogged about the problem, and have suggests and insights as to how to overcome this for the short term:
Paul Weller once sang of "a new direction. We want a reaction. Inflate creation." All three could be attributed to why two major events in the Perl event calendar started in 1999, and now happen all around the world today. The two events, The German Perl Workshop and YAPC::NA, both were a new direction for Perl events and specifically a reaction to more commercial events. They both also brought a new creativity to the Perl community.
In 2011 we now have YAPCs, Workshops and Hackathons happening on a monthly basis somewhere in the world. They are still very much organised by members of the Perl Community, and bring together a diverse group of people to each event. They often inspire some to create Perl events themselves. However, that initial enthusiasm is often quickly followed by panic, when the organisers start to figure out what they need to do to make a great event. Which is where a book might help.
The first two posts dealt with tests at the unit and class level. At the package/module level I was able to test the output of Excel::Writer::XLSX against files generated by Excel.
The "Whatever-Star" was at first alarming to me! I first noticed it when I learned how to shuffle an entire list. The Whatever-Star can do some other stuff, too. But that's ok, we'll start with this.
my @shuffled = < alice bob carol dave erik frank >.pick(*);
Now... in the past I've tried ".pick(1)" which gets me one name at random. Then ".pick(2)" will give me two, and not repeat. If I put in too many then it'll only give me back what it can, in this case all six names. But ".pick(*)" ... that doesn't even look valid! The documentation says (though I can't recall where) that it is the same as ".pick(Inf)". When I picked more than there were, it stopped when there was nothing to pick. So this makes sense... try to pick an infinite number and we'll just get them all. Nice. Still kinda weird about the '*' though.
