2007/8/11, Bill Schwab <BSchwab at anest.ufl.edu>:
> Some of us are already here.  I cannot speak for the others, but I have
> long viewed Squeak as one possible escape plan from Windows, and to a
> lesser extent from disappearance of Dolphin.  To be blunt, I am still
> worried in that order, though that would change over time if Dolphin
> indeed becomes unsupported.
>
> >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.
>
> 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.
>
> ANSI compatibility, or at least friendliness would be a barrier.  My
> favourite example is
> the behaviour of #next, #next:, which "silently" answer nil or truncate.
>  I think these basic reading methods should raise an error on end of
> stream, with truncating variants (#nextOrNil, #nextAvailable:) allowing
> one to be more relaxed.  I do a lot of parsing that needs to be right,
> and "want my bad news early" vs. having something blow up later with no
> clear indication of what went wrong, or worse yet, after incorrect
> results have been obtained.  I could move to my own selectors, but I
> worry about "reverting" and not getting the behaviour I expect.
>
> Underscores.  I have a lot of code that uses them.  Sorry.  I talk to
> databases that use them in field name, and field names make good choices
> for selectors.  Lots of class names too, again thanks to external
> sources.
>
> 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.

Oh they did. Like the weak array stuff does/did. Just have a look at
all those "image lockup" threads in the Seaside mailinglist and the
relevant mantis issues. There are still issues with GC settings. It is
still recommended to have more than one Squeak image per CPU in order
to reduce the amount of punishment a single Squeak image has to take.

Cheers
Philippe

> 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.
>
> Another thing that scares me a bit is printing.  I simply have not
> investigated it in Squeak, but will need to do so.
>
> That's one Dolphin user's perspective.
>
> Bill
>
>
>
>
> Igor Stasenko wrote:
>
> Hopefully, some people will join a squeak community.
>
> On 11/08/07, Chris Kassopulo <ckasso at ...> wrote:
> > http://www.object-arts.com/content/blog/2007Aug10.html
>
>
>
>
> 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
>
>
>