[#10492] Ruby 1.8.6 preview3 has been released — "Akinori MUSHA" <knu@...>

Hi,

26 messages 2007/03/04
[#10500] Re: Ruby 1.8.6 preview3 has been released — Hugh Sasse <hgs@...> 2007/03/05

On Mon, 5 Mar 2007, Akinori MUSHA wrote:

[#10507] Dynamic Array#join with block — <noreply@...>

Patches item #9055, was opened at 2007-03-05 19:57

12 messages 2007/03/05
[#10520] Re: [ ruby-Patches-9055 ] Dynamic Array#join with block — Nobuyoshi Nakada <nobu@...> 2007/03/06

Hi,

[#10594] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org>

In ext/thread/thread.c, remove_one leaves the list in an inconsistent state.

15 messages 2007/03/14
[#10596] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 00:15:57 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10597] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

> > The fix is in thread-mutex-remove_one.diff.

[#10598] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:19:04 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10599] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

On Wednesday 14 March 2007 17:29, MenTaLguY wrote:

[#10600] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:48:42 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10615] Multiton in standard library — TRANS <transfire@...>

Hi--

16 messages 2007/03/15
[#10619] Re: Multiton in standard library — Tom Pollard <tomp@...> 2007/03/16

[#10620] Re: Multiton in standard library — TRANS <transfire@...> 2007/03/16

On 3/15/07, Tom Pollard <tomp@earthlink.net> wrote:

[#10646] Marshal.dump shouldn't complain about singletons if the _dump method is defined — <noreply@...>

Bugs item #9376, was opened at 2007-03-19 15:58

12 messages 2007/03/19
[#10647] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Urabe Shyouhei <shyouhei@...> 2007/03/19

noreply@rubyforge.org wrote:

[#10648] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/19

On Monday 19 March 2007 18:01, Urabe Shyouhei wrote:

[#10651] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Yukihiro Matsumoto <matz@...> 2007/03/19

Hi,

[#10665] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — "Chris Carter" <cdcarter@...> 2007/03/20

On 3/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#10712] Ruby Method Signatures (was Re: Multiton in standard library) — "Rick DeNatale" <rick.denatale@...>

On 3/19/07, TRANS <transfire@gmail.com> wrote:

10 messages 2007/03/21
[#10715] Re: Ruby Method Signatures (was Re: Multiton in standard library) — Jos Backus <jos@...> 2007/03/22

On 3/19/07, TRANS <transfire@gmail.com> wrote:

[#10798] Virtual classes and 'real' classes -- why? — "John Lam (CLR)" <jflam@...>

I was wondering if someone could help me understand why there's a parallel =

12 messages 2007/03/28
[#10799] Re: Virtual classes and 'real' classes -- why? — MenTaLguY <mental@...> 2007/03/28

On Thu, 29 Mar 2007 04:44:16 +0900, "John Lam (CLR)" <jflam@microsoft.com> wrote:

"Real-World" Use of Continuations

From: Brent Roman <brent@...>
Date: 2007-03-30 00:30:30 UTC
List: ruby-core #10813
A couple times on this list, I've read pleas for examples of
real Ruby applications that use Continuation objects. 

Ours is described here:

http://www.zenspider.com/dl/rubyconf2005/EmbeddedRuby.pdf
http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B75DF-4MT6KFX-H-7&_cdi=13037&_user=488091&_orig=browse&_coverDate=02%2F28%2F2007&_sk=999879998&view=c&wchp=dGLbVlz-zSkWb&md5=99829235a3aae38f50df899786b91af2&ie=/sdarticle.pdf

It's real enough, even if it's a little unusual :-)

We've started using Continuations to store checkpoints as Ruby
scripts execute.  These scripts control robotic manipulators, so there is
always the possibility of a failure, either due to a mechanical problem
or a coding error.  The protocols controlled by these scripts
often take hours to complete and consume expensive reagents.
Simply reexecuting them from their beginning in the event of an
error is rarely  a viable option.  So, when an error occurred, we used
to hack up a new script on the spot to recover from
the failure.  Now, using Continuations, we can usually
clear the error condition with a couple simple commands
and resume the execution of the script's failed thread
from its last recorded "checkpoint".

This all works surprisingly well and has been quite easy to implement.
A couple days ago I fixed a typo [that caused an unhandled NameError
two hours into a scripts execution], reloaded the effected method(s) and
resumed execution without losing any important system state!
Honestly, I wish I'd implemented this years ago.

Can anyone help answer the following:

1)  Does the Continuation object include a method to return its associated
     call stack analogous to an Exception object's :backtrace method?
   
     For now, I store the output of Kernel.caller() in my Checkpoints
     just after the callcc that stores the Continuation
     but I feel this must be very inefficient in time and space.
 
2)  If the answer to #2 is no, would it be easy & sensible to implement
      Continuation#backtrace or Continuation#caller ?

3)  Is there another way to implement the generic
     "checkpointing" described above that does not rely
      on Continuation objects, as their future in Ruby seems
     uncertain?  (Is their future still uncertain?)

-- 
 Brent Roman
 Monterey Bay Aquarium Research Institute


In This Thread

Prev Next