At 7:58 PM -0400 6/29/03, Clinton Pierce wrote:
Clarification:
running an invoke() at *any* time will cause all subsequent tracing
to segfault. Thus (pseudoPASM):
loadlib
dlfunc
invoke
trace 1
end
Will cause the segfault.
I checked in a fix for
Clarification:
running an invoke() at *any* time will cause all subsequent tracing to segfault. Thus
(pseudoPASM):
loadlib
dlfunc
invoke
trace 1
end
Will cause the segfault.
> Original Message-
> From: "Clinton A. Pierc
At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
... I'd also like to be able to manipulate the stacks in a context,
pushing things on them, changing values on them, and generally
messing about with the things, so I'm all for it.
Do you have some examples for a usage of such
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [perl #22854]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22854 >
This is either an oversight in the current implementation *or* its a bug. Or bot
Dan Sugalski wrote:
[ stack implementations ]
Well... we only really have three.
Control, User & Pad have the same stack engine. The register backing
stacks and rxstack sum up to 5 more.
... The I/P/N/S stacks are all the
same, the only reason they've got different code is because the elements
Dan Sugalski wrote:
[ update continuation PMC at call time ]
Here are some possibilities to achieve this:
- invokecc (this is slow)
- a new opcode e.g. C (update continuation ctx)
- toss invokecc's current functionality and use this opcode to update
the context and call the sub.
I like option 2.
At 3:08 PM +0200 6/28/03, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
So, now that we're using CPS, will there be a standard way of seeing
what the call stack is (for purposes of debugging/C/&c.)? Is
it just a matter of looking in P0 and then P0's P0, and so on? Or
will that
At 2:43 PM +0200 6/28/03, Leopold Toetsch wrote:
In the meantime interpreter->warns has moved to the context
structure and gets now restored for CPS subroutine calls.
But there is a slight problem (as well as with e.g. pad_stacks)
When we have:
warningson 1
newsub .Sub, .Continuation, _func,
At 5:08 PM -0700 6/26/03, Brent Dax wrote:
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
that
# it was nonfatal, and resume execution from just after the place it was
# thrown from.
The problem with that is that some exceptions are unresumable. For
example
At 11:21 PM +0200 6/26/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 8:26 AM +0200 6/25/03, Leopold Toetsch wrote:
The first question is:
Do we need such a limit check on the register backing stacks too?
If we're going to put limits in, yes.
If we want some secure execut
At 12:57 PM -0400 6/26/03, David Robins wrote:
> So... Configure.pl needs to be able to build a makefile that has
per-C-file flags, and those flags need to be overridable per-file at
configure time by the platform configuration module.
Does the makefile need to be a typical 'make' makefile or is
Melvin Smith wrote:
Then if a language like Perl wants a funky scope type such as "local" (not
to be confused with IMCC .local) then it can implement them at a higher
level.
I'm not too sure, but it seems, that all named variable handling of an
interpreted HL finally ends up in either find_global
Clinton Pierce <[EMAIL PROTECTED]> wrote:
> {
> my $a;
> sub foo {
> my $c;
> $a=1;
> }
> sub main {
> my $usedonce;
> $a=15;
> $usedonce=0;
> foo();
> }
> }
Thi
13 matches
Mail list logo
