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

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Shaping
> Sent: Tuesday, December 26, 2006 4:31 PM
> To: Strongtalk-general
> Subject: Syntax coloring; navigating; debugging Smalltalk; debugging the
> VM; comparisons to Vista Smalltalk
>
>
>
> 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?

You don't have to save and start over, you can just evaluate
'ProgrammingEnvironment flushPainters', which will set them all to nil.
Some of the painters may not be used, but many of them are non-nil.

I don't know how you are looking at their values, but if you are doing it
using 'Inspect It' on the context menu, that won't work right now.  The
context for evaluation isn't set up correctly right now in the class
variables pane, so if you do an inspectit, the selection is evaluated in
global scope and can't see the class variable.  The reference is thus
interpreted as a missing global variable reference and a global variable of
the same name is added; if you see the message 'Global <var>  is used but
not defined so it has been added.' in the transcript, that is what is
happening.

> 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?

Unfortunately, there is only an unimplemented stub right now for class
variable references.  In practice this isn't much of a problem, since access
methods are almost always used, so just look for senders of the access
method as a workaround.

> 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?

Yes, XML is how I would expect it ought to be done.

> Why don't the Home and End keys work in the usual way in text fields?
> I really need to fix this.

I just never got to that.  You are welcome to add it.  The right place to do
it is TextView>>keyDown:focus:event:.

> 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.

Yes, that is very high on the list of things to do.

> 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.

Yes, stability is the highest thing on the list of things to work on.

> Is there a Find-and-Replace dialog?

Not yet.  All these things you want are needed, but it takes developers to
implement them.  Remember, Strongtalk is an unfinished system, and unlike
Vista Smalltalk, no one is being paid to work on it.  If you would like to
help address these issues, that's the best way to make it happen.
Development has been quiescent recently because I have been out-of-town most
of the last few months, and this isn't my day job anyway.  Right after New
Year I will be diving back into this, starting with VM documentation and
debugging to improve stability, followed by porting and a grahical debugger
as the next priorities.   If you want to help out, that will be when
development will be getting more organized.

-Dave


--~--~---------~--~----~------------~-------~--~----~
 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
-~----------~----~----~----~------~----~------~--~---