| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
The story so far... Larry, Tom, Randal, Damian, Jon, Chip, Gnat, Ziggy, Dick and the rest of the gang were chatting with all the other cool Perl kids about where Perl was and should be going. Then Jon threw a coffee cup and the rest is history...
So, as is now traditional, we'll kick off with the goings on in perl6-internals. Confused? You will be after this week's summary.
Jonathan Sillito harrassed Dan about subroutines, continuations and
and other things to do with function calls. He wondered if his
scratchpad.pmc patch fitted what Dan had in mind, and added a few
supplementary questions. Dan answered the supplementary questions and
apologised for not having done the docs on this bit of the design,
saying he'd try and get it out by the end of the week. Melvin Smith
(whose code was involved in some of the questions) also gave some
answers.
groups.google.com -- Questions
groups.google.com[63.120.19.221] -- Answers.
groups.google.com -- More answers
Last week Dan threw down the 'full perl 6 regex engine' gauntlet, and this week Sean "Hero" O'Rourke admitted that he was working on it and that he already had a good chunk of it working. Apparently hypothetical variables and the various cut operators are looking a little tricky. Dan was impressed. Simon Cozens told us that, when he said he'd written a Perl 6 regex parser before breakfast at YAPC, he hadn't been joking, and that he'd put it up in his CVS if people want to poke at it. But the crowd was strangely silent.
Steve Fink also had some questions to ask about the regex engine.
groups.google.com[63.120.19.221]
Mike Lambert has re-added the GC_DEBUG define. The idea behind this is to allow `various limits and settings and logic to be setup such that GC bugs occur relatively soon after the offending code.' and generally to let you write relatively simple code that will trip the kind of bugs that are normally only seen when running complex code. Mike also listed the areas where he knows there are still problems.
Various people have had problems using GC_DEBUG, including at least
one instance where <end> threw a segfault, but it also drew a
flurry of patches from Jason Gloudon and Steve Fink. Much of the
discussion in this thread was rather more technical than I have the
skills to summarize, so I'll just point you at the root node.
Joseph Ryan did some regex optimization in assemble.pl to speed up the
matching of strings. For some reason, this kicked off the longest
thread of the week, about the merits of optimizing a pure perl
assembler when we should really do it in C if we really wanted
speed. Or maybe we should implement the assembler in Parrot
proper. And wouldn't it be cool if we could write self modifying code
in Parrot (needed for eval, Dan's working on a design). Juergen
Boemmels spotted that the patch didn't quite work as promised and
provided a better version, but I don't think it's been applied.
Tom Hughes wondered about the semantics of indexing PerlArrays with strings and PerlHashes with integers. He and Dan discussed it back and forth for a while, and then Tom posted a patch, which Dan liked the look of, but held off on applying while everyone else had a good look. Mike Lambert had a look and raised some issues, which Tom addressed and issued another, enormous patch.
Jerome Quelin has been having some problems with file I/O under parrot 0.0.7. The consensus seems to be that the current Parrot I/O system is, ahem, not as good as it could be, mostly because people have had other priorities. Dan asked for a volunteer to help `get I/O off of Melvin's altogether too-full plate before his wife hunts [Dan] down and does nasty things'. Clinton Pierce seems to have stepped up to handle part of what Dan wants. Well done that man.
groups.google.com[63.120.19.221]
Leopold Toetsch found something confusing in the perl 6 compiler which ends up generating some unexpected byte code. Peter Gibbs reckoned that the generated code was right, but Leopold still sounds unconvinced.
Peter Gibbs chucked a cat in amongst the parrots when he posted some performance numbers for his own private `African Grey' version of Parrot which utilizes some GC speed up techniques that Dan had rejected. Peter's numbers are impressive, but the techniques used break in some places. Peter helpfully posted pointers to his original patches. Dan wondered which bits contributed what to the improved performance, and explained why he had problems with the approaches that Peter was using.
This thread also spawned the thread called `Stack Walk Speedups?' which was kicked off by Mike Lambert outlining the current workings of the GC's stack walking code and wondered if anyone could come up with a faster way of doing it (that worked in the face of the constraints on Parrot's GC.) Peter Gibbs offered one approach, and Jason Gloudon pointed out that his 'stack direction' config patch would help in this area too. Jason also offered a patch giving a 12% speedup on his machine, which was applied. Mike Lambert is also doing some cunning stuff to improve things using Copy On Write (COW) tricks.
groups.google.com[63.120.19.221]
Brent Dax donned his Technical Author hat, and offered a draft PDD (Parrot Design Document) covering Parrot's external data interfaces. Nicholas Clark offered a pile of constructive criticism and discussion is ongoing.
The strangely named `Autovivi' thread rolled on. Miko O'Sullivan asked Larry for some clarification about the default behaviour of pass-by-values, Larry wasn't sure because he hasn't worked out the syntax yet. Luke Palmer suggested that copy-on-write tricks could be used to do let us have our cake and eat it. Deven Corzine suggested defaulting to doing pass-by-value, but Larry suspects that that might make Perl 6 sub calls even slower than perl 5's. David Whipp wondered about threading; nobody replied.
Deven managed to drag the thread back to its nominal subject of
Autovivification when he wondered if <func($x{1}{2}{3})> would
cause an implementation headache. Larry explained that it was cases
like this that made him choose the 'pass by immutable reference',
attempting to give the speed of pass by reference combined with the
guarantees of pass by value. Deven pressed his point and wondered what
would happen in the is rw case. Nicholas Clark explained how Perl 5
avoids autovivification in this case (but it's only one level
deep). Uri Guttman pointed out that this is a 'Hard Problem', but
Leopold Toetsch thought that the Parrot KEY operators may make it
relatively easy to solve.
Last week, Chris Dutton had asked about using Perl 6 to create
anonymous classes, and proposed a syntax. This week, Allison Randal
pointed him at the section of Exegesis 4 which described how to do
exactly that. Rather satisfyingly, the syntax that Chris had invented
was exactly the syntax used in the Exegesis, so the choice appears to
be natural. Trey Harris wondered about some of the other clumsinesses
in Perl 5 when defining classes, and asked some questions about class
methods. Damian confirmed that most of the clumsiness was going away,
and clarified the behaviour of subs in a class definition.
Chris Dutton has been reading up on Pike, and had some observations
(whilst neglecting to explain what Pike is). Apparently pike allows
you to define combination types <private string|int bar> would mean
that <bar> could be a string or an int for instance. Damian wheeled
out his superpositions hobby horse and suggested <my any(str,int)
$bar>, as a way of doing this. Luke Palmer trumped that with <my
all(str,int) $foo> and wondered what such a construct would actually
mean. Damian suggested that it meant Luke needed some serious
therapy. Nicholas Clark got all boring and practical and wondered how
one would implement the any case. Damian reckons it'd just fall out
of the implementation of superpositions.
Somewhere in the thread, Andy Wardley asked a serious question about
what builtin types perl 6 would had, and what the results of ref
$foo would look like.
Peter Behroozi wondered about using Apocalypse 5 rules to capture
balanced and wondered if there shouldn't be a <balanced>
directive. Brent Dax pointed Peter at the cunning recursion
capabilities that come with Apocalypse 5:
rule parenthesized { \( ( <-[()]>+ | <parenthesized> )* \) }
Larry commented that he was considering a builtin <self> rule
that'd allow one to refer to the current rule without having to name
it. Peter then offered his first attempt at a recursive rule to
capture nested HTML tables.
Nicholas Clark patched assemble.pl so that it could complete its
run before the heat death of the universe when run under perl
5.005_03.
Jeff Goff is back and doing cool things with Ruby in parrot.
Jerome Quelin asked what was wanted in a patch. Consensus seems to be either a unified or a context diff, as a mime attachment with a name for the patch and a short description of what it does. Tests are always good (essential) if you're adding new functionality. So are docs.
Jerome also offered a patch which implemented a rand operator but
wondered about portability and when to call srand. Jeff Goff
wondered if we shouldn't implement our own 'rand' using, say, the
Mersenne Twister
(www-personal.engin.umich.edu
and Dan pointed out where srand should be called.
Josef Höök reworked his multidimensional arrays patch one more time and it got applied. Well done Josef, perseverance pays off in the end.
Jason Gloudon added a config patch which tests the direction of stack growth. Applied.
Leopold Toetsch wondered why assembler.pl uses its own PMC.pm instead
of the generated lib/Parrot/PMC.pm. Warnock's Dilemma applies.
Pete Sergeant has written a `quick and dirty' PASM tokenizer and a syntax highlighter based on it.
Jarkko continues his sterling work of squashing Tru64 compiler warnings.
Steve Fink has had a crack at adding a --debugging flag to
Configure.pl. Warnock applies.
Jerome Quelin won my 'making it easy to keep a running joke going' prize when he supplied a Befunge-93 interpreter in parrot, and commented: "Note to Leon Brocard: There's a lot more to do in order to provide a Befunge-98 compliant interpreter, so don't worry! There's still a lot of fun waiting... :o)". Which was very good of him. Thanks Jerome.
The rule/pattern/regex thing kept going. Damian explained that he'd try and use `pattern' for the contents and `rule' for the container. But we that we weren't to hold him to that.
Brent Dax has uploaded a new version of Perl6::Parameters to CPAN. It's his attempt allowing one to declare perl 5 subroutines in a Perl 6ish style.
Daniel Alejandro Grunblatt, 21 years university student from Argentina.
I'm mostly doing the JIT for Parrot but occasionally move on to another fields (like the Parrot Compiler in Parrot or the Parrot Debugger and others).
My mother.
Some day.
I started working on the JIT to learn assembly, and I'm still learning it (yes, I'm slow), I want to see Parrot running fast, and because it's fun.
I like playing basketball, what I haven't done for while now, and used to like playing role games.
No.
This summary was prepared with the aid of more GNER tea (on the down train today). Sadly the GNER ham and cheese toasted sandwich has declined; they've replaced the cheddar in the old version with Wensleydale, which really doesn't melt as well.
Because I'm a bit late this week I've not had time to get the estimable Pete Sergeant to proofread it for me, so if the spelling is worse and the language less coherent this week, just be grateful for Pete's sterling work on my earlier summaries.
Again, if your name appears in this, or any previous summary, and you've still not sent your answers, please consider answering the questions in the "Perl 6 Who's who?" section and sending your answers to [email protected]
Well, so far nobody dislikes my summaries enough to post an alternative. Which is nice. If you think my time writing this is worth anything don't give me money, give it to the Perl Foundation donate.perl-foundation.org and help support the ongoing development of Perl. Remember, suitably large donations will earn you a plug in a future summary, but only if you tell me about it.