Some feedback

Bill Schwab BILLS at ANEST4.ANEST.UFL.EDU
Fri Jul 20 03:29:03 UTC 2001


Hello,

First, some comments/suggestions/complaints.  None of these are 
crucial in that they won't affect whether or not I use Squeak, they 
probably will affect where I'd deploy it and with what kind of user.

(1) the mapping of underscores to assignment operator is 
unfortunate IMHO.  I'd much rather type := than lose a character 
that appears in a lot of code that I might want to file in some day.

(2) The fact that the mouse cursor location can "remove" input 
focus from a text field is a show-stopper for the end users that I 
support.  It's not a big deal because these users always run 
Windows, so I can (and do) use Dolphin to write apps for them, 
but, it's something that I think should change for the long-term 
benefit of Squeak.

(3) I use lots of background processes, and like to name them.  It 
would be nice to have a #name[:] aspect of Process rather than 
having to externally assign names as is done in the 
ProcessBrowser.

(4) Color syntax highlighting is appreciated and very helpful; but, it
appears to rely on pretty printing, which I find to be fairly invasive.  I
often add white space to add emphasis, and pretty printing 
removes that formatting.  It would be nice to have syntax 
highlighting independent of automatic code formatting.

My interest in Squeak is mostly due to it's ability to target Linux.  
I'd create apps with lots of networking, sometimes serial I/O, and 
eventually database activity.  I'm slowly defining a server 
applicatation that I could develop in Squeak to see if the 
Squeak/Linux combination can meet my needs.  End users will 
never see the app, so I won't hear any complaints about GUI
issues.

If the first app proves succcessful, I'd eventually start to write other
systems that would use lots of background processing.  I started 
looking at Squeak's process synch objects, and found what I think 
might be a bug in Semaphore>>critical:.

Inspect the result of:

 | mutex |
 mutex := Semaphore forMutualExclusion.
 [
  mutex critical:[ nil error:'Take this' ].
 ] on:Error do:[ :e | ].
 mutex.

and note that after the error, the sempahore has zero excess 
signals.  Would it be better to define #critical: in terms of 
#critical:ifError:, perhaps like this:

 critical:aBlock
  ^self critical:aBlock ifError:[ :x :y |  self error:x  ].

Appolgies to those of you who suffered through this on c.l.s. a 
while back.

Bill


Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029




More information about the Squeak-dev mailing list