Oh, great! I was running the latest version I saw
listed in 'rakudobrew list-available' which is 2018.10:
~ $ perl6 -v
This is Rakudo version 2018.10 built on MoarVM version 2018.10
implementing Perl 6.c.
thanks!
Brian
On Saturday, November 10, Elizabeth Mattijsen wrote:
> In v6.d
In v6.d this throws the exception:
$ 6 'start die("bye"); sleep 1'
Unhandled exception in code scheduled on thread 4
bye
in code at -e line 1
whereas the exception is silently ignored in 6.c:
$ 6 'use v6.c; start die("bye"); sleep 1'
Not sure if this answers your question, as it is unclear
On Thu, 26 Feb 2009, Daniel Ruoso wrote:
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown excep
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
> for @! {}
> might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every on
Em Qui, 2009-02-26 às 22:26 +1100, Timothy S. Nelson escreveu:
> given(any(@!)) {
> }
using junctions on exception handling doesn't seem like a good idea to
me, because it is too much of a basic feature... but...
for @! {
}
might provide the needed semantics...
OTOH, I think it would be sane t
On Thu, 26 Feb 2009, Timothy S. Nelson wrote:
My suggested solution would be to change $! to an exception container
object. But then we have to use it in the implicit given in the CATCH block.
If we used an any() Junction, would that do what we want?
Ok, Moritz told me on IRC that this won
On Wed, 25 Feb 2009, Larry Wall wrote:
On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote:
Does this mean that $! is a container of some sort?
It's an object, which (in the abstract) can contain anything it jolly
well pleases. The main question beyond that is how it re
On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote:
> Does this mean that $! is a container of some sort?
It's an object, which (in the abstract) can contain anything it jolly
well pleases. The main question beyond that is how it responds if
used like one of the standard cont
Allison Randal wrote:
Presumably the handled opcode will remove the exception Task from the
scheduler and resume execution at the appropriate point. Presumably
also the declining to handle an exception (the replacement for
rethrow) will cause the scheduler to move to the next exception
hand
chromatic wrote:
From the wiki at
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks :
* Deprecate "rethrow".
The replacement seems to be that an exception handler declines to handle an
exception. This is the default behavior; an exception handler explicitly
notifies the sched
Yes please!
On Oct 6, 2006, at 4:27 PM, chromatic wrote:
A thread on p5p recently brought up the idea of multi-language
exceptions.
That is, instead of throwing exceptions with English C-strings
embedded in
the source code, use a localization system.
If there'll soon be a push to clean up
On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
: > @bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progress? e.g. what
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there were s
On Sat, Jun 24, 2006 at 11:18:41PM -0400, Bob Rogers wrote:
>From: Chip Salzenberg <[EMAIL PROTECTED]>
>Date: Tue, 20 Jun 2006 20:59:45 -0700
>
>WRT exception handling, I think the lisp condition/handler model is a good
>starting point. It's simple enough to explain and use, and s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> pushmark 12
> popmark 12
> pushaction Psub
I've now implemented these bits. I hope it's correct, specifically, if a
return continuation in only captured, the action handler is not run.
See t/pmc/exceptions.t
Still missing is the throw opco
At 10:28 AM +0100 11/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Its in and named C since yesterday "return with current
continuation".
Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
>>Its in and named C since yesterday "return with current
>>continuation".
> Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago the first time.
I've asked for names of the o
I switched to local exception handler blocks, and am still getting the same
failure mode.
Of course, it works fine in a simple, single file example.
I've checked everything back in so you can take a look. Once you build tcl,
from the top level directory, try:
oolong:~/research/parrot_8075 coke$ c
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The 'invoke the current return continuation' op apparently got lost
in the blowup. That needs to go in.
Its in and named C since yesterday "return with current
continuation".
Hrm. The name's not right, since
William Coleda <[EMAIL PROTECTED]> wrote:
> I just noticed some test failures in the tcl suite.
exception syntax will change slightly.
> set P4, P5["_invoke_cc"]
especially these constructs (resumable handling).
Please use currently a local handler:
newsub ignore, .Exception_Handler, catc
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
leo
Dan Sugalski wrote:
Hmm, the first thing to take into the account is that return
continuations can be promoted to the fully blown continuations. This
should affect the handlers in the same way - so exception handlers
could have become arbitrary invokable objects at the point when the
exception
At 10:58 PM + 11/18/04, Tim Bunce wrote:
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current
> system is almost OK. What I'd like it to change to is:
>
>
At 10:03 AM +0100 11/19/04, Miroslav Silovic wrote:
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to tak
Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> Hmm, the first thing to take into the account is that return
> continuations can be promoted to the fully blown continuations.
Yes. But an exception handler is not a RetContinuation object. It's an
Exception_Handler object (also derived from Continuat
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to take into the account is that return
continuations can
Tim Bunce <[EMAIL PROTECTED]> wrote:
> I guess the HLL compiler needs to ensure that for every push the
> control flow will always pass through a matching pop.
Not necessarily. The handler is pushed onto the control stack. During a
context change (e.g. from a subroutine return), the previous cont
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The 'invoke the current return continuation' op apparently got lost
> in the blowup. That needs to go in.
Its in and named C since yesterday "return with current
continuation".
> I'd like pushing exception handlers to remain simple -- the current
> syste
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
> On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
>
> > I'd like pushing exception handlers to remain simple -- the current
> > system is almost OK. What I'd like it to change to is:
> >
> > push_eh label
> >
> > with poppin
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current
> system is almost OK. What I'd like it to change to is:
>
> push_eh label
>
> with popping the top exception handler being:
>
> pop_eh
>
> I'm up for better
Will Coleda <[EMAIL PROTECTED]> wrote:
> I'm trying to add exception handling support back in to tcl so I can
> trap references to non-existant variables. This is using a recent, but
> not just-now, cvs checkout.
> I am currently getting a segfault if I enable the exception handler.
> Running the
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Should the "raise" opcode produce resumable exceptions?
There is no problem with resuming after an opcode. E.g. when C
is:
invokecc Px # call exception handler
and the handler returns by C i.e. via the return
continuation, execution just resumes
At 11:53 AM -0400 6/30/03, Benjamin Goldberg wrote:
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 exception
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Exception handlers really strike me as anonymous lexically scoped
>> subroutines that get called with just one parameter--the exception
>> object. As far as the engine should be concerned, when an exception
>>
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, except
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
Luke Palmer wrote:
So, maybe what's needed is a C catcher (C... eew),
where C would throw an exception object with an attached
continuation. And of course, if a warning reached the top of the
stack without being caught, it would print itself and invoke its
continuation.
I thought I'd try and see
Gordon Henriksen wrote:
The most fundamental feature throwing an exception is that it transfers
program execution from the call site. Allowing the caller to resume
execution at that site is a very dangerous form of action at a distance.
I think you'd be better off a giving the caller an explicit wa
Luke Palmer <[EMAIL PROTECTED]> writes:
> This is more of a language thang, so I've redirected your message
> there [here].
>
>> The most fundamental feature throwing an exception is that it transfers
>> program execution from the call site. Allowing the caller to resume
>> execution at that site
This is more of a language thang, so I've redirected your message
there [here].
> The most fundamental feature throwing an exception is that it transfers
> program execution from the call site. Allowing the caller to resume
> execution at that site is a very dangerous form of action at a distance.
MAIL PROTECTED]
> Subject: Re: Exceptions
>
>
> Dan Sugalski wrote:
> > Piers Cawley wrote:
> >> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >>
> >>> Okay, now that we're well on our way to getting
> >>> sub/method/whateve
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, exceptions thrown in C code are difficul
Dan Sugalski wrote:
> Piers Cawley wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> Okay, now that we're well on our way to getting
>>> sub/method/whatever calling down and working, I want to point us
>>> towards what I'm thinking of for exceptions.
>>>
>>> Exception handlers really strike
> > I'm not yet sure whether it's worth having engine support for
> > specific exception type checking
>
> I think we would have:
> - Exception handler = Continuation
> - Exception object = a new class of some type[2]. When the system throughs
> an exception, it would attach 2 properties to the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get called with just one parameter--the exception
> object. As far as the engine should be concerned, when an exception
> is taken we just take a continuation with the addr
At 8:53 AM -0400 6/23/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
Okay, now that we're well on our way to getting sub/method/whatever
calling down and working, I want to point us towards what I'm thinking
of for exceptions.
Exception handlers really strike me as anonymous
Piers Cawley:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get called with just one parameter--the exception
> object.
So, we grab another register for 'current exception continuation'?
Then when code throws an exce
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Okay, now that we're well on our way to getting sub/method/whatever
> calling down and working, I want to point us towards what I'm thinking
> of for exceptions.
>
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get
At 10:56 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >> Perhaps, throw can carry a return value?
> >>
> >> throw {"return value"} $exception;
> >> If there is an active try/catch context the
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> Perhaps, throw can carry a return value?
>>
>> throw {"return value"} $exception;
>> If there is an active try/catch context then the $exception would
>> be propogated, otherwise $@ would
At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
>Perhaps, throw can carry a return value?
>
> throw {"return value"} $exception;
>If there is an active try/catch context then the $exception would
>be propogated, otherwise $@ would get loaded with $exception and
>the return value would be t
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be
At 03:40 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Well, those of you writing "exception" RFCs be sure and include this
>example in there somewhere (if it's relevant to your RFC of course).
Done.
>I'm done thinking about exceptions now.
Some of us are hoping to do the same RSN :-)
--
Peter
On Wed, Aug 16, 2000 at 12:52:07PM -0700, Peter Scott wrote:
> At 09:29 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
> >Let me draw another picture (with "try" and "catch" this time):
> >
> > try {
> > # code that may cause exceptions
> > } catch {
On Wed, Aug 16, 2000 at 12:42:24PM -0700, Peter Scott wrote:
> At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
> >One issue that haven't seen addressed, is how to _not_ have exceptions.
> >
> >I want to use a core module (non-core can do anything they want) but
> >I'd like to write it in procedura
At 09:29 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Let me draw another picture (with "try" and "catch" this time):
>
> try {
> # code that may cause exceptions
> } catch { # catches ALL exceptions
> switch ($@->^_) {
>
At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
>One issue that haven't seen addressed, is how to _not_ have exceptions.
>
>I want to use a core module (non-core can do anything they want) but
>I'd like to write it in procedural mode.
>
> try {
> $obj->method...
> }
On Tue, Aug 15, 2000 at 11:59:40PM -0600, Tony Olekshy wrote:
> Problem 1:
>
> In a large lexical scope, you have no preindication that intended
> non-local flow control is in effect until you read all the way to
> the end of the scope. The equivalent of your example in more human-
> friendly te
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Using exceptions for failure signalling is a more robust software
TO> engineering technique, but only if your exception handling mechanism
TO> doesn't "encourage" you to drop exceptions of the floor.
Is this proven or just an assertion o
Graham Barr <[EMAIL PROTECTED]> writes:
> Also, I have come to dislike the name `exception', its too long for me :)
> and who says we have to copy everyone else.
>
> Lookin in the thesaurus we get
>
> [Nouns] nonconformity [more]; unconformity, disconformity;
> unconventionality, informality, ab
I have moved this to [EMAIL PROTECTED]
Jonathan Scott Duff wrote:
>
> Okay, imagine something for me:
>
> # some code here that may cause an exception
> exceptions {# when thrown, we end up here
> switch ($@->^_) {
> case canFoo { ... }
On Tue, Aug 15, 2000 at 06:23:57PM -0600, Tony Olekshy wrote:
> Jonathan Scott Duff wrote:
> >
> > What's wrong with just using the switch statement? It seems
> > like except and catch are becoming special-purpose switches
> > to me. Is it really necessary?
>
> It's not necessary, but it is th
On Tue, Aug 15, 2000 at 11:47:03AM -0500, Jonathan Scott Duff wrote:
> On Tue, Aug 15, 2000 at 11:47:32AM +0100, Graham Barr wrote:
> > On Mon, Aug 14, 2000 at 10:56:36AM -0500, Jonathan Scott Duff wrote:
> > > try { }
> > > catch SomeException { }
> > > catch SomeOtherException { }
> > >
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Sun, Aug 13, 2000 at 10:51:24PM -0700, Peter Scott wrote:
> > Could be. I'd be interested in seeing non-OOP proposals that do what I
> > want exceptions to do, I have a hard time imagining one.
>
> Well, what is it that you want exceptions t
64 matches
Mail list logo
