November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Exploring an event handling implementation

by Igor Stasenko

2008/11/15 Michael Rueger <m.rueger(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 15, 2008

Re: [Pharo-project] Exploring an event handling implementation

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 15, 2008

Re: [Pharo-project] Exploring an event handling implementation

by Michael Rueger

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

Nov. 15, 2008

Re: [Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by Antoine Marot

No I can't... So I guess ByteSurgeon (or its installation) is the problem here. Marcus> Do you have any idea about this ? Antoine Le 14-nov.-08 Ã 21:35, StÃ©phane Ducasse a Ã©crit : > In 3.9 you can wrap it with bytesurgeon? > > Stef > > On Nov 14, 2008, at 9:16 PM, Antoine Marot wrote: > >> For now it works fine on other methods. That's why I don't get what >> the problem might be. >> >> Unfortunately, my project requires to be able to wrap any method >> and to instrument it with ByteSurgeon. >> >> >> Antoine >> >> >> Le 14-nov.-08 Ã 20:57, StÃ©phane Ducasse a Ã©crit : >> >>> can you try on something less sensitive than copyFrom:to: to debug >>> it? >>> >>> Stef >>> >>> On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote: >>> >>>> Hi all, >>>> >>>> I have a very strange bug when I use method wrappers. >>>> >>>> Here is my wrapper code (actually it does nothing but calling the >>>> method) : >>>> >>>> ProtoObject variableSubclass: #Wrapper >>>> instanceVariableNames: 'compiledMethod' >>>> classVariableNames: '' >>>> poolDictionaries: '' >>>> category: 'Wrapper-Core' >>>> >>>> Wrapper>>#doesNotUnderstand: aMessage >>>> ^aMessage sendTo: compiledMethod >>>> >>>> Wrapper>>#run: aSymbol with: arguments in: rec >>>> ^rec >>>> withArgs: arguments >>>> executeMethod: compiledMethod >>>> >>>> Wrapper>>#compiledMethod: c >>>> compiledMethod:=c. >>>> ^self >>>> >>>> >>>> Now I want to execute this : >>>> >>>> SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper >>>> new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). >>>> >>>> >>>> It works fine with a new pharo-dev image. >>>> But if I install ByteSurgeon before that, it crashes the VM if I >>>> click on the workspace for instance. >>>> >>>> I just don't know what possibly happen, any help would be very >>>> appreciated :) >>>> >>>> >>>> Regards, >>>> >>>> Antoine >>>> >>>> ------ >>>> Antoine Marot >>>> Ph.D Student >>>> UniversitÃ© Libre de Bruxelles >>>> DÃ©partement d'Informatique >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 15, 2008

Re: [Pharo-project] Exploring an event handling implementation

by Marcus Denker

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(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 15, 2008

Re: [Pharo-project] Exploring an event handling implementation

by StÃ©phane Ducasse

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(a)inria.fr > > wrote: > > I know that Alien FFI is now in good hands :) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 15, 2008

Re: [Pharo-project] Exploring an event handling implementation

by David Pennell

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(a)inria.fr > wrote: > > I know that Alien FFI is now in good hands :)

Nov. 15, 2008

Re: [Pharo-project] Exploring an event handling implementation

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 15, 2008

[Pharo-project] Exploring an event handling implementation

by Igor Stasenko

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.

Nov. 15, 2008

Re: [Pharo-project] Nitpicking regarding spelling. Sorry

by Igor Stasenko

hehe.. sometimes people use words with close sounding (but with different meaning) to indicate that things which they should deal with is, of course a common one, but at the same time, in this case it is really hard & stressfull one :) 2008/11/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > but now I would say > > carve etoy up informal slash someone with a knife or other sharp > object. > > carve etoy up divide something ruthlessly into separate areas. > > > > > On Nov 15, 2008, at 8:03 AM, StÃ©phane Ducasse wrote: > >> >> On Nov 15, 2008, at 1:37 AM, Matthew Fulmer wrote: >> >>> On Fri, Nov 14, 2008 at 10:18:30PM +0100, St?phane Ducasse wrote: >>>> >>>> Hi all >>>> >>>> I continued to curved out etoy. >>> >>> Just curious. Do you mean you are "carving" out etoys? curving >>> seems to be the wrong word, but you keep using it >> >> Apparently >> So this is carving >> to carve something out >> take something from a larger whole, esp. with >> difficulty >> if fits perfectly. >>> >>> -- >>> Matthew Fulmer -- http://mtfulmer.wordpress.com/ >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 15, 2008