We've expanded our Perl news coverage and improved our search! Search for all things Perl across O'Reilly!

This week on Perl 6, week ending 2003-03-16

by Piers Cawley
March 16, 2003

Spring is in the air, the Apocalypse is here (or imminent, depending on which sense of the word 'Apocalypse' you are using). We'll start with perl6-internals as usual, before bracing ourselves for the increased volume and ploughing on into perl6-language.

Object Spec

Dan's 3rd try at the Objects and Classes spec received a very small amount of further discussion this week. What there was mostly touched on the boundary between where the line is drawn between parrot's object system and a particular language's object system. The inference I draw from all this is that the next Object spec will be the final(ish) Parrot Object spec.

Parrot 0.0.10

Steve Fink instituted a Parrot feature freeze in the run up to 0.0.10 at the end of last week, aiming for a release on Saturday the 15th of March and noted that he was leaning toward "Juice" as a code name (punning on Leo Tötsch's work on the imcc -Oj optimizations). David Cuny pointed out that there was already a virtual machine called Juice and suggested a whole list of possible code names. Leo Tötsch reckoned that calling it 'Juice' would be 'too much honour' and suggested a list of anagrams of 'Parrot ten'. ("Partner to", "Par Rotten" or "Tarte porn" anyone?).

It looks like we missed the release on the 15th, but Steve announced a release candidate on the 16th, in expectation of a release on the 17th.

http://groups.google.com/groups -- Feature freeze

http://groups.google.com/groups -- Release candidate announced

languages/BASIC reorg

Clinton A Pierce announced that he'd reorganized the languages/BASIC subtree into 'compiled' and 'interpreted' subtrees and noted that he was very impressed with the improvements in Parrot's speed and memory management. Leo Tötsch pointed out a few issues with MANIFEST and the need for a Makefile, and wondered if Clinton had run things through IMCC.

http://groups.google.com/groups

The Judy algorithm

Tim Bunce pointed everyone at the Judy dynamic array code on Sourceforge and wondered if it would be useful for Parrot. (Judy is a high speed dynamic array implementation optimized for modern processor architectures apparently). Leo Tötsch thought it looked interesting and suggested that someone try wrapping Judy up in a PMC and running some performance tests. Elizabeth Mattijsen went and took a look and reported some issues with memory leakage and worried that the project looked 'silent'. Tim mailed her concerns to Judy's author who addressed them in his reply and admitted that he wasn't that good at keeping the website up to date. He said that Judy had been 'tested carefully not to have leakage' and wondered if it might have been an issue with the tool Liz used to do the testing.

I await further developments with interest. If Judy can be made to work, it looks jolly quick.

http://groups.google.com/groups

http://judy.sourceforge.net/application/10minutes.htm

Yet another iterator proposal

Leo Tötsch posted a request for comments on what he called 'yet another iterator proposal'. Nobody commented. I wonder if this means everyone liked it.

http://groups.google.com/groups

Parrot for Windows

Benjamin Goldberg wondered if there were any precompiled parrot binaries for Win32 available as he wants to be able to test parrot code without the current weird rites he has to go through (see his post for details). Clinton A Pierce put a snapshot build up on his site temporarily for Benjamin to download. Robert Spier offered space on www.parrotcode.org for a windows build when the next release comes out which Dan thought would be really cool. Dan also wondered about making an automated build farm but I think he may have a tuit shortage when it comes time to actually implement it. Joshua Hoblitt also offered to host binaries on his CPAN mirror. Clint said he'd be happy to make milestone binaries and wondered if there was a standard way such a distribution should be put together.

http://groups.google.com/groups

Moving to PIO

Jürgen Bömmels continued to make Dan happy by moving more file related opcodes from STDIO to Parrot's PIO libraries. The latest ops to get his attention were open and close. Dan did a happy dance and applied the patch before wondering if we were subject to a code freeze (I don't think so; it was feature freeze time).

http://rt.perl.org/rt2/Ticket/Display.html

IMCC and PDD03 (Calling conventions)

Leo has been thinking some more about the parrot calling conventions described in Parrot Design Document 3 and worried that they can't actually be done. He proposed reducing the number of parameters that can be passed in registers in order to take pressure off the register allocator in IMCC. Dan agreed and quickly changed the PDD to take this into account. Leo then asked for some clarification on a couple of other issues that he was having a hard time understanding. Dan said that it was probably best to come back to these issues after he'd done PDD15 (The object spec). Leo agreed that objects will probably shed more light on the calling conventions and we all sat back to hang on Dan's every object oriented word. Not that there's any pressure at all.

http://groups.google.com/groups

Parrot extensions, or PMC versatility

Darren Duncan had some questions about PMCs and parrot extensions and what he should consider as he wrote a general persistence library. Dan and Benjamin Goldberg had some answers.

http://groups.google.com/groups

sun4 vtable JIT support

Jason Gloudon posted a patch adding support for vtable calls in the sun4/JIT and added support for some more ops. There appeared to be a few problems with the patch so it hasn't been applied yet.

http://groups.google.com/groups

A fish, a barrel and a running joke

Leon Brocard made maintaining this particular running joke almost trivial this week by actually posting something. He's implemented uniq(1) in parrot assembly, though he notes that it's not very fast compared to GNU uniq(1) yet. Dan added it to the distribution in examples/assembly/.

http://groups.google.com/groups

Parrot reaches another milestone

Dan has decided that Parrot has reached the point where it should have a working install make target. He asked for someone to make it so. No takers so far, but he posted late on Sunday so maybe there will be news of this in the next summary.

http://groups.google.com/groups

Meanwhile, over in perl6-language

perl6-language saw 210 messages this week. Which I think is more than it's seen in the last 3 or 4 weeks put together. Maybe it had something to do with the return of Damian Conway and the release of Apocalypse 6 (and the spectacularly short Apocalypse 7).

Statement modifiers

Matthijs van Duin wondered if the issue of multiple statement modifiers has been settled. The thread is long, and the answer is essentially (and authoritatively) "Yes, it's settled. No, you can't do it." So, unless Larry changes his mind the point is moot. However, Matthijs does put his case very well, if you're interested in this area I can recommend reading the thread.

http://groups.google.com/groups

http://archive.develooper.com/perl6-language%40perl.org/msg09331.html

Just when you get fed up of waiting for the Apocalypse...

Two come along at once.

Apocalypses 6 and 7 appeared online on Monday, a mere 9 months since the last one (Apocalypse 7 is all of two sentences long and is contained within Apocalypse 6, we'll be ignoring it from now on). This Apocalypse covered closures, subs, functions, methods, types, signatures and pile of other good stuff. All the syntax introduced was spelled out neatly using Perl 6 rule notation, neatly showing off the power of the syntax introduced in Apocalypse 5. I would attempt to summarize it, but it's already pretty dense so I suggest you all read it:

http://www.perl.com/pub/a/2003/03/07/apocalypse6.html

Now you've digested that, the rest of the summary should be easier to follow.

Damian returned to the list, though he's only reading posts related to Apocalypse 6 and he's pretty busy writing Exegesis 6 too so we're not expecting vast amounts of posts from him.

Austin Hastings kicked off with the first question, wondering if the 's' in <psiglet> was silent. "Of course not." says Larry.

Paul applauded the new macro feature (but Damian corrected his syntax).

S&M vs. B&D

Uri Guttman, displayed entirely too much knowledge about the difference between B&D and S&M asking if Larry shouldn't have used B&D where he used S&M in the apocalypse. Austin Hastings knows too much too it appears, commenting that it depends on whether you consider strongly typed compile-type semantics as being restrictive or painful.

http://groups.google.com/groups

Can "is" properties be specified indirectly?

Austin Hastings wondered if there would be some way of differentiating between an array of constants and an array of variables. In other words, how would one specify an array which may be appended/pushed, but whose values cannot change or a hash to which you could add keys but not change existing entries. Damian thought that you'd have to subclass Array or Hash as appropriate. Luke Palmer wasn't keen on this because then it would be easier to do something in C++ than in Perl, which isn't the usual way of things.

http://groups.google.com/groups

is constant eq pass by value?

Uri Guttman was confused by the default parameter passing style for Perl 6 functions, is constant. A parameter variable declared with is constant is 'locked'; you can't use the same variable to hold a different value.

   sub some_func ($some_arg is constant) {
       $some_arg += 10;
       ...
       return $some_arg;
   }

To do that you need to declare the parameter with is copy. Uri noted that he really should keep his finger off the send button until he's read the whole 'megilla', whatever one of those is.

http://groups.google.com/groups

Pipes

Michael Lazzaro declared that he thought the Apocalypse was great and that the 'sig stuff is very, very nice.' Then he asked about 'pipes' (the new <== and ==> operators which are almost, but not quite, entirely unlike the hypothetical ~> and <~ operators that were discussed so interminably a few summaries back). He wanted to know what was decided about some of the edge cases discussed in the appendix to the apocalypse (and had a comment to make about style). Damian pointed out that Michael's edge cases all collapsed to two:

    @var <== LIST;
    LIST ==> @var;

Damian said that Larry was still unsure about these but that he (Damian) thought they would be allowed in, if only because

    @in ==> map  {...}
        ==> sort {...}
        ==> map  {...}
        ==> @out;

is a lot less ugly than

    @in ==> map  {...}
        ==> sort {...}
        ==> map  {...}
        ==> push @out;

or (John Williams suggestion)

    LIST ==> @var.STORE(*);

I have visions of the Perl 6 naysayers reading this section and muttering dark imprecations about the end of the Perl as we know it...

http://groups.google.com/groups

Pages: 1, 2

Next Page