OMeta 2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Hannes Hirzel
Is it possible that the issue is related to this?

http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165604.html

--HH

On 5/26/15, Phil (list) <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Phil B
On Tue, 2015-05-26 at 05:41 +0000, H. Hirzel wrote:
> Is it possible that the issue is related to this?
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165604.html
>
> --HH
>

I believe I've already applied the patch that post was referring to but
can't be certain as I was unable to download the referenced mcm.
Squeaksource doesn't list that as a valid file at
http://squeaksource.com/OMeta/ or http://squeaksource.com/OMeta.html so
that was either a typo or an older version.  However, the latest commits
to my repo did include patches from the newest pre- package listed there
from around the timeframe of the post and it did fix a bug related to
decompiling & prettyPrint which I suspect was what that post was
referring to.

> On 5/26/15, Phil (list) <[hidden email]> 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



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Juan Vuletich-4
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
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Phil B
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
> >>> [hidden email]
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>
> >
> >
> >
> >
>



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Juan Vuletich-4
In reply to this post by Phil B
Hi Phil,

On 5/24/2015 7:07 AM, Phil (list) wrote:
> 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

Updates #2331 and #2332 are already loaded in the image @ github, you
can simplify installation instructions.

Thanks,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Phil B
On Thu, 2015-05-28 at 09:12 -0300, Juan Vuletich wrote:

> Hi Phil,
>
> On 5/24/2015 7:07 AM, Phil (list) wrote:
> > 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
>
> Updates #2331 and #2332 are already loaded in the image @ github, you
> can simplify installation instructions.
>

And now so is 2337... updated.

> Thanks,
> Juan Vuletich



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: OMeta 2

Phil B
In reply to this post by Phil B
I've added an example Lisp parser which should hopefully put the
examples and tests in better shape.  I think there's now a pretty decent
progression in the examples but could use feedback to confirm, or tell
me what's still needed.

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
12