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 = CRA
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
resour
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 wou
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #19668]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19668 >
Attached patch changes a view places, which cause problems running w/o
trace_system_
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 finalizati
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19670]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19670 >
Hi,
The following code does not work as it should:
read S0, 0, 1
print
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19671]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19671 >
The previous befunge patch enabled befunge to set breakpoints, this one
allows one to
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 s
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 thin
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 thr
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 (start
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 every
Hello,
I just got a question from Lee Pumphret regarding Hook::Scope POST in
loops.
Currently it treats every iteration as a scope entry and scope exit so.
for(1..3) {
POST { print 2 };
print 1;
}
will print "121212",
Since perl6 seems to have a NEXT {} block for doing this, how is POST
an
OK, back from hiatus. We paused a while over the holidays to allow A6
to come to a simmer... it's probably still not going to come off the
stove *too* soon, though, so I suggest we move on.
When we left off, we were talking about context vs. type on p6l. That
didn't really go anywhere, and wo
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
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 th
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 up
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 sema
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,
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 2 Jan 2003 19:21:04 +0100
> Cc: [EMAIL PROTECTED]
> From: Arthur Bergman <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> Hello,
>
> I just got a question from Lee Pumphret regarding Hook::Sco
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 l
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 th
31 matches
Mail list logo
