- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by StÃ©phane Ducasse

I saw Add multi-touch gesture recognizers ClutterPanAction, ClutterZoomAction, and ClutterRotateAction are gesture recognizers that can be used to detect common multi-touch gestures. The ClutterGestureAction class has been modified to make it easy to create new gesture recognizers. And I'm curious to know how they do it because one of these days we will have :) Stef On Sep 24, 2013, at 10:42 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > I agree, Morphic is quite messy but its design is very solid. Its just like > any huge library need to go under a cleanup phase and be improved. > > I checked to find out if QT can be accessed from C , the short answer is no. > So move along nothing to see here. > > I dont know what you mean by "export the functionality to C functions" if > that means rewriting code from C++ to C , then I will have to pass, QT is > huge , even if we utilized the whole pharo community we would not be able to > do this. I think focusing on morphic and existing functionality of Mars will > do for now. > > The way I see it best candidate so far is GTK. Not so good on windows and > macos , but better than having to maintain separate classes for windoom , > macos and linux. And I am not even sure if there many pharoers on windoom > anyway, I rarely see it mentioned here. > > Another interesting candidate is Clutter , its based on Opengl , its a C > library and seems to even support OpenGL ES for mobile platform and of > course compiles on windooom, macos and linux . > > http://en.wikipedia.org/wiki/Clutter_(toolkit) > <http://en.wikipedia.org/wiki/Clutter_(toolkit)> > > I also heard its quite small and easy to use , so maybe morphic could be > based on it. I have not used it myself so I cant vouch for it. > > > Sean P. DeNigris wrote >> >> kilon wrote >>> And the fact that Morphic is written in smalltalk and not just another C >>> library, is hard to beat for customization >> When one wants to do something non-standard, Morphic is insanely powerful. >> The only issue I have is cleaning and refactoring. I think the underlying >> idea is brilliant. >> kilon wrote >>> The only problem is that QT is a C++ library and AFAIK pharo FFIs do not >>> support C++ libraries because of name mangling. >> You have to export the functionality you want to use as C functions. Not >> that hard, but I've only tried it for proof-of-concepts > > > > > > -- > View this message in context: http://forum.world.st/New-Mars-examples-Package-Browser-and-Test-Runner-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 24, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by Camillo Bruni

On 2013-09-24, at 17:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 24 Sep 2013, at 22:23, kilon <thekilon(a)yahoo.co.uk> wrote: > >> Actually it works its just that is not meant to create a progress bar. >> >> To create a progressbar I created a new test >> >> testProgressBar >> UIManager default informUserDuring: [ :bar | >> [ ^ ZnClient new >> signalProgress: true; >> get: 'http://zn.stfx.eu/echo?delay=2' ] >> on: HTTPProgress >> do: [ :progress | >> bar label: progress printString. >> progress isEmpty ifFalse: [ bar current: progress percentage ]. >> progress resume ] ] >> >> it displays the progressbar , but it displays no progress (blue bar thing) >> and it close as soon as it finish the get. I tried to implement that in >> >> createImageFromTemplate >> | name | >> name := UIManager default request: 'Image name?'. >> self showDownloadInProgress. >> [UIManager default informUserDuring: [ :bar | >> [ imageGroup extractTemplate: self selectedTemplate to: name] >> on: HTTPProgress >> do: [ :progress | >> bar label: progress printString. >> progress isEmpty ifFalse: [ bar current: progress percentage ]. >> progress resume ] ]] on: PhLDownloadError >> do: [ :err | >> UIManager default alert: err longDescription. >> ^ self ]. >> >> >> self updateAll. >> >> I assume that code is deeply flawed , hence why it does not display me any >> progressbar at all. Looks like I have a lot to learn. >> >> First I am not sure if ZnClient downloads in packets and if it reports >> progress per packet . If its progress is upon success of download then it >> does not help at all , because in that case there will be only one stage of >> progress upon success of download. I want multiple stages of progress so the >> download bar increases from 0% to 100%(preferably per kb ). IF that is the >> cace then probably I will be better using the HTTP client of monticello to >> download the images which I know it works that way. >> >> Is there a particular reason why we should stick to Zinc ? > > The HTTP client of Monticello _is_ ZnClient, see MCHttpRepository>>#httpClient ;-) > > Now, for performance reasons, progress in only signalled every ZnUtils class>>#streamingBufferSize which is currently 16K. > > Apart from that, the download might go that fast that there is little to show. > > I am certainly not claiming that the HTTPProgress stuff is perfect, but it seems to work. ... and the progress bar certainly much further away from that goal :)

Sept. 24, 2013

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by Esteban Lorenzano

er... of course Mars is designed to alllow the backend you want to plug in, but we thinkthat Gtk3 is ok for Linux and good enough for Windows. For OSX we have the Cocoa backend. So I do not understand this line of argument :) Esteban On Tue, Sep 24, 2013 at 10:42 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > I agree, Morphic is quite messy but its design is very solid. Its just like > any huge library need to go under a cleanup phase and be improved. > > I checked to find out if QT can be accessed from C , the short answer is > no. > So move along nothing to see here. > > I dont know what you mean by "export the functionality to C functions" if > that means rewriting code from C++ to C , then I will have to pass, QT is > huge , even if we utilized the whole pharo community we would not be able > to > do this. I think focusing on morphic and existing functionality of Mars > will > do for now. > > The way I see it best candidate so far is GTK. Not so good on windows and > macos , but better than having to maintain separate classes for windoom , > macos and linux. And I am not even sure if there many pharoers on windoom > anyway, I rarely see it mentioned here. > > Another interesting candidate is Clutter , its based on Opengl , its a C > library and seems to even support OpenGL ES for mobile platform and of > course compiles on windooom, macos and linux . > > http://en.wikipedia.org/wiki/Clutter_(toolkit) > <http://en.wikipedia.org/wiki/Clutter_(toolkit)> > > I also heard its quite small and easy to use , so maybe morphic could be > based on it. I have not used it myself so I cant vouch for it. > > > Sean P. DeNigris wrote > > > > kilon wrote > >> And the fact that Morphic is written in smalltalk and not just another C > >> library, is hard to beat for customization > > When one wants to do something non-standard, Morphic is insanely > powerful. > > The only issue I have is cleaning and refactoring. I think the underlying > > idea is brilliant. > > kilon wrote > >> The only problem is that QT is a C++ library and AFAIK pharo FFIs do not > >> support C++ libraries because of name mangling. > > You have to export the functionality you want to use as C functions. Not > > that hard, but I've only tried it for proof-of-concepts > > > > > > -- > View this message in context: > http://forum.world.st/New-Mars-examples-Package-Browser-and-Test-Runner-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 24, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by Sven Van Caekenberghe

On 24 Sep 2013, at 22:23, kilon <thekilon(a)yahoo.co.uk> wrote: > Actually it works its just that is not meant to create a progress bar. > > To create a progressbar I created a new test > > testProgressBar > UIManager default informUserDuring: [ :bar | > [ ^ ZnClient new > signalProgress: true; > get: 'http://zn.stfx.eu/echo?delay=2' ] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ] > > it displays the progressbar , but it displays no progress (blue bar thing) > and it close as soon as it finish the get. I tried to implement that in > > createImageFromTemplate > | name | > name := UIManager default request: 'Image name?'. > self showDownloadInProgress. > [UIManager default informUserDuring: [ :bar | > [ imageGroup extractTemplate: self selectedTemplate to: name] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ]] on: PhLDownloadError > do: [ :err | > UIManager default alert: err longDescription. > ^ self ]. > > > self updateAll. > > I assume that code is deeply flawed , hence why it does not display me any > progressbar at all. Looks like I have a lot to learn. > > First I am not sure if ZnClient downloads in packets and if it reports > progress per packet . If its progress is upon success of download then it > does not help at all , because in that case there will be only one stage of > progress upon success of download. I want multiple stages of progress so the > download bar increases from 0% to 100%(preferably per kb ). IF that is the > cace then probably I will be better using the HTTP client of monticello to > download the images which I know it works that way. > > Is there a particular reason why we should stick to Zinc ? The HTTP client of Monticello _is_ ZnClient, see MCHttpRepository>>#httpClient ;-) Now, for performance reasons, progress in only signalled every ZnUtils class>>#streamingBufferSize which is currently 16K. Apart from that, the download might go that fast that there is little to show. I am certainly not claiming that the HTTPProgress stuff is perfect, but it seems to work. > I am open to suggestions :) > > > Sven Van Caekenberghe-2 wrote >> On 24 Sep 2013, at 15:18, kilon < > >> thekilon@.co > >> > wrote: >> >>> ah yes of course. Ok thanks for adding me. >>> >>> I took a look at the code, it points back to Zinc , it look like I would >>> need to override ZnClient >> withProgressDo: , no Idea how to do this >>> currently but will continue looking into . I also found how monticello >>> uses >>> progress bars when downloading repos but it does not seem to use Zinc at >>> all. So yeah this will take me quite some time to implement. >> >> Progress is indicated by HTTPProgress Notification that are being >> signalled by the underlying code. You have to catch them and do something >> with them. >> >> Have a look at ZnClientTests>>#testProgress >> >> Although the example in the comment does no longer seem to work... >> >>> Its Fun none the less ;) >>> >>> >>> >>> Damien Cassou wrote >>>> On Tue, Sep 24, 2013 at 1:21 PM, kilon < >>> >>>> thekilon@.co >>> >>>> > wrote: >>>>> yeah I will give it a try, don't know how long will take me but I like >>>>> what >>>>> you have done with Pharo Launcher. I will create an enhancement issue >>>>> when I >>>>> have it working as I want and report back. Esteban has granted me >>>>> commit >>>>> right to pharo 3 inbox too so I will commit there. Or do you want me to >>>>> contribute directly to smalltalk hub repo ? >>>>> >>>>> I am new with pharo and morphic so please bare with me :) >>>> >>>> >>>> the Pharo3Inbox is only for code integrated in Pharo itself. The >>>> launcher won't be integrated in Pharo. I added you to the project >>>> http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher >>>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> "Success is the ability to go from one failure to another without >>>> losing enthusiasm." >>>> Winston Churchill >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/ANN-Launching-Pharo-on-Ubuntu-tp4709757p4710044.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> > > > > > > -- > View this message in context: http://forum.world.st/ANN-Launching-Pharo-on-Ubuntu-tp4709757p4710146.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 24, 2013

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by kilon

I agree, Morphic is quite messy but its design is very solid. Its just like any huge library need to go under a cleanup phase and be improved. I checked to find out if QT can be accessed from C , the short answer is no. So move along nothing to see here. I dont know what you mean by "export the functionality to C functions" if that means rewriting code from C++ to C , then I will have to pass, QT is huge , even if we utilized the whole pharo community we would not be able to do this. I think focusing on morphic and existing functionality of Mars will do for now. The way I see it best candidate so far is GTK. Not so good on windows and macos , but better than having to maintain separate classes for windoom , macos and linux. And I am not even sure if there many pharoers on windoom anyway, I rarely see it mentioned here. Another interesting candidate is Clutter , its based on Opengl , its a C library and seems to even support OpenGL ES for mobile platform and of course compiles on windooom, macos and linux . http://en.wikipedia.org/wiki/Clutter_(toolkit) <http://en.wikipedia.org/wiki/Clutter_(toolkit)> I also heard its quite small and easy to use , so maybe morphic could be based on it. I have not used it myself so I cant vouch for it. Sean P. DeNigris wrote > > kilon wrote >> And the fact that Morphic is written in smalltalk and not just another C >> library, is hard to beat for customization > When one wants to do something non-standard, Morphic is insanely powerful. > The only issue I have is cleaning and refactoring. I think the underlying > idea is brilliant. > kilon wrote >> The only problem is that QT is a C++ library and AFAIK pharo FFIs do not >> support C++ libraries because of name mangling. > You have to export the functionality you want to use as C functions. Not > that hard, but I've only tried it for proof-of-concepts -- View this message in context: http://forum.world.st/New-Mars-examples-Package-Browser-and-Test-Runner-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by kilon

Actually it works its just that is not meant to create a progress bar. To create a progressbar I created a new test testProgressBar UIManager default informUserDuring: [ :bar | [ ^ ZnClient new signalProgress: true; get: 'http://zn.stfx.eu/echo?delay=2' ] on: HTTPProgress do: [ :progress | bar label: progress printString. progress isEmpty ifFalse: [ bar current: progress percentage ]. progress resume ] ] it displays the progressbar , but it displays no progress (blue bar thing) and it close as soon as it finish the get. I tried to implement that in createImageFromTemplate | name | name := UIManager default request: 'Image name?'. self showDownloadInProgress. [UIManager default informUserDuring: [ :bar | [ imageGroup extractTemplate: self selectedTemplate to: name] on: HTTPProgress do: [ :progress | bar label: progress printString. progress isEmpty ifFalse: [ bar current: progress percentage ]. progress resume ] ]] on: PhLDownloadError do: [ :err | UIManager default alert: err longDescription. ^ self ]. self updateAll. I assume that code is deeply flawed , hence why it does not display me any progressbar at all. Looks like I have a lot to learn. First I am not sure if ZnClient downloads in packets and if it reports progress per packet . If its progress is upon success of download then it does not help at all , because in that case there will be only one stage of progress upon success of download. I want multiple stages of progress so the download bar increases from 0% to 100%(preferably per kb ). IF that is the cace then probably I will be better using the HTTP client of monticello to download the images which I know it works that way. Is there a particular reason why we should stick to Zinc ? I am open to suggestions :) Sven Van Caekenberghe-2 wrote > On 24 Sep 2013, at 15:18, kilon < > thekilon@.co > > wrote: > >> ah yes of course. Ok thanks for adding me. >> >> I took a look at the code, it points back to Zinc , it look like I would >> need to override ZnClient >> withProgressDo: , no Idea how to do this >> currently but will continue looking into . I also found how monticello >> uses >> progress bars when downloading repos but it does not seem to use Zinc at >> all. So yeah this will take me quite some time to implement. > > Progress is indicated by HTTPProgress Notification that are being > signalled by the underlying code. You have to catch them and do something > with them. > > Have a look at ZnClientTests>>#testProgress > > Although the example in the comment does no longer seem to work... > >> Its Fun none the less ;) >> >> >> >> Damien Cassou wrote >>> On Tue, Sep 24, 2013 at 1:21 PM, kilon < >> >>> thekilon@.co >> >>> > wrote: >>>> yeah I will give it a try, don't know how long will take me but I like >>>> what >>>> you have done with Pharo Launcher. I will create an enhancement issue >>>> when I >>>> have it working as I want and report back. Esteban has granted me >>>> commit >>>> right to pharo 3 inbox too so I will commit there. Or do you want me to >>>> contribute directly to smalltalk hub repo ? >>>> >>>> I am new with pharo and morphic so please bare with me :) >>> >>> >>> the Pharo3Inbox is only for code integrated in Pharo itself. The >>> launcher won't be integrated in Pharo. I added you to the project >>> http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/ANN-Launching-Pharo-on-Ubuntu-tp4709757p4710044.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/ANN-Launching-Pharo-on-Ubuntu-tp4709757p4710146.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by Sean P. DeNigris

kilon wrote > And the fact that Morphic is written in smalltalk and not just another C > library, is hard to beat for customization When one wants to do something non-standard, Morphic is insanely powerful. The only issue I have is cleaning and refactoring. I think the underlying idea is brilliant. kilon wrote > The only problem is that QT is a C++ library and AFAIK pharo FFIs do not > support C++ libraries because of name mangling. You have to export the functionality you want to use as C functions. Not that hard, but I've only tried it for proof-of-concepts ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Mars-examples-Package-Browser-and-Test-Runner-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

by Eliot Miranda

On Mon, Sep 23, 2013 at 3:10 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Isn't Eliot just implementing this feature, having a segment of non > relocatable objects? > Sort of. Spur will allow any object in old space to stay still, and through become can move any object to old space very simply. So instead of having a special fixed space segment it has a best-bit compaction algorithm that doesn't slide objects, but moves them into holes. With this kind of compaction it is very easy to leave objects put. A further advantage of Spur is that objects have 64-bit alignment so passing arrays to e.g. code using sse instructions, won't cause potential alignment faults. But for NB see below on the hack that the ThreadedFFI uses. > > 2013/9/23 Igor Stasenko <siguctua(a)gmail.com> > >> >> >> >> On 23 September 2013 21:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> >>> On 23 September 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com>wrote: >>> >>>> Hi Jan, >>>> >>>> I think I will add the ByteArray accessor to NBExternalAddress today >>>> or tomorrow since I need it as well for another project. >>>> >>>> hmm, reading from memory into bytearray can be done with memory copy: >>> >>> inputs: address , offset , size to read >>> >>> newAddress := NBExternalAddress value: address value + offset. >>> buffer := ByteArray new: size. >>> NativeBoost memCopy: newAddress to: buffer size: size. >>> >>> same way, writing, just swap the source and destination: >>> >>> newAddress := NBExternalAddress value: address value + offset. >>> buffer "is given from somewhere". >>> NativeBoost memCopy: buffer to: newAddress size: size. >>> >>> but as Jan noted, you cannot tell to write starting at specified offset >>> from/to bytearray, e.g.: >>> >>> copy from: address to: buffer + someOffset >>> neither: >>> copy from: buffer + someOffset to: someAddress >>> >>> this where we need to introduce special 'field address' type, so you >>> can construct it like this: >>> >>> offsetAddress := buffer nbAddressAt: offset. >>> >>> so then you can use it to pass to any function, which expects address, >>> like memory copy >>> or any foreign function. >>> >>> Since objects are moving in memory, we cannot calculate address of field >>> before hand: >>> >>> address := NBExternalAddress value: someObject address + offset. >>> >>> because if GC will happen, after computing such address and its actual >>> use, >>> you will read/write to wrong location. >>> >> >> ** after computing and *before* actual use ** >> >> >>> Thus we should keep oop + offset up to the point of passing it to >>> external function, under >>> controllable conditions, that guarantee there's no GC is possible. >>> >>> >>> Things would be much simpler if we could have pinning, isnt? :) >> > Yes, but for the moment there is a hack one can use, a neat hack invented by Andreas Raab. The Squeak GC is a two-space GC, old space (collected by fullGC) and new space (collected by incrementalGC). An incrementalGC will move objects in new space but leave objects on old space alone. A tenuringIncrementalGC will compact new space and then make new space part of old space. Therefore one way of nearly pinning objects is to do a young GC to tenure objects into old space via tenuringIncrementalGC and then lock fullGC, prevent fullGC from running, until the external call is finished. All arguments to the call become old, and they won't be moved until the fuuGCLock is released. This doesn't help passing a buffer that will be used after the call returns, but it does help a buffer being passed to code that might callback. See uses of PrimErrObjectMayMove, e.g. ThreadedFFIPlugin>>primitiveCallout and platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c>>sqFileReadIntoAt HTH eliot

Sept. 24, 2013

Re: [Pharo-dev] Pharo 3 is interesting

by StÃ©phane Ducasse

On Sep 24, 2013, at 8:38 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > Ok. > > At the same time, I can appreciate the way the change was done. I just merged my system browser from 2.0 to 3.0 with very few problems, just tracking a few deprecations. And given how close I am to the class organisation / RPackage and friends, I can appreciate the care in maintaining a very close API while refactoring. Thanks because we hate this part of the system and this is not what we are dreaming of. if you would see esteban coming to steal fruits in my office these days :) Stef > > Thierry > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] > Date d'envoi : mardi 24 septembre 2013 18:34 > Ã : Igor Stasenko > Cc: Pharo Development List > Objet : Re: [Pharo-dev] Pharo 3 is interesting > > > On Sep 24, 2013, at 6:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 24 September 2013 17:06, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 24/09/2013 16:50, Igor Stasenko a Ã©crit : >> >> >> On 24 September 2013 15:31, Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>> wrote: >> >> I'm managing to get MNUs in Pharo 3.0 in a quite fun way. >> >> I've compiled methods with nil as protocol... The result is kind of >> interesting. >> >> >> i think it is because nil is no longer valid protocol. sure thing it >> should not lead to dnu but to some more >> clear error message. >> >> Well, nil wasn't a protocol either in 2.0 but it was ignored :) >> >> >> anyways, thanks for finding the bug >> >> I triggered it with >> >> aClass compile: 'test ^true' classified: nil notifying: nil >> >> :) >> >> There is also another behavior difference between 2.0 and 3.0: the protocol #'as yet unclassified' disappear when empty in 2.0 and it stays, even empty, in 2.0. >> >> Do you intend it that way? >> >> I don't know the details, there was a lot of work done by Esteban refactoring this.. >> so i letting him to answer your question. > > no, is a bug (known), but still not time to fix it :) > >> >> >> Regards, >> >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> >> >> -- >> Best regards, >> Igor Stasenko.

Sept. 24, 2013

Re: [Pharo-dev] Pharo 3 is interesting

by GOUBIER Thierry

Ok. At the same time, I can appreciate the way the change was done. I just merged my system browser from 2.0 to 3.0 with very few problems, just tracking a few deprecations. And given how close I am to the class organisation / RPackage and friends, I can appreciate the care in maintaining a very close API while refactoring. Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] Date d'envoi : mardi 24 septembre 2013 18:34 Ã : Igor Stasenko Cc: Pharo Development List Objet : Re: [Pharo-dev] Pharo 3 is interesting On Sep 24, 2013, at 6:20 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: On 24 September 2013 17:06, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Le 24/09/2013 16:50, Igor Stasenko a Ã©crit : On 24 September 2013 15:31, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr> <mailto:thierry.goubier@cea.fr<mailto:thierry.goubier@cea.fr>>> wrote: I'm managing to get MNUs in Pharo 3.0 in a quite fun way. I've compiled methods with nil as protocol... The result is kind of interesting. i think it is because nil is no longer valid protocol. sure thing it should not lead to dnu but to some more clear error message. Well, nil wasn't a protocol either in 2.0 but it was ignored :) anyways, thanks for finding the bug I triggered it with aClass compile: 'test ^true' classified: nil notifying: nil :) There is also another behavior difference between 2.0 and 3.0: the protocol #'as yet unclassified' disappear when empty in 2.0 and it stays, even empty, in 2.0. Do you intend it that way? I don't know the details, there was a lot of work done by Esteban refactoring this.. so i letting him to answer your question. no, is a bug (known), but still not time to fix it :) Regards, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Best regards, Igor Stasenko.

Sept. 24, 2013