- 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: > >> 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(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 Michael Rueger

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

Nov. 15, 2008

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

by Igor Stasenko

2008/11/15 Marcus Denker <denker(a)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(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > 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 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