|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
PEPPERPOT 1: Ooh look! It's another Perl 6 summary!
PEPPERPOT 2: Well I never did! What's in it this week?
PP 1: Ooh, I don't know. Shall we have a look?
PP 2: Ooh yes.
Following a convoluted animation sequence involving surreality, fig leaves, classical statuary, and a cardboard cutout of an orange Leon Brocard, the camera pulls back to reveal a large bearded man, sat in a leather chair with a huge Apple PowerBook on his lap. PIERS looks from the screen to the camera and says
PIERS: I never wanted to be a summary writer. I wanted to be a lumberjack, leaping from tree to tree as they float down the mighty rivers of Briti... Ah... *ahem*.
PIERS comes to a stammering stop as he realises that quoting Python is so 20 years ago and that this year all the cool London.pm kids are quoting Buffy the Vampire Slayer instead.
As you may have gathered from the above introduction, it's been fairly quiet this week. However, design, development and discussion continues. As usual we'll start with perl6-internals.
Towards the end of April, Luke Palmer had posted a patch implementing
a long option processing subsystem for Parrot. After wondering if
getopt_long was a standard function (it isn't), Steve Fink applied
Leo Tötsch responded to Peter Gibbs' question of the week before about Parrot's apparently excessive memory use for a simple program. Leo and Peter batted the issue back and forth a few times in the process of tracking down the source of the problem. I think they got to the root of the problem, but I'm not sure if they've worked out a fix just yet.
Last week Clinton A. Pierce had wondered about allocating blocks of 'generic' memory within Parrot for use as targets for native functions (in his case for calling Win32 functions). Piers Cawley wondered if it wouldn't be possible to implement a scratch buffer PMC to manage such blocks of memory. Dan pointed out that this was exactly what the 'unmanagedstruct' PMC type was intended for, but Clint wasn't sure that this did quite what he wanted and asked for more advice.
Later in the week Clint announced that he'd got UnManagedStruct PMCs doing some useful work, including allocating arbitrarily sized buffers from parrot assembly. People were impressed (In fact, Dan went so far as to call Clint his hero in his 'Squawks of the Parrot' weblog). However, Leo Tötsch pointed out that a good deal of the work that Clint had done on UnManagedStruct probably belonged on ManagedStruct instead. Apparently Clint (and Dan) hadn't noticed that ManagedStruct existed. Hopefully now he's had it pointed out to him, things will become a little more logical.
After Dan's last set of changes to the Parrot calling conventions, Brent Dax wondered why we still had a user stack now that it was no longer being used for argument passing. Klaas-Jan Stol reckoned it was still useful and it would make targetting Parrot easier. Luke Palmer wondered if the user stack wouldn't make it harder to implement an exception system.
Interestingly, Dan seems to be toying with having Parrot use Continuation Passing Style function calls at some point in the future. Who knows, maybe the next final calling conventions will mandate CPS (I confess, I rather like the idea myself...)
Getting Parrot working well in a Win32 environment seems to have been a Parrot theme over the last few weeks. This week Cal Henderson popped up with some problems getting things to link. The problem was tracked down quite quickly, and Cal ended up offering to do regular windows builds for the tinderbox system, though it looks like that's not yet as easy as it could be. Apparently the standard Win32 make targets don't quite build enough. I'm sure someone's working on fixing this; getting Win32 into the tinderbox will be really handy.
Zellyn Hunter wondered about how to choose between IMCC and the native parrot assembler. (Zellyn also presented me with a dilemma about which personal pronoun to use, which I solved by going and looking at his website. Unless 'Leah' turns out to be a chap's name I think I'm safe). He also asked about the state of the documentation within CVS, and wondered which documents were still valid and which (if any) had been caught out by the march of development, suggesting a small meta document with information on the validity of the various docs (which begs the question of how one knows that the metadoc is up to date.)
The answer to the first question was "Well, it depends", with the rider that, unless you enjoyed doing your own register allocation, IMCC looked like the saner choice. Jerome Quelin pointed out that the Ook! compiler targets PASM, which seems to be in agreement with the whole sane/unsane thing.
David Robins read Dan's blog entry about stack walking and had a few questions about the details. He wanted to know what was done about false positives (ie, how do you know that something that looks like a pointer is a pointer), and what was done about object destruction. Dan replied that, in one of the Parrot GC system's few conservative choices, Parrot GC took the view that if something in the system stack looks like a pointer then it's safest to assume that it is a pointer and proceed on that basis. He also noted that, if a language required a specific order of object destruction then it was down to the language to handle that.
The usual spectre of timely closure of IO handles was raised again -- Perl 5 guarantees that objects get destroyed (and therefore handles get closed) as soon as an object goes out of scope. This is somewhat harder to guarantee in a system that doesn't use reference counting for garbage collection. Graham Barr commented that "Anyone who depends on GC for the closing of file handles asks for all they get.", which is certainly one way of approaching the issue, but it does rather fly in the face of the Perl 5 Way.
www.sidhe.org -- Dan explains stack walking
Jürgen Bömmels continued his sterling work on the Parrot IO system (PIO), fixing up the problems with buffering and double frees etc that were mentioned last week.
Dan added a
sysinfo op which allows a running program to at least
get some information about the machine it's running on. Things are
apparently somewhat spotty for various architectures that Dan didn't
have immediate access to, but there's a framework in place now and
patches are welcome.
The language list was again busier than the internals list this week, but only just. Maybe we're all waiting with bated breath for the next exegesis. Or maybe everyone's exhausted. It can't last though.
Discussion of the hypothetical/non-existent
bool type continued. I
tried really hard to care.
As Luke Palmer continued to argue that Coroutines were a
useless/dangerous bit of syntactic sugar and we'd be better using
explicit iterator objects. Meanwhile, others discussed the various
options for calling semantics in the case where Coroutines continued
to look like coroutines instead of iterators. Damian Conway proposed
another form of Coroutine calling convention. Damian proposed that
yield return the 'new' arguments with which you 'resumed' the
coroutine. This gives the programmer the option to handle different
arguments however she likes. Piers Cawley liked the idea and posted a
few snippets of code for implementing these semantics using
continuations. He also suggested that it might be handy to be able to
declare 'Blocklike' subroutines that were 'return transparent'. I
think the continuations scared people off because there has been no
comment, even on the Blocklike subs idea.
groups.google.com -- Damian's proposal
Uri Guttman, may his name be forever mispronounced, responded to last week's summary (instead of the original thread, bad Uri!) by pointing out that the simple minded include macro referred to in that summary was inefficient and proposed an optimization. This turned into a discussion of whether file reads should be 'slurpy' by default (Michael Lazzaro thought they should be, almost everyone else disagreed with him).
Then Damian popped up with his proposed Grand Unification
of HERE docs, POD, and general file slurping, which looks very cool,
but unfortunately, the unary
<< operator that Damian proposes
to hang all this off seems to clash with Larry's proposed use of
<<list of words>> as a replacement for
qw/.../. The idea was well received, and people started casting
around for a sensible operator and adding other neat ideas to go with
it. Damian won the 'evil, evil, evil' prize when, after
been proposed as the file slurp operator, he came up with the idea of
vectorizing it, which would lead to such delights as
my($stdout, $stderr) = >><<<<< open 'grep foo * |';
Or, for the avoidance of headaches:
my($stdout, $stderr) = >> <<< << open 'grep foo * |';
(I hate to think how one would write that in a POD C<...> escape).
This then turned into a discussion of whether
sense as a replacement for
qw<...>, especially given the
perceived utility of Damian's proposal.
Towards the end of the thread, Michael Lazzaro withdrew his contention that slurpy reads should be the default.
groups.google.com -- Conway's Unified Here Theory
The camera pulls back from observing a computer screen on which the words "The camera pulls back from..." are being typed and swings around to focus on the typist who looks up from the screen and addresses the camera.
PIERS: And so, by some extraordinary coincidence, fate, it seemed, had decided that you, my readers, should keep your appointment with the end of this summary. But what of the new technologies that had been spoken of?
AUDIENCE: Where *BLEEP*?
PIERS: In an empty house?
AUDIENCE: When *BLEEP*?
PIERS: In the middle of the night?
AUDIENCE: Best time!
PIERS: What diabolical plan had been shaped by Damian and Larry's crazed imaginations? What indeed? From what had gone before it was clear that this was going to be...
AUDIENCE: a picnic?
PIERS: no picnic.
The lights dim, the screen fades to white and the following words scroll up the screens of browsers the world over:
If you've appreciated this summary, please consider one or more of the following options: