This week's Summary
Piers Cawley
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.
Object Freezing
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.
Object Instantiation
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.
A less controversial API addition
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.
Old Big Problems before New Big Problems
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.
Class metadata for PIR/assembly files
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.
Class creation in bytecode
Mere moments after the metadata post, Dan went on to spec out the
assembly language needed to support it.
Open Patches
Leo pointed everyone at http://xrl.us/zaf, 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's notes on objects and classes
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.
Unifying vtables and method invocations
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).
More fixed number assignments
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!
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.
Halloween Release
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.
IMCC leaves the languages ghetto
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.
IMCC, Classes & Metadata, oh my!
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.
PIR changes
For those of you who are implementing things in IMCC, Melvin announced
that he'd added "newsub" and "newclosure" to IMCC, allowing implementors
to simply write "P0 = newsub <label>" and "P0 = newclosure <label>"
which is rather more efficient than the PASM equivalents.
PMC initialization
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
have two "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.
Meanwhile, in perl6-language
Luke Palmer asked a question about named named return values and ":=".
David Storrs boggled slightly.
Next week, Damian Conway answers Luke's question.
Acknowledgements, Announcements, Apologies
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:
* Donating time to the project. We need more programmers, documenters
language implementers and generally useful people.
http://dev.perl.org/perl6/ and http://www.parrotcode.org/ have
details of mailing lists etc.
* Donating money to the Perl Foundation
(http://donate.perl-foundation.org/) to help support Larry, Dan
and Damian and enable them to spend more time working on Perl 6,
rather than petty things like making sure they're earning enough
money to feed themselves.
* Donating feedback to your summarizer (p6summ...@bofh.org.uk).
Luke Palmer
> 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.
(Yeah, I read the thread, but just thought of this now)
So classes will be integers? Fair enough, as there's just as many of
those as there are memory locations.
I do worry about some long-running daemon that uses anonymous classes
heavily. It's possible that after quite some time, we'd run out of
integers, even when there are far fewer than 4 billion classes in
current existence.
So, shouldn't classes instead be objects that can be garbage-collected?
I know that violates that nice equivalency between PMCs and classes, but
I'm sure there's a way to finesse the convenience of that equivalence
somehow...
Luke
Jeff Clites
I'd say it's more like class names are integers, so anonymous classes
don't use them up since they don't have names. But that points out that
there should be a way to instantiate a member of a class given the
class object (itself a PMC), with the above syntax serving as a bit of
a shorthand (possibly an optimized one) for finding the class object
based on its name and then instantiating it.
(And it's not really that a class name is an int, but rather that the
representation of the name spit out by a compiler would be an int.)
Just a thought.
JEff
Leopold Toetsch
> Object Freezing
[ ... ]
> ... The upshot is that we're doing it Dan's way; Glorious Leader
> continues to trump Pumpking Patchmonster.
As this is a summary, abbove sentence is a summary as well. The reality
is more complex. The final implementation will have parts from both
POVs.
Thanks again for your summaries,
leo
Leopold Toetsch
> I do worry about some long-running daemon that uses anonymous classes
> heavily. It's possible that after quite some time, we'd run out of
> integers,
Its the same problem as assigning PIDs to a process. We will have to
cycle around and reuse old "free" numbers sometime.
> So, shouldn't classes instead be objects that can be garbage-collected?
Isn't worth the effort AFAIK.
> Luke
leo
Dan Sugalski
> > Object Instantiation
> > 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.
>
> (Yeah, I read the thread, but just thought of this now)
>
> So classes will be integers? Fair enough, as there's just as many of
> those as there are memory locations.
No, classes are identified by integer. They may or may not also have
names.
> I do worry about some long-running daemon that uses anonymous classes
> heavily. It's possible that after quite some time, we'd run out of
> integers, even when there are far fewer than 4 billion classes in
> current existence.
That's going to take a pretty long time, even with the JIT. I'm not
particularly worried about it, and we can deal with it when it happens.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk