This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

Perl6 Summary for the week ending 20020728

Better late than never, it's the return of Piers Cawley's Perl 6 summaries. First I'd like to thank the very lovely, and worthwhile Leon Brocard for his excellent job of producing last week's summary. Any suggestion that I only asked him to do the job because it made the job of mentioning his name that much easier this week will be laughed at.

The Perl Conference

Last week saw the 6th O'Reilly Perl Conference. I wasn't there and am only slightly jealous. As well as producing parodies of the Apple Switch ads and other amusing things, people talked about useful and interesting stuff, including Perl 6 and Parrot. Sadly there are no switch/parrot or switch/perl6 spoof ads. Yet. However, Leon Brocard has made the slides from his `Targeting Parrot' talk available. Leon is particularly proud of the typography, apparently.

astray.com

Apart from the conference, most of the Perl 6 action has been in perl6-internals, so we'll start there.

Keyed Access

Scott Walters thought that "Keys are not needed." and claimed that they were a premature optimisation which should be done away with to prevent ugliness. Dan pointed out that Scott had missed the important case where data was inherently multi-dimensional. Josef Höök had a dream about morph chains and caching. Scott pressed his case once more and Dan replied pointing out a few misapprehensions on Scott's part and generally mounting a sturdy defence of the status quo, which caused an outbreak of agreement and general understanding. Scott patched up docs/vtables.pod to incorporate the information in this thread. Yay Scott! He then implemented multilevel key lookup for arrays. Double yay Scott!

Meanwhile, over in a side thread, Ashley Winters proposed `ParrotTuple' as a possibly useful PMC, Leon Brocard concurred, suggesting that, because it should be a relatively simple PMC to implement it'd make a great learning project (and, potentially, a great teaching project once it was implemented). Aldo Calpini and Stephen Rawls both volunteered to have a crack at it.

Whilst we shouldn't poke fun, the suggestion that Parrot's opcode dispatch takes 'non-finite time' did make me smile.

Dan promises a better spec for multi level keyed access as soon has he finishes the TPC talk slides.

Quote of the thread: "Generality and elegance are nice, but the point is to go faster" -- Dan Sugalski

Hashing PMCs

Note: Piers Cawley is me. I'll stick to referring to myself in the third person when discussing my posts to the mailing lists. Piers does not do Cerebus the Aardvark imitations all the time.

Anyhoo, Alberto Manuel Brandão Simões (who I will be calling `Alberto' for the rest of the summary) made some suggestions about the implementation of hashing of PMCs in Parrot. Dan said that we should add an `id' method to the basic PMC vtable, and it should return an INTVAL. Nicholas Clark suggested that maybe it'd be better to return an unsigned value and Piers Cawley suggested that, if we were going to call it `id' then it should return a guaranteed globally unique value. Brent Dax suggested that, whatever it was called it should return a string, giving new Math::BigFloat('3.1415926535897932384626433832795'); as his telling example. Alberto reckoned that, if @a = (1,2,3) and @b = (1,2,3) then @a.hash == @b.hash should hold. Piers disagreed and commented that languages like scheme have two or three different equality/equivalence operators to deal with this sort of thing. Dan agreed with him.

GC Speedup

Mike Lambert has committed some changes to Parrot's Garbage Collector that give an 8% performance improvement on the GC heavy tests in examples/benchmarks. Yay Mike! Peter Gibbs pointed out that we're still a lot slower than pre 0.0.7 versions of Parrot. The delay appears to have been introduced because of the `addition of stack-walk code to avoid child collection', which is apparently required to handle exceptions cleanly. Nicholas Clark wondered if we couldn't avoid the stack-walk and get a speedup if we're not calling any external code, but that would mean extra bookkeeping, which might slow things down again. Mike Lambert thought Nick's scheme might have merit and lamented the lack of `real world' parrot programs. But then, as he pointed out, what is a `real world' program? Mike also reflected on the mysteries and difficulties of tuning garbage collectors; the controls available appear to be somewhat complex and the trade offs are subtle and quick to anger. Mike is looking forward to tuning the GC against parrot code that's generated by Sean O'Rourke's perl6 compiler.

Regex bugfix and speedup

Angel Faus has been working on the parrot regex engine and submitted a patch that gives a substantial speedup with simple patterns. Nicholas Clark wondered about compiling perl 5 with regex optimisations turned off so we could compare the speeds of the basic engines without magic. Simon Cozens reckoned that this would be a pointless exercise. Nick restated his reasoning, and Simon then wondered if the current parrot regex engine was worth comparing against, and if it was well enough designed to cope with the rigours of Apocalypse 5 type patterns. Hugo van der Sanden thought that turning off the optimiser in perl 5 would not be easy, but he'd like to make it easier on the perl 5.9 track.

[PATCH] Reduce array.pmc keyed code

Mike Lambert offered a patch to get rid of some of the clutter in array.pmc and the resulting array.c by introducing a layer of indirection, and asked for comments. Scott Walters pointed at his earlier posts about refactoring the PMCs and suggested working together on the issue. And there was agreement. Nicholas Clark added his weight to this by pointing out that, in perl 6, being able to say "`this is an array of ints' and have them stored in sizeof(int)" has been blessed by Larry in one of the apocalypses.

Meanwhile, in perl6-language

Things were quiet, too quiet. The `Hashing PMCs' discussion took place partially in perl6-language, with crossposts back to perl6-internals. Otherwise not much was said.

David Nichol offered some cunning thoughts about perl in a distributed persistent world which looked interesting, and offered a possible macro definition syntax. Luke Palmer didn't like the syntax and wondered if David wasn't thinking too much in Perl 5.

In brief

We're still assuming that the minimum version of perl you need to build Parrot is 5.005, the eventual goal being to make the build self supporting using a `miniparrot' approach (I wonder if we'll call that `budgerigar' or `parakeet').

The mailing list archives are still not searchable (tell me about it), but Brent Dax points out that the ever wonderful Google has the site: keyword to do search restriction. I foresee a handy little autobookmark appearing on my galeon toolbar real soon now.

Steve Fink suggested that RECALL wasn't that good a name for Tanton Gibbs' proposed new preprocessor instruction because of the confusion between `recall' and `re-call', proposing REINVOKE, RE_CALL, CHAIN and the rather wonderful DOITOVERAGAINBUTDOITRIGHTTHISTIME(). Brent Dax suggested AGAIN (visions of the teletubbies as parrot programmers swam in at least one head). This particular bikeshed has now been painted AVOID.

Sean O'Rourke thinks there's a problem with find_method. Nobody else appears to have any thoughts. Warnock's Dilemma applies.

Aldo Calpini provided a short tutorial on submitting patches.

Simon Glover found a bug in parrot's file handling. Apparently the open opcode disagrees with read and write (from core.ops) about what a file handle should look like. Warnock's Dilemma applies.

Simon Cozens' head is exploding as he tries to make an inherently recursive operation into an iterative one.

Jonathan Sillito had a couple of questions about lexical scopes and scratchpads; apparently he has an implementation sketched out, but wanted some clarification. Melvin Smith is also working on something similar.

If you have a `Parrot' directory in your copy of the parrot source, you should probably get rid of it; it can be hard to make diffs otherwise, as Tanton Gibbs discovered.

Stephen Rawls has a problem; Spamassassin thinks his patches are spam.

Miguel de Icaza of Ximian popped up, via Simon Cozens, to point out that the mops test for C# wasn't quite comparing apples with apples because it was using 64 bit values and everything else was using 32 bit integers. Melvin Smith fixed it.

Brent Dax is on holiday 'til August the 3rd. Melvin Smith is supposed to be using the time to spread rumours about him and generally running amok through Brent's code. But he hasn't spread any rumours about Brent yet, though I heard that Brent's `holiday' was in fact a trip back to the factory for an oil change and to have his nuts tightened.

Melvin Smith things Array.pmc is broken and is going to apply some PerlArray.pmc fixes back to Array.pmc. Sean pointed out that there's some perl specific behaviour in PerlArray.pmc that shouldn't be ported.

Mike Lambert, bless him, asked if he could propose a `simply-phrased question?'. He had an IntArray in @P1 and a NumArray in @P2 how would he do the equivalent of S1 = P1[5] * P2[5]? He reckons the answer is trickier than it looks.

Sean O'Rourke wants more ops. As things stand there's no way to get to the vtable's cmp_num and cmp_string methods from parrot assembly. Which is bad. He offers a patch.

Patches

Stéphane Payrard wanted to play with Qt from parrot, but the sources didn't play well with C++. So he's offered a patch.

Alberto has some docs about various PMCs available at natura.di.uminho.pt

Alberto also offered a Boolean.pmc, but it wasn't accepted. However, it's nice, simple example of PMC implementation that may well repay a closer look if you're interested in that sort of thing.

Johnathan Sillito implemented an `invoke' op which calls an arbitrary vtable method. Applied.

Angel Faus offered a patch which `apparently makes the rx engine behave well with the GC'. Warnock's Dilemma applies.

The usleep portability I mentioned in my last summary appears to have been solved, but the patch hasn't been applied yet.

Andy Dougherty supplied a patch to eliminate 69 compilation warnings. Applied.

Sean O'Rourke has patched the perl6 compiler to work with perl 5.005_03.

Who's who in Perl6

  • Who are you?
  • Luke Palmer

  • What do you do for/with Perl 6?
  • I mainly discuss language design issues like the rest of the second-level folk. I occasionally answer questions about Perl 6 syntax, as I have been following very closely it's creation.

  • Where are you coming from?
  • Naturally, from a pathologically eclectic state of mind.

  • When do you think Perl 6 will be released?
  • I don't really care, because I will surely be long deceased before then. :)

  • Why are you doing this?
  • Because I love programming, I love Perl, and I love community projects.

  • You have 5 words. Describe yourself.
  • My slogan: Luke smokes Perl.

  • Do you have anything to declare?
  • Ha! Declarations are for structured programmers!

Acknowledgement, apologies and stuff

There are a few things different about this week's Perl 6 summary.

  • 1 It's late.
  • 2 There's no/very few links and URLs
  • 3 Did I mention that it's late?
  • 4 The grammar's probably even ropier than usual

Yes. I know. Last week was 'fun', for highly sarcastic values of fun. Hopefully net access, commute times and general time available to write summaries will be back to normal next week and you'll get a lovely, shiny, highly linked summary. I'm publishing this now -- without my usual level of proof reading -- only because I'm running so damned late.

Actually, feedback on this would be good; in general adding the links is the most time consuming and tedious part of writing the summaries, requiring a net connection and time to check the links. Which leads me to wonder if I can't write links as predictable google searches using the message-id. Time to experiment methinks.

As usual, if you liked the summary, send money to the perl foundation to help support the ongoing development of Perl 6. Or you could send me one of those shiny T?iBooks that all the cool kids were playing with at TPC. But that's just naked self interest on my part and I'm really writing summaries for love, kudos and egoboo.

Also, if you're involved, however peripherally in the Perl 6 development process, I'd really appreciate it if you'd answer the archive.develooper.com I posted. I'm still waiting for answers from Larry and Damian; Dan's answers will be forthcoming in 5 week's time (I'm publishing them in strict order of receipt).