Thanks to a catastrophic harddrive failure on my main workstation @ $work, the regularly scheduled PPM updates will be skipped this week. I've fired off new builds as we speak and all should be back on the regular schedule.
Sorry for any inconvenience, but it happens. At least I was able to recover 99.9% of the data on that disk, so it was all mainly a big waste of time.
I've finally got around to implementing something that had been on my todo list for way too long.
Feeds are now available for ppm updates from ppm.activestate.com
It's still pretty much beta and all, so expect things to possibly change around a bit, but do try it out and let me know if there is anything that could be improved.
I've recently been spending a lot of my time working on the upcoming PDK 7.0. There are still many things left to do before we are can reach a releasable state, but we are making progress. Most of my time so far has been spent on porting to OSX. It would have been very simple if not for this one very interesting Apple feature. With the whole switch to Intel and all, Apple has introduced (not really, they are a Mach-O feature from NeXT) Universal Binaries. Basically, it's a way to build an application that's capable of running on more than one platform. Intel vs. PowerPC in this case. When using Apple's XCode, generating binaries of that kind is very easy.
The first step on my roadmap was to build a version of the PDK where every single binary was a universal one. That was relatively easy to accomplish and simply required a little added build magic. It's been done, and it works just great. We will be able to ship a single version of PDK that will run/install on any Mac, good.
$> file perlapp perlapp: Mach-O universal binary with 2 architectures perlapp (for architecture ppc): Mach-O executable ppc perlapp (for architecture i386): Mach-O executable i386
Alright, so what does this have to do with PDK? Well, the PDK has a very cool tool, PerlApp, that allows you to produce native binaries from Perl scripts. So, wouldn't it be neat if you could take a Perl script on OSX PPC, use perlapp, and generate a Universal Binary out of it. Sounds like a natural feature to support. And that turned out to be more work than I thought.
Turns out that generating universal binaries is only part of the problem, the easy part. The hard part is that PPC/Intel differ in Endianness. So, when PerlApp generates the final executable that will contain your perl script (and all its dependencies), it generates something very similar to a zipfile to hold all these files in the generated executable. However, it turned out that for performance reasons, mainly, that code had multiple endianness issues that needed to be addressed. So, after many debugging sessions, a couple of segfaults, and various code changes, you now have:
$> bin/perlapp hello.pl PerlApp 6.9.90 dev build 268783 Created 'hello' $> file hello hello: Mach-O universal binary with 2 architectures hello (for architecture ppc): Mach-O executable ppc hello (for architecture i386): Mach-O executable i386 $> ./hello Hello World! $> scp hello osx-ppc-10-4: $> ssh osx-ppc-10-4 "./hello" Hello World!
This is only one of the pieces required for PDK 7.0, but it's a milestone I am very happy to have reached. Now, time to work on the rest of the planned features for OSX!
ActiveState has released ActivePerl 5.8.8.819. It includes quite a few new features, the main ones being:
And the neccessary screenshot of the PPM GUI:
ActiveState has released ActivePerl 5.8.8.817 today. It fixes a number of serious issues that have been found in the 816 release:
I'm happy to announce that we released ActivePerl 5.8.8.816 today. The main highlights over 5.8.7.815 are:
As usual, you can download it via the main ActivePerl page:
http://www.ActiveState.com/ActivePerl
Note that there is a separate link for downloading the 64 bit Beta versions.
Please send feedback to
activeperl-feedback
and report bugs at
bugs.ActiveState.com
I've appended the relevant section of the CHANGES-58.pod file to show some more detail on other changes from the previous release.
ActivePerl build 816, based on Perl 5.8.8.
Bug Fixes and Changes
On Mon Jan 16 14:37:47 PST 2006, ppm.activestate.com answered it's 2,000,000th search query since it was restarted a little while ago.
Why is this interesting at all? True, normally, our ppm servers answers millions of queries a month, so this particular milestone might not be impressive at all.
What makes this news interesting is that this milestone validate's the entirely new & rewritten server codebase running on ppm.activestate.com (Apache / mod_perl / mysql / SOAP-Lite). As the load on the ppm server kept increasing, it became clear that it needed a serious speed boost. So, I finally got around rewritting the server from scratch and deploy it on a brand new, shining server. It had a few hickups early on (my apologies to anybody that noticed) but these were quickly fixed.
So, I expect to now have more time in the future to make further improvements to this service. In the meantime, please, do enjoy a much faster ppm server!
Just a little while ago, I was asked to look into problems Komodo was having with remote mod_perl debugging. I followed the documentation and, indeed, I couldn't get it to work right away.
So, after a bit of fiddling around, here is what I've come up with. It works, and it's even simpler than what's in the documentation.
First, you'll need a little symlink (or copy) of perl5db.pl
$> cd [komodo]/lib/support/dbgp/perllib
$> mkdir Apache
$> cd Apache
$> ln -s ../perl5db.pl .
That's needed bacause later, we'll be using a module that needs Apache/perl5db.pl to exist.
Then, you need to install Apache::DB
$> cpan Apache::DB
Finally, you just need to add a small snippet to your httpd.conf
<Perl>
use lib qw([komodo]/lib/support/dbgp/perllib);
$ENV{PERLDB_OPTS} = 'RemotePort=localhost:32861 LogFile=stderr";
use Apache::DB ();
Apache::DB->init;
</Perl>
<Location />
PerlFixupHandler Apache::DB
</Location>
That's it! You only need to start your webserver in single-server mode and hit a page
* [komodo] == Base installation of your version of Komodo
The great folks of WebGUI.nl have recently invited me to give a few talks about mod_perl at their upcoming conference in Amsterdam.
My friend Geoff Young just returned from the American version of the WebGUI conference in Vegas, and he enjoyed himself quite a lot.
So, I've accepted their invitation, and I'll be giving a total of 4 talks, plus participate in a round-table event about WebGUI & mod_perl.
I'll be giving 2 talks that Geoff did plus 2 of my own. They are:
All in all, I am quite excited, having never been to the Netherlands, it's going to be a great opportunity to visit what I believe is a great European country.
Once again, thanks to the folks of WebGUI.nl!
After a long wait, it's finally official. Some of my talks have been accepted by the ApacheCon planning comitee. I guess the relentless bribing has finally paid off (kidding, no really, ...)
So, come December 10-14, I am going to be in San-Diego, and hopefully will have my slides all nice and ready by now...
I am going to give two talks. The first one will be an introductory talk on porting CGI scripts to mod_perl, titled From CGI to mod_perl, Fast!
The second one, somewhat more technical, will be about improving the performance of an existing mod_perl bases system. It's not about profiling as much as it is about benchmarking, performance measuring/monitoring and tuning. It'll be a fun talk to write up, since I've got tons of material and experience to build on. Just gotta pick the more usefull and straight-forward stuff. Oh, and it's called mod_perl for speed freaks.
It's been a while since I last talked at ApacheCon, so I am quite excited at the prospect. It's been way too long since I last got myself good speaking opportunities. I am hoping I'll be able to keep up the pace and talk at least 2-3 times a year for a while. I need to build up more material and get more practice.
