Re: Problem with lexical scoping

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

Re: Problem with lexical scoping

> > 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!

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

# New Ticket Created by "Andrew Whitworth" # Please include the string: [perl #50770] # in the subject line of all future correspondence about this issue. # 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 apol

Re: Problem with lexical scoping

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

s/string_equal/string_compare/g

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

Functions that malloc()

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 #50768] [PATCH] Update Win32 platform documentation.

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

[perl #50776] myops alarm test failure

# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #50776] # in the subject line of all future correspondence about this issue. # 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 a pa

Re: Problem with lexical scoping

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 pd

Re: Problem with lexical scoping

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 late

Re: s/string_equal/string_compare/g

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

Performance (was Re: Problem with lexical scoping)

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 imp

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

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 difficu

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

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 (b

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

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 d

What are "identifier extensions"?

S02 mentions "identifier extensions" in the section describing adverbial pairs with non-identifier keys (see the table reproduced below). What are identifier extensions? I'm guessing that : and :<+> are both acting as identifier extensions in these examples: statement_control: infix:<

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

Patches applied to trunk in r25705.

[perl #50800] Update PIR coda?

# New Ticket Created by Will Coleda # Please include the string: [perl #50800] # in the subject line of all future correspondence about this issue. # 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..

# New Ticket Created by Will Coleda # Please include the string: [perl #50802] # in the subject line of all future correspondence about this issue. # 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 PIR.