[antlr-interest] v3.0 debug interface

[Terence Parr]

Hi Tom, thanks for the nice comments!

On Mar 23, 2005, at 12:51 AM, Tom Brandon wrote:
> I had a couple of comments about your post (see below), but then
> realised I wasn't quite sure how debugging is supposed to work wrt
> target languages. How is the Antlr GUI executing grammars for 
> debugging?
> Is it executing an interpreted version of the grammar or a compiled
> version?

It will debug generated/compiled parsers only.  Later I might get the 
interpreter to work...well, it works, but it doesn't generate all the 
location(line,pos) calls so the breakpoints don't really work.

>  If it is interpreted then what does it do about actions? Are

The debugger won't work on the interpreter for now, but later it will 
just ignore actions.  That of course makes it impossible to do grammars 
with semantic predicates.

> you planning to support debugging of languages with actions in 
> languages
> other than the language of the GUI? It would seem nice to allow this as
> an option in the design of Antlr though supporting it in the GUI may 
> not
> be a priority.

ANTLR will be a parasite on the running parser in whatever target 
language...so ANTLR's gui has no issues with actions. :)

> You suggest a java debugging interface which can then be proxied out
> over TCP to non-Java clients, but doesn't this mean that the solution
> (at least the solution of the GUI) is limited to debugging grammars 
> that
> target Java?

Nope...

>  Wouldn't it be better to have Antlr specify a language
> neutral TCP based debugging protocol. Then a GUI would implement this
> and with a bit of target language code to run a compiled grammar and
> send the debugging information over TCP any target language could be
> debugged from a single GUI. There may still be target language specific
> protocols (such as your Java interface) but shouldn't Antlr 3 specify a
> single language neutral debugging mechanism.

That Java interface is just the Java way to trigger events.  C or 
whatever would just call functions that emitted a text protocol across 
the socket to the GUI (which happens to be in Java, though that's not 
important...anybody that wants to will be able to handle the protocol).

So, I'll be defining a very simple text language (protocol) for anybody 
that knows how to open sockets to use.  I won't be marshaling method 
calls across the net.  That was always dumb and is dumb now.   
Empirically only text protocols have survived (SMTP, NNTP, FTP, HTTP, 
.....) whereas CORBA is heinous...SOAP and friends frighten me so much 
I'm speechless...but I digress.

> And then the issues with the actual proposal:
>
> Any reason for not going with a more standard Listener based pattern 
> (if
> you weren't already intending such a pattern)?

You mean like the AWT bean listener thing?

>  Will the system support
> multiple listeners? Can't really conceive of a case where multiple apps
> would want to listen,

I couldn't either so I went for simplicity instead. ;)  You can 
daisy-chain to get multiple if you want.

>  but you may want more flexibility in the GUI,
> multiple parts each registering their own listeners rather than
> everything having to come off one master listener (and there's the
> code-gen specific events mentioned below where you might want
> corresponding GUI modules for different code-gens).
>
> Any reason for a non-extensible model? If you use a standard Listener
> pattern with event data wrapped up in objects then you could have a
> generic method (in addition to specific methods), like:
> public void debugEvent(AntlrDebugEvent evt);

All good ideas, but I'm opposed to "OO" for "OO"s sake.  I like 
location(line,charPosition) for example because it's explicit and I'm 
opposed to complexity just "in case".  Though, I agree, changes are a 
bigger deal to an interface if you screw up!  You'll note that the 
exceptions (which may want to track all sorts of stuff later) are 
tossed in as objects. :)

> Not really sure about use-cases for that. Maybe some code generators
> want to add (or subclass) their own events which shouldn't pollute the
> main interface.

Agreed.  I worry that I can't find a use-case either. ;)  I have 
learned that adding complexity now to avoid possible future issues is 
good, but it's an optimization problem.   Further, it says that changes 
later (when you know stuff) are harder than changes now (when you 
don't).  There is some truth in terms of backward compatibility, but 
I'll avoid complexity unless we can think of a real need.

Thanks!

Ter

> Tom.
>
> -----Original Message-----
> From: antlr-interest-bounces at antlr.org
> [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Terence Parr
> Sent: Tuesday, 22 March 2005 13:26
> To: 'antlr-interest' Interest
> Subject: [antlr-interest] v3.0 debug interface
>
> Howdy,
>
> I am working on the debug interface so that parsers trigger events.
> The GUI can listen for these events (initially in Java and then
> marshaled over a socket to support non-Java languages) and do cool
> displays etc...  The debugger will be able to tell the parser to
> Thread.wait() in order to implement breakpoints etc...
>
> Anyway, I've been thinking hard about what events we need to trigger.
> Most of my thoughts are driven by the ways in which I intend to use a
> debugger.  Also I've take some ideas from David Wigg (who suggested I
> fire events for alternatives not just rules) and Scott Stanchfield (who
> did the ParseView debugger).
>
> The code generator adds the appropriate triggers upon -debug
> command-line option.  All but the location() triggers are functioning.
> Currently, I'm going to have the GUI launch the parser with a
> TokenStream but later your apps will be able to create an instance of
> the GUI and pass it to the parser as the debug event listener. :)   By
> default, the parser compiles but doesn't emit any debug output; I'll
> probably change that so it mimics the -traceParser 2.x feature.
>
> BTW, I've kept this interface as small as possible.  Some of the
> functionality I want in the debugger is not obviously possible from 
> this
> interface, but in fact with a little work the debugger will be able to
> do amazing things!
>
> So, here it is so far...I'm happy to receive feedback.  I expect that
> this will change a lot as Jean builds the GUI on top.
>
> Ter
> -------------------------------
> package org.antlr.runtime;
>
> public interface ANTLRDebugInterface {
> <SNIP>
> }
>
> --
> CS Professor & Grad Director, University of San Francisco Creator, 
> ANTLR
> Parser Generator, http://www.antlr.org Cofounder, http://www.jguru.com
>
>
>
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com