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
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
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
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
exceptions.patch
Description: Binary data
malloc.patch
Description: Binary data
Makefile.patch
Description: Binary data
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 @
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
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
# 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
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
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
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
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
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
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
16 matches
Mail list logo
