OMeta 2
Locked
12
12
Re: OMeta 2
 
|
Re: OMeta 2
|
|
Re: OMeta 2
|
|
In reply to this post by Phil B
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 >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> > > > > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org  2337-nextExceptionHandlerFix-JuanVuletich-2015May26-10h58m-jmv.1.cs.st.zip (648 bytes) Download Attachment |
Re: OMeta 2
|
|
Re: OMeta 2
|
|
Re: OMeta 2
|
|
Re: OMeta 2
|
|
| Free forum by Nabble | Edit this page |