[antlr-interest] v3.0 debug interface

[Scott Stanchfield]

Sounds like an ideal place for a factorily that returns a strategery for the
communification of the debuggery informat...

(Sorry -- possessed by the commander-in-chimp for a second... at least my
state voted against him ;)

-- Scott

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org 
> [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Tom Brandon
> Sent: Thursday, March 24, 2005 9:18 PM
> To: antlr-interest
> Subject: RE: [antlr-interest] v3.0 debug interface
> 
>  I agree, though a plugin to what? How exactly is the 
> instrumentation supposed to happen (Ter?)? I assume it will 
> be through custom code generators extending the base ones to 
> add debug functionality? So, will these be provided by Antlr 
> or will the IDE be responsible for hooking in it's own debug 
> generators? And then how will it divide between core Antlr 
> and code-gens? Presumably some mix is needed. Code-gen needs 
> to provide language-specific debug calls, but implementing 
> entire debug system would be troublesome, so ideally core 
> Antlr would be doing something, building on smaller units 
> specified by code-gen (perhaps just low-level call-message 
> stuff, perhaps higher, allowing C# to spit out conditional 
> methods for debug builds might be nice). And then the IDE 
> seems to need some place in the whole thing, to specify 
> whether it wants to be doing in-process (for a 
> target-language it can host) or net based otherwise for instance.
> 
> Tom.
> -----Original Message-----
> From: Scott Stanchfield [mailto:scott at javadude.com]
> Sent: Thursday, 24 March 2005 23:29
> To: Tom Brandon; 'antlr-interest'
> Subject: RE: [antlr-interest] v3.0 debug interface
> 
> I would really prefer the transport mechanism to be a plugin. 
> This would allow socket-based transport if desired, or direct 
> observer communication.
> No need to do network I/O if not necessary.
> 
> The plugin would be responsible for the unicast/multicast support.
> 
> That said, an implementation in Eclipse would need to use 
> socket-based communication ;) I'm just thinking of a 
> command-line version similar to ParseView, which simply adds 
> listeners.
> 
> Later,
> -- Scott
> 
> > -----Original Message-----
> > From: antlr-interest-bounces at antlr.org 
> > [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Tom Brandon
> > Sent: Thursday, March 24, 2005 12:44 AM
> > To: antlr-interest
> > Subject: RE: [antlr-interest] v3.0 debug interface
> > 
> > No, the Antlr GUI, written in Java, or other GUIs in any language, 
> > will be able to debug parsers in any target language.
> > 
> > Terrence Parr said:
> > "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."
> > 
> > Tom.
> > -----Original Message-----
> > From: antlr-interest-bounces at antlr.org 
> > [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Bryan Ewbank
> > Sent: Thursday, 24 March 2005 15:56
> > To: antlr-interest
> > Subject: Re: [antlr-interest] v3.0 debug interface
> > 
> > Perhaps I missed it in this thread, but is the V3.0 debug interface 
> > intended only for Java?  It seems that quite a bit of the 
> discussion 
> > is in that context, so need to ask.
> > 
> > Thanks,
> > - Bryan (C++ ANTLR for me)
> 
> 
>