|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Where does the time go? It seems like only yesterday that I was sat hiding Leon Brocard in the first letters of the first 11 body paragraphs of the last summary. Now, here I am, on the train, typing away in a desperate attempt to get this mailed out before Wednesday. Let's start with perl6-internals again.
Whoever would have thought that freezing objects would be so controversial? Object freezing is when you take an object and generate a 'frozen' representation of it that can be used to make a copy of the original object. It's what Storable, Data::Dumper and YAML (to name three Perl 5 modules) all do more or less successfully. (Most of the time there's no problem, the tricky case is a composite object which involves a circular data structure. Consider this:
Ring -> A -> B -> C -> D ^ | `--------------'
(It's not quite a purely academic example, I can point to at least one text editor that uses a similar data structure).
When you come to freeze your ring, you need some way of detecting the cycle and generating a finite representation that works. This isn't the only problem; thread safety is hard, for instance.)
Dan's set some fairly stringent requirements on whatever mechanism is used for freezing. The most important/stringent is the requirement that (because freezing during object destruction will be a possibility) object traversal is not allowed to use additional memory for that traversal.
Dan is convinced that we can do this using the Garbage Collector's object traversal system. Leo Tötsch is equally convinced that we can't. The resulting thread is rather meaty and hard to summarize without massive amounts of cut and paste so I'll just point you at the root message. The upshot is that we're doing it Dan's way; Glorious Leader continues to trump Pumpking Patchmonster.
In another subthread there was a good deal of misunderstanding about XML declarations and parsing, which got cleared up surprisingly quickly.
Dan had a moment of clarity and declared that the Parrot Way to instantiate an object in class Foo will be:
new P5, .Foo
All we need now is a working implementation. And, apparently, knowing what class a class is a member of might be handy, but Dan's punting on ("ignoring the heck out of") that one.
In the middle of the discussion about object freezing, Dan popped up
another thread to discuss how to invoke Sub/Method PMCs from C
code. So Leo implemented
Parrot_runops_fromc_args(), but he's not
exactly happy about the name. Regardless of the name, having this
implemented is rather spiffy.
Melvin Smith popped up with a rant about the Parrot development effort's tendency to rush off to implement new stuff before making double sure about the 'old' stuff is actually complete and robust. To which I can only say "Hear! Hear!" Dan agreed, and threatened to give Melvin the pumpkin after Leo had finished with it.
Donning his designer's cap again, Dan posted a rough spec for class metadata declarations in PIR and pasm files. It looks pretty decent to me. Melvin Smith made a few telling comments though, so it looks like Dan's post isn't quite the final word on the matter.
Mere moments after the metadata post, Dan went on to spec out the assembly language needed to support it.
Leo pointed everyone at www.parrotcode.org the list of open Parrot patches and asked for a volunteer to go through and make sure that the list is in agreement with reality.
Leo posted a list of thoughts about how classes and objects will work in Parrot and offered a suggestion about using OrderedHashes to handle things.
Leo wondered if we should arrange things so that PMC vtables could be invoked in the same way as in methods on Parrot level objects are invoked. Dan answered that it won't be quite like that, but it will be close. (Yay! A reflective programmer writes).
So, it turns out that adding PMC classes to the core breaks binary compatibility. Which needs fixing. Dan asked for volunteers. I'm afraid I don't know what fixing it would entail.
Plotz (the Pol(l)y-Lingual Opcode Translation for the Z-machine) is Amir Karger's shot at Parrot immortality by getting Parrot to run Infocom adventures. Right now he's prototyping his design in Perl and he's apparently 10 opcodes away from a tool that will run around two thirds of all released Infocom games. He's rather happy about this.
Melvin Smith proposed a "just for fun" Halloween release of Parrot. Dan christened the putative release "The Screaming Pumpkin", and Leo thought there was a little too much stuff in flux at the moment. Me? I think it's going to happen. The codename is too good to resist.
Melvin Smith checked in a large patch to move IMCC from parrot/languages/imcc/ to parrot/imcc, reflecting the intention/reality that IMCC is parrot. As the week progressed, various other directories got moved around in an attempt to make things a little more logical. Everything is now, roughly in its place, but at one point during the week it would have been, frankly, foolhardy to attempt to check parrot out of CVS.
Melvin Smith, who has returned from his Parrot holiday with a seemingly enormous supply of tuits, announced that he'd started work on implementing the class syntax for PIR and had reached a decision point, so he asked for comments. The consensus was to go with a short term hack for the time being, just to get something working, with a big flag for the future.
For those of you who are implementing things in IMCC, Melvin
announced that he'd added
IMCC, allowing implementors to simply write
P0 = newsub <label> and
P0 = newclosure <label> which
is rather more efficient than the PASM equivalents.
Dan decided that the time has come to allow PMCs to be created with
initialization data rather than having separate creation and
initialization phases. Hes proposal, pending a Better Idea(tm) was to
init methods, one taking no arguments and simply creating
an empty PMC, and another which assumes that its parameters are in
the registers (using the standard calling conventions) and goes from
there. Leo thought it was a little heavy. I like it though, the more
things that use standard Parrot calling conventions, the less I have
to remember and the happier I am -- but I am a bear of very little brain.
Luke Palmer asked a question about named named return values and
:=. David Storrs boggled slightly.
Next week, Damian Conway answers Luke's question.
Looks like the Wednesday ship date of the last summary was a temporary aberration. Which is nice.
If you found this summary valuable, please consider one or more of: