[KCP] Thoughts on adding system changes and refactoring ChangeSet

Andreas Raab andreas.raab at gmx.de
Wed Jun 25 09:11:39 UTC 2003


Stephen,

> Yes!  Exactly...this uncertainty principle is key...you must 
> accept up front that you can *never* be instantly notified when
> an event happens...you can only be told that some event happened
> at some point in the past.  To many systems seem to gloss over
> that fact.

I wonder why - Latency is a property of the real world and Heisenberg is
applicable to everything we do ;-)

> Yes...I agree.  A system should allow you to observe any arbitrary 
> property of any object...the key phrase is that the programmer musn't
> be burdened by it (which isn't the case with the systems to which I was 
> referring).  If a programmer has to decide up front what properties 
> someone might be interested in, then I think you lose a lot 
> (in terms of having independent systems that can be freely combined
> to create new systems).

Totally agree.

> >Do you have any first-hand experience with those problems?
>
> Yes...as best I can remember, here are some challenges that I 
> encountered:
> 
>  - process safety issues [...]

Yes, that's a real problem, or actually two. One of them is the ability to
observe a (long-) running process while it is presumably running atomically.
I don't think there's a lot which can be done here short of TeaTime (which
is one the places where I'd like to use it). The other one is the question
whether we can effectively encourage people to write "non-atomic" long
running processes by default. There are some ways of doing this, for example
encouraging event-driven loops instead of others. I haven't really
experimented with this but I think for many situations the latter might be
quite sufficient.

>  - events propogating in endless loops [...]

I think that's only a problem if programmers have to write the notifications
themselves. It's not very hard to prevent back- (or circular) propagation of
events if you think about it a little and so the architecture really ought
to support this and not require the programmer to invent it anew everytime
you use it.

BTW, there are some interesting issues with endless event propagation in
networks with conflicting constraints. I thought about it for a long time in
Tweak and then it turned out that going fully multi-threaded solved this
problem implicitly for me. Why? Because it means that each propagation link
_is_ a process - when you have an endless chain you simply hit CMD-. which
interrupts the current process (the link in the network). Even if you have
many conflicts going on at the same time you can just hit CMD-. until enough
links have been broken for the system to become responsible again. I can't
even count the number of times this saved me when I was debugging this stuff
;-)

[and now you're probably also beginning to understand why I'm so happy that
Squeak's processes are extremely lightweight and that process switches are
sooo incredibly fast]

> - tools, tools, and more tools [...]

Yes, yes, yes! ;-) Absolutely. Partly because you're taking away something
from the programmer (the ability to step directly into a response to some
message) so you really need something that helps explaining about "what the
hell is going on". Adam is currently working on a "heartbeat" for Tweak
which I imagine to become the ultimate tool for visualizing events and
explaining what is going on in the system.

> This in combination with a transactional system (each component
> could have a transactional context) enabled us to create UIs with 
> very little work and in a very short period of time.  The framework
> would allow us to open two UIs on the same system of objects and have
> every aspect of the two UIs fully synchronized (text boxes, scroll bars,
> check boxes...everything)...if you wanted to keep the two UIs in
> isolation, you simply opened them in the context of separate 
> transactions (OK and Cancel translated directly into Commit and Abort).

The point about the transactional context is interesting. Can you say a
little more about what the transactional context defined and how it was
determined? It sounds somewhat like some of the thread-local variables I'm
using in Tweak where we really want to determine various bits of information
based on the current thread we're running in (this is partly motivated by
things like the need to transfer certain state between processes; e.g., when
some user clicks on an object a response to the click may need to obtain
information about this user even in the absence of having it passed
explicitly - and since it's multi-threaded I cannot rely on static globals
so all of them must be process-bound).

Cheers,
  - Andreas



More information about the Squeak-dev mailing list