# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #793]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=793 >
This patch adds shl and shr for PMC's.
/s
-- attachment 1
> On Wed, 10 Jul 2002 12:51:40 -0700 (PDT), John Porter <[EMAIL PROTECTED]>
>said:
> Would I be out of line to request that people edit their email
> headers so that replies only go to the list?
> I'm tired of getting two (or more) copies of everything on
> any thread I've posted in.
On Wed, Jul 10, 2002 at 11:21:10AM -0400, Dan Sugalski wrote:
| I'm not sure that the place to enforce read-onlyness is at the
| string/buffer level. Doing it at the PMC level is more likely the
| right place to do it.
Therefore, "read-onlyness" would be a property of any ole
object and not jus
On Wed, Jul 10, 2002 at 06:49:06PM -0400, Dan Sugalski wrote:
> Yes, this is an issue for systems with a chunked stack. As far as I
> know that only applies to the various ARM OSes, and for those we'll
> have to have some different system specific code to deal with the
> stack. (Which is fine)
"Andreas J. Koenig" wrote:
> ... trimming CC list always would probably be an overreaction.
Sounds like you have good reasons.
Oh well, some people win, some people lose.
:-/
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dia
Brent Dax wrote:
> Nicholas Clark wrote:
> > Unless I'm being thick, x² < y² whenever x < y for positive x
> > and y (ie you don't need to take the square root of the
> > hypotenuse to work out which hypotenuse is shorter. And all
> > we're actually interested in which one is shorter, aren't w
Dan Sugalski wrote:
> lookup is O(n) since we precompute the dispatch table.
Oh. So the cost of computing the table is amortized over all the
mm calls that go to the table for resolution. Could be Bad,
for the typical small Perl program.
Then there's the issue of the size of the table.
Consid
At 2:13 PM -0700 7/10/02, John Porter wrote:
>Dan Sugalski wrote:
>> John Porter wrote:
>> > but what about non-PMC variables?
>>
>> Generally speaking, there aren't any. Everything else (in this case
>> the buffer/string things) is for internal use only. Languages aren't
>> supposed to expos
At 5:39 PM -0400 7/10/02, Melvin Smith wrote:
>Its almost as if the only optimization will be for
>
>foreach my $i (1...1)
>
>where we know the type ahead of time.
>
>We've built this register based VM upon which Perl will probably be
>the most non-optimized language. Things like exposing your
At 6:15 PM -0700 7/10/02, Brent Dax wrote:
>Nicholas Clark:
># On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
># >
># > Dan Sugalski wrote:
>#
># > > Heh. I never expected to have to dust off my trig skills when I
># > > started this. If I need to dig out the calculus books, I
># thi
At 11:37 PM -0700 7/10/02, Ashley Winters wrote:
>On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote:
>> I was referring to the above situation where a lexical might be optimized
>> away without being stored in a pad (for %MY).
>
>I would *hope* %MY is only modified at compile-time. I wouldn
At 9:54 AM -0400 7/11/02, Clark C . Evans wrote:
>On Wed, Jul 10, 2002 at 11:21:10AM -0400, Dan Sugalski wrote:
>| I'm not sure that the place to enforce read-onlyness is at the
>| string/buffer level. Doing it at the PMC level is more likely the
>| right place to do it.
>
>Therefore, "read-onlyne
Dan Sugalski wrote:
> Nicholas Clark:
> > Unless I'm being thick, x" < y" whenever x < y for positive x
> > and y (ie you don't need to take the square root of the
> > hypotenuse to work out which hypotenuse is shorter. And all
> > we're actually interested in which one is shorter, aren't we?)
>
At 9:50 AM -0700 7/11/02, John Porter wrote:
>Dan Sugalski wrote:
>> lookup is O(n) since we precompute the dispatch table.
>
>Oh. So the cost of computing the table is amortized over all the
>mm calls that go to the table for resolution. Could be Bad,
>for the typical small Perl program.
More
Dan Sugalski wrote:
> That trades space for speed,
Ain't it always the way. ! :-)
> In general that's potentially unbounded, but for the specific
> case of PMC vtable methods it's a fixed number.
> It gets more interesting for general methods and subs,
> but we can deal with that a bit later.
On Wed, 10 Jul 2002, Nicholas Clark wrote:
> > Dan Sugalski wrote:
>
> > > Heh. I never expected to have to dust off my trig skills when I
> > > started this. If I need to dig out the calculus books, I think I'll
> > > just go run screaming...
>
> Unless I'm being thick, x² < y² whenever x <
At 10:46 AM -0700 7/11/02, Scott Walters wrote:
>
>> There were serialization/deserialization in the PMC vtables at one
>> point, but that's gone. I think I may add it back in, though of
>> course no PMC is required to provide them.
>
>Please ! -=)
>
>Hi everyone. I'm going to try to take on s
Andy Dougherty wrote:
> Assuming x and y are coordinates in a 2-d space, and that both are
> integers >= 0, why not just use what is affectionately called the
> "taxicab" metric: x+y? It is just as "valid" and even quicker to
> compute than the Euclidean metric sqrt(x^2 + y^2).
Yes! Very inci
On Thu, Jul 11, 2002 at 10:52:31AM -0700, John Porter wrote:
>
> Dan Sugalski wrote:
> > Nicholas Clark:
> > > Unless I'm being thick, x" < y" whenever x < y for positive x
> > > and y (ie you don't need to take the square root of the
> > > hypotenuse to work out which hypotenuse is shorter. And
Nicholas Clark wrote:
> I was thinking that the metric (x*x + y*y) would be fast to
> calculate, as that's all we need for ordering.
Point is, it's rather *more* than we need for ordering.
x + y will suffice.
> And I live in London, where we don't have a regular grid of
> streets, so our taxis
Since we've had a few new faces around here recently, I thought it
would be a good time to remind people about www.parrotcode.org, and
specifically the Development Resources page.
http://www.parrotcode.org/resources
It looks a lot like this, but with links of course...
* Perl 6/Parrot Mail
At 8:58 PM +0100 7/11/02, Nicholas Clark wrote:
>On Thu, Jul 11, 2002 at 10:52:31AM -0700, John Porter wrote:
>>
>> Dan Sugalski wrote:
>> > Nicholas Clark:
>> > > Unless I'm being thick, x" < y" whenever x < y for positive x
>> > > and y (ie you don't need to take the square root of the
>> >
At 7:04 PM +0100 7/11/02, [EMAIL PROTECTED] wrote:
>Ashley Winters <[EMAIL PROTECTED]> writes:
>> Yes, my Scheme interpreter written in Perl6 is coming along nicely. Muahaha!
>> (kidding, obviously)
>
>It's already been done. Though I had to back port the design to perl 5
>to make sure it was co
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
> Nicholas Clark wrote:
> > I was thinking that the metric (x*x + y*y) would be fast to
> > calculate, as that's all we need for ordering.
>
> Point is, it's rather *more* than we need for ordering.
> x + y will suffice.
IIRC, all metr
It appears that not all of the keyed versions for aggregates
are supported by the assembler and/or in the ops file.
If someone has time, I think it would be very useful to catalogue:
1) Which keyed versions are we missing (if any)
2) Which are working (by working I mean they exist in core.ops _a
Dan Sugalski wrote:
> Piers "Fermat" Cawley wrote:
> > Oh yes, and I recently wiped it (p5 port included) by accident.
> > And didn't have a backup. Ah well...
>
> That's just a bit of self-preservation on the part of the universe,
> I expect... ;-P
Then the universe hasn't evolved to the point
Dave Mitchell wrote:
> IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> are strongly equivalent, ie they give rise to the *same* ordering.
> (In the limit as n -> Inf, the metric is max(x,y).)
I'm sorry, YDNRC.
Consider the distance from the origin to the points (0,6) and (3,4).
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #801]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=801 >
This patch makes the following behave as it does in Perl 5:
@a = 1..3; @b = 1..3;
It's time for my weekly post to this old thread. The grammar has
grown enough to deserve more than one file, and is starting to change
in new directions. For example, it's now Turing-complete, if you have
a Parrot engine and a bit of spare time. Call it a primitive "demo
version" of some of Per
In message <[EMAIL PROTECTED]>
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 10, 2002 at 06:49:06PM -0400, Dan Sugalski wrote:
> > Yes, this is an issue for systems with a chunked stack. As far as I
> > know that only applies to the various ARM OSes, and for those we'll
> > ha
30 matches
Mail list logo
