Re: [perl #60044] [BUG?] rethrow just throwing?
-- Will Coke Coleda On Oct 23, 2008, at 23:05, Allison Randal via RT [EMAIL PROTECTED] wrote: Will Coleda (via RT) wrote: I would expect both of these programs to output the same thing, but it looks like rethrow is generating the same output that throw would here. What is the difference supposed to be between these two ops? The two ops are intentionally almost entirely the same. The only difference is that 'throw' creates a new iterator of exception handlers, while 'rethrow' pulls the next exception handler off the iterator. So, 'rethrow' cannot be called on an exception that hasn't been thrown before. And if 'throw' is called on an exception that's already been thrown before, it will return to the first exception handler again, instead of the next exception handler in the chain of handlers. $ cat foo.pir sub foo :main bar() end sub bar baz() end sub baz die eek end $ ../../parrot foo.pir eek current instr.: 'baz' pc 24 (foo.pir:10) called from Sub 'bar' pc 19 (foo.pir:6) called from Sub 'foo' pc 7 (foo.pir:2) $ cat bar.pir sub foo :main push_eh eh bar() pop_eh end eh: .get_results($P0) rethrow $P0 end sub bar baz() end sub baz die eek end $ ../../parrot bar.pir eek current instr.: 'foo' pc 16 (bar.pir:9) I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? Allison Yes.
Re: Parrot on mobile platforms?
On Fri, Oct 24, 2008 at 12:00 AM, Allison Randal [EMAIL PROTECTED] wrote: That being said, I can't imagine Apple would be terribly keen to endorse anything which requires jail breaking the phone. Don't we have contacts in Apple? Getting official approval for trying this out might be a nice thing. In fact, I already know an iPhone developer who would be a great fit for a challenge like this (if he's interested). Yes, but the mobile group is completely separate from the open source group. Still, it's worth asking. Depending on how they interpret the SDK policy: (an application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture…), any VM-based app might be verboten on the iPhone. -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #60044] [BUG?] rethrow just throwing?
On Thu, Oct 23, 2008 at 08:04:41PM -0700, Allison Randal wrote: I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? ...this is what I would expect. If I catch and then rethrow an exception, I'd expect the stack trace to continue to show the location of the original throw, not the location of the rethrow. Pm
Re: [perl #60044] [BUG?] rethrow just throwing?
On Fri, Oct 24, 2008 at 11:21 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 08:04:41PM -0700, Allison Randal wrote: I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? ...this is what I would expect. If I catch and then rethrow an exception, I'd expect the stack trace to continue to show the location of the original throw, not the location of the rethrow. I agree. Otherwise, what's the point of 'rethrow'? -- Mark J. Reed [EMAIL PROTECTED]
Re: Parrot on mobile platforms?
--- On Thu, 23/10/08, Gabor Szabo [EMAIL PROTECTED] wrote: Don't you think it would be important to start working in this direction? What about OpenMoko? Doesn't that run a fairly standard Linux? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
# New Ticket Created by Canol Gökel # Please include the string: [perl #60098] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60098 After doing the Windows installation via setup-parrot-0.8.0.exe I cannot run the perl 6 compiler. When I do for example: perl6 example.pl It gives this error: load_bytecode couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6;Compiler;main' pc -1 ((unknown file):-1) Canol Gokel
Re: [perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
On Fri, Oct 24, 2008 at 8:49 AM, via RT Canol Gökel [EMAIL PROTECTED] wrote: # New Ticket Created by Canol Gökel # Please include the string: [perl #60098] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60098 After doing the Windows installation via setup-parrot-0.8.0.exe I cannot run the perl 6 compiler. When I do for example: perl6 example.pl It gives this error: load_bytecode couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6;Compiler;main' pc -1 ((unknown file):-1) this seems to be a bug, perhaps in the code that generates the perl6 executable. in the meantime, you can remove perl6.exe (in the bin/ dir) and create perl6.cmd (same dir) with the following contents: @echo off rem adjust the path below to suit your environment set PARROT_ROOTDIR=c:\parrot-0.8.0 %PARROT_ROOTDIR%\bin\parrot.exe %PARROT_ROOTDIR%\languages\perl6\perl6.pbc %* ~jerry
Re: [perl #60044] [BUG?] rethrow just throwing?
Will Coleda wrote: Allison Randal wrote: ...you expect 'rethrow' to keep the stack trace of the original 'die'? Yes. The way to do this is to add stack trace information to the Exception's 'stacktrace' attribute when the exception is first thrown, and print that out for an unhandled exception, instead of printing out the literal current path of execution. (This is why I added the 'stacktrace' attribute.) But, the implementation isn't currently using this feature. Largely, we just haven't decided what information to store in 'stacktrace'. I'd say a data structure is more useful than a string, because it can be manipulated by various HLLs to the format of their stacktrace dumps. So, what information do the HLL developers want from the original stack trace? (I suppose technically we should stop calling this a stack trace since it's not a stack. But return continuation chain trace is just too verbose.) Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
On Fri, Oct 24, 2008 at 3:18 PM, Allison Randal [EMAIL PROTECTED] wrote: Will Coleda wrote: Allison Randal wrote: ...you expect 'rethrow' to keep the stack trace of the original 'die'? Yes. The way to do this is to add stack trace information to the Exception's 'stacktrace' attribute when the exception is first thrown, and print that out for an unhandled exception, instead of printing out the literal current path of execution. (This is why I added the 'stacktrace' attribute.) But, the implementation isn't currently using this feature. Largely, we just haven't decided what information to store in 'stacktrace'. I'd say a data structure is more useful than a string, because it can be manipulated by various HLLs to the format of their stacktrace dumps. So, what information do the HLL developers want from the original stack trace? (I suppose technically we should stop calling this a stack trace since it's not a stack. But return continuation chain trace is just too verbose.) Allison I'm not sure tcl has an actual spec on this (since there's just the one implementation), but I need to be able keep track of HLL file/line/proc/ and in some cases raw source. here's a sample I was able to generate with tclsh8.5; eek while executing error eek (procedure foo::bar line 2) invoked from within foo::bar (file baz.tcl line 1) invoked from within source baz.tcl (file bar.tcl line 2) tcl also has some global variables that get dragged into the error handling ($::errorCode, and $::errorInfo); in fact, it's quite possible that I could roll my own mechanism just by using $::errorInfo and ignoring the stacktrace entirely. I'm still interested in the parrot stacktrace for when a -parrot- error occurs, though; debugging things when the original parrot trace is clobbered is quite difficult, especially since -t doesn't always work. (by which I mean fail in the same way as not using it.) -- Will Coke Coleda
