[Cuis] OMeta 2

[Phil (list)]

Juan,

On Tue, 2015-05-26 at 11:13 -0300, Juan Vuletich wrote:
> Hi Phil,
> 
> There was a relatively recent bug when walking exception handlers. The 
> fix is attached. Please try it.
> 

Excellent... that appears to have been the issue exactly.  Fixed.

Thanks,
Phil

> Cheers,
> Juan Vuletich
> 
> On 5/26/2015 1:24 AM, Phil (list) wrote:
> > On Mon, 2015-05-25 at 10:14 -0300, Juan Vuletich wrote:
> >> Hi Phil,
> >>
> >> I'm not that of an expert wrt debugger internals, but will take a look
> >> at this tomorrow (please tell if you solve it!).
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> > Thanks Juan... I could still use some help on this.
> >
> > I was able to get a bit further by wrapping ContextPart trace: around
> > the self halt in OMeta2Base apply: and have attached the relevant
> > output.  As it goes up the handler chain, it runs into a nil which I'm
> > believe is the issue.  If it is, I don't understand why it's nil
> > (isn't an empty block, as used in ometaOr: effectively a noop?)  If it
> > isn't, then I'm at a loss as to what's going on...
> >
> > Thanks,
> > Phil
> >
> >> On 5/24/2015 7:07 AM, Phil (list) wrote:
> >>> Anyone have experience debugging the debugger? If so, I could use some
> >>> pointers...
> >>>
> >>> In my latest repo commit I've included two variants of a rule (you'll
> >>> should be able to replicate if you have the examples loaded.)  One that
> >>> works:
> >>>
> >>> OMeta2LambdaCalculusParserExample debugMatchAll: 'x and y;x*y' with:
> >>> #root.
> >>>
> >>> And one that doesn't:
> >>>
> >>> OMeta2LambdaCalculusParserExample debugMatchAll: 'x and y;x*y' with:
> >>> #rootHang.
> >>>
> >>> The second command is supposed to crash and bring up the debugger but
> >>> appears to get caught in an infinite loop after calling 'self halt' in
> >>> its error handling code.  You can break out of it via alt|cmd-. and get
> >>> to the debugger but the backtrace is all about the problems the
> >>> debugger is having, not the original halt. I have every confidence that
> >>> this is the result of OMeta failing to do something that is needed for
> >>> the debugger to function properly.  The problem I'm having is figuring
> >>> out how to debug the debugger.  When I break out of the loop I see the
> >>> nil object in the context list, but what's that object supposed to be
> >>> and where would it be set / set up?  Any ideas/pointers to docs or
> >>> relevant email discussions on debugging crashes in the debugger itself?
> >>>
> >>> (Note: I had this issue even running OMeta under Squeak 3.10 so I
> >>> suspect there was something that got changed since 3.8/3.9 that broke
> >>> this functionality as I've never seen it working properly...)
> >>>
> >>> Thanks,
> >>> Phil
> >>>
> >>> On Wed, 2015-05-20 at 18:54 -0400, Phil (list) wrote:
> >>>> ... is alive!  Several caveats so please check out the README for the
> >>>> latest updates as things progress:
> >>>> https://github.com/pbella/Cuis-Ports#ometa-2
> >>>>
> >>>> Thanks,
> >>>> Phil
> >>>
> >>>
> >>> _______________________________________________
> >>> Cuis mailing list
> >>> Cuis at jvuletich.org
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>
> >
> >
> >
> >
>