Re: Problem with lexical scoping

2008-02-13 Thread Klaas-Jan Stol
this is very interesting. I think we should store this example somewhere in proper documentation format, maybe in docs/compiler_faq.pod kjs On Feb 12, 2008 8:50 PM, Andrew Parker [EMAIL PROTECTED] wrote: So that works in this situation because the outer lexpad that I want is the same as the

Re: Problem with lexical scoping

2008-02-13 Thread ajr
On a more rational note, has any thought been given to what good enough performance for release will be? Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a problem. -- Email and shopping with the feelgood factor! 55%

[perl #50770] [PATCH] for RT#48276

2008-02-13 Thread Andrew Whitworth
# New Ticket Created by Andrew Whitworth # Please include the string: [perl #50770] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50770 This is a patch for RT#48276 Warn when failure occurs in Parrot_setenv(). I

Re: Problem with lexical scoping

2008-02-13 Thread Geoffrey Broadwell
On Wed, 2008-02-13 at 14:21 +, [EMAIL PROTECTED] wrote: On a more rational note, has any thought been given to what good enough performance for release will be? Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a

s/string_equal/string_compare/g

2008-02-13 Thread Andy Lester
string_equal() is misnamed. It should be string_compare() like strcmp() and memcmp(). Objections? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance

[perl #50768] [PATCH] Update Win32 platform documentation.

2008-02-13 Thread Andrew Whitworth
# New Ticket Created by Andrew Whitworth # Please include the string: [perl #50768] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50768 I've updated some of the documenation and comments in config/platform/win32.

Functions that malloc()

2008-02-13 Thread Andy Lester
There's now a make target to show all the functions that are PARROT_MALLOC: make malloclist xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance

[perl #50776] myops alarm test failure

2008-02-13 Thread via RT
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #50776] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50776 Hi, I still get this test failure, as shown below. (I checked in rt and saw that

Re: Problem with lexical scoping

2008-02-13 Thread Patrick R. Michaud
On Wed, Feb 13, 2008 at 11:26:36AM +0100, Klaas-Jan Stol wrote: this is very interesting. I think we should store this example somewhere in proper documentation format, maybe in docs/compiler_faq.pod FWIW, the information about using getinterp to get at a caller's lexpad is already in

Re: Problem with lexical scoping

2008-02-13 Thread Patrick R. Michaud
On Tue, Feb 12, 2008 at 08:59:46PM -0800, Geoffrey Broadwell wrote: Here's my fear: Parrot will near production release, we'll start finding performance problems, and everyone will be so incredibly ready to get 1.0 out the door that we'll release before fixing them (correct now, fast later

Re: Performance (was Re: Problem with lexical scoping)

2008-02-13 Thread Will Coleda
On Feb 13, 2008 1:41 PM, chromatic [EMAIL PROTECTED] wrote: On Wednesday 13 February 2008 06:21:32 [EMAIL PROTECTED] wrote: Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a problem. That's somewhat difficult, as it's

Performance (was Re: Problem with lexical scoping)

2008-02-13 Thread chromatic
On Wednesday 13 February 2008 06:21:32 [EMAIL PROTECTED] wrote: Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a problem. That's somewhat difficult, as it's the performance of languages hosted on Parrot that's most

Re: s/string_equal/string_compare/g

2008-02-13 Thread chromatic
On Wednesday 13 February 2008 08:26:43 Andy Lester wrote: string_equal() is misnamed. It should be string_compare() like strcmp() and memcmp(). +1

Re: Performance (was Re: Problem with lexical scoping)

2008-02-13 Thread Francois PERRAD
Will Coleda wrote: On Feb 13, 2008 1:41 PM, chromatic [EMAIL PROTECTED] wrote: On Wednesday 13 February 2008 06:21:32 [EMAIL PROTECTED] wrote: Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a problem. That's somewhat

Re: Performance (was Re: Problem with lexical scoping)

2008-02-13 Thread chromatic
On Wednesday 13 February 2008 10:59:41 Will Coleda wrote: One of the thing tcl needs to be fully supported is the ability to add sub hooks that execute on enter/exit of a particular sub[1]; adding this would give us the ability to profile which PIR subs we were spending most of our time (by

[perl #50302] [TODO]: Refactor internals of t/harness

2008-02-13 Thread James Keenan via RT
Patches applied to trunk in r25705.

[perl #50800] Update PIR coda?

2008-02-13 Thread via RT
# New Ticket Created by Will Coleda # Please include the string: [perl #50800] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50800 From PDD07: PIR source files should end with this coda: # Local Variables:

[perl #50802] .t files lying about their type..

2008-02-13 Thread via RT
# New Ticket Created by Will Coleda # Please include the string: [perl #50802] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50802 the pir_code_coda.t is now checking both .pir files *and* .t files that claim to be