On 2019-12-24 08:54, Shlomi Fish wrote:
I intentionally sent previous email to you because I thought it is
unrelated with the original post and didn't want to bother other guys.
I see. In that case the sensible thing to do is to write "[sent in private]" so
I'll know it is intentional see:
; > > > «
> > > > > >
> > > > > > 404
> > > > > >
> > > > > > There isn't a GitHub Pages site here.
> > > > > >
> > > > > > If you're trying to publish one, read the full documenta
're trying to publish one, read the full documentation to learn
> > how
> > > > to
> > > > set up GitHub Pages for your repository, organization, or user account.
> > > > GitHub
> > > > Status — @githubstatus
> > > >
> >
> > > > to
> > > > > set up GitHub Pages for your repository, organization, or user
> account.
> > > > > GitHub
> > > > > Status — @githubstatus
> > > > >
> > > > > »
> > > > >
> > >
t; to
> > set up GitHub Pages for your repository, organization, or user account.
> > GitHub
> > Status — @githubstatus
> >
> > »
> >
> > Please restore your site.
> >
> > Regards,
> >
> > Shlomi
> >
> > On Tue, 24 Dec 20
> Shlomi
>
> On Tue, 24 Dec 2019 11:00:44 +0300
> İsmail Arılık wrote:
>
> > From: İsmail Arılık
> > To: ToddAndMargo
> > Cc: perl6-us...@perl.org
> > Subject: Re: Stack Exchange
> > Date: Tue, 24 Dec 2019 11:00:44 +0300
> >
> > Sorry, I
Sorry, I have noticed that I clicked "Answer" button instead of "Answer
All" button and my email was only sent to ToddAndMargo. I am writing a copy
of my email below:
> The issues you mentioned is actually called community moderation and is
one of the most useful features of SO. It is the secret o
On 2019-12-23 16:01, ToddAndMargo via perl6-users wrote:
it is not correcting my grammar
that I find offensive
And it is not just your grammar. One of
the censors took out "Many thanks -T". Now
that is just being frivolous.
On 2019-12-23 00:34, Patrick Spek via perl6-users wrote:
They may be a negative to you personally because you dislike being
corrected on grammar, but they're not "negative issues" for the
community at large.
Don't get me wrong, it is not correcting my grammar
that I find offensive -- that I ap
On Sun, 22 Dec 2019 14:51:52 -0800
ToddAndMargo via perl6-users wrote:
> Hi All,
>
> I have posted a few times to Stack Exchange. There is a
> lot of intellectual property over there. This I do like.
>
> What I do not like, is that it is hard to carry on a
> conver
Hi All,
I have posted a few times to Stack Exchange. There is a
lot of intellectual property over there. This I do like.
What I do not like, is that it is hard to carry on a
conversation do their their comments being so short
and lacking in formatting. They expect you to add
extra comments
CATCH { default { .say; last; # it
should be applied too lexical `for 1..3` but it controls outsourced loop
from exception stack } } } say "end outer $i";}say "end";
Code and actual/expected output are here:
https://gist.github.com/anonymous/6912bd53ce24af0d76d62d522dfc0b94 . Best
regards.
On Sat Aug 29 04:31:00 2015, coke wrote:
> BTW, I am having a really hard time on moar making this crash. I added
> some debug output to show the number of invocations on moar.
>
> Got up to 1000 invocations before I got bored and killed it.
Here's a sample showing the iterations.
sub recu
On Tue Aug 17 21:46:38 2010, coke wrote:
> Here's a simple program if you're lazy and want to cut and paste
> something to test:
>
>
>
> sub recursion($a) {
> recursion($a)
> }
>
> recursion("see also");
BTW, I am having a really hard time on moar making this crash. I added some
debug outpu
his is what I got:
Internal Error: Unwound entire stack and missed handler
This is commit f17ca342f434a160d455b9d16f7d4a2d17279087 of perl6/doc,
and perl6-m --version says:
This is perl6 version 2015.01-5-g912a7fa built on MoarVM version
2015.01-5-ga29eaa9
This happens on a 64bit Debian Jessie Li
-glossary.pod
Log Message:
---
FIFO is a queue and LIFO is a stack
TL;DR - fix at end.
If I change the MoarVM nursery size to 2034K, then the NQP build fails with
a SEGV in the garbage collector. There's an item on the worklist which is
an utterly bogus pointer. Adding a bit more code to try to see how it is
getting onto the worklist shows it to be coming from th
On Sat Nov 19 18:56:22 2011, sprout wrote:
> On Tue Aug 17 21:46:38 2010, coke wrote:
> > Here's a simple program if you're lazy and want to cut and paste
> > something to test:
> >
> >
> >
> > sub recursion($a) {
> > recursion($a)
> > }
> >
> > recursion("see also");
> >
>
> That example (
On Tue Aug 17 21:46:38 2010, coke wrote:
> Here's a simple program if you're lazy and want to cut and paste
> something to test:
>
>
>
> sub recursion($a) {
> recursion($a)
> }
>
> recursion("see also");
>
That example (with the bad prototype stripped) just gives me:
perl(5674) malloc: ***
# New Ticket Created by Wenzel Peppmeyer
# Please include the string: [perl #77170]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77170 >
If somebody comes up with the brilliant idea (or has to) increase the
recursion lim
Author: lwall
Date: 2010-07-10 00:59:12 +0200 (Sat, 10 Jul 2010)
New Revision: 31610
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] emphasize that LEAVE blocks *always* run even under stack unwinding
Modified: docs/Perl6/Spec/S04-control.pod
I'd just like to report that the stacktraces in Rakudo are back
to being insanely long.
I think they're even longer than when people were
complaining about them being far too long last time, and someone fixed
it.
and are also back to be totally useless
yes.
* masak submits rakudobug
Here's
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #70730]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=70730 >
rakudo: say rand() * Inf
rakudo 7347ec: maximum recursion depth exceeded [...]
o.O
*
On Fri Jul 04 01:39:12 2008, mor...@casella.verplant.org wrote:
> Error messages caused by programmer's mistakes shouldn't include stack
> traces.
>
> Rakudo r29047:
> ../../parrot perl6.pbc -e 'my Int $x; $x = "str"'
> Type check failed
> curr
On Wed, Oct 29, 2008 at 10:06:15PM +0100, NotFound wrote:
> > do_loop:
> > say i
> > push_eh do_inc
> > $P0 = find_method i, "succ"
> > i.$P0()
> > do_inc:
> > pop_eh
> > inc i
> > goto do_loop
>
> I've noticed an anomaly: if you
>> I've noticed an anomaly: if you add .get_results($P0) after pop_eh
>> nothing bag happens, but if you put it before, it starts leaking a lot
>> of memory.
>
> Is that after r32226?
Before it was leaking both ways, I think.
--
Salu2
On Wednesday 29 October 2008 14:06:15 NotFound wrote:
> > With the following example (and the other patches to
> > Parrot_ex_throw_from_op_args added by NotFound++), I'm able
> > to run the following version and get to 250,000 without any
> > difficulty.
> >
> >$ cat x.pir
> >.sub 'main'
>
> With the following example (and the other patches to
> Parrot_ex_throw_from_op_args added by NotFound++), I'm able
> to run the following version and get to 250,000 without any
> difficulty.
>
>$ cat x.pir
>.sub 'main'
> .local pmc i
> i = new 'Integer'
> do_loop:
>
On Tue, Oct 28, 2008 at 10:15:32PM -0500, Patrick R. Michaud wrote:
> ... As discussed in #parrotsketch
> earlier today and summarized at [1], the correct form of the
> above loop would have the "pop_eh" line after the do_inc label,
> so that every exception handler created in the loop is removed
>
On Sun, Oct 26, 2008 at 10:05:21PM -0700, Vasily Chekalkin wrote:
> Exception handling in parrot doesn't unwind used stack frames.
>
> Simple example:
>
> .sub 'main'
> .local pmc i
> i = new 'Integer'
>do_loop:
> say i
>
> I'm working on a patch that defines the helper function
> Parrot_ex_throw_from_op_args to simplfy the throwing in cases like this.
After discussion in #parrotsketch, added this function in r3
--
Salu2
This example fails because the op find_method uses
Parrot_ex_throw_from_c_args, that handles the exception in an inner
runloop. From an opcode is better to use Parrot_ex_throw_from_op, wich
jumps to the handler in the current runloop.
I'm working on a patch that defines the helper function
Parrot_
# New Ticket Created by Vasily Chekalkin
# Please include the string: [perl #60166]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60166 >
Hello.
Exception handling in parrot doesn't unwind used stack frames.
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57330]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57330 >
$ svn info | grep Revi
Revision: 29791
The following works:
$ ./perl6 -e 'exit'
$ ./pe
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #56604]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56604 >
Error messages caused by programmer's mistakes shouldn't include stack
tr
On Wednesday 04 June 2008 20:43:09 Andrew Whitworth wrote:
> This is a minor patch to remove references to the "User stack" (which
> pmichaud++ ripped out recently) from PDD09. It's a small change, and
> not the only one that needs to get made to this document most likel
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #55316]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55316 >
This is a minor patch to remove references to the "User stack" (w
Thanks for reporting, fixed.
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #54712]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54712 >
the stack ops have been removed, the page describing these is empty
now and can
The attached patch, not yet for application, uses the Valgrind memcheck header
to mark items on the stack as initialized. This clears up most of the
uninitialized read errors in our Valgrind checks, which makes it easier to
find real errors.
I'm not applying this patch yet because we n
Based on Tuesday's #parrotsketch discussion, r27153
eliminates the user stack opcodes from Parrot. DEPRECATED.pod
showed that this would occur after the 0.7.0 release, but given
discussions and changes relating to the other stacks it was
decided that this could probably take place now.
On Sun, 6 Apr 2008 01:39:31 +0530
"Senaka Fernando" <[EMAIL PROTECTED]> wrote:
> Hi Chromatic,
>
> do you trace the PMC object roots on the Stack within the GC? or in
> other words is there any Stack enumeration?
Some clarification: I think the question under discuss
Hi Chromatic,
do you trace the PMC object roots on the Stack within the GC? or in other
words is there any Stack enumeration?
Regards,
Senaka
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #44765]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44765 >
Problem: JIT code ist currently optimized to reuse the interpreter on
the stack.
Am Mittwoch, 1. August 2007 00:39 schrieb Bram Geron:
> Leopold Toetsch wrote:
> > It might be on the stack or just in a CPU register. While we have
> > code to mark all possible pointers on the stack, this isn't generally
> > true for CPU registers, as that's rathe
Leopold Toetsch wrote:
> It might be on the stack or just in a CPU register. While we have
> code to mark all possible pointers on the stack, this isn't generally
> true for CPU registers, as that's rather system-dependent.
>
> See also src/cpu_dep.c():trace_system_ar
# New Ticket Created by Andy Lester
# Please include the string: [perl #44019]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44019 >
Coverity found this one.
In PackFile_find_fixup_entry, ep=&e, where e is on th
of Mac system software requiring that the stack be at least 16-byte
aligned at all times. I can tell this because when running with -j, Parrot
ends up at an invalid instruction fault at this instruction in a Mac system
library:
movdqa %xmm0, 32(%esp)
Note the "a" there: "Ali
od thing, as code paths are simplified.
Q: do we really want or need a return stack per context?
The more I think about it, the more it makes sense [but see my change of
heart below]. The return stack needs to be scoped to the context
anyway, so that the code doesn't accidentally C into
Am Sonntag, 24. September 2006 03:43 schrieb Bob Rogers:
>The attached patch creates a C in C for
> the exclusive use of the C ops. herwise. Is that right?
Separating stacks is a good thing, as code paths are simplified.
Q: do we really want or need a return stack per context?
b
Bob Rogers <[EMAIL PROTECTED]> wrote:
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 20:21:32 -0400
Bob Rogers <[EMAIL PROTECTED]> wrote:
> Try the attached patch . . .
That *does* work. I haven't applied it because it's not
necessarily urgent that Tcl w
struct Stack_Chunk *user_stack; /* Base of the scratch stack */
struct Stack_Chunk *control_stack; /* Base of the flow control stack */
+struct Stack_Chunk *return_stack; /* Base of the bsr/jsr/ret stack */
PMC *lex_pad; /* LexPad PMC */
struct Parro
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 20:21:32 -0400
Bob Rogers <[EMAIL PROTECTED]> wrote:
> Try the attached patch . . .
That *does* work. I haven't applied it because it's not
necessarily urgent that Tcl work in trunk. I'm okay with
waiting a
Bob Rogers <[EMAIL PROTECTED]> wrote:
Try the attached patch. If it works, then we have a problem, because
here's the original comment (which I deleted) that went with this line
of code:
/*
* During interpreter creation there is an initial context
* and th
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 17:43:28 -0400
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 16:56:44 -0400
Unfortunately, this patch breaks Tcl. There seems to be some bug with
exceptions.
Here's the Tcl used fo
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 16:56:44 -0400
Unfortunately, this patch breaks Tcl. There seems to be some bug with
exceptions.
Here's the Tcl used for this example:
proc test {} {uplevel #0 {append}}
test
Hmm. I seem to have brok
Bob Rogers <[EMAIL PROTECTED]> wrote:
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 11:53:36 +0200
Am Montag, 18. September 2006 03:56 schrieb Bob Rogers:
>The attached patch consolidates most of the existing stack-unwinding
> code into C
location that threw the exception. That is,
the stack is not unwound until some exception handler chooses to
unwind it by "handling" the exception in question.
So we need the Common Lisp semantics as well.
Larry
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 11:53:36 +0200
Am Montag, 18. September 2006 03:56 schrieb Bob Rogers:
>The attached patch consolidates most of the existing stack-unwinding
> code into Continuation:invoke; previously, RetContinuatio
Am Montag, 18. September 2006 03:56 schrieb Bob Rogers:
>The attached patch consolidates most of the existing stack-unwinding
> code into Continuation:invoke; previously, RetContinuation:invoke and
> find_exception_handler also did stack-unwinding, and none of the three
> did it qu
The attached patch consolidates most of the existing stack-unwinding
code into Continuation:invoke; previously, RetContinuation:invoke and
find_exception_handler also did stack-unwinding, and none of the three
did it quite the same way.
Here are the effects:
1. Improved code sharing, a
eal with it. Is it valid to not use a when/default chain in CATCH
or to change topic, using: $_ = $my_new_topic. ?
An example of that would be helpful.
My second point involves re-throwing errors with useful stack traces.
Here's an example similar to what we do in CGI::App:
try { boom();
On Mon, Jul 17, 2006 at 09:26:12PM -0400, Bob Rogers wrote:
>But what I really meant was: Shouldn't Parrot do a 'setrlimit' on
> itself in order to detect these sorts of bugs sooner, and more usefully?
> Or, maybe 'ulimit -s' would be appropriate before running test cases?
Running the test su
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 17 Jul 2006 11:50:35 +0200
Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers:
> BTW, it doesn't seem right that I can run Parrot for only a second or
> two and get more than 300K stack frames deep. Isn
From: Allison Randal <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2006 00:02:53 -0700
Bob Rogers wrote:
>If, as seems likely, exception bookkeeping is moved to a separate
> stack in the interpreter (with or without dynamic-wind actions), then
> C/C addresses
languages/BASIC has been broken for almost two years, and after multiple
followups, nobody has claimed responsibility for the language
implementation or a fix.
this ticket has been marked 'stalled'.
I believe befunge is the example I was thinking of.
On Mar 4, 2006, at 12:08 PM, Leopold Toetsch wrote:
On Mar 1, 2006, at 14:46, Will Coleda wrote:
We already have at least one language implementation that used to
work just fine using the stack, but has been crippled with various
On Mar 1, 2006, at 14:46, Will Coleda wrote:
We already have at least one language implementation that used to work
just fine using the stack, but has been crippled with various
deprecations over the last few years.
If you are speaking of forth here, then no. That was broken by design.
It
's
> > >use of save/restore opcodes in the code it generates -- indeed,
> > >PGE no longer has any save or restore opcodes and thus doesn't
> > >need the user stack at all.
> >
> > That's indeed an (indirect) answer to the 'do we really n
I don't use the user stack, myself, but one advantage that the
current implementation has over "just using a PMC" is that you don't
have to go out and get the global PMC you're storing things in.
We already have at least one language implementation that used to
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Mon, 27 Feb 2006 09:46:42 -0800
On Fri, Feb 24, 2006 at 12:57:24AM +0100, Leopold Toetsch wrote:
> That's indeed an (indirect) answer to the 'do we really need it' part ;)
Is there any other client of the
,
> >PGE no longer has any save or restore opcodes and thus doesn't
> >need the user stack at all.
>
> That's indeed an (indirect) answer to the 'do we really need it' part ;)
Is there any other client of the user stack that can't be easily replaced by
som
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 08 Jan 2006 17:21:25 +0100
Bob Rogers wrote:
> Actually, I would have assumed that the user stack operated more or less
> independently of the call chain, but I see it is kept in the context
> struct
Bob Rogers wrote:
Actually, I would have assumed that the user stack operated more or less
independently of the call chain, but I see it is kept in the context
structure and not the interpreter. Hmmm . . .
I think so too. It's just in the context as it was there, w/o further
r
Please note again: remove *stack call directives*
* The 4 directives and 'call' are gone. If needed use please:
.param => save
.arg => restore
.return => save
.result => restore
call => bsr
* please note that *parrot calling conventions* still
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37246]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37246 >
* get rid of support for stack calling conventions (.param and friends)
in
On Mon, Sep 19, 2005 at 09:57:24PM -0700, Sean O'Rourke via RT wrote:
> "Joshua Hoblitt via RT" <[EMAIL PROTECTED]> writes:
> > Since the rx_* ops are on the chopping block is there any objection to
> > closing this bug?
>
> No objection from me. Actually, I'm not an active Parrot developer
> now
"Joshua Hoblitt via RT" <[EMAIL PROTECTED]> writes:
> Since the rx_* ops are on the chopping block is there any objection to
> closing this bug?
No objection from me. Actually, I'm not an active Parrot developer
now, and don't see myself becoming one again in the near future, so
you can probably
Cory Spencer <[EMAIL PROTECTED]> wrote:
>> Is there currently any method of determining the depth of the lexical scope
>> pad stack? None of the ops in var.pod seem to be able to provide that
>> information at the moment...
You can query the pad depth like in [1], but ..
Is there currently any method of determining the depth of the lexical scope
pad stack? None of the ops in var.pod seem to be able to provide that
information at the moment...
Actually, I suppose I should clarify what I want to get at here, which is
when lexical pads popped off the stack. Am
Just a quick question:
Is there currently any method of determining the depth of the lexical
scope pad stack? None of the ops in var.pod seem to be able to provide
that information at the moment...
Cory
This doesn't address the deeper problem, but we could also simplify the
whole function by just doing:
static size_t
find_common_mask(size_t val1, size_t val2)
{
size_t mask = ~0;
size_t diff = val1 ^ val2;
while (diff & mask)
mask <<= 1;
return mask;
}
Bit twiddli
This doesn't address the deeper problem, but we could also simplify the
whole function by just doing:
static size_t
find_common_mask(size_t val1, size_t val2)
{
size_t mask = ~0;
size_t diff = val1 ^ val2;
while (diff & mask)
mask <<= 1;
return mask;
}
Bit twiddli
remove that undefined
behaviour and correctly return 0 for that case. This is enough to fix the
DOD problem. I've not changed any of the code further, but I assume that
the problem with small and big chunks is that their pointers differ so much
that prefix will almost always be zero, and many m
remove that undefined
behaviour and correctly return 0 for that case. This is enough to fix the
DOD problem. I've not changed any of the code further, but I assume that
the problem with small and big chunks is that their pointers differ so much
that prefix will almost always be zero, and many m
Nicholas Clark wrote:
> The for loop inside trace_mem_block steps right over it. This if fails:
>
> /* Do a quick approximate range check by bit-masking */
> if ((ptr & mask) == prefix || !prefix) {
Argh, yes. I have pointed out quite a time ago that this mask check
isn't ok. Sm
Nicholas Clark wrote:
The for loop inside trace_mem_block steps right over it. This if fails:
/* Do a quick approximate range check by bit-masking */
if ((ptr & mask) == prefix || !prefix) {
Argh, yes. I have pointed out quite a time ago that this mask check
isn't ok. Small and big
at dod.c:trace_mem_block, which should be called
> by the stack walking code. The variables lo_var_ptr and hi_var_ptr
> should be set and contain the auto variable on stack.
#9 0x08173067 in string_make (interpreter=0x844f388, buffer=0x83a50b0, len=9,
encoding_n
at dod.c:trace_mem_block, which should be called
> by the stack walking code. The variables lo_var_ptr and hi_var_ptr
> should be set and contain the auto variable on stack.
#9 0x08173067 in string_make (interpreter=0x844f388, buffer=0x83a50b0, len=9,
encoding_n
copy of the parrot source code which has had a few debugging printf()s and
> static variables added, but the problem shows up with vanilla parrot source
> code.
Please set a breakpoint at dod.c:trace_mem_block, which should be called
by the stack walking code. The variables lo_var_ptr and hi_v
copy of the parrot source code which has had a few debugging printf()s and
> static variables added, but the problem shows up with vanilla parrot source
> code.
Please set a breakpoint at dod.c:trace_mem_block, which should be called
by the stack walking code. The variables lo_var_ptr and hi_v
quot;iso-8859-1", flags=0) at src/string.c:829
#3 0x08172dfa in string_from_cstring (interpreter=0x844f388,
buffer=0x83a50b0, len=0) at src/string.c:658
#4 0x081b9d97 in Parrot_PMC_typenum (interp=0x844f388,
class=0x83a50b0 "Perl5NULL") at src/extend.c:600
#5 0x080d20dd in S_new_SV
At 5:53 PM -0700 8/17/04, Brent 'Dax' Royal-Gordon wrote:
Michel Pelletier <[EMAIL PROTECTED]> wrote:
if Perl or other languages want an undef returned, it would seem to make
more sense that they assume to cost of catching the exception and
turning it into an undef, than everyone else turning th
Michel Pelletier <[EMAIL PROTECTED]> wrote:
> if Perl or other languages want an undef returned, it would seem to make
> more sense that they assume to cost of catching the exception and
> turning it into an undef, than everyone else turning the undef into an
> exception.
I believe that this is ex
, then
bounds checking code must go through the same overhead to check for the
undef as it would need to initially just check the validity of the
bounds in the first place. Compare:
$I0 = .STACK
if $I0 > 0 goto .$NoError
new $P0, .Exception
$P0["_message"] = "Sta
On Tue, Aug 17, 2004 at 03:15:01AM -0600, Luke Palmer wrote:
: Michel Pelletier writes:
: > > We have to through an IndexError exception for Python. But that's not
: > > done yet.
: >
: > Okay, I'll keep depth checking. I thought about attempting a patch, but
: > Larry says return an undef contai
Michel Pelletier writes:
> > We have to through an IndexError exception for Python. But that's not
> > done yet.
>
> Okay, I'll keep depth checking. I thought about attempting a patch, but
> Larry says return an undef containing an unthrown exception, Dan wonders
> if it should be an empty undef,
On Tue, 17 Aug 2004 08:54:32 +0200
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Michel Pelletier <[EMAIL PROTECTED]> wrote:
>
> > $P0 = new .PerlArray
> > pop $P1, $P0
>
> > kills the process with a 'Array index out of bounds!'. Is there a way
> > to get an exception I can catch out of this?
>
Michel Pelletier <[EMAIL PROTECTED]> wrote:
> $P0 = new .PerlArray
> pop $P1, $P0
> kills the process with a 'Array index out of bounds!'. Is there a way
> to get an exception I can catch out of this?
We have to through an IndexError exception for Python. But that's not
done yet.
> -Michel
le
At 10:51 AM -0700 8/16/04, Larry Wall wrote:
On Mon, Aug 16, 2004 at 05:09:45AM -0700, Michel Pelletier wrote:
:
: $P0 = new .PerlArray
: pop $P1, $P0
:
: kills the process with a 'Array index out of bounds!'. Is there a way
: to get an exception I can catch out of this? Right now I check the
: d
1 - 100 of 315 matches
Mail list logo
