On Fri, Jul 11, 2003 at 04:20:34PM -0400, Chip Salzenberg wrote:
> According to Benjamin Goldberg:
> > There is indeed a clear need for it ...
>
> False.
>
> > We don't *need* to do things this way, of course ...
>
> True.
>
> Having gone through the pain of numstr implementation, I suggest tha
Benjamin Goldberg:
# There is indeed a clear need for it -- the values produced by $! (and
by
# the related $^E) are dual int/string values.
In Perl 5, yes. However, in Perl 6, $! is set for *all* exceptions, not
just C errors, so I suspect that this behavior is no longer
appropriate. (IIRC, C e
Benjamin --
The trick is to find the cheapest possible way to get conditional
processing to occur if and only if there are events in the event
queue.
I'll only be considering the fast core here for simplicity. But,
if you look at include/parrot/interp_guts.h, the only thing of
interest there is t
According to Benjamin Goldberg:
> There is indeed a clear need for it ...
False.
> We don't *need* to do things this way, of course ...
True.
Having gone through the pain of numstr implementation, I suggest that
normal variables should not be forced to do anything so unnatural.
(Customized PMCs
Leopold Toetsch wrote:
[snip]
> - When will we check, it there are events in the event queue?
If we check too often (between each two ops), it will slow things down.
If we don't check often enough, the code might manage to avoid checking
for events entirely.
I would suggest that every flow contr
Leopold Toetsch wrote:
> Nick Glencross wrote:
>
> > Having read up in the past on Perl5 internals, it seems to be
> > capable of keeping more than one representation of a Scalar active
> > at a time.
> >
> > Anyone know if there are plans to do this kind of optimisation?
>
> I don't think, this
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #22914]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22914 >
Having publically and repeatedly embarrassed myself on perl6-internals
today, I
At 10:09 AM +0200 7/11/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Log:
Accessing env variables is a nice thing
Yep. Good idea.
It was about time. :) And trivial, as too much of the pending stuff has been.
> pmclass Env extends default {
What do you think of:
- Env
Lars Balker Rasmussen <[EMAIL PROTECTED]> writes:
> Whoa, that didn't work too well. Let's try again:
>
> gcc on FreeBSD (and I'd imagine others) complains over an fprintf
> in exceptions.c.
>
> malloc.h is deprecated on FreeBSD 5, and will make various
> configuration tests fail. The following p
Lars Balker Rasmussen <[EMAIL PROTECTED]> writes:
> Whoa, that didn't work too well. Let's try again:
>
> gcc on FreeBSD (and I'd imagine others) complains over an fprintf
> in exceptions.c.
>
> malloc.h is deprecated on FreeBSD 5, and will make various
> configuration tests fail. The following p
Index: exceptions.c
===
RCS file: /cvs/public/parrot/exceptions.c,v
retrieving revision 1.17
diff -u -a -r1.17 exceptions.c
--- exceptions.c 10 Jul 2003 16:56:46 - 1.17
+++ exceptions.c 11 Jul 2003 13:29:01 -
@@ -119,7 +119,7 @
exceptions.patch
Description: Binary data
malloc.patch
Description: Binary data
Makefile.patch
Description: Binary data
More fun to play with.
This is t/op/hacks_5.pasm:
newsub P0, .Exception_Handler, _handler
set_eh P0
div I10, 0
print "not reached\n"
end
_handler:
.include "signal.pasm"
print "catched it\n"
set I0, P5["_type"]
neg I0, I0
ne I0, .SIGFPE, nok
print "ok\n"
nok
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Log:
> Accessing env variables is a nice thing
Yep. Good idea.
> pmclass Env extends default {
What do you think of:
- Env extends PerlHash
- interpreter has an empty env variable created at interpreter creation
- on first access to it, the hash ge
Simon Glover wrote:
The PMC version of this op (ie cmod_p_p_p) is identical in
implementation to the plain mod op (mod_p_p_p), which seems rather
pointless. Would anybody object if we just got rid of it?
There should probably be a C vtable meth too which does, what
the current does. s. mod/cmo
Nick Glencross wrote:
Having read up in the past on Perl5 internals, it seems to be capable of
keeping more than one representation of a Scalar active at a time.
Anyone know if there are plans to do this kind of optimisation?
I don't think, this is an optimization at least not for an average
16 matches
Mail list logo
