[antlr-interest] v3.0 debug interface
Scott Stanchfield
scott at javadude.com
Thu Mar 24 20:28:09 PST 2005
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)
>
>
>
More information about the antlr-interest
mailing list