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

Re: [Pharo-project] Issue 333 fix ready for harvesting

by StÃ©phane Ducasse

BTW can you ask jerome to sign the agreement? Stef On Nov 15, 2008, at 9:33 PM, Torsten Bergmann wrote: > Issue ID 333 is fixed [1]. The mcz with version 68 for the Graphics > package in > the pharo inbox can be harvested. > > If you want to try yourself load the GIF [2] before and after > applying the > fix. Thanks to Jerome Peace [3]. > > Bye > Torsten > > [1] http://code.google.com/p/pharo/issues/detail?id=333 > [2] http://www.mathconsult.ch/showroom/unipoly/anim24.gif > [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132428… > > > > > -- > "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 16, 2008

Re: [Pharo-project] Issue 333 fix ready for harvesting

by StÃ©phane Ducasse

Thanks! We will harvest that then. Stef On Nov 15, 2008, at 9:33 PM, Torsten Bergmann wrote: > Issue ID 333 is fixed [1]. The mcz with version 68 for the Graphics > package in > the pharo inbox can be harvested. > > If you want to try yourself load the GIF [2] before and after > applying the > fix. Thanks to Jerome Peace [3]. > > Bye > Torsten > > [1] http://code.google.com/p/pharo/issues/detail?id=333 > [2] http://www.mathconsult.ch/showroom/unipoly/anim24.gif > [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132428… > > > > > -- > "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 16, 2008

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

by Igor Stasenko

2008/11/15 StÃ©phane Ducasse <stephane.ducasse(a)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(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. >> >> _______________________________________________ >> 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

[Pharo-project] Issue 333 fix ready for harvesting

by Torsten Bergmann

Issue ID 333 is fixed [1]. The mcz with version 68 for the Graphics package in the pharo inbox can be harvested. If you want to try yourself load the GIF [2] before and after applying the fix. Thanks to Jerome Peace [3]. Bye Torsten [1] http://code.google.com/p/pharo/issues/detail?id=333 [2] http://www.mathconsult.ch/showroom/unipoly/anim24.gif [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132428… -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

Nov. 15, 2008

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

by StÃ©phane Ducasse

>> >> >>> 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(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. > > _______________________________________________ > 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: > 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

Nov. 15, 2008

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

by StÃ©phane Ducasse

> > 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(a)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(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 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