At Wed, 14 Dec 2011 09:35:06 +0100,
Lukas Renggli wrote:
>
> > I've experimented in what little time I can devote with OMeta, PetitParser,
> > and Treetop. The debugging experience has been roughly consistent across
> > all three.
>
> Casey, did you try the PetitParser IDE? If so, what did you miss?
>
> If not, please check it out
> (http://jenkins.lukas-renggli.ch/job/PetitParser/lastSuccessfulBuild/artifact/PetitParser-OneClick.zip).
> It comes with dedicated tools for grammars (editor, visualizations,
> profiler, debugger, ...). An earlier version of the tool is described
> in Section 3.5 of this paper
> (http://scg.unibe.ch/archive/papers/Reng10cDynamicGrammars.pdf). We
> are currently working on an improved IDE with grammar refactorings.
Wow. Pretty cool.
I'm playing with it a bit, and trying to figure out how I'd detect
an error in my grammar. I introduced a bug in PPJsonGrammer by
changing string to read (omit the last $" asParser):
string
^ $" asParser , char star
and chose "Dynamic" and put {"a": 1, "b": 2} and said "parse". I see
the tree and the parse goes as far as position 3. But of course, it
is not easy to tell that #string has the problem from this. (I'd
think that this is the nature of grammar writing, where the parser
basically does not know what makes sense, especially if there are
other choices.
OMeta2/Squeak has a feature to pop up a Squeak debugger at the
position where the parse went as far as it could, and then you can
step execute it. But of course, it goes into the underlying
implementation and generated code, so it is quite tedious. What we
would like to see in that debugger is the original code and step
execution that makes sense.
Of course, Squeak debugger lets you "restart" a context, but this
does not help much as the parser is stateful. We contemplated Worlds
would help to really rewind a rule and try again...
-- Yoshiki
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
