Gary,
I am having some trouble envisioning #synchronize: - I tend to think in terms of shared resources identified by/with a mutex, or something along those lines. Being a process junkie, I look forward to seeing what you have done.
Could I interest you in more cross-dialect-friendly stream semantics? IMHO, once you have an exception catch a format deviation "now vs. later," you'll be hooked. No hard feelings if you decide to stick with Squeaky streams.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@btinternet.com 11/20/07 1:15 PM >>>
We have some extensions along the lines of "self synchronize: [aBlock]"... which was why the semaphore stuff was important. I guess we'll (Pinesoft) get some time to release these things too...
Go for it with Streams, personally I still use them in the "traditional" sense, quirks and all!
As for (presentation) platforms it will be some work to provide a flexible and pertinent layer for that...
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 20 November 2007 5:08 PM To: ui@lists.squeakfoundation.org Subject: RE: [UI] Re: MenuMorph hand weirdness
Gary,
MVP indeed predates OA's work, but I have to walk a fine line of
making
something compatible and untainted. I do not think I can serve as a coder on a clean version. Tests I can write and distribute.
As for you starting at the bottom and me at the top, that's perfect! You clearly have great skill at graphical coding, and have a lot of
MVP
work that can stress test my (non-existent, so far) MVP framework; I also have meta data->code translators that can push it. A design goal should be to allow the view hierarchy to change; OA anticipated that, and it makes sense to continue and extend it. If the effort succeeds, we can begin work on a clean room version knowing that success is possible.
3.9 it is. I am very pleased to see you also using processes. The first tangible system I would be likely to port is a serial communication multiplexer. It makes heavy use of streams[*], and arguably heavy use of processes. The latter is murky to me, as my earliest evaluations of Squeak included a reality check on the
scheduler
and synchronization; at the time people reported dwarfing my requirements without problems. The more recent "fix this or we switch to Java" discussions were unsettling, though you reported having improved results with the resulting patches.
[*] I would very much like to put teeth into EndOfStream. I might
even
see how to do it. As I see it, silent truncation by #next: is an accident waiting to happen, and exception handling is the answer. The problem would be getting it accepted.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@btinternet.com 11/20/07 10:06 AM >>>
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill
Schwab
Sent: 20 November 2007 2:44 PM To: ui@lists.squeakfoundation.org Subject: RE: [UI] Re: MenuMorph hand weirdness
Gary,
In terms of describing an interface, I immediately zoom out to the
two
ways one might approach it: graphical editing, and writing code.
The
nature of the GUI editor and the language are "just details." IMHO, both methods are essential for happy programmers. I have some GUI generating/translating tools that I would expect to port to whatever Smalltalk system I end up using; they speak MVP. If I land in
Squeak,
it will have an MVP framework, if only because I will write one out
of
frustration :)
a concise (programmatic) construction framework would be nice as a basis for graphical tools. Code generation-reintegration is, IMHO, more flexible and explict than live prototypes. It is alway good to know that there
is
a basis for recreating a (specific) UI for a system. Similar to the concept of the image, good to know that it can (essentially) be regenerated if corruption problems occur.
As I have mentioned before, I am concerned that any MVP work I do
would
be tainted with Object Arts' intellectual property. However, if I create a framework (tainted) and my own tests for it (by definition clean - right???), then the tests could be the basis for a clean MVP framework for Squeak. Any flaws? It is a lot of wasted work to
write
and then have someone else rewrite a framework, but it might solve
the
problem. At least the rewrite would occur with the benefit of
tests.
MVP, as I remember, predates Dolphin in research terms...
With some cleverness, Morphs as views, native widgets, SVG, etc.,
are
hopefully just different types of views in the framework.
Indeed, though a mechanism (call it a theme or configuration perhaps) to bind a coherent set of things together will help. If things are cross-pluggable then it should be easy to mix-n-match to suit any
need.
As a practical matter, I have a few too many Squeak images for my
own
good. I need to archive them all, mine code out of them, and create
one
image that will move back and forth between Linux and Windows. Any thoughts on 3.9 vs. 3.10? For 3.9, I would want the delay/queue/semaphore fixes; IIRC, those are included in 3.10??
Bill
Since I'm currently working on deployment to customers I'll be sticking with 3.9 (fixes applied) for the moment. Others in the office are on
the
3.10 dev beta images. Once our release is stable we'll migrate to 3.10 in the background, I don't forsee any real problems, not the right time
to
abandon 3.9 for our deliverables just yet.
Found another process related bug i may have to air in the dev list. Looks like Process>>isTerminated is not thread safe/and/or correct. Have has instances where a live process has responded "true" to isTerminated, briefly! (we are using quite a few processes at various priorities - preemption bites!)
For me, for a fresh start, I'd like to start at "the bottom", basic drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet halfway...
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui