[stringtemplate-interest] visualizer mockup

Terence Parr parrt at cs.usfca.edu
Wed Nov 25 13:41:35 PST 2009


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



More information about the stringtemplate-interest mailing list