Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

DAxelrod (4649)

DAxelrod
  (email not shown publicly)

I'm interested in hard problems.

Recently, I've started thinking a lot about what CP6AN might look like.

Class::MOP and the Perl 6 Metamodel make me more excited than I'd like to admit.

Also expect occasional wordy technology-related rantings.

Journal of DAxelrod (4649)

Friday October 06, 2006
09:06 AM

Which win32 perl flavor?

Unfortunately, even the best of us are sometimes forced to use Windows.

Which perl would you recommend on Windows for somebody doing development work in Perl? I'm unlikely to be writing XS, although I might need XS modules. Note that this will not be running production software, so I don't need something stable as in Debian-stable.

Perl under Cygwin? ActiveState? Vanilla? Strawberry? Something else completely?

Tuesday October 03, 2006
11:53 AM

OT: I <3 NJ

My reaction to this:

A while ago...
NJ Legislator 1: So, if we count that pile of dollar bills three times, it means we have more money!
NJ Legislator 2: But we don't have more money, we've just counted wrong.
NJL1: Not "wrong". Differently!
NJL2: Uh, you think the public will fall for that?
NJL1: Sure! Even though they dump a huge percent of their high property taxes into schools, they don't know enough math to catch it, and they don't have enough civic responsibility to care!

Later...
McGreevy: I'm a Gay American.
NJ: Dude, it's 2004. No one cares if you're having orgies with midgets and Koala bears.
McGreevy: And while your heart is bleeding for me, the powerless repressed minority who, uh, holds most powerful office in the state...
NJ: Sigh. What?
McGreevy: I've been funnelling large amounts of your tax dollars to my lover! But buy my book about it!
NJ: Dammit! Get out of office!
McGreevy: I can see you're not yet tolerant enough to accept me. Fine. I'll step down. In a few months. Buy my book.
Interim Governor: You didn't elect me, but I actually don't suck! Democracy works!

Later...
NJ Supreme Court: Hey, Legislature?
NJ Legislature: What is it? Want more caviar or bling?
NJSC: No. Listen, you gotta stop this crazy accounting crap.
NJ Legislature: Uh, sure thing. It'll take effect after we're all out of office and our predecesors will have to deal with the fallout.
NJSC: Sorry. Come up with a non-fantasy budget before you adjourn for the summer.
NJL: Aww, but I was just about to ship off to Aruba on taxpayer dollars!
New Governor: No. I'm locking you in the freakin' building until you come up with a budget.

Now...
NJ Legislature: Ok, everybody. We're raising taxes-
Public: -We don't have to pump our own gas now, do we?
NJL: No. Nobody even mentioned that.
Public: Well, it always comes up whenever anybody talks about New Jersey.
NJL: Listen, we're also making you pay for media downloads and shipping and handling. That'll mostly affect younger citizens.
18 Year Old NJ Citizen: Dammit! If I cared enough to vote, I would so get rid of this government!
McGreevy: Buy my book!
Citizen: No. I'd have to pay taxes on shipping and handling.

DISCLAIMER
Facts have been bent for humor's sake. Feel free to correct me in the comments.

Saturday September 16, 2006
01:53 PM

Testing Installed Modules: Opening a Can of Worms

Ovid recently asked what should be a simple question: How should we install tests along with modules?

Of course, this is not a simple question at all and breaks down into several distinct problems. The first is actually "How do we test an installed module?"

kwilliams responded with the brilliant idea of a Module::Build retest action, that would look for modules in @INC instead of blib.

Unfortunately, this doesn't completely solve our first problem.

Why? Because way too many tests are written with the assumption that they will be running from within an unpacked module distribution. Which means they require context outside of the installed .pm files.

Off the top of my head, the kinds of tests that have this problem include

  • Tests that pull in specific files from the distribution
    • Tests that pull in test modules not in blib
    • Tests for scripts installed with the module
    • Tests that pull in data files (which may end up being installed)
  • Tests that depend on the whole distro structure
    • Test::Signature
    • Test::Distribution
    • Test::Pod
    • Test::Pod::Coverage
    • tests that rely on the MANIFEST
    • tests that scan files for spelling errors, minimum versions, or prereqs

You could argue that any of these that are abstracted into Test::Whatever modules have enough of a layer of indirection to account for however you test installed modules. But I think that misses the point. A list that large is not evidence of special cases. It's evidence that it's important for tests to have more than the .pm alone.

One solution that sucks could be a way of marking which tests assume they're being run in a distribution and which ones don't care. That would be horribly tedious.

Maybe this is evidence that we need a metadata database to go with our installed modules. We already have a PACKLIST that sorta kinda serves as an installed module database. The problem is, now we need an API for tests to query that database.

Maybe we're going about this wrong. Tests need a distribution. Modules work in a distribution and out of a distribution. It's common to develop modules inside a distribution.

Why not install an entire module distribution?

Have a lib-like directory which is searched for entire distributions rather than just .pm files. When you use a module, it will actually be pulled from its distribution.

Running modules from within distributions? Doesn't that sound like PAR?

Tuesday September 12, 2006
05:29 PM

OT: Law is not Code

I've read several times now that computer geeks don't usually take the same approach to law as, say, lawyers. For example Eben Moglen characterized this as "the hacker belief that laws are form of code that are executed without errors or ambiguities." EDIT: Alias rightly points out that this is a strawman. I think a statement closer to what I'm getting at might be "the hacker belief that laws are a form of code that are intended to be executed without errors or ambiguities". End Edit

I'm starting to see why that might be the case.

Something that fascinates me is how the US Supreme Court has bootstrapped itself into its current role. (Basically, for those unfamiliar, a lot of what the US Supreme Court does is issue rulings on whether various laws are constitutional or not (unconstitutional laws are nullified), but the Constitution does not explicitly give the Court this power.)

It ocurred to me that the only reason the Court uses precendent in its decisions is precedent.

How's that for circular logic?

Yes, I am aware that if they completely decided to drop precedent, it would most likely cause other branches of the government and citizens to take actions that would undermine the court. That's beside the point here.

Sunday August 13, 2006
10:16 PM

Traits Paper Moved

You know the Traits Paper everyone seems to be talking about? The URL a lot of them point to no longer contains the paper.

So, for future reference, the Traits Paper is actually

Nathanael Schärli, Stéphane Ducasse, Oscar Nierstrasz and Andrew Black, "Traits: Composable Units of Behavior", Proceedings ECOOP 2003 (European Conference on Object-Oriented Programming), LNCS, vol. 2743, Springer Verlag, July 2003, pp. 248-274.

and its URL is now http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf.

Chopping off part of the URL reveals the website of the Software Composition Group at the University of Berne, who seem to have written several more awesome papers.

Sunday August 06, 2006
09:23 PM

No, wait! I come in peace!

[ #30547 ]

Let me make a few things clear about what I said in my previous entry.

What I'd like to do is step back, take a look at what we have, and try to figure out where to go from here. I'm not planning to start a new CPAN or anything.

I'm also not going to write a bunch of decrees about what I think other people should do. I'm hoping to be able to gain enough of an understanding of what the various projects around the CPAN infrastructure are so I can figure out how I can help. Another important part of this is that I'm not trying to piss people off. Shake up their assumptions a little, maybe, but not piss them off. That said, keep the criticism coming. Just please don't dismiss me outright based on what I've said so far.

If you like, the better way to see what I'm trying to do is that I'm doing research, forming some oppinions, and asking others whether these oppinions are crazy. Then I'll work from there.

And don't worry, I don't want to break backward compatibility. But I'm curious what the design possibilities might look like if we didn't take backward compatibility for granted.

Saturday August 05, 2006
10:03 AM

A CPAN Revolution

Incremental, backward-compatible change has its place. But sometimes it's good to be able to break your ties with the past and change how you look at things.

I've become convinced that we need to do this with CPAN.

Don't get me wrong, the CPAN is not only wonderful, it's one of Perl's best strengths. That doesn't mean we can't make it much, much better.

Ok, so what do I mean when I say CPAN? I'm referring to a lot of different things.

  • Module packaging (including metadata and versioning)
  • Installation mechanisms for modules
  • Package managers
  • Package repositories
  • Specification of dependencies
  • Interfaces, both APIs and UIs
  • Probably some other things I've forgotten

It would be a benefit to look not only at our own past, but the accomplishments of other people solving similar problems. There are plenty of packaging systems, library management technologies, etc. and in the great Perl tradition, we should steal as many of their good design ideas as possible.

Step one is to come up with some sort of spec. Step zero is research. What have we designed? What have others designed? What are our needs?

It's going to be an exciting ride.