The Perl 6 Summary for the week ending 20021229
This is not your normal summary. It's been Christmas, things have been
quiet, I've been concentrating on mince pies, roast goose and all that
other good stuff. Normal service will be resumed next week.
Acknowledgements
* Larry Wall
Steve Fink wrote:
On Dec-31, Leopold Toetsch wrote:
I think, it moves the problems just around with a lot of overhead. E.g.
cloning a PerlArray of 10^6 entries would need 1000 generations
I don't understand. The outer clone belongs to generation N. Then if
you called clone() individually
Steve Fink wrote:
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
my %x;
{ # start scope
my $timer1 = Timer-new();
my
Steve Fink wrote:
Another (maybe silly) possibility suggested itself to me based on a
private mail re: infant mortality from Thomas Whateley: could we try
optimistic allocations?
if (alloc_object() == NULL) {
undo everything
do_DOD_run
interp-on_alloc_fail =
Matt Fowles wrote:
All~
Parrot_do_at_most_N_DOD/GC(1);
do_clone
Parrot_unblock_DOD/GC(-1);
This would allow it to do one DOD run if it realized that it needed it part
way through the clone, but would never do more.
Very interesting approach. Yep. No need to check for probably needed
Steve Fink wrote:
On Jan-01, Leopold Toetsch wrote:
Yep. The goal can only be, to either have *all* code paths that might
trigger DOD checked, or use one of the mentioned strategies. Though
reducing possibilities of infant mortatility by early anchoring is IMHO
always a good thing: it
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #19668]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19668
Attached patch changes a view places, which cause problems running w/o
On Wed, Jan 01, 2003 at 08:09:05PM -0800, Steve Fink wrote:
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
Timely finalization
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19670]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19670
Hi,
The following code does not work as it should:
read S0, 0, 1
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19671]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19671
The previous befunge patch enabled befunge to set breakpoints, this one
allows
Hi there,
How can one retrieve the keys of a PerlHash in Parrot assembly? Is there
a way to traverse a hash?
Jerome
--
[EMAIL PROTECTED]
Jason Gloudon wrote:
On Wed, Jan 01, 2003 at 08:09:05PM -0800, Steve Fink wrote:
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
The best partial solution to early finalization is compile-time
tracing of possible references by the compiler which can explicitly
generate the appropriate DESTROY calls.
What about refcounting + real GC?
refcounting will free most of the objects as soon as possible, and the
real GC
At 10:24 PM +0100 1/2/03, Angel Faus wrote:
The best partial solution to early finalization is compile-time
tracing of possible references by the compiler which can explicitly
generate the appropriate DESTROY calls.
What about refcounting + real GC?
Yech, refcounting is one of the
From: Angel Faus [mailto:[EMAIL PROTECTED]]
What about refcounting + real GC?
refcounting will free most of the objects as soon as
possible, and the real GC system makes sure that even
cyclical references are eventually freed..
I believe this was covered in that same Re: DOC etc
Jerome Quelin wrote:
Hi there,
How can one retrieve the keys of a PerlHash in Parrot assembly? Is there
a way to traverse a hash?
Not yet.
There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would
almost be all to implement aggregate iterators. Missing is IMHO how to
reset
Angel Faus wrote:
What about refcounting + real GC?
As soon as you start to refcount objects, which need active destroying,
you end up refcounting all objects (a timer may be stored in an
aggregate, passed to subs, may have references, ...).
So this is not an option, except changing
On Thu, Jan 02, 2003 at 08:12:45PM +0100, Leopold Toetsch wrote:
Angel Faus wrote:
What about refcounting + real GC?
As soon as you start to refcount objects, which need active destroying,
you end up refcounting all objects (a timer may be stored in an
aggregate, passed to subs, may
At 11:18 PM -0500 12/31/02, David Robins wrote:
On Tue, 31 Dec 2002, Dan Sugalski wrote:
I don't think any ops do that presently (that would take a PMC** param).
Oh, sure, lots do. Remember the ops get a pointer to the PMC
register, which is itself a pointer. Whatever you stuff in there is
Okay, I've been working on getting bytecode generation nailed down,
and then digging into the vtable split stuff, but I thought I'd
specify at least a little how objects (this would be real
language-level we're object-oriented dammit! objects, not the
lower-level stuff we're currently working
I've been playing with a few test programs, and I'm finding it
depressingly easy to get perl 5 to beat the pants off of Parrot for
runtime speed, often by a factor of 4, regularly by a factor of two.
There are a number of trouble spots that we can address now, without
affecting anything else
Nicholas Clark wrote:
On Thu, Jan 02, 2003 at 08:12:45PM +0100, Leopold Toetsch wrote:
[ refcounting ]
Effectively everything currently holding an object needing active
destruction becomes an object needing active destruction, (for the duration,
but no longer), and so on all the way back
Here's a proposal w.r.t. adaptive GC (it's a variant of
the NEW/BABY/DONTGCME/whatever flag): all buffers are
created with this flag, but we only clear the flag on
DOD runs when we _know_ it's safe (e.g. between opcodes);
if we find we're getting low on resources, we queue a do-DOD-now
event to be
Dan Sugalski wrote:
Still, for 'real' OO, it's all reference object stuff, so things should
Just Work. The pending questions about
... strings still is pending ;-)
Remember string_set ins substr and 50% live performance increase.
Do we want do reuse string headers like PMCs (and change
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower, which
is a Bad Thing.
Your are sure, that you didn't start swapping?
I have here this test pushing X integers into a PerlArray, then clone
it,
Mitchell N Charity wrote:
Do you have a recommendation between GLOBAL and LXR?
I'd suggest LXR. It understands perl files out-of-the-box, is more
I've asked one of our volunteers who already runs some similar systems
for us if he can get this running. If not, I'll see about setting you
At 6:52 PM -0500 1/2/03, [EMAIL PROTECTED] wrote:
Here's a proposal w.r.t. adaptive GC (it's a variant of
the NEW/BABY/DONTGCME/whatever flag): all buffers are
created with this flag, but we only clear the flag on
DOD runs when we _know_ it's safe (e.g. between opcodes);
if we find we're getting
At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower,
which is a Bad Thing.
Your are sure, that you didn't start swapping?
Oh, absolutely. One of
28 matches
Mail list logo
