Peter Gibbs wrote:
> > How much of the speed win is from the cycle count instead of stack
> > walking? Unless you've solved the problem of recursive interpreter
> > calls and setjmp, it's not a valid solution, no matter what the speed
> > win might be.
> According to my notes the progression (fo
# New Ticket Created by Mike Lambert
# Please include the string: [perl #16269]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16269 >
I finally was able to get Peter's old COW patch up and running with our
current codebas
Mike Lambert wrote:
> Just for fun, can you run Hanoi on CVS versus CVS+COW?
>
> I just got COW implemented here, and while I get a 17% speedup on
> life, I get a 5% loss on hanoi. Since you only posted life, it's a
> bit hard to see if the drop on hanoi is just my fault, or the fault of
> COW in
At 8:53 AM + 8/17/02, Mike Lambert (via RT) wrote:
>
>However, in the interest of saving someone from updating yet-another COW
>patch in the long-distant future because this wasn't applied (similar to
>how Peter's patch got left to bit-rot), can we try to reach a closure on
>this patch (either
Hi Mike
Elapsed times for 'time parrot hanoi.pbc 14 > /dev/null' are:
CVS: 52.81, 52.05, 52.33
CVS + grey COW: 51.53, 52.06, 51.67
CVS + Mike's COW: 44.31, 44.48, 44.55
CVS + grey1: 35.89, 36.48, 36.60 (+COW +cyclecount -stackwalk)
End June grey: 30.14, 29.35, 29.53
And 5000 generations of life
On Sat, 17 August 2002, Nicholas Clark wrote:
> But how on earth would you implement such a thing? :-)
I imagine that type specifiers require that values assigned to
the corresponding variable satisfy: value.isa(type). Using a
superposition as a type means that the result of that test comes
ba
Aaron Sherman wrote:
> So,
>
> my all(str, int) $foo = $!;
>
> would be fine?
I'd expect so.
> I'm forgetting what has been said about $!
Typically contains an object with both string and integer conversions.
Whether convertability to both types is enough to satisfy a
superpositional
In a message dated Sat, 17 Aug 2002, [EMAIL PROTECTED] writes:
> [$!] Typically contains an object with both string and integer
> conversions. Whether convertability to both types is enough to satisfy a
> superpositional type is an interesting question. I suspect it *is*.
Then I'd assume that mul
Hello All,
After reading over Apocalypse 5 one more time, I noticed that balanced
matches (like capturing nested parenthetical comments ((like this))) had
been glossed over in the rejection of RFC 145. What was not even
mentioned in the rejection was the possibility of balanced expressions
that
Peter Behroozi:
# After reading over Apocalypse 5 one more time, I noticed that
# balanced matches (like capturing nested parenthetical
# comments ((like this))) had been glossed over in the
# rejection of RFC 145. What was not even mentioned in the
rule parenthesized { \( ( <-[()]>
As Peter has pointed out, our stackwalk code is rather slow.
The code that's in there was my first-attempt at the need for stack
walking code. There's one optimization in place, but the algorithm behind
the optimization could use some work.
Basically, it finds the min and max values of all heade
At 3:07 PM +0200 8/14/02, Josef Hook wrote:
>I've moved all code into one file now.
Cool. Would someone commit this, please?
--
Dan
--"it's like this"---
Dan Sugalski even samur
On Sat, 17 Aug 2002, Brent Dax wrote:
: Peter Behroozi:
: # After reading over Apocalypse 5 one more time, I noticed that
: # balanced matches (like capturing nested parenthetical
: # comments ((like this))) had been glossed over in the
: # rejection of RFC 145. What was not even mentioned in
Larry Wall:
# That being said, there may well be a builtin rule that
# refers to the current rule without having to name it. That
# lets you write anonymous recursive rules, or possibly a
# generic rule that could have more than one name.
I suspected as much, but didn't use it to avoid stepp
On Sat, 2002-08-17 at 14:31, Brent Dax wrote:
> Peter Behroozi:
> # After reading over Apocalypse 5 one more time, I noticed that
> # balanced matches (like capturing nested parenthetical
> # comments ((like this))) had been glossed over in the
> # rejection of RFC 145. What was not even menti
Mike Lambert wrote:
> As Peter has pointed out, our stackwalk code is rather slow.
> Anyone feeling adventuresome and want to attempt to speed this up?
If you want to get some improvement at the cost of some duplicated
code, you can remove the * direction logic, and write two copies of the
loo
At 3:30 PM + 8/17/02, Tom Hughes (via RT) wrote:
>
>Attached is my first cut of a patch to address the keyed access issues.
>
>This patch doesn't do everything, but it does bring things more or less
>in line with Dan's recent specification I hope. I'm sure there are also
>problems with it so i
On Sat, Aug 17, 2002 at 10:23:32PM +0200, Peter Gibbs wrote:
> If you want to get some improvement at the cost of some duplicated
> code, you can remove the * direction logic, and write two copies of the
> loop. (patch attached, but not fully tested)
> I'm sure there is more that can be done, b
I've uploaded a new version of my Perl6::Parameters module. This is
mostly just a "make it compile" version; its design is out of sync with
the current Perl 6 design, a problem I'll resolve in the next version.
It should be bouncing around between mirrors right now, so it may be up
to a day befo
Jason Gloudon wrote:
> The configure-time-stack-growth-direction patch makes these #define'd
constants,
> so you get the same speedup.
Do you also have a patch to determine the minimum stack increment?
The IA32 architecture, for example, has no restrictions on pointer
alignment (and hence PARROT
At 9:33 PM -0400 8/16/02, Melvin Smith wrote:
>At 03:45 PM 8/16/2002 -0400, Jerrad Pierce wrote:
>>I was wondering if perl would be handling negative array indices in the
>>same manner as perl 5?
>>That is to FETCHSIZE + index = real index, before attempting to fetch
>>the element.
>>It would be s
At 8:45 AM +0200 8/7/02, Angel Faus wrote:
>Dan Sugalski escribió:
>> At 8:40 AM +0200 8/6/02, Angel Faus wrote:
>> >The point about the lack of documentation remains, and i will
>> > solve it as soon as i get an indication that the design is ok.
>>
>> The design's fine, and we can add what we
At 11:41 PM +0200 8/13/02, Jerome Quelin wrote:
>Well, I don't know if this is interesting, but here's a patch that implement:
>op rand(out NUM)
>op rand(out NUM, in INT)
>
>and does what you can guess. There's also a test file (I don't know wether
>the tests should go in an existant test
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Has someone looked at and maybe committed this?
The reason I asked which pieces of Parrot were prototypes was because
optimizing the hell out of something that's only a prototype is nothing
short of intellectual masturbation, and it seems nobody actually
The POD below my sig is a proposed PDD on external data interfaces, that
is, the way embedders and extenders will access Parrot's data types. It
covers Strings, Buffers, and PMCs, as well as a few related functions.
Let me know what you think.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot
On 17 Aug 2002, Peter Behroozi wrote:
: However, since you forced me to read through A5 again, I now have
: another question :). Since we can now do
:
: $string.tr %hash;
:
: what happens when the keys of %hash have overlapping ranges by accident
: or otherwise? Are there any other options tha
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #16278]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16278 >
This patch modifies the stack walking code to create a prefix mask for doing a
fast a
On Sun, Aug 18, 2002 at 02:51:34AM +, Jason Gloudon wrote:
> # New Ticket Created by Jason Gloudon
> # Please include the string: [perl #16278]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=16278 >
Moved the static
Applied, thanks.
> Moved the static prototype to dod.c
>
> Jason
Applied, thanks.
Mike Lambert
> This is a config test for the direction of stack growth that makes
> the direction a compile time constant.
>
> --
> Jason
> Attached is my first cut of a patch to address the keyed access issues.
First, thanks for spending the time to implement and clean up the keyed
code. Hopefully this'll clean the floor so that when this list has key
discussions, we'll all be arguing about the same thing. :)
> This patch doesn't
At 3:50 PM -0400 8/17/02, Dan Sugalski wrote:
>At 3:07 PM +0200 8/14/02, Josef Hook wrote:
>>I've moved all code into one file now.
>
>Cool. Would someone commit this, please?
Nevermind--I did.
--
Dan
--"it's like this
Somewhat random question here:
We all know how to alias things in Perl 5. The binding operator allows aliasing in
Perl 6, I understand. So, how do we alias grammer rules? Here are my guesses.
Rules live in the same namespace as subroutines, so you can use the &. Or possibly
(because filehandle
33 matches
Mail list logo
