[self-interest] Re: event system

[shaping at bigfoot.com]

----- Original Message -----
From: Jecel Assumpcao Jr <jecel at lsi.usp.br>
To: <shaping at bigfoot.com>
Cc: <self-interest at egroups.com>
Sent: Wednesday, April 07, 1999 8:50 PM
Subject: Re: event system


> shaping at bigfoot.com wrote:
> > This sounds reasonable, but I was thinking at a somewhat higher,
> > widget-component-connectivity level.  Jecel, please study the
signal/slot
> > architecture used by Troll Tech (http://www.troll.no/products/qt.html).
I
> > want to avoid C++ at all costs, but the basic idea has nothing to do
with
> > that language.  I think their signal/slot pattern can be adapted to
Self,
> > where it would be more readable and run at comparable or faster speeds.
> > Please let me now what you think.
>
> To me, it looks just like the variant of the dependency mechanism
> (the "observer pattern") used in the Smalltalk V user interface.
> The names of the things are very different, but the end result
> is quite the same. It would be equivalent of the "push" part of
> of my event system proposal. You don't need anything special for
> the "pull" part - normal message sends work just fine. And you
> can do a user interface with just "push" (you don't need to
> poll for 'cursorPosition' if you handle all the 'mouseMoved'
> events fast enough).
>
> > > [slices idea]
> >
> > Yes, good idea, but I don't see clearly how to implement it.  We
definitely
> > need the power of "class controls all instances" but without classes
proper
> > (or conventional).  I'm not fluent enought yet with Self to be of much
help
> > now, in this regard.
>
> If you are asking how you can do something like Smalltalk's
> "aClass allInstances" in Self, no problem - there are methods to
> enumerate certain collection of objects, like all the children of
> a certain traits object.

I was referring to easily controlling/changing a single feature of a related
group of related instances without a lot of leg work.  Essentially, how do
we factor behavior and structure in Self?
>
> > So, why again are we not implementing Self or tinySelf on Squeak just to
> > test out some of these ideas?  I would love to do that.  We have good
> > imaginations, but they are not that good, and we all know that.  We need
to
> > do some real programming and bump into some real walls.  Do you think
the
> > Squeak implementation of Self is not worth the effort based on where
your
> > progress stands on tinySelf?
>
> Actually, I am going to throw away the current tinySelf when it
> is done (it is just a test for the parallelism model), so the tinySelf
> that will run on PCs hasn't even been started yet. If Squeak's new
> Jitter2 works out it might be worth doing a Self on top of that. I
> think we need the speed of a compiler in the runtime system so we
> don't have to mess with translating parts of applications to C and
> convert them to primitives.

Speaking of converting to C, someone is now working on a similar idea but
with Objective-C.  That's better, but I would still rather have just one
language.
>
> > > ----------------------------------------------------------------
> > > [event system graph]
> > > ----------------------------------------------------------------
> >
> > This looks like it has merit, but seems a little vague.  Can someone
give me
> > an event-by-even, object-by-object contrived scenario that illustates
how
> > these push-pull buffers/pumps might work.   From the description, I'm
not
> > certain whether graph nodes are objects like keyboard and mouse, or
event
> > queues of some sort.
>
> Keyboards don't exist - only a series of queues:
>
>   - a microcontroller checks for contacts, debounces, converts to
>     scan codes and places them in a 16 entry FIFO
>   - another routine in the same microcontroller grabs the scan codes
>     from the FIFO and sends them along some serial interface (PS/2,
>     USB or RS232)
>   - a keyboard driver in the PC is interrupted by the serial interface
>     and places the scan codes in a system FIFO
>   - some GUI code reads the system FIFO an generates events that are
>     put in a queue after translating some scan codes and transforming
>     others into state (shift, caps lock, control) instead
>   - some other part of the GUI reads these key events from the queue
>     and, working with some character output device, takes care of
>     editing commands (backspace, etc) and folding the state back
>     into the events ("shift" + "a" = "A")
>
> My whole point is that many applications just want their edited ASCII,
> but all the other stops in this journey could be useful for other
> applications. And imagine you have two keyboards: the one embedded in
> your laptop and a PS/2 one you plug in at work. You would have two
> such string of FIFOs and a multiplexer somewhere to merge their events
> into a single queue. So if you just want what the user typed no
> matter where, then you can have it. If you want to treat the two
> keyboards differently (how about a two player game?), you should be
> able to do so too.

When you merge the events into a single queue, I suppose they are somehow
tagged as belonging to different keyboards.  Yes?

Thanks for the low-level mechanical details, but what then is the graph for?
Why not just use a collection of queues for various devices generating and
accepting streams of data?

>
> Things are even more fun with mice and stuff.
>
> > Didn't I see someone else on the Web working on a Squeak implementation
of
> > Self?  A company I think.
>
>   http://www.appliedreasoning.com/goodies/squeak/self/selfSqueak.html

That's it.



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/self-interest
Free Web-based e-mail groups by eGroups.com