[Cuis] OMeta 2

[Juan Vuletich]

Hi Phil,

There was a relatively recent bug when walking exception handlers. The 
fix is attached. Please try it.

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
>>>
>
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2337-nextExceptionHandlerFix-JuanVuletich-2015May26-10h58m-jmv.1.cs.st.zip
Type: application/zip
Size: 472 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150526/0a368a35/attachment-0004.zip>