Why aren't these Disney Python jobs for Squeak?

Paul Fernhout pdfernhout at kurtz-fernhout.com
Fri Sep 22 18:21:52 UTC 2000


Bert Freudenberg wrote:
> 
> On 22 Sep 2000, Randal L. Schwartz wrote:
> 
> >     halfdome.holdit.com>> squeak -headless
> >     Segmentation fault
> >  *** Aside: is anyone aware of this or working on this? ***
> 
> It was noted two days ago by someone, and some weeks ago by me. The fix is
> trivial. In sqXWindow.c, ioSetCursorWithMask(), insert at the top:
> 
>   if (!isConnectedToXServer) return 0;

One issue is what the priorities are for what is being tested (and
retested).

But there is a much bigger design issue here. What is a headless Squeak
doing connecting to an X-server? While the patch you suggest may work,
the deeper issue is that modular code for headless operation should
never require such a patch. 

Dan Ingalls himself in an earlier post pointed towards exceptions as one
key aspect of working towards a better headless system -- because this
allows better decoupling of model code from the GUI displaying
exceptions.
 
> > I can't imagine a CGI "script" written in Squeak no matter how well
> > the design would be... the startup cost of launching a new image is
> > probably too high.
> 
> With a stripped-down image that is built into the executable that
> shouldn't be a big deal. Now the time is:
> 
> bert.balloon > echo Smalltalk snapshot: false andQuit: true > myscript
> bert.balloon > time squeak -headless myscript
> 0.560u 0.140s 0:00.70 100.0%    0+0k 0+0io 233pf+0w

Great benchmarking. And I agree that Squeak as is can be useful for some
web applications (especially if used as you outline).

Still, what does this stack trace imply about performance bottlenecks?

>     Segmentation fault
> 
>     1083038176 CursorWithMask>beCursor
>     1083038084 Cursor class>currentCursor:
>     1083037992 InputSensor>currentCursor:
>     1083037900 Cursor>show
>     1082995260 SystemDictionary>snapshot:andQuit:
>     1082995168 ScreenController>snapshotAndQuit
>     1082994780 SelectionMenu>invokeOn:
>     1082994688 ScreenController>controlActivity
>     1082994596 Controller>controlLoop
>     1082994504 Controller>startUp
>     1082994292 [] in ControlManager>activeController:
>     1082994384 [] in BlockContext>newProcess
>     halfdome.holdit.com>> 

It is saying that when you startup Squeak to do a bit of text handling,
you get a lot of GUI related processing going on. This just should not
be. It is wasteful both of CPU time and testing time. It is code that
shouldn't be run because it is unneeded and thus is just one more thing
that can go wrong (as it did). It causes both the VM and image to be
larger than they have to be.

This situation is a reflection of the monolithic image philosophy. There
isn't even a need for a Controller class in a headless image, let alone
a need to start one up. Yet could I easily pull out "Controller" and its
subclasses from Squeak and make an image to run headless? No. Not being
able to remove Controller is a sign of a deep weakness in the current
Squeak approach and toolset. Not that this can't be fixed in time, but
it is a core thing requiring extensive refactoring and new image
building tools.

Yes, it is convenient in some cases to use the same image for
development and deployment. However, one should have the option of
getting rid of the clutter. This is probably best and most reliably
accomplished by building up an image from modules/classes (the ANSI way)
rather than stripping down an image (the current Squeak way). As Les
Tyrrell pointed out a long while back, it is much easier to test an
intentional composition of complete modules than to test the leftovers
of an ad-hoc stripping process for unintentional side effects or
behaviors.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com





More information about the Squeak-dev mailing list