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
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
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
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
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
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
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
>
> 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!
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
On Tue, 2008-02-12 at 21:36 -0500, Bob Rogers wrote:
> From: chromatic <[EMAIL PROTECTED]>
>Date: Tue, 12 Feb 2008 17:03:31 -0800
>
>On Tuesday 12 February 2008 16:55:06 Geoffrey Broadwell wrote:
>
>> Feh. Please someone tell me there is a light at the end of this tunnel?
>
>Don
From: chromatic <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:03:31 -0800
On Tuesday 12 February 2008 16:55:06 Geoffrey Broadwell wrote:
> Feh. Please someone tell me there is a light at the end of this tunnel?
Don't worry. Parrot will give Rakudo a whole different set of perfor
On Tuesday 12 February 2008 16:55:06 Geoffrey Broadwell wrote:
> Feh. Please someone tell me there is a light at the end of this tunnel?
Don't worry. Parrot will give Rakudo a whole different set of performance
problems than Perl 5 has.
-- c
On Tue, 2008-02-12 at 12:46 -0500, Bob Rogers wrote:
> From: Andrew Parker <[EMAIL PROTECTED]>
>Date: Tue, 12 Feb 2008 15:17:03 +0100
>
>Thanks for the pointer, Bob. I read through it and it might be
>tangentially related to this. That problem is about scopes being
>modeled b
So that works in this situation because the outer lexpad that I want
is the same as the caller's lexpad. Thanks for the tip :) After
poking around a bit at what "getinterp" does I found some good reading.
* docs/ops/core.pod - getinterp returns the ParrotInterpreter
* src/pmc/parrotinterp
On Mon, Feb 11, 2008 at 10:27:27PM +0100, Andrew Parker wrote:
> .namespace
> .sub "outer"
> new $P12, "Integer"
> assign $P12, 1
> .lex "x", $P12
> get_global $P18, "inner"
> newclosure $P18, $P18
> $P17 = $P18()
> print $P17
> print "\n"
> .end
>
> .sub "inner" :
From: Andrew Parker <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 15:17:03 +0100
Thanks for the pointer, Bob. I read through it and it might be
tangentially related to this. That problem is about scopes being
modeled by subs in parrot. IMHO there is not a great problem there,
Thanks for the pointer, Bob. I read through it and it might be
tangentially related to this. That problem is about scopes being
modeled by subs in parrot. IMHO there is not a great problem there,
since a sub is really an abstraction for entering and leaving a scope
and so a good abstract
17 matches
Mail list logo
