[Neworleans-pm] Fwd: This week's Summary
E. Strade, B.D.
estrabd at yahoo.com
Mon Sep 6 09:44:39 CDT 2004
=====
http://www.brettsbsd.net/~estrabd
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
----- Original message -----
From: "The Perl 6 Summarizer" <p6summarizer at bofh.org.uk>
To: perl6-announce at perl.org
Date: Mon, 06 Sep 2004 15:40:17 +0100
Subject: This week's Summary
The Perl 6 Summary for the week ending 2004-09-03
Another week, a free weekend, and still I haven't started writing
the
summary until Monday. Still, I don't actually start at college 'til
next
week, so that's all right then.
We start with perl6-internals.
Compile op with return values
The discussion of how to return something from dynamically compiled
code
continued with Leo, Dan and Steve Fink all working to clarify and
address the issues.
http://xrl.us/cybq
Library loading
Dan started the process of nailing down Parrot's dynamic loading API
so
that it can be added to the embedding interface. Steve Fink and
Aaron
Sherman had suggestions.
http://xrl.us/cybr
Pathological register allocation scenarios
Gregor N Purdy had asked Dan if his work compiler could be made to
spit
out structurally equivalent C code to the Parrot code that was
breaking
IMCC. His idea being that we could then see how C compilers dealt
with
such nastiness. Dan thought that, whilst this was a good idea, it
would
be too much work to implement. Gregor wasn't so sure.
http://xrl.us/cybs
Dan and Leo demonstrate comic timing. Again.
14:17:09 GMT Dan: PerlHash test 20 is failing? Anyone know what's up
so
we can fix it?
15:30:41 GMT Leo: It stopped failing at 15:55 CEST (13:55 GMT)
16:32:29 GMT Dan: D'oh!
We love it when a patch comes together.
http://xrl.us/cybt
PMC Instantiation
Leo had raised issues with the current scheme for PMC instantiation.
This week Dan came through with some design which got discussed and
(I
think) implemented.
http://xrl.us/cybu
Last bits of the basic math semantics
If you believe Barbie, "Math is hard". She's right, up to a point.
The
list's spent a couple of weeks now sorting out the design of Parrots
underlying mathematical and numeric systems to make sure that maths
works right (for sufficiently useful values of 'right'). This
particular
line of discussion covers rotations and stuff, where you're actually
treating a number as a bit field.
http://xrl.us/cybv
Cross-compiling parrot
And you thought compiling Parrot on a Win32 box was hard. Robert
Schwebel wants to cross compile Parrot and isn't having a good time.
Dan
wasn't surprised because the Parrot build process still gets most of
its
information from the local perl installation which will generally be
wrong when you're cross compiling.
Dan noted that part of the problem is that we don't have people on
the
team with a need or the experience of doing cross compilation and
added
that he'd be thrilled if this were to change. Any patches to make
things
better for cross compilers will, of course, be gratefully received.
http://xrl.us/cybw
Proposal for a new PMC layout and more
Leo's concerned that the current PMC layout isn't the Right Thing,
and
laid out a proposal describing some changes he thinks would be
worthwhile. In essence, he argues for removing the requirement for
fixed
sized PMC headers and separate variable sized buffers in favour of
unifying buffers and PMCs so that PMCs become variable sized, thus
eliminating some time consuming indirection, and space consuming
overheads.
Nicholas Clark thought the proposal was interesting, but said that,
since the proposed changes would be invisible to the user, he'd be
far
happier with a functionally complete implementation of parrot with
stable, useful APIs.
Dan rejected the proposal (both for technical reasons and because he
agreed with Nicholas). I don't think Leo was convinced by the
technical
reasons, but the "Let's get the interfaces finished!" argument
clinched
it.
http://xrl.us/cybx
http://xrl.us/cyby -- Dan explains why not.
Semantics for regexes
Dan appears to have opened an entertaining can of worms when he
outlined
his view of the minimum string semantics required to support a
regular
expression engine and asked for comments. Boy did he get them. And
boy
did they run off in all sorts of strange directions. Interesting
directions mind. Anyway, further down the thread, Dan, Chip
Salzenburg
and Patrick Michaud seemed to reach something approximating
agreement
about the low level semantics required.
http://xrl.us/cybz
TODOs and calls for volunteers
Leo came up with a list of things that need fixing/implementing and
asked for volunteers. These include sorting out what happens with
the
experimental ops, implementing "new_extended" for every PMC class
and
finishing up BigInt's MMD and vtable functions.
He also had some proposals for how we should get the Integer classes
properly implemented now we know what the semantics will be.
http://xrl.us/cyb2
http://xrl.us/cyb3
http://xrl.us/cyb4
http://xrl.us/cyb5
Meanwhile, in perl6-language
Roles trying to be nice
Abhijit Mahabal had some questions about making roles work. Luke,
Patrick & Jonathan Scott Duff set about answering them. I'm not
entirely
sure that any of the answers so far are enough for Abhijit, but then
I'm
not entirely sure that any answer could be enough. At some point you
have to take things on trust and hope that nothing breaks at
runtime.
http://xrl.us/cyb6
Pipeline performance
Rod Adams brought up some issues with the performance of
'pipelining'
arrays in Perl 5 -- in general doing say "grep {...} map {...} @ary"
is
rather slower than writing an explicit loop. He wondered if Perl 6
would
be faster. Larry's answer that all lists function lazily if they can
in
Perl 6 seems to imply that yes, Perl 6 will be faster.
http://xrl.us/cyb7
Synopsis 9 draft 1
"Synopsis 9?" I hear you ask "But we haven't seen Apocalypse 9
yet!".
Indeed we haven't, but that's not stopped Larry writing it. Synopsis
9
gives an overview of Perl 6's data structures (hopefully enough for
anyone who happens to be starting work on a rough cut of a Perl 6
implementation) which will be covered in more detail when the
Apocalypse
itself comes out.
The usual storm of discussion and general proofreading goodness went
on.
http://xrl.us/cyb8
The range operator
Joe Gottman wondered if there would be sufficiently lazy way to
generate
ranges. In particular, he wanted to know if he'd be able to write
"reverse (1..5)" and have Perl handle that lazily, or if he could do
"5
.. 1 :by(-1)". Larry thought that, if range objects were made
sufficiently smart, there would be no reason why the "reverse"
approach
couldn't be lazy.
http://xrl.us/cyb9
Can PRE and POST be removed from program flow?
John Siracusa wondered if it would be possible to turn off the PRE
and
POST Design By Contract hooks in production code to improve
performance.
(Leaving aside arguments about whether this is sensible; personally
I
reckon that a production environment is where you should be most
worried
about values that might fail the PRE/POST hooks). Larry reckoned it
would be possible to simply clobber the global definitions of PRE
and
POST to make them no ops. This wasn't enough for John, who wanted to
be
able to get rid of them entirely so even the call to the no op
didn't
happen. So Damian showed him the obvious macros...
http://xrl.us/cyca
Announcements, Apologies, Acknowledgements
It looks like the Google groups gateway is working again, so I'll
keep
with the Google style linking.
If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development
of
Perl. You might also like to send feedback or contributions to a
'getting Piers to OSCON 2005' fund to mailto:pdcawley at bofh.org.uk
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
Or, you can check out my website.
http://www.bofh.org.uk/
More information about the NewOrleans-pm
mailing list