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

"Shaping" <[email protected]>
Newsgroups gmane.comp.lang.smalltalk.strongtalk
Message-ID <[email protected]>
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


--~--~---------~--~----~------------~-------~--~----~
 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
-~----------~----~----~----~------~----~------~--~---
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.