use Perl

My raw footage for YAPC::NA 2006 was 1.2 TB. That's not feasible to upload.

As the volunteer who spent many hundreds of hours (and accidentally many thousands of dollars on bandwidth fees) I take GREAT offense at your suggestion of public humiliation. Perhaps I should insist on a similar clause if I submit a patch to Rakudo?

http://yapcna2006.equilibrious.net/2006-06-28.PatrickRMichaud/

http://yapcna2006.equilibrious.net/2006-06-28.PatrickRMichaud_Part2/

It's MUCH harder than you might think.

http://yapcna2006.equilibrious.net/2006-06-26.AdamKennedy/

http://yapcna2006.equilibrious.net/2006-06-28.AdamKennedy/

Lazyweb,

The following is a known bug that crashes Perl 5.10.0 (solved for 5.10.1 via Perl RT#52740)

perl -MCompress::Zlib -MDevel::Symdump -e'Devel::Symdump->rnew'

I continue to be amazed at how friendly you are in person.

True. Java is actually lucky in this area: it's trivial to embed an arbitrary file in a Jar file right next to the .class that uses it.

In the worst case, you can use templates for the generated code. That pulls the odd indentation out of the main code.

Code generation is OK if it's transient -- passed straight to a compiler and run. If instead it's written to disk as a template, then it's just formalized copy-and-paste, with all of the maintenance downsides.

The biggest drawback to runtime code generation is obscurity. It's opaque to static analysis and smat editors, and to most humans too.

This effect is very real, I think.

I saw a similar effect in Perl::Critic. When I first got commit, it seemed like Jeff took a short breather. When Elliot joined, I couldn't keep up with his energy and had to work just to keep up with the commit emails let alone the code. Now, I've been gone from P::C so long that I feel I'll have to relearn a lot just to make a contribution.

I had a related experience trying to contribute to Rakudo. I was trying to learn Parrot, Perl6 and Rakudo at the same time and the ground kept moving underneath me. That was exciting to watch, but hard to track, and I chose to set aside my own Perl6 work until a few more features were ready for me -- now it's been 8 months since I touched it...

The Planet project (the software behind Planet Perl, etc) went through this several times -- with the Jeff Waugh generation, the Scott James Remnant generation and the Sam Ruby generation. Each time the code changed dramatically for the better but most participants were just trying to keep up until the end of the burst of code, when the bug reports and patches and test cases started coming in. I think the bug reports do slow down the "alpha"

This effect happens even in commercial code, but it's much more muted there because developers have a fixed time budget instead of tuits, so there a smaller disparity between "alpha" and the masses.

::ProhibitCapsAndPunctuationInAuthorName

No, not NSLibraryDirectory. It's NSDocumentDirectory. From XCode docs:

NSSearchPathDirectory
These constants specify the location of a variety of directories.
 
typedef enum {
   NSApplicationDirectory = 1,
   NSDemoApplicationDirectory,
   NSDeveloperApplicationDirectory,
   NSAdminApplicationDirectory,
   NSLibraryDirectory,
   NSDeveloperDirectory,
   NSUserDirectory,
   NSDocumentationDirectory,
   NSDocumentDirectory,
   NSCoreServiceDirectory,
   NSDesktopDirectory = 12,
   NSCachesDirectory = 13,
   NSApplicationSupportDirectory = 14,
   NSDownloadsDirectory = 15,
   NSAllApplicationsDirectory = 100,
   NSAllLibrariesDirectory = 101
} NSSearchPathDirectory;

You're way off base on this one.

I've been using Mac for Perl dev for about 6-7 years (whenever OS X 10.1 came out) and consider it first class. The Mac:: packages are largely irrelevant -- Carbon is a legacy API from the 90s, about as relevant today as a Win95-specific API would be I suppose. If you used a Win95:: library, you'd get similar complaints from users of a modern Windows OS.

The "flood" of Win32:: packages is because you need those platform-specific hacks to get anything done on Windows Perl. Not so for Mac. Typically, anything I code on Mac builds of Perl works the same on Linux, which is certainly not the case for my Windows Perl experience (prior to Strawberry anyway). There is a lack of new Mac:: packages for the same reason that there is a lack of Linux:: packages.

And I even use Apple's build of Perl. It's certainly not abandoned. It works great. I hear they even bundled 5.10 on 10.6. Just stop using the legacy Mac:: modules and I predict things will get better. Apple probably just bundles those for the same reason that 5.10 bundles Switch.pm.

Wow! What a great extension! Thanks for the recommendation. This advice alone justifies my blog posting. :-)

Oh, you're right. Weird, I didn't know that Adobe restricted adding annotations. I usually use Apple's bundled Preview.app for annotating PDFs, so I'd never noticed.

I had misunderstood your comment about keys to mean that you needed a key to create a PDF application. Apologies for reading too fast.

Adobe is certainly not holding the keys tightly. The PDF specification has been wide open almost since the beginning. The problem is more that it's a huge specification and it takes a lot of work to get it right.

I'm the author of CAM::PDF, an open-source library for PDF manipulation. It's a pretty big library, but I only support the very basics of the PDF features. And I'd probably find that I averaged less than minimum wage if I divided the dollars earned on this product by the huge number of hours I've spent working on it.