OT: Dolphin smalltalk giving up

Bill Schwab BSchwab at anest.ufl.edu
Sat Aug 11 20:20:21 UTC 2007


Jason,

First, in re-reading, I noted that I failed to mention something: I am
not saying that Squeak freezes when networks turn ugly.  I simply
remember how hard I had to work at it the last time.  Given what I am
reading about the threading that underlies it, my scepticism is renewed
:( 

Regardless of the state of sockets in the face of adversity (aka
reality), Dolphin's overlapped call mechanism is quite useful, and might
not be too tough to add.  There are many caveats to it, such as
undocumented thread affinities, but when it works, it is _really_ nice. 
I have had very good results with it.

At the risk of becoming a broken record: my complaints about the Squeak
GUI are not about look, they are about feel.  I can sell funny looking,
but I cannot sell clumsy.

Bill




"Jason Johnson" wrote:

On 8/11/07, Bill Schwab <BSchwab at ...> wrote:
>
> >From a developer's perspective, it is a tough transition. I can work
in
> Squeak, but it is a bitter pill compared to Dolphin. From an
end-user's
> perspective, I fear that Squeak out of the box would cause mutiny. As
I
> have always said, the GUI feel the problem. I deal with busy users in
> sometimes dire circumstances. They cannot be expected to remember
> whether they have previously opened a dialog (modality can be a good
> thing). I think I would be able to design and build around some of the
> limitations.

The Dolphin GUI is very very nice to be sure. It's a real shame that
it didn't catch on more. For me it would seem like a no brainer for a
small company: An easy language to use, a fast development
environment.

> Tweak scares me a bit. The capability is fine (even great), but I have
> reservations about dragging the compiler into it. I would much rather
> see a higher level GUI editor that uses a time-aware variant of a
> traditional event system for routing. While I am no big fan of native
> widgets, I would probably opt for something like wxSqueak to force the
> point.

After the previous discussion wouldn't direct rendering be a better
option? If sig's OpenGL API turns out to be nice maybe that could be
used. What is really missing is to have the image be able to open
extra native windows. The same kind of base canvas (or what ever you
call them) windows as now, just more then one.

In a related question, how much can one legally duplicate the look of
Windows/Mac, or is there a legal problem there at all? It seems a bit
arbitrary to say that you can't make windows that look like native
windows, but you can freely call the OS to do it, no?

> I am glad to see that Andreas fixed some critical threading bugs. I am
> somewhat surprised that it took so long for them to surface. How does
> one square that with the popularity of Swikis and other server uses of
> Squeak? I would have thought they would stress the VM enough to show
> such bugs, but they apparently did not, or worse yet, the community
> largely ignored the problems??? Insights would be appreciated.

I think this was showing up on the Seaside sites from various people,
but it was non-trivial to track down.

> I am not sure how to copy with the loss(??) of Dolphin's overlapped
> threads. For those not familiar with them, Dolphin provides a way to
> mark external functions to be called on a separate OS thread such that
> only the calling Smalltalk Process is blocked. With a really good SSL
> Socket implementation, I should be able to wean from them. By really
> good, I mean that the image cannot hang when a network wire is pulled
or
> a machine or DNS entry does not exist. The calling process should
> block, but not the entire image.

I wonder how hard it would be to add this.


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

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




More information about the Squeak-dev mailing list