Loading ...
Sorry, an error occurred while loading the content.

Re: [Io] Odd bug, probably coroutine related

Expand Messages
  • Steve Dekorte
    ... For now, I d suggest doing: e := try(E raise) if(e, return)
    Message 1 of 7 , Feb 1, 2009
    View Source
    • 0 Attachment
      On 2009-01-30, at 5:16 PM, Stefan O'Rear wrote:
      > E := Exception clone
      >
      > foo := method(
      > loop(
      > try(E raise) catch(E, return)
      > )
      > )
      >
      > foo


      For now, I'd suggest doing:

      e := try(E raise)
      if(e, return)
    • Stefan O'Rear
      ... I have a workaround; I was just posting because I thought Io shouldn t crash with something like that. I ve simplified it to: foo := method(x, x)
      Message 2 of 7 , Feb 1, 2009
      View Source
      • 0 Attachment
        On Sun, Feb 01, 2009 at 12:51:41PM -0800, Steve Dekorte wrote:
        >
        > On 2009-01-30, at 5:16 PM, Stefan O'Rear wrote:
        > > E := Exception clone
        > >
        > > foo := method(
        > > loop(
        > > try(E raise) catch(E, return)
        > > )
        > > )
        > >
        > > foo
        >
        >
        > For now, I'd suggest doing:
        >
        > e := try(E raise)
        > if(e, return)

        I have a workaround; I was just posting because I thought Io shouldn't crash
        with something like that.

        I've simplified it to:

        foo := method(x, x)
        loop(foo(return)) # No exceptions, coroutines involved

        though it's still rather resistant to my attempts to debug it. A null pointer
        is getting into a PHash somehow and is being followed by the garbage collector,
        but is not triggering assert(value)s on all the PHash_ public APIs.

        -sorear
      • Stefan O'Rear
        ... Update - there seem to be two orthogonal issues here. Second: ^C is not very robust. It runs the Io interpreter in signal context, causing massive
        Message 3 of 7 , Feb 1, 2009
        View Source
        • 0 Attachment
          On Sun, Feb 01, 2009 at 01:12:46PM -0800, Stefan O'Rear wrote:
          > foo := method(x, x)
          > loop(foo(return)) # No exceptions, coroutines involved
          >
          > though it's still rather resistant to my attempts to debug it. A null pointer
          > is getting into a PHash somehow and is being followed by the garbage collector,
          > but is not triggering assert(value)s on all the PHash_ public APIs.

          Update - there seem to be two orthogonal issues here.

          Second: ^C is not very robust. It runs the Io interpreter in signal context,
          causing massive failures if the process context interpreter was doing anything
          interesting. Probably stopStatus should be a sig_atomic_t and have a big for
          stopping from a signal, then the code can start an interrupt handler in a
          coroutine at a safe point.

          First, and more complicatedly, control operators use dynamic scope; they
          always refer to the innermost dynamically enclosing control structure. This
          might sound like a good thing; it's not, because it horribly breaks
          encapsulation.

          For the sake of having an example, suppose Number + was rewritten in Io:

          Number myPlus := method(other, self + other)

          Now, if you try to use control operators with both, you see a marked
          difference:

          Io> foo := method(1 +(return 1) +(1)); foo
          ==> 1
          Io> foo := method(1 myPlus(return 1) +(1)); foo
          ==> 2

          The reason is that the return 1 applies to the dynamically enclosing
          structure - the myPlus method itself - and the chain reduces to 1+1.

          Viewed in this light my original problem was one of assuming that
          Exception catch (a predefined method) would work the same with control
          operators as Object if (a primitive).

          I'm not sure exactly what the solution to this is, but I think it
          involves evalArgAt relaying stop statuses?

          -sorear
        • Steve Dekorte
          ... That s right. It s probably a one or two line of code change.
          Message 4 of 7 , Feb 2, 2009
          View Source
          • 0 Attachment
            On 2009-02-01, at 6:25 PM, Stefan O'Rear wrote:
            > I'm not sure exactly what the solution to this is, but I think it
            > involves evalArgAt relaying stop statuses?

            That's right. It's probably a one or two line of code change.
          • Stefan O'Rear
            ... Relaying stop statuses would be closer to what I intuitively expect, but it would probably be prudent to put some (as yet uncharacterized) restrictions on
            Message 5 of 7 , Feb 2, 2009
            View Source
            • 0 Attachment
              On Mon, Feb 02, 2009 at 01:40:22AM -0800, Steve Dekorte wrote:
              >
              > On 2009-02-01, at 6:25 PM, Stefan O'Rear wrote:
              > > I'm not sure exactly what the solution to this is, but I think it
              > > involves evalArgAt relaying stop statuses?
              >
              > That's right. It's probably a one or two line of code change.

              Relaying stop statuses would be closer to what I intuitively expect,
              but it would probably be prudent to put some (as yet uncharacterized)
              restrictions on the (documented) use of call evalArgAt, because there
              is a slippery slope here.

              If we allow:

              foo := method( call evalArgAt(0) )

              then do we not allow:

              bar := method(x, x evalArgAt(0) )

              foo := method(bar(call))

              ? How about:

              foo := method( x := call; block(bar(x)) )

              ? But then:

              callCC := method(arg, cell := false; list(1) foreach( cont := foo(break))
              cell ifFalse(cell = true; arg call(cont)) )

              Of course, callCC does not work with the relaying approach; the challenge
              is to decide what restrictions are needed to make relaying = naive lexical,
              and decide if they are acceptable...

              -sorear
            Your message has been successfully submitted and would be delivered to recipients shortly.