Re: Syntax coloring; navigating; debugging Smalltalk; debugging the VM; comparisons to Vista Smalltalk

Hi,

I'll just comment on DeltaParser, since you mentioned you wanted to look at it.
Probably the most important fix in that area is not to the parser
itsefl, but to the AST hierarchy. It doesn't separate the syntax
cleanly from the semantics, so the tree carries a lot of baggage that
shouldn't be there: scopes, types, specialized nodes for compilation
(like temps vs. parameters).

Cleaning that up would be easy - except for keeping the typechecker
and compiler working.

As far as syntax coloring - it depends what you want to do.  Some
coloring requires intervening at the lexical level (say, if you want
to highlight unfinished comments or strings, or balance parentheses).
DeltaParser is probably irrelevant to that - but DeltaScanner might be
useful.


On 12/26/06, Shaping <[email protected]> wrote:
>
> David Griswold wrote:
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]On Behalf Of Shaping
> > > Sent: Monday, December 25, 2006 2:01 AM
> > > To: Strongtalk-general
> > > Subject: Re: Fonts; syntax coloring; type annotations
> > >
> [...]
> > >   The
> > > > reason your changes aren't taking effect is that the painters used to
> > > > render
> > > > the programming environment are cached in class variables in class
> > > > ProgrammingEnvironment, so they are only built once (Painters hold the
> > > > graphics state for rendering).  Look at the methods in the instance
> > > > category
> > > > 'private-painters' in ProgrammingEnvironment.  If you set any
> > > of the class
> > > > variables in that class to nil (or just save and restart the image after
> > > > changing the font specification)
> > >
> > > I saved and restarted the image after changing the font in a method
> > > pane (I
> > > could not find any other place to do this, and am assuming that the
> > > scope
> > > for the change is all method panes; not sure).  There was no change.
> > >
> > > I tried setting CodePainter to nil, saving, and restarting.  This did
> > > not
> > > work either.
> >
> > My last email outlined how to change the font the browsers use for code.
>
> I changed ProgrammingEnvironment>>smallPoint and  >>smallTypeface,
> saved, and cycled, and now see all methods paint correctly in the new
> typeface.  Thanks.  However, there are no nonnil cached values for the
> few class-side Painters I checked.  Why?  Next I want to change some of
> the other Painters to get the typeface and color scheme I want.  I'm
> also looking at DeltaParser and its users to determine how best to
> color method code.  Pointers/suggestions are welcome.
>
> I'm having some trouble getting around.  Is there a "References" menu
> for class variables?
> The tree of protocols and methods is elegant overall, except for a
> distracting problem:  too much peripheral field activity, as the tree
> expands and collapses, pushing the rest down or pulling it back up.
> It's a little disorienting, and I miss the usual class browser, mostly
> for this reason.  Also, in the same vein, when you click on a class,
> you get a new window, always.  This default creates more motion and
> more portals than I want, blowing my train of thought sometimes.  If I
> want more portals (windows) on the sytem, I prefer to open them myself
> (spawn/new/clone menu perhaps), and then change the contents of the
> panes in that portal by clicking about.  I'd like to know how everyone
> feels about this, and how well you're acclimating to Strongtalk's
> pure-tree-and-auto-spawn way.
>
> We really need a clean dev-environ restoration mechanism.  I'm wasting
> time getting back to where I was after a save and cycle.  Does anyone
> have any ideas or preference on how to do this?  Should we serial
> window structure as XML, write out the file, and parse it on startup?
>
> Why don't the Home and End keys work in the usual way in text fields?
> I really need to fix this.
>
> For me, besides all of my favorite creature comforts, the biggest
> impediment to commitment to Strongtalk is the lack of a debugger for
> tracing through the code.
>
> The second biggest problem is the crashing.  I haven't loaded the CPP
> code into VS 2005, but intend to soon.  If there are new instructions
> for building to make this easier, please let me know.  Does anyone know
> the specific causes of the crashes, in tems of actual CPP files, code
> line numbers?  Is there an growing list of VM bug-and-clean-up wisdom
> somewhere?  I'm aware of the VM syllabus, and am wondering whether
> those most familiar with the VM code are documenting their discoveries
> of problems or best-guesses.
>
> Is there a Find-and-Replace dialog?
>
> ...
>
> I'm looking hard at Vista Smalltalk, too:
>
> http://www.vistascript.net/vistascript/docuwiki/doku.php?id=home
>
> It's very nascent, but looks extremely good, the most exciting feature
> being the scalable vector graphics, which /just works/ as part of the
> .NET assemblies (WPF) that Vista wraps.  Response time of the system in
> IE7 is OK to very good, not stellar, but I can't tell whether the tiny
> lags are slow smalltalk or slow C# assemblies, or whether this is to be
> expected where scalable vector graphics are concerned.  I suspect the
> speed hit lies somewhat in all three areas, mostly in the last.  Anyone
> have experience with Vista Smalltalk or care to comment on its
> potential/problems?  The big problems for me are its speed and having
> to debug C# code, potentially.  Heterogenous debugging is a
> productivity killer.  Otherwise, Vista Smalltalk is off to a nice
> start.
>
>
> Shaping
>
>
> >
>


-- 
Cheers, Gilad

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---