[Cuis-dev] Regarding Ometa2

[Phil B]

On Fri, Jul 5, 2019, 5:10 PM Philip Bernhart <philip.bernhart at posteo.de>
wrote:

>
> >
> > I subclassed from OMeta2Debug and it still gets into that problem.
> >
> > What besides that could be done on the side of Cuis to make such errors
> > escapeable? I naively think that this could improve general stability of
> > Cuis.
> >
> > Thanks for your input.
>
> Sorry for the fuss. I just noticed that I didn't try aut CMD-. now
> it seems to work with OMeta2Debug subclassed.
>
> I don't understand the magic behind it, but that makes it debugable.
>
> Sorry for the "wrong alarm".
>

Glad that it at least allows you to escape out of it now.  Basically what's
going on with the default OMeta parser is that it hijacks virtually all
exception handling to use for control flow.  IMO, this is a design bug from
the original implementation I've been meaning to fix but IIRC it's a bit
tricky to do correctly.  The debug parser intentionally 'breaks' a couple
of things to behave a little nicer but they are things that aren't going to
be an issue for 99% of parsers. (I suspect if you get to the point of
having a parser that breaks as a subclass of OMeta2Debug, you'll also have
developed enough of an understanding of OMeta internals to understand why
both it and OMeta are doing things the way they are)

If you can come up with a reproducible example of a hanging parser you
could share, I'd like to take a look at it to see if I can get OMeta2Debug
to catch it.  Hanging parsers were the original use case I created the
debug subclass for so if I've missed something, I'd like to correct it.

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190705/2bbef04f/attachment.htm>