[ReviewRequest] Error-handling and use of `future`

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[ReviewRequest] Error-handling and use of `future`

Tony Garnock-Jones-5
Hi all,

At the moment, if I printIt

        (1 future / 0)

this results in a Promise, as expected.

Separately, when the UI process next runs (almost immediately), it ends
up signalling ZeroDivide, causing a debugger to open.

It does not either resolve or reject the promise.

The promise remains pending forever, when it should be rejected.

The attached changeset is small and simple, and fixes this problem. It
spans several packages - Morphic, System, Kernel and KernelTest - which
is why it's a changeset and not a bunch of submissions to the inbox.

If people could take a look over it, that'd be great! If the consensus
is that the change is an improvement, I'll commit to MC and update trunk.

I have specific questions:

1. How should unhandled errors by `future` sends be treated? The current
code, and the code after the attached changeset, always opens a
debugger. Would it be better to *not* open a debugger, instead relying
on the user of the Promise to care about #whenRejected:? I cautiously
suggest this might be the case. (Concretely, in the language of the
changeset, all that would change is that `true` in Promise>>fulfillWith:
would become `false`.)

2. What code is using `future`? Where can I find some examples of code
that (isn't already broken and that) might break if I change the way
`future` works? It seems like `future` is not widely used at all. If
this is the case, perhaps we might be free to improve it.

3. How can we properly test errors signalled by a future send, if it
pops up a debugger that we can't suppress? See the changeset's
PromiseTest>>testFutureRejection, which currently has to be an
expectedFailure for this reason.

Tony



FuturePromiseErrorHandling.1.cs (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ReviewRequest] Error-handling and use of `future`

marcel.taeumel
I would prefer to see the debugger in such a case, unless the user makes use of #whenRejected: explicitely.

I use future sends to perform frequent checks/tasks in the UI process. On each check, I decide whether to continue polling or not. I do not want to use Morphic alarms directly for such a case.

You can avoid the debugger in the case of MorphicProjects like this:

[
1 future / 0.
"If needed, wait with a delay here."
Project current world doOneCycle.
]
on: ZeroDivide
do: [:err | ]


Best,
Marcel

Am 13.02.2018 13:59:11 schrieb Tony Garnock-Jones <[hidden email]>:

Hi all,

At the moment, if I printIt

(1 future / 0)

this results in a Promise, as expected.

Separately, when the UI process next runs (almost immediately), it ends
up signalling ZeroDivide, causing a debugger to open.

It does not either resolve or reject the promise.

The promise remains pending forever, when it should be rejected.

The attached changeset is small and simple, and fixes this problem. It
spans several packages - Morphic, System, Kernel and KernelTest - which
is why it's a changeset and not a bunch of submissions to the inbox.

If people could take a look over it, that'd be great! If the consensus
is that the change is an improvement, I'll commit to MC and update trunk.

I have specific questions:

1. How should unhandled errors by `future` sends be treated? The current
code, and the code after the attached changeset, always opens a
debugger. Would it be better to *not* open a debugger, instead relying
on the user of the Promise to care about #whenRejected:? I cautiously
suggest this might be the case. (Concretely, in the language of the
changeset, all that would change is that `true` in Promise>>fulfillWith:
would become `false`.)

2. What code is using `future`? Where can I find some examples of code
that (isn't already broken and that) might break if I change the way
`future` works? It seems like `future` is not widely used at all. If
this is the case, perhaps we might be free to improve it.

3. How can we properly test errors signalled by a future send, if it
pops up a debugger that we can't suppress? See the changeset's
PromiseTest>>testFutureRejection, which currently has to be an
expectedFailure for this reason.

Tony



Reply | Threaded
Open this post in threaded view
|

Re: [ReviewRequest] Error-handling and use of `future`

marcel.taeumel
... for me, I do not see or use the promise object. It is just a regular (even if deferred) message send. Thus, the debugger should appear as usual for other message sends.

Best,
Marcel

Am 13.02.2018 15:00:04 schrieb Marcel Taeumel <[hidden email]>:

I would prefer to see the debugger in such a case, unless the user makes use of #whenRejected: explicitely.

I use future sends to perform frequent checks/tasks in the UI process. On each check, I decide whether to continue polling or not. I do not want to use Morphic alarms directly for such a case.

You can avoid the debugger in the case of MorphicProjects like this:

[
1 future / 0.
"If needed, wait with a delay here."
Project current world doOneCycle.
]
on: ZeroDivide
do: [:err | ]


Best,
Marcel

Am 13.02.2018 13:59:11 schrieb Tony Garnock-Jones <[hidden email]>:

Hi all,

At the moment, if I printIt

(1 future / 0)

this results in a Promise, as expected.

Separately, when the UI process next runs (almost immediately), it ends
up signalling ZeroDivide, causing a debugger to open.

It does not either resolve or reject the promise.

The promise remains pending forever, when it should be rejected.

The attached changeset is small and simple, and fixes this problem. It
spans several packages - Morphic, System, Kernel and KernelTest - which
is why it's a changeset and not a bunch of submissions to the inbox.

If people could take a look over it, that'd be great! If the consensus
is that the change is an improvement, I'll commit to MC and update trunk.

I have specific questions:

1. How should unhandled errors by `future` sends be treated? The current
code, and the code after the attached changeset, always opens a
debugger. Would it be better to *not* open a debugger, instead relying
on the user of the Promise to care about #whenRejected:? I cautiously
suggest this might be the case. (Concretely, in the language of the
changeset, all that would change is that `true` in Promise>>fulfillWith:
would become `false`.)

2. What code is using `future`? Where can I find some examples of code
that (isn't already broken and that) might break if I change the way
`future` works? It seems like `future` is not widely used at all. If
this is the case, perhaps we might be free to improve it.

3. How can we properly test errors signalled by a future send, if it
pops up a debugger that we can't suppress? See the changeset's
PromiseTest>>testFutureRejection, which currently has to be an
expectedFailure for this reason.

Tony



Reply | Threaded
Open this post in threaded view
|

[ReviewRequest 2] Error-handling and use of `future`

Tony Garnock-Jones-5
In reply to this post by marcel.taeumel
Hi Marcel,

Thank you for the feedback! It has been helpful. I have a revised
proposal (see below) and updated changeset (attached). If the updated
proposal doesn't strike anyone as problematic, I'll go ahead and commit it.

On 02/13/2018 02:00 PM, Marcel Taeumel wrote:
> I would prefer to see the debugger in such a case, unless the user makes
> use of #whenRejected: explicitely.

This is a good idea. How about the following:

Promise >> fulfillWith: aBlock
        self fulfillWith: aBlock passErrors: rejecters isEmpty

... and usage of `fulfillWith:` in the future-handling code as
previously proposed, meaning that the debugger will be seen exactly when
no `whenRejected:` has been sent to the Promise?

That is,

    (1 future / 0)

will make the debugger show up, but

    (1 future / 0) whenRejected: []

will not.

In both cases, the Promise will be rejected with a ZeroDivide.

> You can avoid the debugger in the case of MorphicProjects like this: [...]

Ah, excellent, thank you, that works well. Now there are no failing
tests and no expected failures in the tests in the changeset.

Tony



FuturePromiseErrorHandling.2.cs (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Fw: Re: [ReviewRequest 2] Error-handling and use of `future`

marcel.taeumel
I forgot the list ... 

------ Weitergeleitete Nachricht --------
Von: Marcel Taeumel <[hidden email]>
Datum: 14.02.2018 11:35:39
Betreff: Re: [ReviewRequest 2] Error-handling and use of `future`
An: Tony Garnock-Jones <[hidden email]>

Hi Toni,

if it is a "promise", why aren't the states "kept" and "broken"? Or "delivered" and "broken"? Well, "resolve" sounds more like message lookup/sending, yet promises do actually make use of that mechanism here.

... #onDelivery: ... #onBreak: ...

:-)

Best,
Marcel

Am 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <[hidden email]>:

Hi Marcel,

On 02/14/2018 06:58 AM, Marcel Taeumel wrote:
> could elaborate on what it means, in general, to "reject a promise"?
> Does rejection directly map to the exception mechanism? Or are there
> other cases?

It's terminology lifted from https://promisesaplus.com/, and it is more
general than the exception mechanism. One advantage of this generality
is that it is able to usefully propagate failures in a concurrent system
in a way that the stack-oriented nature of exception propagation cannot.

Briefly: a promise is a calculation that may yield either a result or a
failure, each with an associated value. A failure value may be any
value, Exception, nil, String, or otherwise. In Squeak, the "resolved"
handlers are notified if the promise yields a result, and the "rejected"
handlers are notified if the promise yields a failure.

The connection to exceptions is that in most cases a signaled exception
should cause a promise to yield a failure.

There's a connection in the reverse direction, too: Promise>>#wait will
signal BrokenPromise if a promise yields a failure.

Rejection is a new-ish (2013?) feature of Squeak promises that doesn't
seem to have been properly integrated; the changes I've been making
recently feel to me like more fully fleshing out the idea. One nice
side-effect of the partiality of the integration of rejection is that
no-one can possibly have been using it :-) leaving us free to assign
sensible semantics to it without fear of backwards-compatibility problems.

Tony


Reply | Threaded
Open this post in threaded view
|

Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`

Bert Freudenberg
The term "rejection" is commonly used in other languages, so I'd rather not invent a new term unless we have a good reason.

- Bert -

On 14 February 2018 at 11:36, Marcel Taeumel <[hidden email]> wrote:
I forgot the list ... 

------ Weitergeleitete Nachricht --------
Von: Marcel Taeumel <[hidden email]>
Datum: 14.02.2018 11:35:39
Betreff: Re: [ReviewRequest 2] Error-handling and use of `future`
An: Tony Garnock-Jones <[hidden email]>

Hi Toni,

if it is a "promise", why aren't the states "kept" and "broken"? Or "delivered" and "broken"? Well, "resolve" sounds more like message lookup/sending, yet promises do actually make use of that mechanism here.

... #onDelivery: ... #onBreak: ...

:-)

Best,
Marcel

Am 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <[hidden email]>:

Hi Marcel,

On 02/14/2018 06:58 AM, Marcel Taeumel wrote:
> could elaborate on what it means, in general, to "reject a promise"?
> Does rejection directly map to the exception mechanism? Or are there
> other cases?

It's terminology lifted from https://promisesaplus.com/, and it is more
general than the exception mechanism. One advantage of this generality
is that it is able to usefully propagate failures in a concurrent system
in a way that the stack-oriented nature of exception propagation cannot.

Briefly: a promise is a calculation that may yield either a result or a
failure, each with an associated value. A failure value may be any
value, Exception, nil, String, or otherwise. In Squeak, the "resolved"
handlers are notified if the promise yields a result, and the "rejected"
handlers are notified if the promise yields a failure.

The connection to exceptions is that in most cases a signaled exception
should cause a promise to yield a failure.

There's a connection in the reverse direction, too: Promise>>#wait will
signal BrokenPromise if a promise yields a failure.

Rejection is a new-ish (2013?) feature of Squeak promises that doesn't
seem to have been properly integrated; the changes I've been making
recently feel to me like more fully fleshing out the idea. One nice
side-effect of the partiality of the integration of rejection is that
no-one can possibly have been using it :-) leaving us free to assign
sensible semantics to it without fear of backwards-compatibility problems.

Tony






Reply | Threaded
Open this post in threaded view
|

Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`

Eliot Miranda-2
In reply to this post by marcel.taeumel
Hi Tony,

On Wed, Feb 14, 2018 at 2:36 AM, Marcel Taeumel <[hidden email]> wrote:
I forgot the list ... 

------ Weitergeleitete Nachricht --------
Von: Marcel Taeumel <[hidden email]>
Datum: 14.02.2018 11:35:39
Betreff: Re: [ReviewRequest 2] Error-handling and use of `future`
An: Tony Garnock-Jones <[hidden email]>

Hi Toni,

if it is a "promise", why aren't the states "kept" and "broken"? Or "delivered" and "broken"? Well, "resolve" sounds more like message lookup/sending, yet promises do actually make use of that mechanism here.

... #onDelivery: ... #onBreak: ...

:-)

Best,
Marcel

Am 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <[hidden email]>:

Hi Marcel,

On 02/14/2018 06:58 AM, Marcel Taeumel wrote:
> could elaborate on what it means, in general, to "reject a promise"?
> Does rejection directly map to the exception mechanism? Or are there
> other cases?

It's terminology lifted from https://promisesaplus.com/, and it is more
general than the exception mechanism. One advantage of this generality
is that it is able to usefully propagate failures in a concurrent system
in a way that the stack-oriented nature of exception propagation cannot.

One thing to think about is that, because exception handling in Smalltalk is above the VM, exception handling does not have to be limited to a stack-oriented propagation.  There is no reason why promises could not keep track of their creating environments and that exception propagation could be modified to cross promise boundaries, searching for handlers within their originating contexts.

Perhaps this is what the onRejected: mechanism does.  But I've wondered for a few years (without playing, and so my thoughts are vapor and probably quite ill-formed) that such a system could be more convenient.

This line of thought originated in Croquet, which is heavily promise based.  One of the problems in a promise based system is debugging; promises are not easy to relate back to their origin.  With suitable support form the Vm for garbage collection promises appropriately it might be possible to have promises hold onto their originating environments so that when an uncaught exception does occur in a promise one can make sense of its history.  The support needed would include the kind of stack splitting/cloning one sees in Scheme with call/cc where, when a continuation is created the stack is lazily split as either the parent or child continuation returns, frame by frame, leaving the other continuation with a fully formed stack that can be used to understand the computational history.

Briefly: a promise is a calculation that may yield either a result or a
failure, each with an associated value. A failure value may be any
value, Exception, nil, String, or otherwise. In Squeak, the "resolved"
handlers are notified if the promise yields a result, and the "rejected"
handlers are notified if the promise yields a failure.

The connection to exceptions is that in most cases a signaled exception
should cause a promise to yield a failure.

There's a connection in the reverse direction, too: Promise>>#wait will
signal BrokenPromise if a promise yields a failure.

Rejection is a new-ish (2013?) feature of Squeak promises that doesn't
seem to have been properly integrated; the changes I've been making
recently feel to me like more fully fleshing out the idea. One nice
side-effect of the partiality of the integration of rejection is that
no-one can possibly have been using it :-) leaving us free to assign
sensible semantics to it without fear of backwards-compatibility problems.

Tony






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`

henry
I have been working on my code for awhile now, years. My Raven code also provides Promise execution, though the promise returned from an eventual {future} send is also eventual to the resolution, meaning you can also eventually send to the promise of future resolution.

 Raven is distributed so a small actors model is provided: See RemoteHandler. After publishing an object, in one vat-machine, a different vat-machine can obtain a remote promise which eventually resolves to a far reference (see NewFarERef)..


See PromiseERef. And tests, please.

This allows promise chaining: (42 eventual * 10) hash asString length

I am confused how my code may propagate exceptions thrown when eventually computing. Supposed to Break with BrokenERef and propionate eventually through whenBroken:. Maybe have a default breakReactor for opening the debugger that gets overridden.

How did you implement promise exceptions within the extant promises? Is there any thoughts on integrating this implementation? It derives from http://Erights.org ELib, best as I knew how.

Sent from ProtonMail Mobile


On Thu, Feb 15, 2018 at 14:34, Eliot Miranda <[hidden email]> wrote:
Hi Tony,

On Wed, Feb 14, 2018 at 2:36 AM, Marcel Taeumel <[hidden email]> wrote:
I forgot the list ... 

------ Weitergeleitete Nachricht --------
Von: Marcel Taeumel <[hidden email]>
Datum: 14.02.2018 11:35:39
Betreff: Re: [ReviewRequest 2] Error-handling and use of `future`
An: Tony Garnock-Jones <[hidden email]>

Hi Toni,

if it is a "promise", why aren't the states "kept" and "broken"? Or "delivered" and "broken"? Well, "resolve" sounds more like message lookup/sending, yet promises do actually make use of that mechanism here.

... #onDelivery: ... #onBreak: ...

:-)

Best,
Marcel

Am 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <[hidden email]>:

Hi Marcel,

On 02/14/2018 06:58 AM, Marcel Taeumel wrote:
> could elaborate on what it means, in general, to "reject a promise"?
> Does rejection directly map to the exception mechanism? Or are there
> other cases?

It's terminology lifted from https://promisesaplus.com/, and it is more
general than the exception mechanism. One advantage of this generality
is that it is able to usefully propagate failures in a concurrent system
in a way that the stack-oriented nature of exception propagation cannot.

One thing to think about is that, because exception handling in Smalltalk is above the VM, exception handling does not have to be limited to a stack-oriented propagation.  There is no reason why promises could not keep track of their creating environments and that exception propagation could be modified to cross promise boundaries, searching for handlers within their originating contexts.

Perhaps this is what the onRejected: mechanism does.  But I've wondered for a few years (without playing, and so my thoughts are vapor and probably quite ill-formed) that such a system could be more convenient.

This line of thought originated in Croquet, which is heavily promise based.  One of the problems in a promise based system is debugging; promises are not easy to relate back to their origin.  With suitable support form the Vm for garbage collection promises appropriately it might be possible to have promises hold onto their originating environments so that when an uncaught exception does occur in a promise one can make sense of its history.  The support needed would include the kind of stack splitting/cloning one sees in Scheme with call/cc where, when a continuation is created the stack is lazily split as either the parent or child continuation returns, frame by frame, leaving the other continuation with a fully formed stack that can be used to understand the computational history.

Briefly: a promise is a calculation that may yield either a result or a
failure, each with an associated value. A failure value may be any
value, Exception, nil, String, or otherwise. In Squeak, the "resolved"
handlers are notified if the promise yields a result, and the "rejected"
handlers are notified if the promise yields a failure.

The connection to exceptions is that in most cases a signaled exception
should cause a promise to yield a failure.

There's a connection in the reverse direction, too: Promise>>#wait will
signal BrokenPromise if a promise yields a failure.

Rejection is a new-ish (2013?) feature of Squeak promises that doesn't
seem to have been properly integrated; the changes I've been making
recently feel to me like more fully fleshing out the idea. One nice
side-effect of the partiality of the integration of rejection is that
no-one can possibly have been using it :-) leaving us free to assign
sensible semantics to it without fear of backwards-compatibility problems.

Tony






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Raven and Squeak-E (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

Tony Garnock-Jones-5
Hi Henry,

On 02/16/2018 04:30 PM, henry wrote:
> http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz

This looks fascinating! I'd love to play with it, but I am having
trouble loading it into an image.

It seems to depend on at least:

 - STON
 - Cryptography

The STON dependency, if ignored, at least lets the Raven mcz load, but
during class initialization there are problems with ASN.1 and a missing
class called "PhaseHeader".

Do you have a series of steps that would let Raven load cleanly into a
fresh Trunk image?

> How did you implement promise exceptions within the extant promises? Is
> there any thoughts on integrating this implementation? It derives from
> http://Erights.org ELib, best as I knew how.

At present, Promise signals BrokenPromise when a client synchronously
waits on the result. That's the only real support there is, aside from
the recently-proposed changes to the `future` mechanism to catch
exceptions from `future` message-sends and turn them into rejected promises.

It'd be neat to harvest some of the great work that went into Squeak-E
for mainline Squeak. If not the code, than at least some of the designs.

Tony

Reply | Threaded
Open this post in threaded view
|

Re: Raven and Squeak-E (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

henry
Apologies for not mentioning the dependencies. Please load Cryptography, ParrotTalk, STON suitable for Squeak, then load Raven (which was SqueakE).

Sent from ProtonMail Mobile


On Sun, Feb 18, 2018 at 09:57, Tony Garnock-Jones <[hidden email]> wrote:
Hi Henry, On 02/16/2018 04:30 PM, henry wrote: > http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz This looks fascinating! I'd love to play with it, but I am having trouble loading it into an image. It seems to depend on at least: - STON - Cryptography The STON dependency, if ignored, at least lets the Raven mcz load, but during class initialization there are problems with ASN.1 and a missing class called "PhaseHeader". Do you have a series of steps that would let Raven load cleanly into a fresh Trunk image? > How did you implement promise exceptions within the extant promises? Is > there any thoughts on integrating this implementation? It derives from > http://Erights.org ELib, best as I knew how. At present, Promise signals BrokenPromise when a client synchronously waits on the result. That's the only real support there is, aside from the recently-proposed changes to the `future` mechanism to catch exceptions from `future` message-sends and turn them into rejected promises. It'd be neat to harvest some of the great work that went into Squeak-E for mainline Squeak. If not the code, than at least some of the designs. Tony


Reply | Threaded
Open this post in threaded view
|

Exception handling and concurrency (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

Tony Garnock-Jones-5
In reply to this post by Eliot Miranda-2
Hi Eliot,

On 02/15/2018 07:34 PM, Eliot Miranda wrote:
> One thing to think about is that, because exception handling in
> Smalltalk is above the VM, exception handling does not have to be
> limited to a stack-oriented propagation.  There is no reason why
> promises could not keep track of their creating environments and that
> exception propagation could be modified to cross promise boundaries,
> searching for handlers within their originating contexts.

Yes, that's a neat idea. I've been mulling over something similar,
regarding callbacks attached to Promises. Sometimes it's OK to run them
in the context of the UI process, but other times they really want to be
run in the context of the process that was running at the time they were
attached to the Promise. I'm still thinking about what the smallest
change I can get away with might be.

In general, exceptions per se - or rather, stack-based exception
*handler* mechanisms - don't adapt well to a concurrent setting. Miller,
Tribble and Shapiro's "Concurrency Among Strangers" (2005) [1] is great
on this topic. Their idea of "plan interference" really captures the
problem well.

  [1] http://www.erights.org/talks/promises/paper/tgc05.pdf

However, aside from the E-style techniques, an Erlang style design works
quite well. There, stack-oriented exceptions and exception handlers cope
with error signalling and recovery within a process, and Erlang's "link"
mechanism propagates entire actor failures among processes. (In some
ways this is reminiscent of E's two-layered design, with vats containing
objects.)

> Perhaps this is what the onRejected: mechanism does.  But I've wondered
> for a few years (without playing, and so my thoughts are vapor and
> probably quite ill-formed) that such a system could be more convenient.

Yep. My recently-completed doctoral work was on a new actor/tuplespace
inspired hybrid model of concurrency that in some ways makes things like
error signalling and recovery less terrible. (See
http://syndicate-lang.org/tonyg-dissertation/ if you're interested.)

> might be possible to have promises hold onto their originating
> environments so that when an uncaught exception does occur in a promise
> one can make sense of its history.

Recording this kind of causal information is hard, but could be
worthwhile. I don't yet have enough experience with Promises to be able
to do the design work. I wonder if there's an overlap with "E-order".
I've always had trouble digging through erights.org enough to get a
clear picture on exactly what E-order entails.

Cheers,
  Tony

Reply | Threaded
Open this post in threaded view
|

Re: Raven and Squeak-E (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

Tony Garnock-Jones-5
In reply to this post by henry
Hi Henry,

On 02/18/2018 03:02 PM, henry wrote:
> Cryptography,

I loaded Cryptography-rww.115.mcz from Squeaksource.


> ParrotTalk,

ParrotTalk-rww.19.mcz, also from the Squeaksource Cryptography project.

I think this is the piece I was missing before.


> STON suitable for Squeak,

I installed ConfigurationOfSton from
http://ss3.gemtalksystems.com/ss/STON, and executed

  ConfigurationOfSton load.

This gets stuck trying to retrieve Metacello (!) from seaside.gemstone.com.

I abandoned loading STON for now.


> then load Raven (which was SqueakE).

I loaded Raven-HenryHouse.21.mcz, also from the Squeaksource
Cryptography project, and it seemed to load OK (barring the missing STON
classes!). Hooray!


Thank you. I'll explore a little.

Tony

Reply | Threaded
Open this post in threaded view
|

Re: Raven and Squeak-E (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

henry
I was confused which STON to read into Squeak so I experimented and came up with these three packages:

http://www.squeaksource.com/Oceanside/Ston-Core-SvenVanCaekenberghe.36.mcz

http://www.squeaksource.com/Oceanside/STON-Text%20support-TheIntegrator.2.mcz

http://www.squeaksource.com/Oceanside/Ston-Tests-SvenVanCaekenberghe.34.mcz

​- HTH



-------- Original Message --------
 On February 18, 2018 12:19 PM, Tony Garnock-Jones <[hidden email]> wrote:

>Hi Henry,
>
> On 02/18/2018 03:02 PM, henry wrote:
>>Cryptography,
>>
> I loaded Cryptography-rww.115.mcz from Squeaksource.
>
>
>>ParrotTalk,
>>
> ParrotTalk-rww.19.mcz, also from the Squeaksource Cryptography project.
>
> I think this is the piece I was missing before.
>
>
>>STON suitable for Squeak,
>>
> I installed ConfigurationOfSton from
>http://ss3.gemtalksystems.com/ss/STON, and executed
>
> ConfigurationOfSton load.
>
> This gets stuck trying to retrieve Metacello (!) from seaside.gemstone.com.
>
> I abandoned loading STON for now.
>
>
>>then load Raven (which was SqueakE).
>>
> I loaded Raven-HenryHouse.21.mcz, also from the Squeaksource
> Cryptography project, and it seemed to load OK (barring the missing STON
> classes!). Hooray!
>
>
> Thank you. I'll explore a little.
>
> Tony
>


Reply | Threaded
Open this post in threaded view
|

Re: Exception handling and concurrency (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

Frank Shearar-3
In reply to this post by Tony Garnock-Jones-5
On 18 February 2018 at 07:12, Tony Garnock-Jones <[hidden email]> wrote:
Hi Eliot,

On 02/15/2018 07:34 PM, Eliot Miranda wrote:
> One thing to think about is that, because exception handling in
> Smalltalk is above the VM, exception handling does not have to be
> limited to a stack-oriented propagation.  There is no reason why
> promises could not keep track of their creating environments and that
> exception propagation could be modified to cross promise boundaries,
> searching for handlers within their originating contexts.

Yes, that's a neat idea. I've been mulling over something similar,
regarding callbacks attached to Promises. Sometimes it's OK to run them
in the context of the UI process, but other times they really want to be
run in the context of the process that was running at the time they were
attached to the Promise. I'm still thinking about what the smallest
change I can get away with might be.

In general, exceptions per se - or rather, stack-based exception
*handler* mechanisms - don't adapt well to a concurrent setting. Miller,
Tribble and Shapiro's "Concurrency Among Strangers" (2005) [1] is great
on this topic. Their idea of "plan interference" really captures the
problem well.

  [1] http://www.erights.org/talks/promises/paper/tgc05.pdf

However, aside from the E-style techniques, an Erlang style design works
quite well. There, stack-oriented exceptions and exception handlers cope
with error signalling and recovery within a process, and Erlang's "link"
mechanism propagates entire actor failures among processes. (In some
ways this is reminiscent of E's two-layered design, with vats containing
objects.)

> Perhaps this is what the onRejected: mechanism does.  But I've wondered
> for a few years (without playing, and so my thoughts are vapor and
> probably quite ill-formed) that such a system could be more convenient.

Yep. My recently-completed doctoral work was on a new actor/tuplespace
inspired hybrid model of concurrency that in some ways makes things like
error signalling and recovery less terrible. (See
http://syndicate-lang.org/tonyg-dissertation/ if you're interested.)

Congratulations!
 
> might be possible to have promises hold onto their originating
> environments so that when an uncaught exception does occur in a promise
> one can make sense of its history.

Recording this kind of causal information is hard, but could be
worthwhile. I don't yet have enough experience with Promises to be able
to do the design work. I wonder if there's an overlap with "E-order".
I've always had trouble digging through erights.org enough to get a
clear picture on exactly what E-order entails.

C# Tasks (promises) routinely keep track of their "stack", for what it's worth. I've never had a need to look into how exactly they do this, but maybe that's an avenue to explore?

Debugging Task-based code never feels any different to debugging "normal" code, FWIW. (Of course that may well be because I make sure my colleagues use immutable data structures and all that...)

frank
 
Cheers,
  Tony