This week's Perl 6 Summary
The Perl 6 Summary for the week ending 2005-05-24
Note to self: It's generally not a good idea to go installing Tiger on
the day you return from holiday. It's especially not a good idea to fail
to check that it didn't completely and utterly radish your Postfix
configuration. And your emacs. And the backing store for your website.
And a bunch of other stuff. It's an especially bad idea not to have
backups of things like your aliases file...
Nor is it a good idea to get preoccupied with all these joys and
completely forget that you're supposed to be writ ting the Perl 6
summary.
Ahem.
I'm very, very sorry.
So, on with the show.
This week in perl6-compiler
Inline::Pugs
Autrijus announced the availability of Inline::Pugs. If you've ever been
moved to mix up Perls 5 and 6 in one program, your prayers have been
answered. Just grab Pugs and Inline and you're set. Brian Ingerson made
things even more delightfully evil:
#!perl
use pugs;
sub postfix:! { [*] 1..$_ }
sub sum_factorial { [+] 0..$_! }
no pugs;
print sum_factorial(3); # 21
http://xrl.us/f73s
Experimental Coroutine support
Autrijus announced that Pugs now has an experimental implementation of
coroutines. It's almost certainly not final, but it's good enough for
exploration and feedback purposes.
http://xrl.us/f73t
Graphing tool for PerlGuts Illustrated
Yuval Kogman asked what tool was used to generate the 'pretty diagrams'
in PerlGuts Illustrated because he wanted to use it for diagrams in a
forthcoming PugsGuts Illustrated. Ingy said that Gisle had hand hacked
postscript based on initial diagrams drawn on graph paper. After some
discussion, the plan seems to be that Yuval will just draw diagrams,
scan them and bung them into the pugs repository. He'll rely on the
LazyWeb to turn them into beautiful scalable graphics.
http://www.lazyweb.org/
http://xrl.us/f73u
Perl Development Server
Okay everyone, repeat after me: Juerd is a star!
You may ask me why, and I shall tell you.
Juerd and his cosponsors, Twistspace will making a Perl 6 development
server available over the internet to any Perl 6 developers who are
working on 'everything that improves Perl 6 development'. So, if you've
been put off working on Pugs by the hassles of getting Haskell working
on your machine, or if you have the kind of bandwidth that makes svn
updates a painful prospect, worry no longer. Just sign up for a
development account.
There was much rejoicing and suggesting of hostnames. Rather bizarrely,
there was also discussion of the etymology of 'sipuli' (Finnish for
'onion' in case you were wondering).
http://xrl.us/f73v
Two releases in one day
Autrijus announced the release of Pugs 6.2.4. About half an hour later
he announced the release of Pugs 6.2.5.
http://xrl.us/f73w
Undef issues
Adrian Taylor thought he'd found some issues with Perl 6's understanding
of undef. It turned out that he'd found some issues with his own
understanding of same.
http://xrl.us/f73x
Method/attribute chaining
Alex Gutteridge found some weirdness with the chaining of autogenerated
attribute methods (I wonder if the same weirdness occurs with hand
rolled attribute methods). So far it remains unfixed, but given the
speed of Pugs development I doubt it'll stay that way for long.
http://xrl.us/f73y
Meanwhile, in perl6-internals
Parrot as an extension language
Colin Adams continued to have problems using Parrot as an extension
language for Eiffel. It turns out that interfacing between statically
strongly typed languages and Parrot isn't easy.
http://xrl.us/f73z
Fixing t/src/manifest.t
Dino Morelli reported problems with t/src/manifest.t and wondered how
some of the failures came about. Jürgen Bömmels thought that the problem
was an overzealous test -- the original version of which simply ensured
that version control and the MANIFEST were in sync. He provided his
suggested version of a less eager, but still svn compatible test.
Further discussion thrashed out the various difference use cases for
manifest checking.
http://xrl.us/f733
More t/p6rules tests
Dino Morelli posted a bunch of tests for the Perl 6 rules. Well, he did
once he'd done battling his mailer's somewhat bizarre choice of MIME
type for his test files. Remember, if you're about to attach a .t file
to a message you send to the list, make sure your mailer doesn't declare
it to be an application/x-troff file -- text/plain is your fiend.
Patches were applied.
http://xrl.us/f734
Stressing the hash
Leo asked for some stress and bench mark tests for hashes because he was
in the process of redoing src/hash.c. Bob Rogers provided one.
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030831 Welcome to this week's Perl 6 summary. This week, for one week only I'm going to break with a long established summary tradition. No, that doesn't mean I won't be mentioning Leon Brocard this week. Nope, this week we're going to start by discussing what's been said on the perl6-language list this week. Now that's out of the way, we'll continue with a summary of the internals list. Continuation Passing is becoming the One True Calling Style Jos Visser had some code that broke in an interesting fashion when find_lex through an exception, so he asked the list about it. Leo Tötsch explained that exceptions and old style subs don't play at all well together. It seems to me that the total and utter deprecation of subs using the old style calling conventions is not far distant. http://xrl.us/rtk Embedding Parrot in Perl Luke Palmer has started to learn XS in the service of his project to embed Parrot in Perl. Unsurprisingly, he had a few questions. He got a few answers. http://xrl.us/rtl Implementing ISA Leo Tötsch has implemented isa. The unfashionably lowercased chromatic argued that what Leo had implemented should actually be called does. Chris Dutton thought does should be an alias for has. Piers Cawley thinks he might be missing something. http://xrl.us/rtm More on constant PMCs and classes Leo Tötsch's RFC on constant PMCs and classes from last week continued to attract comments about possible interfaces and implementations. http://xrl.us/qxk A miscellany of newbie questions James Michael DuPont a bunch of questions and suggestions about bytecode emission, the JIT and about possibly extracting the Parrot object system into a separate library. Leo supplied answers. http://xrl.us/rtn What the heck is active data? Dan clarified what he'd meant when he talked about Active Data. His one sentence definition being 'Active Data is data that takes some active role in its use -- reading, writing, modifying, deleting or using in some activity'. The consequences of such data are far reaching; even if your code has no active data in it, Dan points out that you still have to take the possibility into account, or solve the halting problem. Benjamin Goldberg seemed to think that you didn't need to solve the halting problem, you could just add scads of metadata to everything and do dataflow analysis at compile time. I look forward with interest to his implementation. Matt Fowles wondered why active data necessitated keyed variants of all the ops, asking instead why we couldn't have a prepkeyed op to return an appropriate specialized PMC to use in the next op. Dan agreed that such an approach was possible, but not necessarily very efficient. Leo Tötsch disagreed with him though. TOGoS wondered if this meant that we wouldn't know whether set Px, Py did binding or morphing until runtime. (It doesn't. set always simply copies a pointer). In an IRC conversation with Dan we realised that some of this confusion arises from the fact that set_string and friends behave as if they were called assign_string; to get the expected set_string semantics you'd have to do: new Px, .PerlUndef set_string Px, some string Hopefully this is going to get fixed. http://xrl.us/rto Mission haiku Nicholas Clark To make some kind of mark Committed haiku. Don't you. Yes, I know that's not a haiku. It's a Clerihew. I suggest that anyone else who feels tempted to perpetrate verse on list restrict themselves to a sestina or a villanelle, or maybe a sonnet. I also note that POD is a lousy format for setting poetry in. http://xrl.us/rtp Jürgen gets De-Warnocked Jürgen Bömmels had been caught on the horns of Warnock's Dilemma over a patch he submitted a while back. It turns out that he'd been Warnocked in part because both Leo and Dan thought he already had commit rights. So that got fixed. Welcome to the ranks of Parrot committers Jürgen, you've deserved it for a while. http://xrl.us/rtq Parrot Z-machine New face Amir Karger wants to write the Parrot Z-machine implementation and had a few questions about stuff. So far he's been Warnocked. http://xrl.us/rtr Notifications Dan described how Parrot's notification system would work, and what that means for weak references. Michael Schwern thought the outlined notification system would also be awfully useful for debugger watch expressions. Tim Bunce worried about some edge cases. http://xrl.us/rts MSVC++ complaints Vladimir Lipskiy (who's been doing some stellar work recently on various build issues amongst other things) found some problems trying to build Parrot with MSVC
This Week's Perl 6 Summary
Perl 6 Summary for the week ending 20030703 Ooh look, it's another Perl 6 summary. Doesn't that man ever take a holiday? I think he took one last month. Is it in Esperanto this week? I don't think so. Does Leon Brocard get a mention? It certainly looks that way. Does it start with the internals list again? I think it does, in fact, here it comes now. Approaching Python Discussions (and coding) of the Parrot implementation of Python continued this week. Michal Wallace is working on taking a preexisting (but incomplete, it's a proof of concept only) python parse tree - parrot code generator and rejigging it to generate code for IMCC. Assuming the initial rejig is doable, Michal surmises that getting a complete python compiler will be 'just' a matter of fleshing out the rest of the visitor methods, 'and then dealing with the C-stuff.' Actually, the main strand of this discussion dealt with ways of extending IMCC to help optimize the translation of stack based code to code that uses registers more efficiently (register unspilling as Benjamin Goldberg called it), which should help with any bytecode translator based efforts. http://xrl.us/crudf http://xrl.us/crukq Semantics of clone for PIO-objects Jürgen Bömmels' work on the Parrot IO system continues to find edge cases in Parrot's memory management subsystem. As initially written, a clone call adds a reference to a ParrotIO object, but that object is neither garbage collected nor refcounted, and it gets destroyed when its first reference is destroyed. The problem can be solved by allocating a new ParrotIO in the clone call, but Jürgen had some questions about how to handle various things like what to do with buffering or position pointers. Jos Visser offered a suggestion involving indirection and reference counting which met with (at least) Melvin Smith's approval. http://xrl.us/crusx Making 'make' less verbose Leo Tötsch checked in a patch to make make's output rather less verbose. After the patch, the make process only echos the name of the file being compiled, and doesn't spam your terminal with the entire compiler commandline (the compiler warnings do that). Some people liked this. Others didn't. http://xrl.us/cruz5 Don't trace system areas in sweep ops One of the things we discussed at the Parrot BOF was how to solve the 'bogus objects' problem when doing timely destruction sweeps (The 'bogus objects' problem is when the stack walk code detects chimerical objects through holes in the C stack (hmm... if anyone has a good drawing of this?)). After much discussion we came to the conclusion that the trick was to only walk the system stack during DOD (Dead Object Detection) runs that got triggered via resource starvation. This works because There is nothing unanchored and alive beyond the runloop's stack. Brent Dax was impressed, but then, he wasn't at the BOF so he doesn't know how long it took us to get to the answer. http://xrl.us/cru73 User defined events Klaas-Jan Stol wondered if there would be some way of generating and posting user defined events. Uri Guttman thought that there probably would be. http://xrl.us/crviz PHP/Parrot The language implementation insanity continues! Stephen Thorne announced that he's working on implementing a PHP parser and is seriously considering targetting Parrot. He asked for pointers to good docs on how to go about doing so. He worried a little about bootstrapping as well. Luke Palmer and Simon Glover were forthcoming with lots of useful answers and pointers. http://xrl.us/crvsa Why Parrot uses Continuation Passing Style In a delayed response to a question from Klaas-Jan Stol, Dan has posted a long message on the reasons for choosing Continuation Passing Style as Parrot's calling convention. It's definitely worth the read if you're at all interested in the reasoning behind Parrot (and the reason that my copy of *Perl 6 Essentials* has a signed correction from Dan). http://xrl.us/crv24 IMCC supports the Parrot Calling Conventions Leo announced that IMCC's brand of assembler, PIR (I can't remember what it stands for, Parrot Intermediate Representation perhaps). Of course, there are things it doesn't quite do yet (tail call detection, only preserving 'necessary' registers...) and it's somewhat lacking on the test front, but it's a start. Yay Leo! http://xrl.us/crv75 Another task for the interested: Coverage Dan threw out another 'task for the interested' this week. At present we don't have a complete set of coverage tests for the parrot opcodes, nor do we even know why opcodes do have coverage. Volunteers to fix this state of affairs (start with a coverage report
This week's Perl 6 Summary
Perl 6 Summary for the week ending 20030727 Welcome to another in the ongoing series of Perl 6 summaries in which your faintly frazzled summarizer attempts to find a native speaker of Esperanto to translate this opening paragraph in honour of the huge amount of money (1371 Euros) raised for TPF during the YAPC::Europe auction, when the official language of both London.pm and Paris.pm's websites were auctioned off as one lot. Somewhat to the surprise of everyone, the winning bid was for Esperanto. As Jouke Visser just commented on IRC, the price was well worth paying just to see the looks of panic on the faces of Mark Fowler, Leon Brocard and other London.pm worthies as the price of keeping the website English (and changing Paris.pm's website to English in the process) shot up beyond the reach of their collective pocket. Meanwhile, we'll return to English and start with the internals list as usual. Events Junior reporter: Mr Macmillan, what caused your greatest difficulties in your time as UK Prime Minister? Macmillan: Events dear boy, events. Whilst I'm not sure Dan would fully agree with Macmillan, there was a certain amount of concern about Events (well, event handling). Damien Neil is still convinced that asynchronous IO is the Wrong Thing, but he hasn't convinced Dan, and (in this at least) it's Dan's opinion that counts. http://xrl.us/nj3 http://xrl.us/nj4 -- Dan ditches the cranky reply Memory system issues Jürgen Bömmels' work on the aforementioned Asynchronous IO system means that he's been getting rather more involved with the internals of Parrot's memory allocation and Garbage Collection system than he intended. He had a few questions, which Dan answered. http://xrl.us/nj5 Splitting core.ops Brent Dax announced that the patch splitting core.ops into a slightly more logical set of smaller files has been committed. This occasioned a small flurry of discussion and a smaller flurry of patches to ensure that all the new .ops files had their associated documentation files built. http://xrl.us/nj6 Parrot docs translated to Japanese Koichi Sasada, a Japanese university student has translated the Parrot Primer into Japanese and put it on his website. He wanted to know if he could publicise the translation. This summary is (at least in part) his answer. http://xrl.us/nj7 http://xrl.us/nj8 -- In English http://xrl.us/nj9 -- In Japanese PMC methods Luke Palmer can't stop thinking of other ideas as he works on implementing lazy PMCs. His latest idea relates to accessing methods on PMCs without having to generate scads of new opcodes (Personally, I don't see what's wrong with using the object stuff for getting both PMC vtable (C) methods and methods that are implemented in Parrot itself.) Luke proposed a few ops which he reckons will solve the problem. http://xrl.us/nka objects.t Failures Simon Glover tracked down a problem with the objects.t test file that had been failing on some, but not all platforms. It turns out that the class_hash wasn't included as part of the root set, which meant that the garbage collector could try to reclaim it before it got used. Which is bad. He supplied a two line patch to fix the problem. Which is good. Dan made with the D'oh!, commenting that he'd known he'd forgotten something. http://xrl.us/nkb RFC: Cleaning up the ParrotIOLayer API Jürgen Böemmels has reached a point in his redoing of the Parrot IO subsystem that he wanted to remove and/or rename several of the old methods so he posted an RFC explaining what he intended to do and asked for comments. Gregor N. Purdy had some comments, mostly to do with the data structures involved (with particular reference to strings) but other than that there has been no further comment. http://xrl.us/nkc Parrot Emits an Executable Daniel Grunblatt checked in a patch to make parrot generate native executables. There are caveats about what must be done in order to get a working executable and the original patch needed to have a few wrinkles ironed out, but this looks like a fantastic start to me. http://xrl.us/nkd Approaching Python Michael Wallace wondered about the issue of compiling python to parrot. He wondered if it would be possible to make use of the existing Python compiler module which generates python bytecode from a parse tree. He wondered if it'd be worthwhile modifying it to generate parrot bytecode. The discussion which followed covered various options for handling Python code, ranging from bytecode transformation to translating the source code into Perl 6 (which is probably the least likely to save Dan from pie). I'm not sure if a particular approach was chosen, but Michael
Re: This week's Perl 6 Summary
Piers Cawley [EMAIL PROTECTED] wrote: Okay, okay, PONIE really stands for 'Perl On New Internal Engine'. That's that what they say. Actually it was: PONIEPONIE: Perl5 Obsoletes Nasty Internals Entirely: Parrot Occupies Numerous Interpreters Everywhere But that was to bulky. Or too many ponies, w/o any camels... [ quote of the week ] Dan: I'm really bad at reading my mails Leo: You should at least read *my* mails Everyone: Hear! Hear! (or words to that effect) s/read/please read/ - albeit the pronounciation of my above is ok ;-) Piers, thanks again for doing these summaries it was a great pleasure to meet you »in personam«, leo
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030615 Welcome to the last Perl 6 Summary of my first year of summarizing. If I were a better writer (or if I weren't listening with half an ear to Damian telling YAPC about Perl 6 in case anything's changed) then this summary might well be a summary of the last year in Perl 6. But I'm not, so it won't. Instead, I'm going to try and keep it short (summaries generally take me about 8 hours on an average day, and I really don't want to lose 8 hours of YAPC thank you very much). It's getting predictable I know, but we'll start with the internals list again... Class instantiation and creation Dan continued slouching towards full OO and outlined the issues involved with setting up classes and asked for people's opinions. People offered them. http://xrl.us/jou Writing Language Debuggers Clinton Pierce wanted to know how to go about writing language level debuggers in Parrot. (This man is unstoppable I tell you.) He offered some example code to show what he was trying to do. Benjamin Goldberg had a style suggestion for the code, but nobody had much to say about Clint's particular issue. http://xrl.us/jov Converting Parrot to continuation passing style A lot of this week's effort was involved in getting support for the Continuation passing style function calling into Parrot. Jonathan Sillito posted a patch. This lead to a certain amount of confusion about what needs to be stashed in the continuation and a certain amount of bemusement about the implications of caller saves rather than callee saves (in a nutshell, a calling context only has to save those registers that *it* cares about; it doesn't have to worry about saving any other registers, because its callers will already have saved them if they cared.) Dan ended up rewriting the calling conventions PDD to take into account some of the confusion revealed. I think the upshot of this is that the Parrot core now has everything we need to support the documented continuation passing calling conventions. But I could be wrong. http://xrl.us/jow http://xrl.us/jox Segfaulting IMCC for fun and profit Clint Pierce's BASIC implementation efforts continue to be one of the most effective bug hunting (in code and/or docs) efforts the Parrot team has. This time, Clint managed to segfault IMCC by trying to declare nested .subs using the wrong sorts of names. Leo Tötsch explained how to fix the problem. It seems that fixing IMCC to stop it segfaulting on this issue is hard, since the segfault happens at runtime. http://xrl.us/joy Passing the time Clint's BASIC can now place chess! Not very well, but we're in 'dogs dancing' territory here. Bravo Clint! There was applause. http://xrl.us/joz Meanwhile in Damian's YAPC address... New DISPATCH method Last week Ziggy worried about multimethod dispatch not being good enough. This week at YAPC, Damian announced DISPATCH, a scary magic subroutine which allows you to define your own dispatch rules. Essentially it gets called before the built in dispatch rules, beyond that, I know nothing. Sorry, no link for this. Meanwhile in perl6-language Ziggy's obsoleted thread Last week I mentioned that Adam Turoff had worried a little about multimethod dispatch, and wanted to know if it would be possible to override the dispatch system in an easy way. This week, he outlines the sorts of things he might want to do. See above for the resolution. Details don't exist just yet, but we'll get there. http://xrl.us/jo2 Type Conversion Matrix, Pragmas (Take 4) Michael Lazzaro posted the latest version of his Type Conversion Matrix and asked for comments and hopefully definitive answers. There was a small about of discussion... http://xrl.us/jo3 Returning from a nested call Whilst idly 'longing for the cleansing joy [of] Perl', Dave Storrs wondered how/whether he could write a method that would return from its caller. Answer: Yes, use leave. http://xrl.us/jo4 printf like formatting in interpolated strings Edward Steiner wondered about having some way to to printf like formatting of numbers in interpolated strings. Luke Palmer (who just told me he's embarrassed about something I wrote about something he said last week, but I'd forgotten it) came up with a cool looking suggestion in response. http://xrl.us/jo5 Acknowledgements, Announcements and Apologies Well, that wraps up my first year of summary writing. Thanks to everyone for reading, it's been fun. I have one announcement to make: As of next week, there will be no obligatory reference to Leon Brocard -- I'm getting bored of it, you all must have been bored with it for months... If you've appreciated this
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030601 Another Monday, another Perl 6 Summary. Does this man never take a holiday? (Yes, but only to go to Perl conferences this year, how did that happen?) We start with the internals list as usual. More on timely destruction The discussion of how to get timely destruction with Parrot's Garbage Collection system continued. Last week Dan announced that, for languages that make commitments to call destructors as soon as a thing goes out of scope, there would be a set of helpful ops to allow languages to trigger conditional DOD (Dead Object Detection) runs at appropriate times. People weren't desperately keen on the performance hit that this entails (though the performance hit involved with reference counting is pretty substantial...) but we didn't manage to come up with a better solution to the issue. http://xrl.us/iu5 Bryan C. Warnock, patchmonster of the week Bryan C. Warnock seems to be attempting to outdo Leo Tötsch in the patchmonster stakes this week. He put in a miscellany of patches dealing with the Perl based assembler, opcode sizes, debugging flags and probably others. Most of them were applied with alacrity. The Perl 6 Essentials book Dan Sugalski gave a rundown of how the Perl 6 Essentials book came about, what's in it and all that jazz. He started by apologizing for not mentioning it before, but he thought he had. This led Clint Pierce to wonder if there was something up with Dan's Garbage Collection system. The existence of the book probably goes some way to explaining Leo Tötsch's relative silence over the last few weeks. Nicholas Clark wondered if it explains why Parrot doesn't have objects yet. Brent Dax wondered when it would be available (by OSCON this year apparently). http://xrl.us/iu6 IMCC, PASM and constants/macros Clint Pierce had some big headaches with moving his BASIC interpreter over to IMCC owing to problems with .constant which is legal for the assembler, but not for IMCC. Leo Tötsch pointed Clint at IMCC's .const operator. Bryan Warnock wondered if IMCC and the assembler's syntax couldn't be unified. Leo noted that it wasn't quite that straightforward because .constant declares an untyped constant, but .const requires a type as well. It turns out that .const wasn't quite what Clint needed, so Leo pointed him at .sym and .local which do seem to do what he needs. http://xrl.us/iu7 3-arg opens Bryan Warnock wondered if open I3, temp.file, r was valid code. Answer, no, the right way to do it is the Perlish open I3, temp.file, . Jürgen Bömmels promised more and better documentation for the Parrot IO system. Eventually. http://xrl.us/iu8 Smaller PMCs Leo Tötsch's work on the new PMC layout continues apace. I'm afraid I don't quite understand what's going on in this area, which does make it rather tricky to summarize things. It seems to have a good deal to do with memory allocation and garbage collection... Leo thinks that it's the right thing, but there seem to be issues involved with good ways of allocating zeroed memory. http://xrl.us/ijt An experimental Wiki for parrot development Mitchell N Charity has put up an experimental Wiki for Parrot and primed it with a few things. Stéphane Payrard pointed out that it's rather hard to make a WikiWord from, for example, PMC. (10 points to the first person to email [EMAIL PROTECTED] with the expansion of PMC). http://xrl.us/iu9 IMCC packfile bug While toying with pbc2c.pl, Luke Palmer discovered that it doesn't want to play with IMCC generated .pbc files. Apparently this is because we currently have two bytecode file formats. Leo Tötsch thought the problem lay with assemble.pl which is old and slow and doesn't produce 'proper' parrot bytecode. Leo also thought that the way pbc2c.pl worked wasn't actually any use. Dan reckoned the time had come to ditch assemble.pl too, and reckoned there was a case for renaming IMCC as parrot since it can run either .pbc or assembly files. Leo liked the idea, but is concerned about the state of the Tinderbox. http://xrl.us/iva Method Calling Dan tantalized all those waiting eagerly for objects in Parrot by discussing how to make method calls. This, of course, means a few new ops, called findmeth, callmeth and callccmeth for the time being. Jonathan Sillito had a few naming consistency issues with the ops. Dan agreed there were issues and asked for suggestions for an opcode naming convention. http://xrl.us/ivb Simple Constant Propagation in IMCC Matt Fowles posted a patch to add simple constant propagation to IMCC. Essentially this means that, say set I0, 5 set I1, 2 set I2, I1 add I2, I0 would
Re: This week's Perl 6 Summary
On Monday, March 31, 2003, at 07:39 AM, Piers Cawley wrote:
Argument initializations
Michael Lazzaro summarized the various different and proposed
assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how these
could be
used in method signatures and proposed some changes to the
signature
system as set out in Apocalypse 6. People were dubious about this,
with
Damian saying I don't think that allowing 20 different types of
assignment in the parameter list of a subroutine actually helps at
all.
I'm not sure Michael is convinced yet.
Nah, I'm convinced that nobody likes the
putting-more-initializers-in-the-sig idea, so it can die. And I'm
convinced that we can't use ::= for the purpose of if-uninitialized,
because it's not consistent with the other meaning.
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined and not present is rather crucial for some
common algorithms. But I have no idea what to propose calling it,
which is a bit of a pickle. :-/
$h{ k } = 'blah'; # always
$h{ k } //= 'blah'; # if not defined
$h{ k } ///= 'blah'; # if not exists ???
MikeL
Re: This week's Perl 6 Summary
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote: I'm still hoping rather desperately for a if-uninitialized op in general, even if only for hashes, because the difference between present but undefined and not present is rather crucial for some common algorithms. Can you give some examples? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: This week's Perl 6 Summary
On Monday, March 31, 2003, at 10:15 AM, Jonathan Scott Duff wrote:
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined and not present is rather crucial for some
common algorithms.
Can you give some examples?
Sure, edited slightly from my last mail...
I suppose my own most common example is a hash representing a cache...
it's entirely possible for Cundef to be calculated and cached, but
that doesn't mean the cache entry is invalid and should be
recalculated every time -- a nonextant key would mean the cache entry
is invalid.
{
$cache.{ $key } = foo($key)# (1)
if not exists $cache.{ $key };
$cache.{ $key };
}
In my own experiences, code similar to the above is awfully common.
An assign-if-not-present form (at least for hashes, but in a magical
fairy world, for arrays/params/whatever, too) such as:
$cache.{ $key } ///= foo($key); # (2)
would be a lot cleaner, and maybe a little faster, since it's testing
C$cache.{ $key } once instead of -- what, 2.5 or 3 times, I guess,
depending on how you count it?
There are other examples -- working with external data sources,
primarily -- but they pretty much always boil down to the same general
concept. I basically want the shortest, *fastest* possible way to say
the caching code above given above.
MikeL
Re: This week's Perl 6 Summary
Piers Cawley writes:
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Actually, I was confused , thinking that state declare trait (is
property ) of the closure , and that could explain examples before
that letter in the thread. But then it became clear that state declare
property ( but property ) of the closure - in the sence that it is born
anew every time closure is created. But then , it is still unclear ,
how one should look at closure - as a variable , as a value , or both.
also , From the post of Larry Wall ,
{...
state $a = INIT/FIRST/ENTER/... { ... } ;
...}
force evaluation of the whole closure at the time prescribed by
INIT/FIRST/ENTER/... .
this is similar to behaviour in perl5:
sub a{ my $x = shift ; my $y ; return sub { INIT{$y=1}; $x+$y } }
print a(1)-(), a(2)-() ; #print 22
so , yes, state creates but property of the closure , but its
initialization controlls when and how many times that closure will be
created.
arcadi
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030330
Welcome once again to the gallimaufry that is a Perl 6 summary.
Unfettered this week by the presence of feline distraction we plunge
straight into the crystal clear waters of perk6-internals.
Iterator proof of concept
People must really like Leo Tötsch's Iterator proposal and patch. There
was only one comment about it this week (from Leo, so I'm not sure if it
counts) asking for thoughts about a possible Ref or Reference class.
Anyone?
http://xrl.us/fao
Bonsai
Zach Lipton announced that he has Bonsai up and running on the Parrot
CVS repository. This gives us a shiny new way of looking at the history
of the distribution. Thanks Zach.
http://tinderbox.perl.org/bonsai
BASIC, IMCC and Windows
Clinton A Pierce had problems trying to get IMCC building correctly
under Win32 in order to generate a binary distribution for the win32
platform. He finally brought up a working IMCC on Friday and asked for
comments about what a binary distribution should look like.
http://xrl.us/fap
http://xrl.us/faq
getopt.macro
Inspired by the argument processing in Leon Brocard's uniq(1)
implementation, Jonathan Scott Duff presented a getopt macro for Parrot
programmers. Benjamin Goldberg had a few suggestions about how to make
things a little more flexible.
http://xrl.us/far
Patch to examples/assembly/cat.pasm
Paul Duncan offered a patch to examples/assembly/cat.pasm which would
cause it to terminate when it received a ctrl-D.
http://xrl.us/fas
IMCC and scientific notation
Having got IMCC working in a win32 environment, Clinton A Pierce
discovered that IMCC didn't understand scientific notation, but the
parrot assembler does. Leo Tötsch pointed out that it sort of does, but
instead of 1e20 you have to write 1.e20. Joseph Ryan wondered if
handling scientific notation wasn't really a job for individual
compilers, but Clint and Mark Biggar explained why this wasn't a good
idea. As Mark said, in a world with BigFloats you don't want to have to
expand 1e2048 into a 2049 character string if you can possibly help it.
http://xrl.us/fat
RT spam
Someone claiming to be Marla Hurley crawled out from under a stone and
took it upon themselves to offer credit to the perl6 RT installation.
Thanks. We needed that.
Meanwhile, over in perl6-language
The language list was again busier than the internals list this week,
but volume has fallen on both lists. (If you don't count an off topic
thread on the internals list, which I haven't, there were only 22
messages there this week. And very few patches from Leopold Tötsch, I
hope he's all right.)
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Larry saw something in it, and the question shifted to ways of doing
state variable initialization, which in turn led to possible changes in
the various control of flow keywords. As Larry pointed out, if you have
a static variable:
state $variable
Then, assuming that you need 'undef' to be a possible value for your
variable, you need some way of doing once and only one initialization of
that variable.
state $variable;
ONCE_AND_ONLY_ONCE { $variable = $initial_value };
The problem is that INIT and CHECK blocks happen too early; in the code
above, $initial_value may well not be set, if your state variable is set
up inside a closure this becomes even more likely. Larry reckons that
the most useful initialization semantics appear to be 'just in time'. In
other words you want initialization to happen on the first actual call
to a closure. But FIRST {...} is already taken, so Larry is
considering renaming FIRST and LAST to ENTER and LEAVE, freeing up FIRST
to mean my very first time. Freudian analysis was discouraged.
http://xrl.us/fau
Argument initializations
Michael Lazzaro summarized the various different and proposed assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how these could be
used in method signatures and proposed some changes to the signature
system as set out in Apocalypse 6. People were dubious about this, with
Damian saying I don't think that allowing 20 different types of
assignment in the parameter list of a subroutine actually helps at all.
I'm not sure Michael is convinced yet.
http://xrl.us/fav
P6ML?
Michael Lazzaro asked if anyone was actually working on P6ML (a project
name that popped up last week in the 'XML is too hard for Programmers'
thread) and if there was any idea of what such a project would
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030316 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://makeashorterlink.com/?E133153C3 -- Feature freeze http://makeashorterlink.com/?F353239D3 -- 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://makeashorterlink.com/?J263219D3 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://makeashorterlink.com/?D473519D3 http://makeashorterlink.com/?W283539D3 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://makeashorterlink.com/?R293459D3 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://makeashorterlink.com/?J3A3219D3 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://makeashorterlink.com/?G2B3129D3 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
megillah (was Re: This week's Perl 6 Summary)
PC == Piers Cawley [EMAIL PROTECTED] writes: PC To do that you need to declare the parameter with is PC copy. Uri noted that he really should keep his finger off the PC send button until he's read the whole 'megilla', whatever one PC of those is. it is appropriate that today is purim, which is the holiday that celebrates the story of queen esther and mordachai's victory over the evil haman. the book of esther is one of the 5 books in the bible that were traditionally written on a single scroll which is called a megillah. the torah (5 books of moses) on the other hand is written on a double scroll where you wind up on one spindle and unwind from another spindle. so megillah really just means a type book and is used colloquially as i did above. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: megillah (was Re: This week's Perl 6 Summary)
--- Uri Guttman [EMAIL PROTECTED] wrote: PC == Piers Cawley [EMAIL PROTECTED] writes: PC To do that you need to declare the parameter with is PC copy. Uri noted that he really should keep his finger off the PC send button until he's read the whole 'megilla', whatever one PC of those is. it is appropriate that today is purim, which is the holiday that celebrates the story of queen esther and mordachai's victory over the evil haman. the book of esther is one of the 5 books in the bible that were traditionally written on a single scroll which is called a megillah. the torah (5 books of moses) on the other hand is written on a double scroll where you wind up on one spindle and unwind from another spindle. so megillah really just means a type book and is used colloquially as i did above. The stuff I learn on this list amazes me. Thanks, Uri. =Austin
Re: This week's Perl 6 Summary
Piers Cawley wrote: Coroutines end and DFG Nobody explained what DFG stands for. It's a commonly used TLA standing for Data Flow Graph, which accompanies the CFG (Control Flow Graph). Both are necessary for register allocation. leo
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030309 Ooh look, it's another of those Perl 6 Summaries where Piers tries to work a gratuitous reference to Leon Brocard into a summary of what's been happening to the Perl 6 development process this week. As tradition dictates, we'll start with all the action from perl6-internals. Object Specs With his great good taste and impeccable timing, Dan Sugalski managed to release his second draft of an Object spec at 22.27 GMT on Sunday March the second. Which meant that, strictly, the root message of this thread doesn't belong in this summary. To which I say 'Tosh!' Brent Dax wondered how this spec coped with classless OO languages like JavaScript and whether such languages would have to fake things with anonymous classes. It seems that faking it is going to the 'right' way. Erik Bagfors asked for a clear example of the difference between attributes and properties, and between class and object variables. Dan didn't actually offer an example, but explained that properties are 'runtime assigned name values pairs that are stuck on a variable', while attributes 'correspond to instance variables or slots in other object systems'. Dave Whipp wondered about the semantics of creation and destruction of objects with a long list of questions. Dan replied that there was a 'Class Spec' forthcoming at some point too. The Object spec concerns itself with 'just the behaviour of objects that already exist'. Some further discussion of this happened in perl6-language, but Dan dragged it back into perl6-internals. I shall follow his example by summarizing those subthreads here, whilst muttering rude words under my breath about people make a poor summarizer's life so hard. Garrett Goebel (not Göbel, as I mistakenly spelt it last week) wondered about serialization and persistence and wondered whether a 'pure Parrot' serialization scheme would be possible, allowing one to serialize Perl, Python, Ruby etc objects at the Parrot level. Dan pointed out that there were freeze and thaw vtable entries for PMCs, and said that he had some 'sketches of necessary core functionality to make it feasible'. It looks like simple 'data objects' will be simple to serialize at the parrot level. Sam Vilain suggested a whole bunch of extra things to be associated with Objects. Dan noted that all of Sam's suggestions were actually things that belonged with Classes rather than objects, with the exception of what Sam referred to as 'associations'. Garret asked for some clarification of what Sam was talking about, tying it to something Sam had said in perl6-language about 'exporting object relationships in a sensible and consistent manner', so Sam did a brain dump which outlined a scheme for persisting almost anything in a language neutral manner (requiring more or less complicity on the part of some languages) with loads of neat ideas in it. Dan liked the ideas, but isn't going to go the whole way (probably). Dan also implied that Parrot's serialize/deserialize methods would make use of the GC system to make sure that everything gets dumped properly, once and only once, solving the problem of cyclic references (YAY! An OO Persistence tool writer writes). Dan released the next iteration of his tentative object spec on Sunday (but a little earlier this time). He and Uri Guttman spent the rest of the day thrashing out some issues and clarifying some terminology. Dan is threatening a glossary with the next try at an object spec. (Dan just suggested on IRC that I summarize these threads as 'Dan muttered incoherently about objects again. Folks generally humored him.' Which I would never do of course; I'm English and I know how to spell 'humour'.) http://makeashorterlink.com/?L22455AA3 -- Object spec (try 2) http://makeashorterlink.com/?M2A2623C3 -- Garrett's first question http://makeashorterlink.com/?M2B2323C3 -- Sam Vilain's suggestions http://makeashorterlink.com/?P2C2323C3 -- Garrett asks for clarity http://makeashorterlink.com/?W2D2523C3 -- Sam's brain dump. http://makeashorterlink.com/?S1E2213C3 -- Object Spec (try 3) IMCC and multiple source files K Stol wondered whether it was possible to write multi-file IMCC programs. Leopold Tötsch answered that, whilst there's no Parrot linker as yet, but by the time we read his post we could use the .include macro to glue source files together. http://makeashorterlink.com/?A5F2213C3 Patch Roundup Jason Gloudon added some more ops to the sun4 JIT core. His patch was applied, along with most of Steve Peters' patches from last week. Jürgen Bömmels patched the print ops to use pure PIO (Parrot IO) rather than a scary stdio/PIO hybrid. Dan applied this one with alacrity (I
Re: This week's Perl 6 Summary [OT]
--- Leopold Toetsch [EMAIL PROTECTED] wrote: Piers Cawley wrote: Coroutines end and DFG Nobody explained what DFG stands for. It's a commonly used TLA standing for Data Flow Graph, which accompanies the CFG (Control Flow Graph). Both are necessary for register allocation. leo So what's a TLA? :) btw, great work Leo...in general! ;o] __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com
This week's Perl 6 Summary
The Perl 6 summary for the week ending 20030216
Welcome to the all new, entirely unaltered, all singing, all dancing
Perl 6 summary. Your beacon of reliability in the crazy world that is
Perl 6 design and development.
Another quiet week. Even quieter than last week in fact, unless my mail
spent some of the time up the spout, but I don't think so.
So, as is traditional, we kick off with perl6-internals
CGP - The Computed Goto Prederefed Runloop
Last week I mentioned that nobody seemed to have commented on Dan's bet
with Guido van Rossum that Parrot would outperform Python by OSCON 2004.
(I also missed the fact that the penalty for losing the bet now involves
cream pies as well as $10 and a round of drinks...). After I posted the
summary to the mailing lists, Leopold Tötsch informed me that he had
commented indirectly by announcing his new, improved, ludicrously quick
runloop that combines computed GOTOs and predereferencing. Whatever that
means.
This week, Leo and Nicholas Clark worked out how to combine the
blistering pace of the JIT core (for operations that had been translated
into hand hacked machine code) with the blistering pace of the CGP
runloop (for the other ops). As far as I can tell, this involved turning
the idea 'inside out', the VM actually starts up running JIT compiled
code and calls out to the CGP core to execute non-JITable sequences of
ops. The numbers for this approach look fantastic (quite stunningly
quick...) So Leo checked it in.
http://makeashorterlink.com/?Y27C12083
http://makeashorterlink.com/?Q48C22083 -- Some numbers
http://makeashorterlink.com/?G19C21083 -- Check in notice
Optimized runloops and threading issues
Last week we were reminded that JIT and predereferenced runloops don't
work in a threaded environment. This week Jerome Vouillon pointed out an
approach that looks like it could fix that (it seemed to convince Leo).
Dan (possibly playing mail catchup) said he was okay with having to fall
back to the old fast core (as opposed to the current, stupidly fast
core) in the presence of threads, but Leo seem to think that, using
Jerome's scheme we'll be able to have our cake, eat it and still throw
the cream pie at the Python team. Huzzah!
http://makeashorterlink.com/?P2AC23083
keyed_int issues
Leo Tötsch had wondered about why {get,set}_type_keyed_int vtable
methods needed to take an INTVAL* value instead of a plain INTVAL as
it introduced some possibly unneeded conditional code, a stack variable
for the key and made life hard for JIT code. It looks like the pointer
is a holdover from an early approach to doing multidimensional keyed
structures.
http://makeashorterlink.com/?W2BC32083
Changes to the calling convention and other fallout
Dan returned from the Sebastapol Perl 6 meeting with a few announcements
and one change in the parrot calling convention (how many calling
conventions have we had now?).
http://makeashorterlink.com/?N2CC62083
Macro support in IMCC
Jürgen Bömmels announced that he'd implemented macro expansion in IMCC
(Yay Jürgen!). Leo liked it, but requested a few changes before he'd
check it in, so hopefully, some time soon the mainline IMCC will have
macros, which is very nice.
http://makeashorterlink.com/?A2DC15083
Meanwhile, in perl6-language
Almost all the discussion was about the difference between arrays and
lists. Deborah Ariel Pickett came up with a good list of questions about
arrays and array references in scalar and list contexts, which Michael
Lazzaro answered (very neatly I thought) with a list of their different
contextual behaviours. Deborah extended Michael's list to hashes and
hashrefs in a reasonably obvious way. Smylers came up with a possible
new sigquote (after paraphrasing): We should limit new features to
those that arise from a desire for the functionality rather than a
desire to use up 'spare' syntax. (Okay, it's not exactly *snappy*, but
I think it's important).
http://makeashorterlink.com/?H1EC23083 -- Deborah's questions
http://makeashorterlink.com/?C1FC42083 -- Michael's answers
And that wraps it up for the language list. I'm sure it'll pick up again
soon though. There are rumours of a draft apocalypse in the next couple
of weeks, and presumably that implies a real apocalypse soon after.
Assuming we haven't had another kind of Apocalypse in the mean time.
Announcements, Acknowledgements and AnotherWordBeginningWithA
This week's summary was again prepared in the comfy chair with
surprisingly few distractions apart from the late arrival of mail from
Leon Brocard announcing that he'd implemented a brainf*ck compiler in
brainf*ck, but that didn't really happen this week so I've got no excuse
for mentioning Leon's name in this
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030209 Welcome to the latest Perl 6 summary, your handy cut out and keep guide to the goings on in the crazy world of Perl 6 design and development. It's been a rather quiet week this week; only 75 messages in perl6-internals and a mere 57 in perl6-language. So, at least it's palindromic. We start off, as is traditional, with perl6-internals The 2004 Performance challenge Dan announced that he'd made a bet with Guido van Rossum that Parrot would be faster at executing a pure python benchmark of some sort to be determined. The details of the challenge will be announced at OSCON 2003 and the results at OSCON 2004. Dan stands to lose $10 and a round of beer for the Zope/Pythonlabs folks. (Dunno how many of them there are though...). We don't know what he stands to win yet, but I'd hope 'beers from each of the Zope/Pythonlabs folks' are included. For some reason nobody commented on this. http://makeashorterlink.com/?K2C815C63 More Parrot Objects Jerome Quelin wondered how Parrot objects would handle property inheritance. Dan pointed out that properties don't get inherited and Jerome realised he meant to ask about attribute inheritance. Attributes *are* inherited but are mostly invisible to any methods but the methods of the class that defines the attributes (though they will be accessible (presumably through reflection)). In another subthread, we got confused by multimethods. http://makeashorterlink.com/?O6D816C63 http://makeashorterlink.com/?O4E822C63 -- Multimethods Bytecode Metadata James Michael DuPont wanted to know what had been decided about Bytecode metadata and outlined the things that he'd like to know about a given bytecode. Leo Tötsch reckoned that what James wanted was either in the bytecode right now, or was handleable by the framework that was in place. He pointed James to docs/parrotbyte.pod in the Parrot distribution. Further discussions centred on the *amount* of metadata and whether this would affect loading speed and efficiency, or get in the way of the desired 'mmap and go' principle. Jürgen Bömmels pointed out that we also had to be capable of passing meta data from a compiler 'through' IMCC and on to the final bytecode. There was also a touching reunion between James Michael DuPont and Gopal V. Ah... http://makeashorterlink.com/?E41925C63 Multi programming language questions Phil Hassey has been lurking, fascinated on the internals list for a couple of months. This week he broke the silence by asking a couple of questions about cross language function dispatch, string compatibility and global scopes. For instance, PHP, Common Lisp and others are case insensitive about functions. Which is okay when you're calling such a function from a case sensitive language, but can be tricky if you call out from a case insensitive to a case sensitive language. Dan thought that there wasn't going to be much that could be done about this problem (at least, not transparently) but seems to think that the other issues raised shouldn't be too problematic. http://makeashorterlink.com/?R32931C63 Random questions David popped up and, after remarking on the amount of progress Parrot had made since he last looked at it, had a few questions about various bits and pieces. Leo and Dan provided a bunch of good answers. http://makeashorterlink.com/?X63912C63 A Scheme for extending core.ops Leo Tötsch seems to have got bored of 'just' being the Patch Monster and has been producing some discussion documents proposing all sorts of useful tricks for improving the design/speed/extensibility of Parrot's internals. This week he turned his attention to core.ops. His plan involves a way of reducing the size of core_ops, improving cache locality and generally solving a raft of problems I didn't even know Parrot had. His new scheme allows for a small core.ops, easy extension and no execution speed penalty for non core ops. As is usual with Leo's stuff, the scheme came with code. Gregor had a bunch of observations and suggestions and he and Leo thrashed out a slightly modified scheme for going forward. http://makeashorterlink.com/?P54921C63 Week of the alternative runloops Leo Tö offered a couple of different core runloops this week. First up was the Computed Goto Prederefed (CGP) runloop which, essentially combined a two runloop optimization techniques to provide what can only be described as massive speedups. The -O3 compiled version ran parrot_mops 6 times faster than the basic 'fast_core' and more than 3 times faster than the previous fastest core. People were impressed. A few days later, Leo reached into his bag of tricks and pulled out the CSwitch runloop that did
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030126 Welcome to the first Perl 6 summary of the new 'Copious Free Time enabled' era, which should mean that these summaries will get mailed out on Monday evening from now on. We start, as usual, with perl6-internals The eval patch Leopold Tötsch continued to work on making eval and its associated operators work and asked for some opinions about a problem he was having with jumps between code segments. Jason Gloudon played sounding board and the two of them found a way forward. http://makeashorterlink.com/?I27426D33 The Parrot crashes Dan announced that Parrot was crashing big time under (at least) OS X, throwing segfaults in the NCI mark routine. Other people contributed reports of what was happening on their platform and Leo Tötsch tried to track down the error, working on the assumption that it was something to do with his eval patch as that was the last patch that had gone in. Later in the week Dan realised that part of the problem with OS X was a problem with imclexer.c, an autogenerated file being generated with bad code. Leo reckoned it was a problem with something having been multiply defined, which had since been fixed. Still later in the week, Steve Fink offered some analysis on the NCI mark routine and a patch which attempted to fix the problems he saw with it. Leo reckoned that the patch wasn't quite right, but the analysis was good and used that to fix the problem and discovered in the process that the parrot build process's dependency analysis wasn't quite up to the mark. (I don't think there's a fix for that yet, but at least we know the problem exists...) http://makeashorterlink.com/?D18434D33 http://makeashorterlink.com/?R39426D33 http://makeashorterlink.com/?A2B432D33 Compiling to Parrot K Stol is looking for a final project for his Bachelor's degree and would like to implement some language targeting Parrot and asked for suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested Java (though Gopal V wasn't sure that was such a good idea just yet). Dan suggested that, just because someone else was already working on a TCL compiler it didn't mean it wasn't worth trying anyway, but apparently it would have been unlikely to get approval as a Bachelor's project. There was some further discussion of Lua and whether there would be any real point in implementing it and the thread died down before Mr Stol told anyone what he'd decided to do, which was rather a shame I thought. http://makeashorterlink.com/?R1C423D33 Extending the packfile format Some months ago, Jürgen Bömmels offered a patch to extend the Parrot packfile format whilst retaining backward compatibility. This week, after a little modification, Leo Tötsch applied it. James Mastros wondered if it didn't make sense (at least before parrot 1.0) to ignore backward compatibility issues and just make it right. Leo and Dan agreed, but Leo pointed out that, at least until the switch from assemble.pl to IMCC was complete, maintaining backward compatibility was the right thing. (So, if you're currently using assemble.pl to assemble your language, consider moving it to IMCC sooner rather than later). http://makeashorterlink.com/?U5D442D33 The long running Objects thread Discussions continued. A good deal of time this week was spent discussing the overrideablility (there's got to be better word than that...) of OO method dispatch for different languages (and at a language level too I hope -- I like flexibility). Python for instance seems to require that every step in the process be subject to override. Dan pointed out that dispatch would end up being implemented as vtable methods on per language Object PMCs so that messages from one language's objects to another's would use the target language's dispatch rules. Which seems rather cute (in a good way). http://makeashorterlink.com/?P3E424D33 -- Christopher Armstrong talks about Python http://makeashorterlink.com/?H1F442D33 -- Dan on how it works. Intersegment branching Leo Tötsch added a new opcode for intersegment branches, called branch_cs which was his implementation of the fix that he and Jason Gloudon had discussed while talking about problems with eval. Dan didn't think Parrot needed this and that we could just use a plain jump. Leo pointed out that there were several places where this didn't quite work, especially in the presence of JIT optimization. Dan didn't think that didn't mean it wouldn't work, but reckoned that the cases Leo pointed out were reasons he wanted to see intersegment jumps mediated by subroutine calls. Leo followed up to this with an example. I can't for the life
This week's Perl 6 summary
The Perl 6 Summary for the week ending 20030119 Summary time again, damn but those tuits are hard to round up. Guess, what? perl6-internals comes first. 141 messages this week versus the language list's 143. Objects (again) Objects were still very much on everyone's mind as the discussions of Dan's initial thoughts about objects in Parrot continued. Jonathan Sillito put up a list of questions about Dan's original message which Dan answered promptly. Down the thread a little Dan mentioned that he hoped Parrot's objects would serve, reasonably unmodified for a bunch of languages (ie, he hoped that there wouldn't be a requirement for PythonRef/Attr/Class/Object etc), Chris Armstrong thought that, given what Dan had outlined so far, that wouldn't be straightforward. Dan thanked him for throwing a spanner in the works, asking for more details which Chris provided. Meanwhile Jonathan had some supplementary questions... Hmm... doing this blow by blow will take forever. Suffice to say that details are being thrashed out. At one point Dan's head started to spin as terminology mismatches started to bite, leading Nicholas Clark to suggest an entirely new set of terms involving houses and hotels (but with some serious underpinnings). http://makeashorterlink.com/?Y21952033 -- thread root, from last week. http://makeashorterlink.com/?M52912033 -- Jonathan's questions http://makeashorterlink.com/?A23912033 -- Chris throws a spanner http://makeashorterlink.com/?Z44922033 -- Nicholas tries for a monopoly on silliness Optimizing and per file flags Nicholas Clark wrote about requiring the ability to adjust compiler optimization flags on a per file basis (brought up by Dan on IRC apparently) and proposed a scheme. Quote of the thread (and quite possibly the year so far): When unpack is going into an infinite loop on a Cray 6000 miles away that you don't have any access to, there isn't much more you can do. Thanks for that one Nick. http://makeashorterlink.com/?I15965033 The draft todo/worklist Dan posted his current todo/worklist, which he described as reasonably high level, and a bit terse. I particularly liked the last entry Working Perl 5 parser. Surprisingly, there was very little discussion, maybe everyone liked it. http://makeashorterlink.com/?L56921033 Parrot Examples Joe Yates asked if we could add a helloworld.pasm to parrot/examples/assembly. Joseph Guhlin wondered what was so special about print Hello, world\n end that it would need a file of its own (though he did forget the end in his post, and segfaults are not really what you want in sample code). http://makeashorterlink.com/?E27912033 Thoughts on infant mortality (continued) Jason Gloudon posted a wonderfully clear exposition of the problems facing anyone trying to implement a portable, incremental garbage collector for Parrot which sparked a small amount of discussion and muttering from Dan about the temptation to program down to the metal. http://makeashorterlink.com/?X38931033 Operators neg and abs in core.ops Bernhard Schmalhofer posted an enormous patch adding neg and abs operators to core.ops. There were a few issues with the patch so it hasn't gone in yet and an issue with what underlying C functions are available reared its head too. http://makeashorterlink.com/?L29951033 The eval patch Leo Tötsch seems to have spent most of the week working on getting eval working and he opened a ticket on rt.perl.org to track what's happening with it. The response to this can be summarized as 'Wow! Fabulous!'. Once more, for Googlism, Leopold Toetsch is my hero. http://makeashorterlink.com/?I5A922033 Pretty Pictures Mitchell N Charity posted some pretty pictures that he'd generated with doxygen and graphviz. Most of the responses to this suggested he use different tools. Ah well. http://makeashorterlink.com/?B2B921033 Solaris tinderbox failures Andy Dougherty created an RT ticket for the Solaris tinderbox, which have been failing with the delightfully useful 'PANIC: Unknown signature type and wondered if things could be fixed up to be a little more informative. Apparently it was as issue with Leo's recently checked in eval patch. So Leo fixed it. http://makeashorterlink.com/?D1C925033 Parrot compilers Cory Spencer wondered about how the current compilers that target parrot work, noting that they seem to be duplicating a good deal of labour, and wondered if anyone had worked on a gcc like framework with a standardized Abstract Syntax Tree (AST). Everyone pointed him at IMCC. Gopal V also pointed out that, given the variety of implementation languages (C, Perl, Parrot...)
This week's Perl 6 summary
The Perl Summary for the week ending 20021222 Hello, good morning and welcome to the Christmas edition of the Perl 6 summary. For some reason I have convinced myself to sit here on Christmas Eve writing a summary for all you crazy kids out there who hang on my every word. Plus, it beats wrapping all the presents and last minute panic shopping. So, let's get perl6-internals out of the way first. The Road to 0.0.9 The first half of the week saw a feature freeze in the run up to the release of Parrot 0.0.9, so people spent their time trying to track down and fix various tinderbox issues and other bugs. Steve Fink worked on trying to get the NCI (Native Call Interface) tests to work properly. Simon Glover and Leo Tötsch worked on tracking down a GC bug that was causing problems for the scratchpad tests. Andy Dougherty is having problems getting languages/perl6 to pass its tests. Apparently part of the problem is that the undef function isn't fully defined. Andy also found problems with sprintf and 64 bit INTVALs (fixed by Brent Dax), PMCs and 64 bit INTVALs (fixed by Leo Tötsch), PerlHashes and gcc-2.95.3 and 2.8.1 on Solaris (confirmed as a problem with other versions of gcc on Solaris by Joshua Hoblitt), dependency issues between Jako and IMCC from a clean directory and problems with the Jako life implementation. Bruce Gray sent a pile of fixes for Win32 systems, covering GC and build problems. Compiling to ParrotVM Klaas-Jan Stol is thinking of writing a compiler that targets Parrot for his Bachelor's in Computer Science, probably a TCL compiler, and he asked for suggestions and tips. David Robins made a few suggestions and pointed out that parrot is a moving target. Dan protested that it wasn't moving that much (If I 'adn't nailed it to the perch, it'd've muscled up to them bars and... VOOM!) and said that he thought a TCL to Parrot compiler would be great. Will Coleda put up a URL for his first pass at such a beast and asked that we be gentle with him (he put up a URL for his second pass later, which is the link below). Gopal V pointed out that IMCC may be a better target than Parrot assembly as that took care of register allocation and generally helped programmers retain their hair and also suggested that, if the compiler was written in C then DotGNU's TreeCC would be worth looking at. Tanton Gibbs, who is working on a C++ compiler agreed that TreeCC is 'an extremely nice system' that he recommended highly. http://makeashorterlink.com/?T27042FD2 http://www.coleda.com/users/coke/parrot/ http://makeashorterlink.com/?H2CF62ED2 Register scanning Apologizing for reopening the register scanning can of worms, Steve Fink wondered about the requirement that all Parrot GC implementations scan all hardware registers for live pointers. Apparently this is a real problem with, for example, the IA64 architecture. He proposed that configure probe for systems that would support register scanning GC, but that the default implementation should use a 'registration' system. He followed this up with a 'naive' implementation of such a system. Jason Gloudon suggested another scheme that I'm afraid I didn't understand to implement 'accurate' GC. http://makeashorterlink.com/?L2DF41ED2 http://makeashorterlink.com/?T1EF22ED2 Returning a new PMC from ops David Robins wondered about the cleanest way to return a new PMC from an op. He and Leo Tötsch thrashed it out. http://makeashorterlink.com/?K1FF62ED2 Parrot v0.0.9 Nazgul released Steve Fink announced the release of Parrot version 0.0.9, aka Nazgul complete with a long list of new features, and the usual call for further assistance. Well done everyone. As Steve says, Parrot is getting dangerously close to being really usable... http://makeashorterlink.com/?X10022FD2 http://makeashorterlink.com/?C51024FD2 Meanwhile, in perl6-language It was quiet... too quiet. Only 48 messages in perl6-language, maybe we're all keeping quiet so as not to distract Larry from writing the next Apocalypse. Comparing Object Identity This thread (along with every other thread in the language list this week) continued from last week. Dan pointed out that using long lived object IDs (ie. unique for all time) would be expensive, and reckoned that the basic approach should be fast and good enough for the common case. Piers Cawley wondered if doing object 'identity' comparison with a method (eg: $obj.is($other_obj);) wasn't actually the best way forward. (Piers had been applying his OO rule of thumb -- if you're not sure of how to do something, take a look at a Smalltalk image). Dave Whipp proposed an adverb syntax ($a eq : ID $b) which would be generalizable: $a eq:i
Re: This week's Perl 6 summary
On Tuesday, December 24, 2002, at 02:55 AM, Piers Cawley wrote: Apparently part of the problem is that the undef function isn't fully defined. Well, isn't that sort-of the point? :-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
This week's Perl 6 summary
The Perl 6 Summary for the week ending 20021117 Oh! my ears and whiskers, I'm late! It's 0650, it's 20021120 and I've only just started writing the summary. Call me lazy, call me a shirker, call me anything you damn well please, just don't interrupt me while I'm writing this. Yup, it's past time for another peek into the lives of those strange beings we call the Perl 6 development community, starting off, as usual, with the perl6-internals crew. Quick Roadmap Dan returned unscathed from this year's Lightweight Languages workshop and presented a short roadmap for the next few miles. Dan reckons that if we hit all those milestones we'll have a complete imperative core. Which will be nice. http://makeashorterlink.com/?N1CE21482 Branch Dump Michael Collins stuck his head above the parapet to report that using branch provoked a core dump on his Linux setup. It turned out to be a problem with his code. Dan debugged his code and offered a reasonably full explanation of how parrot's branch actually works (and why you should really use labels in hand written assembler.) Gopal V worried that allowing branches to non-instructions was unsafe and wondered if, at least, a parrot -fverify switch might be in order. Dan agreed, but his reasoning was somewhat different. Elsewhere in the thread Dan tells us that he wants safe interpreters to be as safe as a locked down VMS system, but he's unsure as to whether we'll reach that gaol. (Mmm... nice typo there Piers, leave it) http://makeashorterlink.com/?P2DE44482 http://makeashorterlink.com/?X6EE23482 Parrot BASIC 2 Clinton A. Pierce announced his complete re-write of BASIC for Parrot, this time modelling his implementation on QuickBASIC. Here's a list of the new features, lifted from Clint's announcement: * Compiled directly to Parrot Assembly * Interpreted * Richer syntax than Parrot BASIC 1.0, which was based on GW-BASIC * Much, much faster than Parrot BASIC 1.0 * Support for user defined types * Support for variable scopes (but apparently, QuickBASIC scoping is 'bizarre') Nobody said anything -- I think they were rendered speechless. However, I'd like to take the opportunity to use this platform to say Yay Clint!. This is superb news. Okay, so supporting BASIC wasn't exactly Parrot's initial goal, but it's great to see that a single hacker can implement such a complete language using Parrot. http://makeashorterlink.com/?L2FE14482 scope and functions in languages/scheme Not to be outdone by Clint's BASIC implementation, Jürgen Bömmels has taken advantage of Jon Sillito's lexical scopes patch to add functions to scheme (before it was just scheme syntax, now it has some claim to being really scheme like). Bravo Jürgen! http://makeashorterlink.com/?H20F35482 Leo Tötsch is the Patch Monster This week, Leo has been mostly: * Fixing JIT to make it restartable * Fixing JIT to make it play well with Perl 6 * Fixing JIT so you can see what's going on when you use gdb. And generally seeming to pop up with useful contributions in almost every thread. Where does he find the time? Bootstrapping Perl 6 Marius Nita asked about the Perl 6 compiler, wondering what language it'd be written in, Perl or C? Markus Laire thought it'd eventually get written in Perl 6 or Parrot `or something else which runs on parrot'. Gopal V worried about the bootstrapping problem and asked that the Perl 6 compiler be written in something other than Perl 6 in an attempt to avoid a `dependency hellhole'. Brent Dax pointed out that we're pretty much obliged to write Perl 6 in Perl in order to get the self modifying parser behaviour and noted that we'd ship it as bytecode. Nicholas Clark pointed out that, strictly, you can't build perl5 from scratch without an installation of perl5, but the p5porters get 'round the problem by shipping the generated headers as part of the perl5 tarball. Dan points out that the goal is for Parrot to require a C compiler and a platform shell or Make tool (either should do). Nicholas Clark attempted to kick off a variant of Monty Python's `Yorkshiremen' skit (Make tool? Luxury! We 'ad to make do wi' a console and switches! You were lucky! We used to 'ave to mek waves in' t'mercury delay line wi' us tongues!), reckoning that it should be possible to get by with just a C compiler and asked that we `archive this message and hold it against me when the time comes, and you're looking for someone to prove it by making it work'. http://makeashorterlink.com/?V31F34482 http://makeashorterlink.com/?W32F15482 -- Archive this message Quick note on JIT bits Dan announced that he was about to `do exceptions' and wanted to give a heads
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20021110
Far off in distant Newark a figure, muttering something about `Leon
Brocard', shambles across a railway bridge and makes its way into a
waiting room. Time passes. After a while, a train arrives and the figure
shambles on board, takes its seat, pulls a laptop from its bag and
starts to type. This is what it types: `=head1 The Perl 6 Summary for
the week ending 20021110'.
Yes, it's time for another update on the japes and tomfoolery from the
world of Perl 6. We start, as usual, with perl6-internals.
The Myth of Fingerprints
At the end of the previous week, Gregor posted an outline of his
proposal for fixing the fingerprinting issue with dynamic loading. (The
fingerprinting issue is that 'old' .pbc files may break big time when
run on newer Parrots. Ideally we'd like Parrot to refuse to run such
files *before* bad things happen. It's proposed that this be done by
adding `fingerprints' to .pbc to allow for identification by Parrot.)
Leopold Tötsch wasn't at all sure about Gregor's approach, pointing out
that it would have massive speed implications, and lo, the thread got
dragged off in the direction of a discussion of optimizing Parrot for
speed. How did that happen then?
http://makeashorterlink.com/?T12252F62
on_exit not portable
Andy Dougherty pointed out that Solaris doesn't have on_exit, which is
used by Parrot to clean up after itself, and suggested that
interpreter.c be reworked to use atexit. However, SunOS has on_exit
but doesn't have atexit. It's a quandary. Josh Wilmes suggested
implementing Parrot_on_exit() and Parrot_exit() in platform.c and
half promised a patch (unless somebody beat him to it.) Leo Tötsch and
Nicholas Clark both said, essentially Nice idea, go do it.
Dan chimed in, pointing out that the current on_exit behaviour seemed
to be there as a workaround for bugs in exceptions, and that fixing
those was probably the better idea. Leo turned off the 'on_exit' stuff,
just as Josh was sending a patch implementing the Parrot_* functions. I
think that, as we now stand, we're back to doing exit cleanup, but using
the portable Parrot_* functions.
http://makeashorterlink.com/?F53246F62
http://makeashorterlink.com/?G14231F62
Should memory be washed?
Peter Gibbs was unsure of the guarantees given by Parrot_allocate and
friends regarding the contents of the memory supplied. Apparently, some
code appears to assume that it will get pre-washed memory, while other
code does its own cleaning. Which is right? Leo Tötsch reckons that the
current behaviour (memory is zeroed at allocation time) should be
guaranteed. Dan wasn't so sure that this was a good idea if we go for a
`malloc like' scheme and thought that it could be argued that it was a
bug for any code to assume that the memory it got was zeroed.
Eventual consensus was that the basic allocator should not guarantee
zeroed memory, but that there should be a set of allocator functions
that *do* return zeroed memory. Leo checked in a patch to that effect.
Then they started talking about performance.
http://makeashorterlink.com/?X15224F62
string_set is back
Leopold Tötsch has added a 'string_set' function which allows strings to
be recycled instead of having to create new strings every time. This can
lead to substantial speed gains when used appropriately. This led to a
discussion on when it was appropriate to use non destructive assignment
and when to use a destructive set. Somewhat to my surprise, nobody has
yet suggested the lispish set is non destructive, set! is
destructive split, allowing the Parrot coder to choose. Looks like I
just suggested it here.
http://makeashorterlink.com/?M26225F62
Meanwhile, over in perl6-language
Amazingly, the main topic of conversation this week wasn't the dreaded
operator thread...
Unifying invocant and topic naming syntax
Allison Randal has written an article about Perl 6 topics for perl.com.
`Ralph' read this and didn't appear to like it very much, particularly
the sub foo ($bar) is given($baz) { ... } syntax which sets $baz to
the value of the caller's topic. (If you're not sure what I'm talking
about, now would be a good time to read Allison's article. Topics are
great, you'll like them.) Ralph wanted to do sub foo ($baz : $bar is
topic) { ... }, and supplied several further, terser and terser
declaration forms, method f ($self : $c : $a*, $b) {...} anyone?
Allison thought Ralph was barking up the wrong tree, and explained the
thinking behind the topic related syntax and pointed out that Ralph
appeared to be conflating two `independent but interacting features'
with his proposal, but Ralph didn't give up that easily. Eventually,
after comments from Damian and
Re: This week's Perl 6 Summary
Piers Cawley writes: FMTWYENTK about := Bravely declining to expand the acronym in his subject, arcardi posted a summary of his current understanding of the behavior of :=, the its far more then what you ever need to know and after Damian Conway answer it becomes JEOWYNTK - just enough of what you ever need to know . ( is it ??? ) arcadi .
Re: This week's Perl 6 Summary
Supercomma!
[snip]
Larry then confessed that he was thinking of changing the declaration of
parallel for loops from:
for @a ; @b ; @c - $a ; $b ; $c {...}
to something like:
for parallel(@a, @b, @c) - $a, $b, $c {...}
Assuming that semicolon is no longer going to be a supercomma in these
situations, does that mean that we C addicts can have Cfor back to do
the kinds of loops that we mean when we say for loops? I really
don't much like the Cloop keyword.
for ($i = 1; $i 10; $i++) { ... }
(Or is there still some syntactic ambiguity that I haven't thought of?)
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
The city lights shine seaward, swirling in a trance, her eyes upon the water
alone in her last dance. - _Oh Life (There Must be More)_, Alan Parsons
