[self-interest] Re: event system

[Jecel Assumpcao Jr]

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.

> 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.

> > ----------------------------------------------------------------
> > [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.

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

It doesn't seem to be moving forward (unlike their neat DOS port),
though I am the last person who can complain about that, right?

-- Jecel


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