Spring is sprung, the Equinoctal gales seem to have blown themselves out, I'm a proud step grandfather and life is generally grand.
"So, what's been going on in perl6-internals?" I hear you ask. Let's find out shall we?
It appears that embedded Parrot tries to do too much. In particular, it grabs signals that its embedder may not want it to deal with. Dan declared that at some point Parrot would have to treat signals as something the embedding environment controls (And the standalone Parrot interpreter becomes just another place where the Parrot core is embedded).
Unhygenic namespaces are bad, mm'kay?
Mitchell N Charity posted the results of doing
$ nm ./blib/lib/libparrot.a | egrep ' [TDRC] |\.o:' | grep -v Parrot_
and the results are rather embarrassing. Parrot exports a bunch of symbols that have no Parrot specific prefix, and which have the potential to clash with symbols that the embedder is using for something else. Arthur Bergman agreed that doing something about this would be a jolly good idea and proposed prefixing all externally visible macros, types and functions with
There followed some discussion of the prefices that are currently in use within Parrot (there are several); Arthur pointed out that many of them are still worryingly generic and proposed expanding most of the 'P's in them to a full 'Parrot'. Jeff Clites suggested that it would be a good idea to get the linker to only expose external entry points in the first place, though there are issues of cross platform compatibility to deal with in order to implement that. Dan announced that, despite the potential pain, this would be the way forward.
Tim Bunce wondered if anyone was tracking the mailing list and adding questions and (good) answers to the FAQ. Apparently, chromatic has taken this job upon himself, but he confessed that he hadn't actually been doing recently. He's on it though.
Mitchell N Charity pointed out that PerlNum didn't appear to retaining the sign of zero. (Which, frankly, does my head in every time I think about it; minus zero? What's that then?). Apparently retaining the sign is the Right Thing and, when Mitchell pointed it out, PerlNums were doing the intuitive thing (zero is zero is zero, and the sign's irrelevant). It's what the floating point standard mandates though, so things were changed.
Jens Rieks continues to stress the object stuff (he's working on writing an EBNF parser). He posted a test to the list that led Leo Tötsch to find and fix 3 bugs in the Garbage Collector's DOD phase.
Will Coleda, who's working on implementing Tcl for Parrot had a few questions. My particular favourite one was "Unicode?", which seems to echo a lot of people's feelings on that particular issue.
Leo answered his questions (the answer to the Unicode one being "Needs a lot of work still.").
In the thread that followed, Gay, Jerry (Or should that be Jerry Gay? What's a Summarizer to do eh?) wondered why you wrote
store_global "global", Pn, but
find_global Pn, "global", which he thought was inconsistent. My rule of thumb for this is that the target always comes first on the opcode argument list. Jens Rieks pointed out that opcode arguments are always ordered so that any
OUT arguments come first.
Will Coleda announced the latest version of his Tcl interpreter. Judging by the Changelog extract he posted, things are looking very good. You'll find it in the latest Parrots from CVS.
Larry, Dan and chromatic had a discussion about what's responsible for dispatch and whether Roles are inherited or acquired by some other means. It got rather philosophical (I like philosophy). Dan got the last word.
Simon Glover found a bug in Parrot's string->number handling. It turns out that the route from
-1.2 to a number is different to that from
"-1.2" to a number. Which means that the two resulting numbers don't have the same value. Which is bad.
It turned out to be down to hysterical reasons from when IMCC just generated parrot assembly and then called parrot to do the actual execution; then parrot would use the same string conversion routines at compile and run time.
Leo fixed it.
Dan pointed out that, as the Ponie work goes on, integrating Parrot with Perl 5, we need to get the embedding interface fixed up so that it plays well with others.
He was also concerned that we seemed to be reinventing perl's Configure.SH in a horribly piecemeal fashion and suggested that we should just dig all the stuff out in one swell foop. Larry pointed everyone at metaconfig and discussion ensued.
Quite how metaconfig sits with the miniparrot based configuration/build plan that Dan's talked about was left as an exercise for the interested reader.
Work continued on making objects more efficient. The object PMC had a good deal of fat/indirection removed, and work started on implementing a method cache. Dan reckoned that the two most useful avenues for exploration were method caching and thunked vtable lookups.
Zellyn Hunter suggested people take a look at papers on Smalltalk's dispatch system by Googling for [smalltalk cache].
Mitchell N Charity suggested a couple of possible optimizations (and benchmarks to see if they're worth trying).
There was some discussion of the costs of creating return continuations. (My personal view is that the current continuation and stacks implementation isn't the Right Thing, but I don't have the C skills to implement what I perceive to be the Right Thing. Which sucks.)
Leo reckons that, with a method cache and continuation recycling, he's seeing a 300% improvement in speed on the object oriented Fibonacci benchmark.
Jeff Clites gave everyone a heads up about the work he's doing on a patch to incorporate the use of ICU (the Unicode library Parrot will be using) and some changes to our internal representation of strings. Apparently the changes give us a simpler and faster internal representation, which can't be bad.
Jens Rieks and Piers Cawley both had problems with continuations. Leo Tötsch tried explain what they were doing wrong. There seemed to be a fair amount of talking past each other going on (at least, that's how it felt from my point of view) but I think communication has been established now. Hopefully this will lead to a better set of tests for continuation usage and a better understanding of what they're for and how to use them.
Mitchell Charity argued that we should think carefully before doing too much more optimization of Parrot until we've got stuff working correctly. Leo agreed, up to a point, but pointed out that optimizing for speed is lot of fun. Brent Royal-Gordon thought that it was a balancing act, some things are painfully slow and need optimizing, at other times, things are painfully none existent and need to be implemented. Objects were both of those things for a while.
Piers Cawley said that, for all that objects were slow (getting faster), he thought they were rather lovely.
At the back end of the previous week, Larry introduced the idea of
subscripting hashes with
when you mean
This surprised John Williams (and others I'm sure, it certainly
surprised me, but it's one of those "What? Oh... that makes a
lot of sense" type surprises.) Larry explained his thinking on the
Apparently it arose because
was too ugly to live, but too useful to die, so
:foo«bar» was invented, and
once you have that, it is but a short step to
(If you've not read Exegesis 7, you probably don't know that
:foo«bar» is equivalent
foo => 'bar', but
you do now.) John wasn't convinced though. It remains to be seen if
he's convinced Larry.
Larry: unfortunately it's an unavoidable part of my job description to decide how people should be surprised.
Oh lord... I'm really not following this particular thread. The mutating methods thread branched out in different directions that made my head hurt. I *think* we're still getting
$aString.lc; # None mutating, returns a new lower case string $aString.=lc; # Mutating, makes $aString lower case
I'm going to bottle out of summarizing the rest of the thread. Hopefully subthread perpetrators will be kind to an ageing Summarizer and change subject lines to reflect the content of a given subthread. Ta.
Joe Gottman has been reading Synopsis 3 and had a bunch of questions. Much of the ensuing discussion covered the use of the 'broken bar' glyph as an infix form of the
zip operator. Which I didn't quite realise as I skimmed the thread during the week because courier doesn't seem to distinguish between the broken bar and the standard bar. Larry later suggested using the yen (¥) symbol instead, which has the advantage of looking a little like a zipper. I really hope that firms up from suggestion to design call.
Whee! I have an announcement! This summary is dedicated to my step grandson, Isaac Stamper, born 2004-03-17T13:13GMT at the RVI in Newcastle. There are (of course) photos online at http://www.bofh.org.uk/photos/Isaac/, but you don't have to go and look at them.
I'd also like to apologise to everyone on perl6-internals for my complete inability to post attachments to the list. I hope that those who are interested got to see my first cut at a Parrot implementation of xUnit in the end.
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send me feedback at mailto:email@example.com, or drop by my website, maybe I'll add some content to it this week.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
http://www.bofh.org.uk/ -- My website, "Just a Summary"