[Pharo-project] Exploring an event handling implementation
Hello list, it is strikes me, how complex event handling in squeak. :) I want to make it less fuzzy, but it looks like there is too much to do for achieving that. In current state, it grew out from multiple evolutionary steps - old VM has no event queue, so at language side, it has to support two ways to fetch events from VM. A key primitive which feeds an events from VM is in EventSensor>>primGetNextEvent: , which fills a provided array with 8 indices. It looks like a good point to reuse same array for fetching events, to not create new instance for each single event, right? (in EventSensor>>fetchMoreEvents) eventBuffer := Array new: 8. [self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [self processEvent: eventBuffer]. But hey.. let's look further: EventSensor>>queueEvent: evt "Queue the given event in the event queue (if any). Note that the event buffer must be copied since it will be reused later on." eventQueue ifNil:[^self]. eventQueue nextPut: evt clone. so, its avoiding creating new instance in #primGetNextEvent:, but then creating a new one later (by cloning it), e.g. instead of using single primitive which creates new instance & fill it with values, we use two primitives. Well, this strategy would be valid, if we, instead of putting raw event buffers into queue, first, decode the event and put a nice XXXXEvent instances instead. But this not happens in EventSensor, and i really disappointed and asking, why? Instead, an EventSensor puts a raw event buffers (arrays with 8 values) in queue, and then gives them away! Which means that there is not a single place in image where you should deal with cryptic values returned by VM primitive. I think, that first & most important task of event handling should be get rid of this cryptic looking array of 8 values, by deciphering them and replacing with an appropriate instances of some event, which having a good protocol & easy to manipulate/work with. Consider an easy scheme, which can deal with deciphering event buffers into a nice events: First , we can associate each kind of event with a class. There is not much of them , defined in VM /* Event types. */ #define EventTypeNone 0 #define EventTypeMouse 1 #define EventTypeKeyboard 2 #define EventTypeDragDropFiles 3 #define EventTypeMenu 4 #define EventTypeWindow 5 So, all we need to do is to have an array of eventKinds , which contains appropriate classes for each event kind. eventKinds := Array new: 5. eventKinds at: 1 put: MouseEvent. eventKinds at: 2 put: KeyboardEvent. ... then, if we want to decode an event from event buffer, we can simply do: newEvent := (eventKinds at: (eventBuffer at: 1)) decodeFrom: eventBuffer. And voila, we can play with events as we like. e.g. instead doing something cryptic like: type := eventBuffer at: 1. type == 1 ifTrue: [ ... ] we can write code in more human friendly manner: event isMouseEvent ifTrue: [. ..] As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :) P.S. I'm understand, that event handling code is born from multiple waves and being modified by different developers. And i'm appreciate their efforts, because despite the design it works! -- Best regards, Igor Stasenko AKA sig.
Igor I hope that mike will reply because normally ESUG will pay him to clean the event system. And I would love to have that integrated in pharo. Now I think that this is important to move one: Let us dream about 1 year time from now. And let us make it becoming true. I really want (this is not that fun to do) but I will do it rentlessly - remove etoys, bookmorph, (may be project ....) and then we should go to the next level, network, file, events. I know that Alien FFI is now in good hands :) So let us build a good and fun community to make this gem shine. step by step. I do not know how to call for more help but if you (guys listening) want to help please do it. Stef On Nov 15, 2008, at 1:19 PM, Igor Stasenko wrote:
Hello list,
it is strikes me, how complex event handling in squeak. :) I want to make it less fuzzy, but it looks like there is too much to do for achieving that.
In current state, it grew out from multiple evolutionary steps - old VM has no event queue, so at language side, it has to support two ways to fetch events from VM.
A key primitive which feeds an events from VM is in EventSensor>>primGetNextEvent: , which fills a provided array with 8 indices. It looks like a good point to reuse same array for fetching events, to not create new instance for each single event, right?
(in EventSensor>>fetchMoreEvents)
eventBuffer := Array new: 8. [self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [self processEvent: eventBuffer].
But hey.. let's look further:
EventSensor>>queueEvent: evt "Queue the given event in the event queue (if any). Note that the event buffer must be copied since it will be reused later on." eventQueue ifNil:[^self]. eventQueue nextPut: evt clone.
so, its avoiding creating new instance in #primGetNextEvent:, but then creating a new one later (by cloning it), e.g. instead of using single primitive which creates new instance & fill it with values, we use two primitives. Well, this strategy would be valid, if we, instead of putting raw event buffers into queue, first, decode the event and put a nice XXXXEvent instances instead. But this not happens in EventSensor, and i really disappointed and asking, why?
Instead, an EventSensor puts a raw event buffers (arrays with 8 values) in queue, and then gives them away! Which means that there is not a single place in image where you should deal with cryptic values returned by VM primitive.
I think, that first & most important task of event handling should be get rid of this cryptic looking array of 8 values, by deciphering them and replacing with an appropriate instances of some event, which having a good protocol & easy to manipulate/work with.
Consider an easy scheme, which can deal with deciphering event buffers into a nice events: First , we can associate each kind of event with a class. There is not much of them , defined in VM /* Event types. */ #define EventTypeNone 0 #define EventTypeMouse 1 #define EventTypeKeyboard 2 #define EventTypeDragDropFiles 3 #define EventTypeMenu 4 #define EventTypeWindow 5
So, all we need to do is to have an array of eventKinds , which contains appropriate classes for each event kind.
eventKinds := Array new: 5. eventKinds at: 1 put: MouseEvent. eventKinds at: 2 put: KeyboardEvent. ...
then, if we want to decode an event from event buffer, we can simply do:
newEvent := (eventKinds at: (eventBuffer at: 1)) decodeFrom: eventBuffer.
And voila, we can play with events as we like. e.g. instead doing something cryptic like:
type := eventBuffer at: 1. type == 1 ifTrue: [ ... ]
we can write code in more human friendly manner:
event isMouseEvent ifTrue: [. ..]
As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :)
P.S. I'm understand, that event handling code is born from multiple waves and being modified by different developers. And i'm appreciate their efforts, because despite the design it works!
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Is somebody working on Alien for Pharo?I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses? -david On Sat, Nov 15, 2008 at 6:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I know that Alien FFI is now in good hands :)
John is working on it. On Nov 15, 2008, at 3:12 PM, David Pennell wrote:
Is somebody working on Alien for Pharo? I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
-david
On Sat, Nov 15, 2008 at 6:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I know that Alien FFI is now in good hands :) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 15.11.2008, at 15:12, David Pennell wrote:
Is somebody working on Alien for Pharo? I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
It's Apache licensed. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Igor Stasenko wrote:
As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :)
Tell me about it. I have something 80% finished, hope to have it ready for testing really soon now :-) It's always the 20% that gets you... Michael
excellent excellent! Let us know we will be really happy to integrate all that good energy in pharo (definitively a cool name). Stef
Igor Stasenko wrote:
As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :)
Tell me about it.
I have something 80% finished, hope to have it ready for testing really soon now :-) It's always the 20% that gets you...
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/15 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :)
Tell me about it.
I have something 80% finished, hope to have it ready for testing really soon now :-) It's always the 20% that gets you...
Good to hear. I'm currently trying to do something with VM part of it, to support multiple host windows and a clear way how language side can control it. But this will require changing an event dispatching scheme. Currently the events going in following way: EventSensor -> HandMorph , or even worse, consumed directly by different code. If you wanna look how easy to consume the VM event, just look at HandMorph>>processEvents (sarcasm). Instead, i suggest that events should go in different route: EventSensor -> HostWindow instance -> subscriber(s). A HostWindow instance does not know anything about subscriber(s). So it can be a HandMorph, or something else (if one wants to use a non-morphic framework, we should allow it). It is important to handle event by HostWindow at first place, because some events, obviously, will be specific to host window (like window closing notification, or window activation/deactivation). It is good, that the there is not much senders of #nextEvent , a most importrant one is HandMorph, but there is a number messy code which deals with raw event buffers spread among different XXXXXInputInterpreter classes in Multilingual-TextConversion category. I'm sure there is a number of other places like this. As i mentioned, it is highly inefficient and inhumane to force people dealing with raw event buffers with their cryptic stuff (if someone want to argue - just take a look at #nextCharFrom:firstEvt: implementations). I can't imagine how much patience people had to write up this code. And i can't imagine one who may want to fix it, if there is a bug :) I missed the discussion and was not aware that you are rewriting the events. Michael , can you, please , give me a pointers where i can read about new events design? Also, if you have some code to download, may i take a look at it? I want to know how i can integrate my stuff with it.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2008/11/15 Marcus Denker <denker@iam.unibe.ch>:
On 15.11.2008, at 15:12, David Pennell wrote:
Is somebody working on Alien for Pharo? I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
It's Apache licensed.
Mind i ask, why do we need alien Alien FFI library, especially which comes with non-MIT license? Is there something wrong with current FFI implementation, and is there any comparison to tell which one is better and why? The most heavyweight part of any foreign function interface is coercion of values. I don't think that Alien knows anything about squeak's object memory model and its objects - so you have to write own. The rest part of FFI - how an actual call made is quite unimportant. I had to touch an FFI plugin for Hydra, and changed few instructions, which made it run faster than original FFI on regular squeak VM. It can be optimized even further to use stack-allocated buffer for pushing arguments, to populate values directly on stack instead of collecting them into buffer and then pushing on stack, like currently done. But there's not much can be done with coercing stuff - you can't avoid converting values back and forth, this what makes FFI slow.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
Instead, i suggest that events should go in different route: EventSensor -> HostWindow instance -> subscriber(s).
A subscriber model is part of my design, allowing for pluggable event architectures actually. I'm not going to change the current Morphic event handling itself, that would require rewriting most of the system. I will publish code as soon as I can make it load and run somewhat safely. Swapping out the event handling is, let's say, interesting ;-) Reagarding another suggestion in an earlier mail, I don't think the event object creation should be in the VM. The raw, barebones event structure is the most flexible, anything else can and should be handled in the image. More on that later. Michael
2008/11/15 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
Instead, i suggest that events should go in different route: EventSensor -> HostWindow instance -> subscriber(s).
A subscriber model is part of my design, allowing for pluggable event architectures actually. I'm not going to change the current Morphic event handling itself, that would require rewriting most of the system.
Heh :)
I will publish code as soon as I can make it load and run somewhat safely. Swapping out the event handling is, let's say, interesting ;-)
Reagarding another suggestion in an earlier mail, I don't think the event object creation should be in the VM. The raw, barebones event structure is the most flexible, anything else can and should be handled in the image.
I'm ok with it. What i hate to see is the countless places dealing with bare bones instead of single place which converts this stuff into a nice wrappings with simple and understandable behavior/protocol - so you can easily extract any bit of information from event in human friendly manner and forget about using bare event buffers at all.
More on that later.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Good to hear. I'm currently trying to do something with VM part of it, to support multiple host windows and a clear way how language side can control it. But this will require changing an event dispatching scheme. Currently the events going in following way: EventSensor -> HandMorph , or even worse, consumed directly by different code. If you wanna look how easy to consume the VM event, just look at HandMorph>>processEvents (sarcasm).
I heard a lot of gory stories about this part of Squeak so I imagine :)
Instead, i suggest that events should go in different route: EventSensor -> HostWindow instance -> subscriber(s).
A HostWindow instance does not know anything about subscriber(s). So it can be a HandMorph, or something else (if one wants to use a non-morphic framework, we should allow it).
Yes this is really important not to be tied with Morphic.
It is important to handle event by HostWindow at first place, because some events, obviously, will be specific to host window (like window closing notification, or window activation/deactivation).
It is good, that the there is not much senders of #nextEvent , a most importrant one is HandMorph, but there is a number messy code which deals with raw event buffers spread among different XXXXXInputInterpreter classes in Multilingual-TextConversion category. I'm sure there is a number of other places like this.
As i mentioned, it is highly inefficient and inhumane to force people dealing with raw event buffers with their cryptic stuff (if someone want to argue - just take a look at #nextCharFrom:firstEvt: implementations). I can't imagine how much patience people had to write up this code. And i can't imagine one who may want to fix it, if there is a bug :)
I missed the discussion and was not aware that you are rewriting the events. Michael , can you, please , give me a pointers where i can read about new events design? Also, if you have some code to download, may i take a look at it? I want to know how i can integrate my stuff with it.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Igor Stasenko wrote:
I'm ok with it. What i hate to see is the countless places dealing with bare bones instead of single place which converts this stuff into a nice wrappings with simple and understandable behavior/protocol - so you can easily extract any bit of information from event in human friendly manner and forget about using bare event buffers at all.
That's what I'm trying to do :-) Michael
Is somebody working on Alien for Pharo? I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
It's Apache licensed.
Mind i ask, why do we need alien Alien FFI library, especially which comes with non-MIT license? Is there something wrong with current FFI implementation, and is there any comparison to tell which one is better and why?
I'm not good enough about the details but eliot was not talking about the current with more than "prototype" implementation
The most heavyweight part of any foreign function interface is coercion of values. I don't think that Alien knows anything about squeak's object memory model and its objects - so you have to write own. The rest part of FFI - how an actual call made is quite unimportant.
send an email to eliot directly. Gilad was not either describing the squeak one with nice terms :)
I had to touch an FFI plugin for Hydra, and changed few instructions, which made it run faster than original FFI on regular squeak VM. It can be optimized even further to use stack-allocated buffer for pushing arguments, to populate values directly on stack instead of collecting them into buffer and then pushing on stack, like currently done. But there's not much can be done with coercing stuff - you can't avoid converting values back and forth, this what makes FFI slow.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Is somebody working on Alien for Pharo? I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
It's Apache licensed.
Mind i ask, why do we need alien Alien FFI library, especially which comes with non-MIT license? Is there something wrong with current FFI implementation, and is there any comparison to tell which one is better and why?
I'm not good enough about the details but eliot was not talking about the current with more than "prototype" implementation
The most heavyweight part of any foreign function interface is coercion of values. I don't think that Alien knows anything about squeak's object memory model and its objects - so you have to write own. The rest part of FFI - how an actual call made is quite unimportant.
send an email to eliot directly. Gilad was not either describing the squeak one with nice terms :)
Ah, i thought you talking about different implementation. I hear about Eliot's plans to make a better FFI, but didn't heard that its having a name - Alien.
I had to touch an FFI plugin for Hydra, and changed few instructions, which made it run faster than original FFI on regular squeak VM. It can be optimized even further to use stack-allocated buffer for pushing arguments, to populate values directly on stack instead of collecting them into buffer and then pushing on stack, like currently done. But there's not much can be done with coercing stuff - you can't avoid converting values back and forth, this what makes FFI slow.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Yes, but... what about the Apache license? On Sat, Nov 15, 2008 at 8:17 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
John is working on it.
On Nov 15, 2008, at 3:12 PM, David Pennell wrote:
Is somebody working on Alien for Pharo?
I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
-david
On Sat, Nov 15, 2008 at 6:45 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
I know that Alien FFI is now in good hands :) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17.11.2008, at 03:08, David Pennell wrote:
Yes, but... what about the Apache license?
large parts of pharo are already apache L now... (everything coming from apple) Marcus
On Sat, Nov 15, 2008 at 8:17 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: John is working on it.
On Nov 15, 2008, at 3:12 PM, David Pennell wrote:
Is somebody working on Alien for Pharo? I've been meaning to ask about how Pharo will handle the non-MIT (Apache) license of Alien. Do we have a list of friendly/compatible licenses?
-david
On Sat, Nov 15, 2008 at 6:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I know that Alien FFI is now in good hands :) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On 16-Nov-08, at 10:49 PM, Marcus Denker wrote:
On 17.11.2008, at 03:08, David Pennell wrote:
Yes, but... what about the Apache license?
large parts of pharo are already apache L now... (everything coming from apple)
Marcus
Clarification about the swirl of licenses is at http://www.squeak.org/SqueakLicense/?version=1
participants (6)
-
David Pennell -
Igor Stasenko -
John M McIntosh -
Marcus Denker -
Michael Rueger -
Stéphane Ducasse