January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] unload all

by StÃ©phane Ducasse

excellent like that I can work on the loading part I love sooooooo writing configurations. Stef On 20 Jan 2014, at 12:18, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Here is the job: > https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKerne… > > -- Pavel > > > 2014/1/20 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 19 Jan 2014, at 09:44, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > > 2014/1/18 Sven Van Caekenberghe <sven(a)stfx.eu> > > > > On 18 Jan 2014, at 20:53, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > > > > COOOOOOOLLLLLLL !!!!!! > > > > +1 > > > > And interesting as well (I want to understand how to unload NB, for example). > > > > For simplicity I use the attached code. The image needs to be restarted after NB unloading. To do it properly, we need to solve this issues: > > https://pharo.fogbugz.com/f/cases/12624/make-image-startup-independent-on-N… > > https://pharo.fogbugz.com/f/cases/11869/NativeBoost-usage-in-PreferenceStar… > > > > -- Pavel > > > > > > > > > Ben > > > > > > On 18 Jan 2014, at 16:37, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > > >> Hi, > > >> > > >> I finally successfully created a script that is able to unload everything *by Monticello* except kernel packages, network, Monticello, Gofer and related packages. I will setup a job when Jenkins will be healthy again. > > >> It uses several temporary patches that we need to solve properly: > > >> - make NativeBoost optional > > >> - make UserManager optional > > >> - small super-easy issue https://pharo.fogbugz.com/f/cases/12679/change-package-of-ClassTrait-soleIn… > > >> > > >> The size of resultant image is about 6.6 MB, 4.9 MB without MC data and caches. BTW in the full image Monticello data have about 5MB. The image has no Undeclared nor obsolete classes and is really able to load something using Gofer. > > >> > > >> With some care we can make it usable base for the next remodularization effort. > > >> > > >> Cheers, > > >> -- Pavel > > >> > > > > > > > > > > > <cleanAfterNB.st><unloadNB.st> > > Thanks for the scripts, Pavel. > > I was already looking at the environment stuff, it is good to see that the problem is confined to that area. > > When I continue trying to make a 3.0 image run on the Raspberry Pi, I will try using this script. > > Sven > > >

Jan. 20, 2014

Re: [Pharo-dev] Making Platform Installers

by StÃ©phane Ducasse

May be we should turn that into a chapter. Stef On 20 Jan 2014, at 14:01, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sat, Jan 18, 2014 at 7:17 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> If I understood your question correctly, you can steal my NSIS script at >> https://code.google.com/p/biosmalltalk/wiki/NSISInstallerScript and execute: >> >> makensis.exe myscript.nsi > > > I also wrote a Pharo installer using NSIS: > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/ > > and one for Mac too: > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/ > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Jan. 20, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] MessageTally in GTInspector

by Pharo4Stef

this is not only loading the challenges. we should handle cross cutting changes. Stef On 20 Jan 2014, at 11:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I think I understand the implications. > > Moose comes with these tools out of the box, so for people that work with Moose it makes perfect sense to work with tools from the future :). Btw, you can work with the bare GToolkit (only the components needed for Pharo) from here: > https://ci.inria.fr/moose/job/gtoolkit/lastSuccessfulBuild/artifact/gtoolki… > > I also think that the dependency problem is an important one, but it is orthogonal with the work on producing the IDE. I want to get these tools in Pharo, and I want to spend the energy in ensuring modularity, too. The components of the GToolkit are modular now. If at some point we decide to integrate them, the simplest thing we can do is to create the job that ensures their unloadability before the integration. > > Another option is to go back to a Core image and build the working image. I think we should reevaluate this option in the light of the latest Monticello speedups. For example, the current build time for a GToolkit image is 1.5 mins (loads Glamour, Roassal, Graph-ET, GToolkit) which is not a lot. > > Doru > > > > > On Mon, Jan 20, 2014 at 8:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On 19 Jan 2014, at 22:58, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > This is gorgeous. > > The Moose distribution of Pharo looks like to be better suitable for code development than the vanilla one. This makes me remember the Development image of Damien. > > > Do you really ***understand*** the implications? > Because once people will start to put dependencies everytwhere on roassal and start to run smalllint on your code and â¦. > that you will have to follow it and merge and â¦. > you will look at the problem. > > Without unload process that is systematically exercised, tools to manage dependencies and a process to build and support modular images we will end up with a monolithic system. > > I just tried to unload ProfStef and it was full of left instance behind. I tried to unload Nautilus for example and RB. > > Stef > > > > > > Alexandre > > > > > > On Jan 18, 2014, at 8:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > >> Hi, > >> > >> The GTInspector just became a performance analysis tool, too. You can simply inspect a MessageTally and you get several useful views that help you identify performance problems. > >> > >> You can read a more detailed description here: > >> http://www.humane-assessment.com/blog/assessing-pharo-performance-with-gtin… > >> > >> As an appetizer, I attached a screenshot with a Graph-ET chart (thank you Daniel Aviv for developing this engine). > >> > >> <MessageTally-chart.png> > >> > >> To play with the code, you can just work in the latest Moose 5.0 image: > >> https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-… > >> > >> Please let me know what you think. > >> > >> Cheers, > >> Doru > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 20, 2014

Re: [Pharo-dev] RFB on Pharo3

by Sven Van Caekenberghe

On 20 Jan 2014, at 16:26, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 20 Jan 2014, at 3:39 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 20 Jan 2014, at 15:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Ohh, I misread the mail. Sorry. >>> >>> Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. >> >> But if he does that, RFB will no longer work on 2.0 >> >> And for such a small difference, having two code versions is silly, so the only solution is a dynamic hack (try one, if failed, try the other). > > Smalltalk os platformName / Smalltalk os version works on both 2.0 and 3.0. Problem solved then ;-) > Cheers, > Henry

Jan. 20, 2014

Re: [Pharo-dev] RFB on Pharo3

by Henrik Johansen

On 20 Jan 2014, at 3:39 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 20 Jan 2014, at 15:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Ohh, I misread the mail. Sorry. >> >> Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. > > But if he does that, RFB will no longer work on 2.0 > > And for such a small difference, having two code versions is silly, so the only solution is a dynamic hack (try one, if failed, try the other). Smalltalk os platformName / Smalltalk os version works on both 2.0 and 3.0. Cheers, Henry

Jan. 20, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Jean Baptiste Arnaud

On 18 Jan 2014, at 09:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦. +1, we need to think the, best solution is to have NativeBoost on ARM. We need an agreement between, time to develop and usage. Maybe first I should fix Alien or FFI. Then one day, port Nativeboost on ARM. > > >>> On 17 January 2014 22:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Who is JB ? >>> >>> >>> Jean Baptiste Arnaud. The invaluable asset in any team :) >>> The hacker who without any help configuring & compiling VM on raspberry. Oh, for real, I'm flattered. >> >> Good to know. >> >> Thanks Jean-Baptiste ! >> > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Jan. 20, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Jean Baptiste Arnaud

+ 1. And for Seed that can be helpful too. On 18 Jan 2014, at 09:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > +1 > On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Btw, to reduce the pain, i propose to introduce: >> >> NativeBoost isAvailable >> >> protocol. >> >> The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following: >> >> isAvailable >> ^ self primIsAvailable notNil >> >> primIsAvailable >> "Answer flag indicating whether running a native code enabled by plugin" >> <primitive: #primitiveIsEnabled module: #NativeBoostPlugin> >> >> ^ nil >> >> Then you can easily implement a fallback mechanisms, if NB is not avail. >> >> >> >> On 17 January 2014 23:07, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> On 17 January 2014 22:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Who is JB ? >> >> >> Jean Baptiste Arnaud. The invaluable asset in any team :) >> The hacker who without any help configuring & compiling VM on raspberry. >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> -- >> Best regards, >> Igor Stasenko. > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Jan. 20, 2014

Re: [Pharo-dev] RFB on Pharo3

by Sven Van Caekenberghe

On 20 Jan 2014, at 16:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I think we should use Metacello versions for this, no? Yes, that is one option, that is what I meant by 'having 2 code versions'. But it is a lot of hassle for one little platform difference. Maybe the project already has some platform specific code, then it would be easier to play along. > Doru > > Sent from my iPhone > > On Jan 20, 2014, at 15:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 20 Jan 2014, at 15:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Ohh, I misread the mail. Sorry. >>> >>> Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. >> >> But if he does that, RFB will no longer work on 2.0 >> >> And for such a small difference, having two code versions is silly, so the only solution is a dynamic hack (try one, if failed, try the other). >> >>> Doru >>> >>> >>> On Mon, Jan 20, 2014 at 3:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> On 20 Jan 2014, at 15:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Thank you. >>>> >>>> Could you please open an issue and propose a slice for this? >>> >>> RFB is an external package, right ? >>> >>>> Doru >>>> >>>> >>>> On Mon, Jan 20, 2014 at 1:57 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>> Hi there, >>>> >>>> this is causing a debugger to be open in the deprecated method >>>> >>>> >>>> RFBSession>>desktopName >>>> "Answer the name of the desktop, constructed from the image, host and platform names." >>>> "RFBSession new desktopName" >>>> >>>> ^String streamContents: [:stream | >>>> stream >>>> nextPutAll: SmalltalkImage current imageName asFileReference basename; >>>> nextPut: $@; >>>> nextPutAll: server localHostName; >>>> nextPutAll: ' ['; >>>> nextPutAll: OSPlatform platformName; space; nextPutAll: OSPlatform osVersion; >>>> nextPut: $]. >>>> interactive ifFalse: [stream nextPutAll: ' - view only']] >>>> >>>> >>>> fix: >>>> >>>> >>>> RFBSession>>desktopName >>>> "Answer the name of the desktop, constructed from the image, host and platform names." >>>> "RFBSession new desktopName" >>>> >>>> ^String streamContents: [:stream | >>>> stream >>>> nextPutAll: SmalltalkImage current imageName asFileReference basename; >>>> nextPut: $@; >>>> nextPutAll: server localHostName; >>>> nextPutAll: ' ['; >>>> nextPutAll: Smalltalk os name; space; nextPutAll: Smalltalk os version; >>>> nextPut: $]. >>>> interactive ifFalse: [stream nextPutAll: ' - view only']] >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >

Jan. 20, 2014

Re: [Pharo-dev] RFB on Pharo3

by Tudor Girba

I think we should use Metacello versions for this, no? Doru Sent from my iPhone On Jan 20, 2014, at 15:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 20 Jan 2014, at 15:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Ohh, I misread the mail. Sorry. >> >> Sebastian: I just checked, and you have commit rights to PharoExtras, so you could just commit your fix to the RFB project. > > But if he does that, RFB will no longer work on 2.0 > > And for such a small difference, having two code versions is silly, so the only solution is a dynamic hack (try one, if failed, try the other). > >> Doru >> >> >> On Mon, Jan 20, 2014 at 3:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> On 20 Jan 2014, at 15:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Thank you. >>> >>> Could you please open an issue and propose a slice for this? >> >> RFB is an external package, right ? >> >>> Doru >>> >>> >>> On Mon, Jan 20, 2014 at 1:57 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>> Hi there, >>> >>> this is causing a debugger to be open in the deprecated method >>> >>> >>> RFBSession>>desktopName >>> "Answer the name of the desktop, constructed from the image, host and platform names." >>> "RFBSession new desktopName" >>> >>> ^String streamContents: [:stream | >>> stream >>> nextPutAll: SmalltalkImage current imageName asFileReference basename; >>> nextPut: $@; >>> nextPutAll: server localHostName; >>> nextPutAll: ' ['; >>> nextPutAll: OSPlatform platformName; space; nextPutAll: OSPlatform osVersion; >>> nextPut: $]. >>> interactive ifFalse: [stream nextPutAll: ' - view only']] >>> >>> >>> fix: >>> >>> >>> RFBSession>>desktopName >>> "Answer the name of the desktop, constructed from the image, host and platform names." >>> "RFBSession new desktopName" >>> >>> ^String streamContents: [:stream | >>> stream >>> nextPutAll: SmalltalkImage current imageName asFileReference basename; >>> nextPut: $@; >>> nextPutAll: server localHostName; >>> nextPutAll: ' ['; >>> nextPutAll: Smalltalk os name; space; nextPutAll: Smalltalk os version; >>> nextPut: $]. >>> interactive ifFalse: [stream nextPutAll: ' - view only']] >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > >

Jan. 20, 2014

Re: [Pharo-dev] Making Platform Installers

by Damien Cassou

On Mon, Jan 20, 2014 at 3:25 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Where can I find the code for this? https://github.com/pharo-project/pharo-ci build-dmg and build-windows-installer -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Jan. 20, 2014