Dan,
As it stands, KEY * is a win when:
1) All of the array indices are constants and hardcoded into the instruction
stream
2) The PMC handling the index does not have to recurse.
In all other cases, as it currently stands, it is a loose. I hate to come out
and be so blunt, but I thin
On Sunday 21 July 2002 06:46 pm, Scott Walters wrote:
> 2. PMCs return iterators allocated on a stack that allow them to function
> as KEY *s allocating a single fixed size peice of memory rather than all of
> the parts of a linked list. In other words, factor out the part of PMCs
> that index a g
At 11:46 AM -0700 7/21/02, Scott Walters wrote:
>In all other cases, as it currently stands, it is a loose. I hate to come out
>and be so blunt, but I think this is the culmination of what I've found, and a
>lot of people are saying. This approach is penny wise, pound foolish.
Being blunt since I
At 10:26 AM -0700 7/21/02, Scott Walters wrote:
>It is pretty clear that no one is happy with the keyed system. It
>doesn't do what people want (eg, let you use arrays as keys).
>While keys are supposed to be fast, constructing them takes a series
>of instructions.
>
>Perspective:
>
>Keys are not
At 5:44 PM +0100 7/21/02, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Mike Lambert <[EMAIL PROTECTED]> wrote:
>
>> Does anyone who is more familiar with the keyed stuff than I am, want to
>> write two parrot examples, one that uses three-level keys, and one that
>> dereference
At 7:06 PM +0100 7/21/02, Tom Hughes wrote:
>In message <20020721174150$[EMAIL PROTECTED]>
> Scott Walters <[EMAIL PROTECTED]> wrote:
>
>> I propose that keyed access do exactly eight things:
>>
>> * fetch a PMC using a key
>> * fetch a integer using a key
>> * fetch a number using a
Dan,
Thanks for being a good sport. I'm not in a hurry here - don't feel like you
need to be.
> >> I propose that keyed access do exactly eight things:
> >>
> >> * fetch a PMC using a key
> >> * fetch a integer using a key
> >> * fetch a number using a key
> >> * fetch a string using a k
On Sat, Jul 20, 2002 at 10:23:45PM -0400, Tanton Gibbs wrote:
> without the recall it performs in: 16.055 seconds
> with the recall it performs in: 16.722 seconds
>
> So, it slowed it down 6.5 tenths of a second after 10,000,000 times. That
> is not too bad for ensuring correct semantics.
>
>
# New Ticket Created by "Tanton Gibbs"
# Please include the string: [perl #15306]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15306 >
This patch does a number of things
1.) adds the RECALL command. This command was de
I stated #4 wrong...it should be perlnum.pmc not perlint.pmc
- Original Message -
From: "Tanton Gibbs (via RT)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 22, 2002 12:26 AM
Subject: [perl #15306] [PATCH] pmc RECALL command implemented
> # New Ticket Created by "Tanto
> I stated #4 wrong...it should be perlnum.pmc not >perlint.pmc
[snip exceedingly long unnecessary repost...]
It's late...I didn't mean to take up your bandwidth :(
sorry about that.
# New Ticket Created by Scott Walters
# Please include the string: [perl #15308]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15308 >
There are some questions burried in there, marked with XXX. I'm sorry I was
unable to
The thought process went something like this.
In a world of distributed perl data, we want an
expression like
foreach (grep { $_->{smoker} and $_->{age} > 18 } @Subscribers){
$->send($Cigarette_Advertisement)
}
to do the filtering on the machine that holds the s
13 matches
Mail list logo
