|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
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.
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/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.
Apart from the conference, most of the Perl 6 action has been in perl6-internals, so we'll start there.
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
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
Math::BigFloat('3.1415926535897932384626433832795'); as his telling
example. Alberto reckoned that, if
@a = (1,2,3) and
@b = (1,2,3)
@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.
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.
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.
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.
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.
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
CHAIN and the rather wonderful
DOITOVERAGAINBUTDOITRIGHTTHISTIME(). Brent Dax suggested
(visions of the teletubbies as parrot programmers swam in at least one
head). This particular bikeshed has now been painted
Sean O'Rourke thinks there's a problem with
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
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 * P2? 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.
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.
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.
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.
Naturally, from a pathologically eclectic state of mind.
I don't really care, because I will surely be long deceased before then. :)
Because I love programming, I love Perl, and I love community projects.
My slogan: Luke smokes Perl.
Ha! Declarations are for structured programmers!
There are a few things different about this week's Perl 6 summary.
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).