Re: This fortnight's summary
On Wed, Aug 25, 2004 at 08:19:06PM +0100, The Perl 6 Summarizer wrote: Chia-liang Kao announced that he (I'm guessing, I'm not very good at Yes, he. But I assume that someone's already confirmed this to you. He's been in London recently. I'm not sure if he's still here. Nick
Re: This fortnight's summary
On Wed, Aug 25, 2004 at 08:19:06PM +0100, The Perl 6 Summarizer wrote: A small task for the interested Dan posted another of his small tasks for the interested (maybe we should start calling them STFTIs?). This time he's after source tests to test the embedding interface and some fixing of the auto-prefix scheme. Hmm... I suppose that this acronym would be pronounced stuff-it. --
RE: This fortnight's summary
None of the links for the perl6-language threads work. Joe Gottman
This fortnight's summary
The Perl 6 Summary for the fortnight ending 20040621 Good evening. You find me typing away in a motel room on the edge of the Lake District on the shortest night of the year. I suppose, by rites, I should be spending the night by some stone circle drinking, dancing and generally making merry, but as I'm a teetotal, unfit, atheistical nerd with a mission to summarize I'll skip that and plough straight into the activities of another arcane sect. Yes, it's perl6-internals again... Towards an accurate README Andy Dougherty sent in a patch adjusting the Parrot README so that it accurately reflected the toolset needed to build parrot. For some reason, as well as the requirement for a C++ compiler if you want to build the ICU library, we've moved to needing Perl 5.6.0 rather than 5.005. Nicholas Clark suggested that, rather than bumping the Perl version requirement, we bundle appropriate versions of modules Parrot required, but chromatic thought it better to check the for the correct versions of said modules at Configure time and bail out if they weren't there. There was further discussion about whether going to Perl 5.6.0 as a requirement was the right thing to do -- the issue is that some OSes (FreeBSD and Solaris 8 were cited) still only ship with 5.005 family Perls. My feeling (which I didn't mention in the thread, more fool me) is that, as eventually the goal is to eliminate the need for Perl at all in the build process, then require 5.6.0 rather than 5.005 isn't exactly the end of the world. http://groups.google.com/[EMAIL PROTECTED] http://groups.google.com/[EMAIL PROTECTED] OS X Builds again Someone finally summoned up the tuits to fix the OS X build. Step forward Nicholas Clark and accept your plaudits. http://groups.google.com/[EMAIL PROTECTED] Basics of the PMC class set Dan announced that he was about to make some changes to the repository, including establishing a basic set of PMC classes. Matt Fowles wondered about Array PMCs, which seemed to be missing from Dan's list. Dan agreed that they should be rationalized as well. Bernhard Schmalhofer suggested adding a complex number class to Dan's basic menagerie, but Dan was unconvinced. http://groups.google.com/[EMAIL PROTECTED] Correct use of #define Nicholas Clark was moved to growl by a section of include/parrot/string.h that used a #define to define a type. Actually, he was moved to 'swearing and cursing and time wasted grepping to find out what a STRING is'. Dan agreed that this was bad and decreed: 'Typedefs for types, #defines for constants and bizarre (*temporary!*) debugging things.' http://groups.google.com/[EMAIL PROTECTED] The next release During a lull while Leo Ttsch was away at a conference, Dan mused on the next release of parrot. His goal for that is a rejig of classes/, aiming to make sure that all the PMCs we want are in and working, and that the ones we don't care about are neatly deprecated. Warnock applies. http://groups.google.com/[EMAIL PROTECTED] A small task for the interested Stretching the definition of 'small' somewhat, Dan asked for volunteers to implement the missing PMCs detailed in PDD 17. He reckoned it should be 'fairly straightforward'. A new entrant in these summaries, Ion Alexandru Morega took a crack at the String PMC and posted a patch to the list which was promptly ignored. Which seems a little unfair really. http://groups.google.com/[EMAIL PROTECTED] Bignums! Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up to the plate. Leo suggested that, rather than starting from types/bignum.c, it might be better to use an existing, maintained, maths (Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will be a cold, cold day in hell when I start abbreviating 'mathematics' as 'math'. Ahem.) package. Dan worried about license compatibility; the proposed GMP package is licensed under the LGPL which may (or may not) be compatible with Parrots Artistic/GPL dual licence. After a closer reading he reckoned that GMP's license is definitely incompatible with Parrot. http://groups.google.com/[EMAIL PROTECTED] Adding Fixed*Array classes Matt Fowles posted a patch implementing Fixed Array classes. Dan applied it. Leo wondered about the patch's use of malloc(3) instead of Parrot's memory management. Dan wasn't worried in the case of fixed size arrays. http://groups.google.com/[EMAIL PROTECTED] Resizeable*Array classes Fresh from his Fixed Array triumph, Matt Fowles posted a patch implementing nave Resizeable Arrays. Leo thought it a little too nave, and worried about duplication of existing functionality. Dan wasn't worried about the navet, or the duplication of functionality. He
Re: This fortnight's summary
On Wed, 23 Jun 2004, The Perl 6 Summarizer wrote: Bignums! Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up to the plate. Leo suggested that, rather than starting from types/bignum.c, it might be better to use an existing, maintained, maths (Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will be a cold, cold day in hell when I start abbreviating 'mathematics' as 'math'. Ahem.) package. Dan worried about license compatibility; the proposed GMP package is licensed under the LGPL which may (or may not) be compatible with Parrots Artistic/GPL dual licence. After a closer reading he reckoned that GMP's license is definitely incompatible with Parrot. http://groups.google.com/[EMAIL PROTECTED] The license issues there require that the full source of GMP ship with any binary copy. (the license has no provide a place to fetch it provision--the source is required) Which would make the Gameboy version of Parrot somewhat cumbersome. :) Resizeable*Array classes Fresh from his Fixed Array triumph, Matt Fowles posted a patch implementing nave Resizeable Arrays. Leo thought it a little too nave, and worried about duplication of existing functionality. Dan wasn't worried about the navet, or the duplication of functionality. He pointed out that it was more important to get *something* which could be improved and that the duplication was okay given that the idea was to get a standard framework in place and then eliminate the duplication. (I admit that I'm a little surprised to hear Dan, who's normally a strong advocate of up front design, preaching the refactorers creed...) Ah, but the design is already fixed. And I'm a big advocate of I don't care if it's implemented by the appropriate application of garden gnomes so long as it works school of thought. The code is close to irrelevant, it's the architecture and API of a black box and the system that box exists in that's important. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: This fortnight's summary
On Wed, 2004-06-23 at 08:12, Dan Sugalski wrote: The license issues there require that the full source of GMP ship with any binary copy. (the license has no provide a place to fetch it provision--the source is required) Which would make the Gameboy version of Parrot somewhat cumbersome. :) Has anybody inquired to the GMP project as to the possibility of relaxing that restriction? If GMP truly is the best bignum implementation, I definitely think it's worth asking. If nobody else is pursuing this then sure, I volunteer to subscribe to some lists and try to find the people to ask. I'll wait for a Yes from Dan or Leo before I run off trying to represent the Parrot project, of course. :) - Scott
Re: This fortnight's summary
The Perl 6 Summarizer wrote: PIO_unix_pipe() Leo's implemented a PIO_unix_pipe() method which allows you to run an external program and capture the results with a Parrot IO handle. He doctored the open opcode to use it pipe = open /bin/ls -l, -| While that's right regarding above syntax snippet, the credits for CPIO_unix_pipe() belong to Melvin Smith, who'd implemented it in the first place. I did just (as normal) make it more workable. Doctored is ok, though ;) leo - this is the usual thanks for your summariies, Piers, but ...
This fortnight's summary
The Perl 6 Summary for the fortnight ending 2004-06-06
Whee! There's a new graphics card in the G5, which means I can type this
at the big screen again, which makes me happy. Well, it would make me
far happier if the new card didn't leave horrible artifacts all over the
screen like some kind of incontinent puppy attempting to fulfil OpenGL
draw instructions. Maybe next week will see a third card in the box.
Dang! It looks like the G5 will be off receiving some TLC from an Apple
service centre while I'm on holiday next week. Which means that the
'weekly' summaries will continue on their fortnightly summer holiday
schedule for at least one more summary. But then the lists themselves
appear to be on summer footing anyway.
Ahem.
As you will probably have worked out by now, we start with
perl6-internals.
Library loading
Jens Rieks is working on library loading code that does all the nice
things we've come to expect from other languages. The plan being that
you'll be able to write (say)
use('some_library')
and Parrot will go off and search it's include paths for
some_library.(pbc|imc|pasm|whatever) and load it. As he noted, if you're
going to implement that kind of code in parrot assembler (or PIR, or
whatever), you need some way of loading the loading code. It's also a
good idea to have a working stat. Jens added a
Parrot_load_bytecode_direct function to the parrot core to support the
first part. His please for a functional (if not complete) stat were
answered by Dan who set about implementing the stat API he outlined a
few weeks ago.
http://xrl.us/b689
Embedding Parrot
Leo Ttsch and chromatic answered Paul Querna's questions from last
week about embedding Parrot.
http://xrl.us/b69a
Using PMCs as PerlHash keys
TOGoS wanted to know how he could use a PMC as a key in a PerlHash. Leo
replied that it was as simple as doing
$P2 = new Key
$P2 = key_string
$P0 = $P1[$P2]
Piers Cawley did some naive translation into PASM and got himself
horribly confused. Leo and TOGoS corrected him.
http://xrl.us/b69b
First draft of IO and event design
Remarking that events and IO are (kinda, sorta) the same thing, Dan
posted his first draft of a unified IO and events design and asked for
comments. This being p6i, he got several (though not as many as usual,
maybe everyone likes it).
Freeze, objects, crash, boom
Will Coleda tried to get freezing and objects to play well together and
failed. So he asked a bunch of questions. Leo didn't solve the problem,
but he did have some pointers to where it was coming from.
http://xrl.us/b69c
MMD table setup semantics
Possibly winning an award for the oldest rejuvenated thread, Nicholas
Clark had some questions about a post Dan made about MMD at the end of
April. He made a suggesting about how to calculate 'distance' for multi
dispatch. Dan pointed out that Larry had decreed that the 'distance'
would be the 'Manhattan Distance'. (Google has several definitions).
http://xrl.us/b69d
Compiler FAQ entry
Will Coleda posted a possible set of entries for the compiler writers'
FAQ. Leo had a few quibbles. Sterling Hughes suggested that having
small, runnable source code examples would be really helpful.
Layering PMCs
Dan kicked off a discussion on how to go about layering PMCs. The usual
suspects offered suggestions. The aim is to be able to layer behaviours
on top of PMCs without massive overhead or combinatorial explosion
problems. As usual with these things, there's several possible ways of
doing it, the debate is about choosing the best one.
http://xrl.us/b69e
IO Layers
Leo had some questions about the (not fully implemented)
ParrotIOLayerAPI. He laid out a proposal for implementing things. Uri
Guttman and Dan joined in a discussion of the issues. (Simple summary of
the issues: Asynchronous IO is hard. Possibly more accurate summary of
the issues: Asynchronous IO is *not* synchronous)
http://xrl.us/b69f
PIO_unix_pipe()
Leo's implemented a PIO_unix_pipe() method which allows you to run an
external program and capture the results with a Parrot IO handle. He
doctored the open opcode to use it
pipe = open /bin/ls -l, -|
Dan liked it, but proposed also adding a backtick operator.
http://xrl.us/b69g
Register spilling
Dan noted that it's possible to get the register allocator caught up in
an infinite loop (or as near infinite as makes no difference) as it
tries to work out a register spilling strategy. He proposed there be a
'slow but working' fallback method to use if the normal method goes
through too many iterations. Leo suggested an delightfully brute force
approach with some possible elaborations that Dan didn't think
This fortnight's summary
The Perl 6 Summary for the fortnight ending 2004-04-18 The only problem with summarizing two week's worth of Perl 6 happenings is that there's twice as much stuff to summarize. Still, there's no way I could have made the time to write a summary last week so I'll take my lumps. I am exceedingly grateful that Apocalypse 12 (Objects) wasn't released the Thursday *before* Easter though, as it is I can clear the decks for the expected perl6-language explosion next week. We'll start with perl6-internals as usual. Initializers, finalizers and fallbacks There was some discussion of the various functions that get called by object initialization/destruction etc. Dan wondered what he'd been thinking when he declared that there would be distinct FINALIZE, DELETE and CLEANUP properties (instead of declaring that a function must be called (say) FINALIZE, you can mark any function with a FINALIZE property, and Parrot will recognise that as the function to call at finalization time). Andy Wardley quibbled about American/British spelling, but Tim Bunce pointed out that the 'ize' form is preferred by the Oxford English Dictionary (and your humble summarizer). Leo meanwhile made a (Warnocked) proposal for a new init scheme. http://tinyurl.com/2s2xp http://tinyurl.com/2dfj8 New SDL Parrot bindings Taking advantage of Parrot's new, improved object system, chromatic updated us all on his efforts to provide a shiny OO interface to the SDL library. Jens Rieks wondered about chromatic's implementation choices, and posted a few suggestions and questions. Dan reckoned he'd prefer it if the SDL bindings used Parrots internal events systems. The catch being that Parrot doesn't actually have an internal events system yet... Later in the fortnight, chromatic posted an initial release and promised to post his notes and slides from the Portland Perl Mongers meeting where he was showing it off. There's no sign of 'em yet though. http://tinyurl.com/265sg http://tinyurl.com/2kpax new method Jens Rieks and chromatic were unsure of the best name for a constructor method. They'd like to be able to write a method called new, but IMCC wouldn't allow it. Leo Tötsch pointed out that there's already a default constructor method: __init. However, chromatic wasn't too keen on it because he wanted to be able to pass arguments to the constructor. Leo pointed out that, although it wasn't officially supported, you could pass arguments in the same was as if you were making a normal parrot function call. Dan pointed out that our current initialization system is some way from being the final one (which will use properties to mark constructor methods). What we have now is more like an allocator than a real constructor. http://tinyurl.com/3gv6y Overriding __find_method in PASM? Noting that, according to PDD15, defining a method called __find_method should allow Perl 5 AUTOLOAD-like behaviour, chromatic wondered if it was workable yet and, if it wasn't, how he should go about adding it. Leo confessed that what was in the docs was a cut and paste error and AUTOLOAD behaviour hadn't yet been defined. He suggested a workaround using exceptions (which turned out to be overkill for what chromatic needed, but it looks interesting.) http://tinyurl.com/ypvze Language interoperability Randy W. Sims popped over from the Module-Build mailing list, where they've been discussing plugin architectures to allow for the modification and extension of Module::Build's capabilities. One of the desiderata is that, once the transition to Parrot is underway, it should be possible to write plugins in any language supported by Parrot. (Mmm... a build system written in Befunge, it's what the world's been crying out for I tell you). There are currently two competing schemes, one involving manipulating the class hierarchy at runtime and the other involving plugins held in particular directories and a formal API. Randy wondered if there were any technical reasons to choose one scheme or another. Dan reckoned that there were no particular technical reasons, but the inheritance based scheme rather offended his sensibilities, going so far as to say No way in hell it'll ever make it in as parrot's standard module building system if you do it [the inheritance munging solution]. http://tinyurl.com/33nsw Save the Return Continuation! The ongoing discussion about continuations seems to be fizzling slightly. Piers Cawley had proposed moving the return continuation out of P1 and held 'somewhere else' (possibly the control stack) and then, when a routine needed to do cunning things with the current continuation it could access it with some op (say get_current_cont). Dan reckoned he
