[stringtemplate-interest] visualizer mockup

[Gerald Rosenberg]

Agreed, the only portable part is to have ST4 capture and provide 
relevant information in some convenient language neutral form -- my 
thinking is that when ST4 is executed in a debug mode, it will do a 
final burst transfer of recorded information (using a serializer like 
PB or Thrift over some simple pipe or socket) to a waiting UI process.

After that, it is all UI and there are just too many combinations of 
java, C#, swt, swing, Eclipse, NetBeans to consider 
portability.  Just have to pick a reference framework, with whatever 
constraints it might have, and let others port.

If you go with, say, an extension of AW, I can help make sure that 
the ST4 debug data production is sufficient and neutral, considering 
AntlrDT as a proxy for whatever other ports there will be.

If you go with an Eclipse-based tool, I can contribute a bit more.

@Jim: the dashboard looks to be just a GWT web-application fronting a 
protocol buffers-based data store.  Or, am I looking at the wrong 
stuff?  My thinking was for a tool that would be actively integral to 
the edit/debug cycle.

Best,
Gerald

At 01:41 PM 11/25/2009, you wrote:
>Yeah, i want a standalone thing so I can keep using eclipse 
>;)  Gerald can integrate into AntlrDT or whatever.  Hmm...if I use 
>eclipse SWT, I can't incorporate this into AW.  Crap. I hate making 
>these choices with distant ramifications.
>Ter
>On Nov 25, 2009, at 1:38 PM, Jim Idle wrote:
>
> > Ter,
> >
> > Did you look at the Google dashboard stuff? It all seems to 
> integrate with everything else mentioned here Google wise and they 
> have some neat demos with full source that you can steal.
> >
> > IDE integration is OK, but even doing the cutdown stuff is a bit 
> of a pain and as I use Netbeans, I don't really want the terrible 
> Eclipse interface; but you know if you choose Netbeans then Eclipse 
> junkies will hate it. So a standalone dashboard reusing all the 
> Google code seems like a pretty good solution to me. I don't think 
> you need much of a protocol, something like AW will work fine I 
> think and the C# version of that Google stuff looks fine. Though if 
> you want to generate a text description file, then all you need is 
> a good parser to assemble it into the dashboard - know any? ;-) If 
> you make this as components, then someone could do Eclipse 
> integration and Netbeans integration etc pretty easily I think.
> >
> > Jim
> >
> >
> >
> >> -----Original Message-----
> >> From: stringtemplate-interest-bounces at antlr.org [mailto:stringtemplate-
> >> interest-bounces at antlr.org] On Behalf Of Terence Parr
> >> Sent: Wednesday, November 25, 2009 11:22 AM
> >> To: Barrie Treloar
> >> Cc: StringTemplate Mailing List
> >> Subject: Re: [stringtemplate-interest] visualizer mockup
> >>
> >>
> >> On Nov 24, 2009, at 4:47 PM, Barrie Treloar wrote:
> >>
> >>> On Wed, Nov 25, 2009 at 5:03 AM, Terence Parr <parrt at cs.usfca.edu>
> >> wrote:
> >>>> Oh, and another architectural issue.  Should this be a socket based
> >> thing like ANTLRWorks so C# and Python targets don't have to build
> >> their own GUI?  I'd say yes, but then it's harder to drill down into
> >> objects in the attribute table.  I'll have to YAML or JSON marshall
> >> objects across the socket.  Some objects like binary arrays might be
> >> hard to represent properly in language indep manner in gui too.
> >>>
> >>> I think some of the discussion so far raised some misunderstandings.
> >>>
> >>> Is this meant to be a static inspection of the template? i.e some
> >>> meta-data about template generation - which either resides inside the
> >>> template or perhaps in another source (file, socket stream, etc)
> >>
> >> I think we should collect all data like a flight data recorder and then
> >> ship to the GUI.  Unlike AW, i doubt step by step eval is useful.
> >>
> >>> Or is this meant to be something dynamic so that as the template is
> >>> generated you can see what is going on?
> >>
> >> static data but interactive
> >>
> >>> My understanding so far has been that this would be static
> >> inspection.
> >>> And if so I am unclear what a socket implementation would provide.
> >>
> >> Yeah, Gerald pointed out a file of text would be better all at once.
> >> sockets are more complicated. we want multiple targets to be able to
> >> use same gui.
> >> T
> >> _______________________________________________
> >> stringtemplate-interest mailing list
> >> stringtemplate-interest at antlr.org
> >> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
> >
> >
> >
> > _______________________________________________
> > stringtemplate-interest mailing list
> > stringtemplate-interest at antlr.org
> > http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>
>_______________________________________________
>stringtemplate-interest mailing list
>stringtemplate-interest at antlr.org
>http://www.antlr.org/mailman/listinfo/stringtemplate-interest