This week on Perl 6 (10/20-27, 2002)
by Piers CawleyNovember 04, 2002
So, kicking off, as is customary, with perl6-internals before getting down to attempting to summarize the monster that was perl6-language:
C# and Parrot
The dialogue with Rhys Weatherley and Gopal V from the DotGNU project continues apace, mostly to do with clarifying what C# needs in the way of datatypes and the like. It appears that Leon Brocard is the go to guy if you need to know the exact details of almost anything in a language spec. Maybe he's just really good with Google.
Gopal V wondered whether there was someone involved in p5i who would mind acting as a liaison with the DotGNU people and who could give them a heads up when, for example, the packfile format changed. Leopold Toetsch wondered what type of changes were potential C# breakers, as there were probably things that we thought of as `internal' that the C# team could be depending on. Leo also thought that the liaison person should probably be Dan.
http://groups.google.com/groups
Scratchpad Confusion
At the end of last week, Allen Short pointed out some discrepancies between the implementation of scratchpads and the description of them in PDD6. John Sillito reckoned that PDD6 was waiting on a rewrite from Dan, especially where Scratchpad PMCs were concerned as there were a couple of different patches waiting on Dan's say so. Dan also offered some clarification, but hasn't ruled on the Scratchpad PMCs yet.
http://groups.google.com/groups
Help! Bugs! Crawling All Over Me! OR the Road to 0.0.9
Steve Fink wants the GC bugs ironed out before he goes adding much in the way of new features, and he wants to start putting together a 0.0.9 with working GC, too. To that end, he deliberately broke all the tests by turning GC_DEBUG on for tests. There's a certain amount of cleverness involved in how he did this; read his post if you're interested. Peter Gibbs found what he thought was a fix for a couple of the failures and pointed to the possibility of a fundamental problem in MultiArray as the culprit for the remaining failure. Steve applied this patch with much rejoicing, and then came up with a trial patch that seemed to fix the multiarray-triggered failure. This patch had not been finalized by the end of the week.
Steve also kicked off discussion of the forthcoming 0.0.9 release, when he posted his list of prerequisites and sparked off a decent amount of discussion of various points. Steve's overarching goal for this release appears to be 'bug reduction and general consolidation.'
http://groups.google.com/groups
http://groups.google.com/groups
Keyed ops, the Return.
I think it's safe to say that some people aren't entirely happy with keyed ops as they stand now in Parrot. The week before, Leopold Toetsch had written a proposal for keyed ops. This week, he supplied a proof of concept patch. Jürgen Bömmels liked it but Dan took a little more convincing. I'm not sure he is entirely convinced yet, but he's willing to live with it.
http://groups.google.com/groups
64-bit ints and Noncapable Hardware
Dan announced that he was about to bite the bullet and declare that INTVALS have to be 64-bit integers and wanted to know of any (plausible) platforms that have neither native nor emulated 64-bit integers. Martin D Kealey pointed at what sounds like a scary proposal from C99 involving declarations and clever compilers and wondered whether it might be a way forward for Parrot. Rhys wondered how well the idea would play with something as dynamic as Parrot and the languages expected to run on it, but Martin didn't seem to think it would be much of a problem.
http://groups.google.com/groups
http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/
Configuring and DOD
Erik Lechak couldn't get the latest parrot to build on WinXP. Josh Wilmes diagnosed a problem with the way the configuration tools probed for stack direction, and patched things so that stack direction detection was done at runtime once more. Jason Gloudon, who had moved the detection phase out into configuration time wasn't sure that this was a good idea 'cos it would lead to a performance hit in the stack walking code. Nicholas Clark, with his clever head on, came up with three different ways of doing things at runtime without a performance hit, and Dan blessed the third choice.
http://groups.google.com/groups
Execute in place?
Rhys Weatherley has been taking a look at our packfile format code,
and thinks it could be improved by designing the format in such a way
that it can be mmapped into a block of memory and executed immediately,
as opposed to the way parrot currently does it, which involves moving
stuff around in memory before starting execution. Dan said that that's
how things were originally done, and if it wasn't still possible, then
that was a bug.
http://groups.google.com/groups
Copyright Notices and License Stuff
Toward the end of the week, Dan announced that he was about to straighten out the copyright and licensing situation. As a first step, he would be marking everything in the core as Copyright YAS. It looks like Parrot itself will be moving to an MIT-style license `Over no objections whatsoever from the FSF.'
If you've made any contributions to Parrot's code base, then you've probably already been contacted, but if you haven't and have an objection, then you should contact Dan.
Most of the discussion of this happened during the next week, and I'll return to it in my next summary, but response was generally favorable after some clarifications from Dan.
http://groups.google.com/groups
Allow a NULL Interpreter in sprintf Like Functions
Jürgen Bömmels sent in a patch that allowed the use of a
NULL interpreter in sprintf like functions. Leo Toetsch applied it,
but wondered whether it was actually the right thing. Dan seemed to think
that, in the long run, it probably wasn't and that, if something went
horribly wrong before an interpreter got properly set up, then it was
probably best to use the standard library functions.
http://groups.google.com/groups
http://groups.google.com/groups
Draft Sketch of Bytecode Generation
Dan offered a `very sketchy' draft of his thoughts on what we need from our bytecode generation system. Initial reaction seemed positive.
http://groups.google.com/groups
Pages: 1, 2 |
