This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the week ending 20040111
It's Monday. People have been talking about Perl 6, Parrot and the
European Union Constitution. Let's find out what they've been saying
about Parrot first shall we?

  Threads
Threads were discussed some more. Dan's deadline is coming up soon,
hopefully soon after that discussion will move from Holy Skirmishes
about architecture and on to meaningful discussions of a real
implementation.

Hmm... that came out rather more dismissive than I intended.

  Continuation problems
Luke Palmer found a problem with Parrot's continuations. A continuation
is supposed to encapsulate the interpreter's control state, in other
words the position of the program counter and the state of the register
stacks, and a pointer to the previous continuation. However, it turns
out that a Parrot continuation just contains the program counter and a
pointer to the previous continuation. There was some discussion of why
this was so (Melvin Smith seemed to claim that it was both his fault and
not his fault).

Everyone agreed that this needed to be fixed pretty promptly and it
wasn't long before Luke posted a patch.

http://tinyurl.com/2jzv2

http://tinyurl.com/3for3

  A problem with threads
In a change from the discussions of thread philosophy, Jeff Clites
posted about a problem he was having with Parrot's current threads
implementation which was causing problems when trying to join multiple
threads. Between them, Jeff and Leo Tötsch tracked down a possible cause
of the problem and Jeff offered up a patch which Leo applied.

http://tinyurl.com/yssjs

  The PPC JIT gets fixed
Jeff Clites also posted a patch which cleans up the last problems with
the JIT on PPC. Leo applied it. Us Apple users cheered.

http://tinyurl.com/2pyft

  Luke Palmer gets his act together
Luke Palmer decided to get his act together (given the level of his
contribution to the Perl 6 lists so far, I'm almost scared to find out
what he's going to be like now...) and finish up his 'Priority DOD'
rethink of the Garbage Collector. I confess I'm not really qualified to
discuss what's different about it, beyond the claim of a 10,000% speed
up when there were no 'eager' PMCs about (things that need immediate
cleanup on scope exit; the canonical example being a Perlish file
handle) and only a 5% slowdown when there were.

Luke and Leo discussed the patch a bit before Leo applied it.

http://tinyurl.com/2afyc

http://tinyurl.com/235ak -- Luke explains the patch

  IMCC speed issues
Dan posted some timings he'd made of IMCC compiling some large subs,
which were not the most wonderful timings I've ever seen. A 41 minute
compile isn't generally what one wishes to see. Melvin Smith had a few
ideas about what was causing it, as did Leo (it seems that IMCC's
register allocation is very slow in the presence of spilling and Live
analysis increases with the product of the number of lines and variables
in a segment. Leo recommended redoing the sub to reduce the number of
(and avoid long lived) PIR variables (ie. registers) by using lexicals
or globals instead.

http://tinyurl.com/2wb6l

  References to hash elements
Arthur Ponie Bergman had some questions about how references to hash
elements would be done. Consider the following Perl code:

   my %hash;
   $foo = \$hash{key};

   $$foo = bar;

   print $hash{key}; # Prints bar

Arthur wondered how this could be made to work with the current vtable
setup, specifically in the presence of tying. Simon Cozens thought that
there should be a special HashElement PMC which would handle fetching
the actual value from the hash (or writing it back to the hash) as
appropriate. Dan agreed with him, so it looks like this might be the way
forward.

http://tinyurl.com/2hop4

  Instantiation?
Michal Wallace asked how to instantiate objects from Parrot. Luke Palmer
supplied the answer, but pointed out that, at present, classes can only
have integer attributes. It turns out that, for Michal's purposes, he
can probably get by with using properties instead, so that's all right.

Stéphane Payrard did the decent thing and implemented the other
attribute types. He even wrote tests.

http://tinyurl.com/3dul5

http://tinyurl.com/ywgvo

  Creating 'proper' interpreters in Parrot
Simon Cozens wondered what was left to do to allow parrot to be embedded
in an interpreter and have PIR fed directly to it. Leo pointed him at
his own YAL.

http://tinyurl.com/2smrp

http://toetsch.at/yal/ -- Yet Another Language

  yield op?
Michal Wallace was uncomfortable with the workings of Parrot Coroutines
and posted a sample of parrot code which demonstrated why. Leo promised
to fix it once he'd applied Luke's 

Re: This week's summary

[Uri Guttman]

 TP6S == The Perl 6 Summarizer [EMAIL PROTECTED] writes:


  TP6S   Congratulations Dan

  TP6S Melvin Smith offered his congratulations to Dan for the
  TP6S first commercial use of Parrot. I think I can safely say we
  TP6S all echo those congratulations.

shouldn't that be production use? i don't recall ever hearing about a
non-commercial but production use of parrot. anyhow, that is something
that needs to be publicized somehow. parrot squawks in real life, code
at 11!

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: run-once code

[Luke Palmer]

David Storrs writes:
 Given this code:
  
 if ( some_expensive_lookup_function() = $MAX_RECORDS ) {
mark_that_we_have_reached_max_records();   
return;
 } 
 
 After I enter that block once, I never want to evaluate the condition
 again--I want the code to completely disappear from the bytecode (or,
 at least, be jumped around).  How would I do that in Perl 6?

Hmm...

my $max_reached;
sub mark_that_we_have_reached_max_records() {
$max_reached = 1;
}

if !$max_reached  some_expensive_lookup_function()  $MAX_RECORDS {
mark_that_we_have_reached_max_records();
return;
}

That's a new feature we're adding called conditional code removal,
sometimes known as short circuiting :-)

I've given some thought to this sort of thing for optimization, however.
Obviously a conditional on a variable isn't a big price to pay, but when
you have a lot of them, removing the code altogether might save you some
important cycles.  This is particularly true if this condition is within
a tight loop.

So, let's say you have something like:

$x = 100_000;
my $seen;
while $x -- 0 {
if $seen || cheap_condition() {
something();
}
$seen++ if other_cheap_condition();
}

We'd like this to be easy to unroll into:

$x = 100_000;
while $x -- 0 {
if cheap_condition() {
something();
}
last if other_cheap_condition();
}
while $x -- 0 {
something();
}

Especially if something() is a complex expression that's prone to typing
errors, we'd like to keep out the code duplication.

This could well be something the optimizer does, but assuming otherwise,
optimized currying could be to our benefit.

sub do_the_loop($x, $seen) {
while $x -- 0 {
if $seen || cheap_condition() {
something();
}
last if !$seen  other_cheap_condition();
}
return $x;
}

do_the_loop.assuming(seen = 1).(
do_the_loop.assuming(seen = 0).(100_000));

If curries are subject to a short constant-folding pass, this should
easily give us the effect we want.

 (I recall seeing something about how to make assertions drop out, but
 I want to be able to do this at run-time, not compile-time.)

As uri said, who can tell the difference?

Luke