can you unsubscribe me asap
rgds
venkat
-Original Message-
From: Ashley Winters [mailto:[EMAIL PROTECTED]
Sent: Monday, December 06, 2004 7:19 AM
To: Luke Palmer
Cc: Leopold Toetsch; Perl 6 Internals
Subject: Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[E
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> > This term came up in a recent discussion[1]. But I'd like to give this
> > term a second meaning.
>
> Except what you're talking about here is premature *optimzation*.
> You're expecting certain
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> > This term came up in a recent discussion[1]. But I'd like to give this
> > term a second meaning.
>
> Except what you're talking about here is premature *optimzation*.
Yes, indeed.
Cheers,
Mich
Piers Cawley writes:
> I'd submit that, in the vast majority of cases you're not going to be
> dealing with full continuations, and on the occasions when you are the
> programmer using them will be aware of the cost and will be willing to
> pay it.
Yeah probably. Except the problem isn't the cost
Leopold Toetsch writes:
> This term came up in a recent discussion[1]. But I'd like to give this
> term a second meaning.
Except what you're talking about here is premature *optimzation*.
You're expecting certain forms of the opcodes to be slow (that's the
pessimization part), but then you're acut
On Dec-01, Dan Sugalski wrote:
>
> C, for example, is weakly typed. That is, while you tell the system
> that a variable is one thing or another (an int, or a float), you're
> perfectly welcome to treat it as another type. This is *especially*
> true of values you get to via pointers. For examp
Luke Palmer <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
>> I'd submit that, in the vast majority of cases you're not going to be
>> dealing with full continuations, and on the occasions when you are the
>> programmer using them will be aware of the cost and will be willing to
>> pay it.
>
>
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #32877]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32877 >
I am pretty certain that parrot was building fine in Tru64 back in
2004/11/07 15
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
>> Thanks for the clear explanation. I did not realize that S registers
>> could switch pointers, that does make things a little harder. I have
>> a recommendation for a possible hybrid solution. Incur the co
Can we get a ruling on this? I tend to agree with the statement "Random build
files do not
belong in the root directory".
The patch has been un-ACK'd for nine months at the moment.
> [EMAIL PROTECTED] - Tue Mar 02 03:49:32 2004]:
>
> Steps:
> (1) move ./libnci.def to ./src/libnci.def
> (2)
Thanks, applied.
Bernhard Schmalhofer (via RT) wrote:
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 >
Hi,
this patch adds a ta
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 >
Hi,
this patch adds a target 'help' to 'parrot/docs/Makefile'. A list of
ava
Sam Ruby <[EMAIL PROTECTED]> wrote:
> General thoughts on the proposal to replace VTABLES with methods:
> 1) Anything that is unary (i.e., contains exactly or one argument) is
> not affected by MMD.
That's not quite true. We currently have just infix MMD dispatching on
left and right. That's just
A cache, well caches things and speeds something up, and can be
considered as an optimization. OTOH, knowing that things can be
reasoable fast, can open the mind for possible solutions that would
otherwise be silently discarded as known to be slow.
I'm not proposing the usage of inline caching
This term came up in a recent discussion[1]. But I'd like to give this
term a second meaning.
During design considerations we (including me of course too) tend to
discard or pessimize ideas early, because they look inefficient. Recent
examples are e.g.
- spilling
- lexical (re-)fetching
- metho
General thoughts on the proposal to replace VTABLES with methods:
1) Anything that is unary (i.e., contains exactly or one argument) is
not affected by MMD. There is no need to replace any such methods.
2) While I don't see Python translators using a "sin" opcode, I can see
the implementation o
Given a multi sub declaration a la S13:
multi sub *infix:<-> (MyInt $left, int $right) {mysub($left, $right)}
multi sub *infix:<-> (int $left, MyInt $right) {myrsub($right, $left)}
The first one would create a MMD function variant of
sub_p_p_ior Pleft."sub"(Iright, Pdest)
o
Bernhard Schmalhofer (via RT) wrote:
Hi,
this patch adds support for dynamic evaluation of 'Parrot abstract syntax
tree As Simple Text'. This was done be implementing the C-function
'ast_compile_past'.
Great, thanks.
Simple examples for dynamic executable PAST are in t/pmc/eval.t. The
toplevel node
18 matches
Mail list logo
