Re: A Perl Task - Benchmarking

Hi Leo, Attached is a quick'n dirty parrotbench, instead of a complicated test harness it uses bash to make time measurements, so that new languages are very simple to add. Currently it's just a proof of concept but if you like it i will make a better version with pretty printing, extended reports

Re: Magic blocks (was: Compile-time undefined sub detection)

Oh, I accidentally left NEXT out of my canonical list. We do need to have the equivalent to Perl 5's "continue". Larry

Magic blocks (was: Compile-time undefined sub detection)

Okay you guys, you're running away from one kind of madness and proposing various other kinds of madness in its place. Mostly you're confusing what should be easy and what should be possible. First a note about cleanup dependencies. In general, these should be driven by the structure of the data

Re: [perl #27469] [PATCH] Use named constants in iterator.pod

Jens Rieks <[EMAIL PROTECTED]> wrote: > Hi, > On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote: >> >> this patch is just a little documentation update in 'docs/iterator.pod'. > This file is automatically generated from classes/iterator.pmc Actually the patch is against docs/pmc/iterat

Re: [perl #27469] [PATCH] Use named constants in iterator.pod

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > this patch is just a little documentation update in 'docs/iterator.pod'. > Now named constants are used for setting up the iterator in the examples. Thanks, applied. leo

[perl #27465] [PATCH] Library to access configuration info

# New Ticket Created by "Brent Dax" # Please include the string: [perl #27465] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27465 > The attached patch creates a Parrot-level library similar to Parrot::Config. There ar

Re: [perl #27469] [PATCH] Use named constants in iterator.pod

Hi, On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote: > # New Ticket Created by Bernhard Schmalhofer > # Please include the string: [perl #27469] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27469 > > > > H

[perl #27469] [PATCH] Use named constants in iterator.pod

# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27469] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27469 > Hi, this patch is just a little documentation update in 'docs/iterator.pod'.

A Perl Task - Benchmarking

I'd a short look at perlbench from CPAN. This inspired me to the following idea: examples/benchmarks/* has a bunch of programs e.g. oo1.pasm oo1.pl oo1.py stress.pasm stress.pl ... Now like perlbench is able to compare run times of different perl versions, the goal of this task is to

Re: [DOCS] Documentation tools

On 6 Mar 2004, at 05:31, Robert Spier wrote: [...] The problem isn't today. It's the "trend" and next month, when someone decides they need to add some other module, and has a precedent to follow. Then, suddenly we end up with 30 different modules included in our distribution, each one changed

Re: Freezing strings?

Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> wrote: > Renaming did it. freeze/thaw for PerlNum checked in, with test. Fine, thanks. > The first time I ran tests after compiling, I got a failure in > t/pmc/signals.t--it thought that no tests had run, and the harness > eventually reported 12/6 su

Re: Freezing strings?

Leopold Toetsch wrote: Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> wrote: I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push

RE: Compile-time undefined sub detection

> -Original Message- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > Austin Hastings writes: > > # Each "broad class" of upcased block is an execution group. The entries > > # in each execution group are not guaranteed to run in any > particular order, > > # and in fact may run in paral

Re: Freezing strings?

Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> >> The interfaces are all there. It *should* just be: >> - cut'n paste code from perlint >> - s/_integer/_string/ for (push, shift) and s/int_val/str_val/ > It was. I've committed it, along with a test for it. All te

Re: [perl #27391] parrot -t crash

Jens Rieks <[EMAIL PROTECTED]> wrote: > The following code crashes parrot if run with -t (trace). Fixed. That was not an easy one. A slightly wrong implementation (braino courtesy of leo) did reset interpreter->lo_var_ptr (the stack limit), when reentering the run loop, e.g. in object's __init c

Re: Freezing strings?

Leopold Toetsch wrote: If it's just some busywork, such as copying some code into PerlString and tweaking it, I can probably do it, but I've been out of the loop for a while, so anything particularly involved is likely beyond me. The interfaces are all there. It *should* just be: - cut'n paste code

Re: Compile-time undefined sub detection

Austin Hastings writes: > Perhaps this is one of those places where properties can help. Instead of > having BEFORE, REALLY_BEFORE, NO_I_MEAN_REALLY_BEFORE, DONE, MOSTLY_DONE, > PARTIALLY_DONE, WELL_DONE, DONE_AND_PROCESS_SPACE_ALMOST_RECLAIMED, etc., we > could simply use some ordering properties:

[CVS ci] JIT/NCI

I have put in the follwing patch: - if CAN_BUILD_CALL_FRAMES is defined, call the JITed version - if that returns zero, use the hardcoded version in nci.c - else use hardcoded version So you can implement signatures step by step. If you are going to implement JITted NCI stubs: 1) create a functi