This Week on p5p 2001/08/07

Aug 8, 2001 by Simon Cozens

Notes

Please send corrections and additions to perl-thisweek-YYYYMM@simon-cozens.org where YYYYMM is the current year and month. Changes and additions to the perl5-porters biographies are particularly welcome.

For the final time, this is a somewhat abridged summary, since I’m still on the road. This week is Washington and Philadelphia.

Subroutine Prototypes

Jeff Pinyan started the ball rolling with a collection of ideas he’d had on how to extend the subroutine prototype system. Strangely enough, these ended up looking more and more like regular expressions. Unfortunately, the discussion collapsed under the weight of its own complexity, as people suggested that the prototype for a subroutine which did something like split would have to be ((&($$?)?)?). Jarkko tried to focus the discussion away from operations such as repetition and grouping, and toward better type coercion - specifically, a generic reference-to-anything operation. (It was more or less agreed that this ought to be \.) Kurt Starsinic came up with a neat set of guidelines to aid thinking about prototypes; Chris Nandor complained that people were adding more incomprehensible line noise to Perl instead of taking it away.

Jeff did come up with a patch to make \? take a reference, so it would be easy to change that to \. - I don’t know if this has been done or integrated yet.

-Wall fixes

Well done to Richard Soderburg, who produced a set of neat patches which make Perl compile without warnings under -Wall on his platform, FreeBSD.

Paul Marquess noted that it would probably be handy to have Perl compile itself with -Wall but compile other extensions more loosely; Jarkko saw to it.

The Great SDK Debate

Tim Bunce kicked off the discussion on SDKs by pointing out two flaws in our treatment of SDK and module selection:

One was the understanding that we should select and include only _one_ module for any given area of functionality. Thereby forcing us into futile debates about which of several similar modules to include.

I see no problem with ‘lowering the bar’ of entry into an SDK. The requirements should be simply that the module: is reasonably useful; is reasonably well documented; the interface is reasonably stable. If that means we end up with an SDK with five different date modules, so what?

The other mistake was that we were trying to define ‘the’ (one) SDK. I’d rather see multiple SDKs (web centric, database centric, xml, net, etc). Sure they’ll be overlaps, but that’s a bonus not a problem.

He then asked that we start thinking about defining these multiple SDKs. Matt Sergeant added another mistake: that the creation of SDKs was too big a task for two or three individuals.

Kurt Starsinic asked why SDKs couldn’t be built on the Bundle model. Adam Turoff provided his notes from the P5P meeting at TPC:

The Bundle approach doesn’t capture versions of the included modules, just the module names. An SDK version must be in a Known Good State ™ and should be versioned itself.

Bundles don’t work because they’re a quick hack at a meta distribution. If someone downloads a 2K bundle file and goes offline, they don’t have all of the modules they need to install (and can’t throw that 2K bundle file around inside the firewall effectively). This says to me that an SDK needs to be a packaged version of a specific set of module distributions (compressed or not) that comprise a specific version of that SDK.

We probably want to take a page from the [x]emacs folks and keep the SDKs alongside the core distribution on CPAN and other such mirrors. There’s the core emacs source + about 3-5 groups of additional packages, and emacs-sumo which contains everything. Perhaps there’s room for perl-5.8-web-1.3.tar.gz alonside perl-5.8-win32-2.3.tar.gz, etc., which should be a simple matter of packaging at distribution time (and repackaging at SDK upgrade time).

There’s an unresolved issue with DLL Hell; if two modules include a common module (e.g. Date::Broken), SDK 1 may function with version 3.14, and SDK 2 may function with version 2.78, but both SDKs can’t be installed concurrently because of conflicting requirements with that common module.

John Peacock noted that we could solve some of these problems by either allowing multiple versions of a module to co-exist, or extending the use semantics to ask for precise versions.

Elaine came out in support of bundles, disagreeing with some of Adam’s points. (or rather, the points that Adam had summarized from the general discussion) Notably, bundles can require individual versions from individual modules.

Peter Scott said that we don’t have to care whether or not we make the modules somehow “harmonise” - so long as we reduce the set of version numbers that administrators have to worry about from, say, fifty individual modules down to five SDKs. Elaine disagreed that this is a good idea, as it reduces overall control from the administrator. The people who will care about which versions are installed now don’t get all the information, and those who don’t care still won’t care, so they’re not helped either.

Everyone’s agreed that we need SDKs, which is the main thing, but opinions differed on how to make one “official” and how to ensure that the user installs what they need. Isn’t that exactly where we were last week?

New Stuff!

Jarkko announced that we had a new port officially supported in the distribution - Perl now cross-compiles “out of the box” to WinCE. He also (finally) decided to merge Artur’s wonderful threads modules into core. Hoorah!

There’s also a new cool Configure feature of being able to tell it what additional modules you want to have downloaded and installed from CPAN - porters following bleadperl will see another question in the interactive run, or may specify -Dextras="..." to tell Configure which modules to get.

Various

Ilya’s “retirement” is looking more and more dubious as he again piped up with a bunch of patches this week, this time for h2xs. Gerrit Haase spend a while investigating upgrading fcrypt.c in Win32, but found that the version distributed with current versions of libdes already has the Perl patches folded in.

Doug McEachern fixed up a slew of weird threads bugs and other leaks, as usual. I made the optimizer pluggable - optimizer.pm is on CPAN, and lets you do Great Things.

Peter Prymmer produced some test harness cleanups, plus some Win32 build fixes. Thanks, Peter!

Jarkko asked if Storable should use B::Deparse to serialize code blocks. Casey West had already done that months ago, but nobody was listening. This just goes to show that if you do cool stuff for Perl, people might not listen the first time but they’ll come around to your way of thinking in the end.

Until next week I remain, your humble and obedient servant,

Simon Cozens