September 2013 - Pharo-dev - lists.pharo.org

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,linux #269

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux…>

Sept. 25, 2013

[update 2.0] #20620

by Marcus Denker

20620 ----- 11217 backport 20 No timestamp in MCMethodDefinition>>= https://pharo.fogbugz.com/f/cases/11217 11624 backport Pharo2: Add missing asLayoutFrame in Browser openAsMorphClassEditing: https://pharo.fogbugz.com/f/cases/11624 11662 Pharo 2.0 20619: Undeclared https://pharo.fogbugz.com/f/cases/11662 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1069.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.785.diff

Sept. 25, 2013

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

by Henrik Johansen

On Sep 24, 2013, at 10:42 , 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. Depends on what you want you mean by solid. For exploratory visual programming, it's a solid design. For building GUIs from standard components and a clear separation of responsibilities between a morphs constituent parts (*parts* you say? who needs that, we're all morphs!), it's much less solid than say, MVC/MVP. Cheers, Henry

Sept. 25, 2013

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

by Henrik Johansen

On Sep 24, 2013, at 9:58 , Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 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. Not to be a drag, but SSE operations have 16-byte alignment requirement. With 8-byte aligmnent of first indexable slot, you'd still need to use aligned loads/stores. Cheers, Henry

Sept. 25, 2013

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

by btc＠openinworld.com

Sept. 25, 2013

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

by Sven Van Caekenberghe

Kilon, Here is another example: OrderedCollection streamContents: [ :out | [ ZnClient new signalProgress: true; url: 'http://stfx.eu/PharoV20.sources'; downloadTo: '/tmp' ] on: HTTPProgress do: [ :notification | out nextPut: notification. notification resume ] ]. The resulting collection has more than 1000 elements. So from the standpoint of Zn it works. What is then done with the notifications is another thing. Regards, Sven On 24 Sep 2013, at 22:53, kilon <thekilon(a)yahoo.co.uk> wrote: > The confusion of the noob, I saw a method though it was a class, did not see > "self" in front of it. Yeap its definitely Zinc , its staring me in the face > with that blank look :D > > Ok then its certainly my lack of understanding. I will take my time learning > how Zinc works and how progress bar works. Will take a deeper look into how > Monticello uses it. Thanks for the help, I should be able to figure this > out. If not you will know it by the deep sounds I make when I hit my head > against the wall. > > > Sven Van Caekenberghe-2 wrote >> On 24 Sep 2013, at 22:23, kilon < > >> thekilon@.co > >> > 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. >>> > > > > > > -- > View this message in context: http://forum.world.st/ANN-Launching-Pharo-on-Ubuntu-tp4709757p4710159.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

Personally I don't care that much to be frank with you. I think the age of "native look" has passed and failed miserably. All the rage now is custom look guis, graphics app are strictly custom look, sound and music apps are strictly custom look and web apps of course as well. Only business apps are remaining stuborn stuck in the past. Its no mistake that the clear winner on the GUI department is by far QT . Take a look even at iOS even iOS dropped the macos look for its own custom look. Custom look is everywhere. Even macos embraces it with Launchpad, Time machine and who knows what the future holds. Windoom has suprised us with Metro, probably not a success but seems that even the sloth giant Micro$oft has taken notice where things are heading. QT is the king of it because it has created a very flexible API which is not only capable in looking native but also very good in customisation. Well the king is web design here, but since its not considered desktop technology I will say QT for the record. Saying all that, I am not a believer of GTK. And I have heard that on windows people prefer to commit murder than use GTK. GTK is mainly linux orientated and I dont even think its even on Android. There was a bug on macos about tablet with pressure sensitivity and several other bugs with gimp and mypaint, the bottom line was that there were not enough developers for either windows or macos. GTK3 looks like diffirent story though but I still have my doubts. Looks more flexible, better designed but still does not change the fact that it lack people on non linux platforms to maintain it. And its a rather huge lib. I am interested into Clutter because my main interest is Graphics and OpenGL, so I have my own personal agenda on this. Now if you want to support GTK3 on windoom, I say go for it, its not as if you have a better choice. Maintaining a windoom port with using windoom apis will be much more of a pain anyway. So GTK3 certainly makes sense for me. I just dont see myself abandoning morphic any time soon for it. At least not this century. I prefer smalltalk to C bugs anyday. EstebanLM wrote > 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@.co > > 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. >> >> -- 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

The confusion of the noob, I saw a method though it was a class, did not see "self" in front of it. Yeap its definitely Zinc , its staring me in the face with that blank look :D Ok then its certainly my lack of understanding. I will take my time learning how Zinc works and how progress bar works. Will take a deeper look into how Monticello uses it. Thanks for the help, I should be able to figure this out. If not you will know it by the deep sounds I make when I hit my head against the wall. Sven Van Caekenberghe-2 wrote > On 24 Sep 2013, at 22:23, kilon < > thekilon@.co > > 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. >> -- View this message in context: http://forum.world.st/ANN-Launching-Pharo-on-Ubuntu-tp4709757p4710159.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 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