[antlr-interest] v3.0 debug interface

[Tom Brandon]

Ah, great, looks like we were on the same page as far as the inteface
between GUI and lexer\parser goes, you just sent specs in terms of Java
interface rather than the net based protocol. And I certainly wasn't
think of some nasty CORBA style thing, just a text protocol like you
suggest.

As to the format of the interface, I meant the standard Java style
listeners, extend java.util.EventListener (just a tag for tools) and
then (add|remove)Listener(...); methods (hadn't remembered that Java's
"Listener" pattern was quite so simple, too long living day to day in
C#'s delegate land I guess).

Amd then events of the form:
void location(LocationEvent evt); 
where LocationEvent extends java.util.EventObject.

While I agree about the general issue of cost\benefit, these changes
seem of little cost, seem to offer some functional benefit (the two
use-cases of modular handling in the GUI and code-gen specific events)
and also fit the standard Java design patterns thus making them easier
to understand for those familiar with other Java apps (in this case a
rather weak point due to the simplicity of the pattern but still) and
understandable by other language tools.

Tom.
-----Original Message-----
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Terence Parr
Sent: Thursday, 24 March 2005 06:36
To: 'antlr-interest' Interest
Subject: Re: [antlr-interest] v3.0 debug interface

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