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

RFB on Pharo3

by Sebastian Sastre

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']]

Jan. 20, 2014

[pharo-project/pharo-core] f01921: 30710

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: f01921e1e606b99d90837706a86bc0bfba1c7517 https://github.com/pharo-project/pharo-core/commit/f01921e1e606b99d90837706… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-20 (Mon, 20 Jan 2014) Changed paths: M ClassOrganizer-Core.package/ClassOrganization.class/instance/accessing/removeCategory_.st A ClassOrganizer-Core.package/ClassOrganization.class/instance/accessing/removeProtocolIfEmpty_.st A ClassOrganizer-Core.package/ClassOrganization.class/instance/accessing/removeProtocol_.st M Monticello.package/MCMethodDefinition.class/instance/installing/removeSelector_fromClass_.st A Nautilus.package/AbstractNautilusUI.class/instance/accessing/groupsAreVisible.st M Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/groupsButtonLabel.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenAdded_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenRegistered_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenRemoved_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenRenamed_.st M Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenUnregistered_.st M Nautilus.package/AbstractNautilusUI.class/instance/group/addNewGroup.st A Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/groupsAreVisible.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script363.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30710.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tests.package/MCPackageTest.class/instance/private/aMethodRemoved_.st M Tests.package/MCPackageTest.class/instance/tests/testUnload.st A Tests.package/MCPackageTest.class/instance/tests/testUnloadWithAdditionalTracking.st Log Message: ----------- 30710 12449 Nautilus setting "Show groups on top" breaks automatic group update https://pharo.fogbugz.com/f/cases/12449 12490 Unloading package does not unload correctly https://pharo.fogbugz.com/f/cases/12490 http://files.pharo.org/image/30/30710.zip

Jan. 20, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30710 Home: https://github.com/pharo-project/pharo-core

Jan. 20, 2014

Re: [Pharo-dev] unload all

by Pavel Krivanek

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] [Moose-dev] [ANN] MessageTally in GTInspector

by Tudor Girba

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] [Moose-dev] [ANN] MessageTally in GTInspector

by Tudor Girba

Hi, First, I am happy to see that these efforts get noticed :). This is just the most visible part of the tremendous work happening in Moose. Then, I think it is indeed important to start approaching the problem of the direction of the IDE explicitly. Ideally, we should indeed have one strong and novel IDE. I think there is great potential there. Cheers, Doru On Sun, Jan 19, 2014 at 11:04 PM, Marcus Denker <marcus.denker(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. > > > Keep in mind that we need to take care: the problem back than was that we > had actually not a good situation: we developed one image, but then people > used other tools > when they downloaded the final version. > This means that details never got fixed and improved: why put a lot of > effort into getting the details in the browser correct if everyone will use > another browser? > And that other browser did not see a lot of work, either, because it was > not part of the development effort of Pharo itself. > > It was actually quite bad. We need to really take care to not have that > again. > > And we do *not* have the manpower to manage two sets of tools anyway. > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 20, 2014

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

by Tudor Girba

I am happy you like it. Indeed, as mentioned before, the goal is to get all the Moose knowledge and let it flow in the Pharo IDE. This is just the beginning :) Doru On Sun, Jan 19, 2014 at 10:58 PM, 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. > > 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] something wrong with pharo ci server?

by Christophe Demarey

Hello, Le 18 janv. 2014 Ã 15:22, Johan Brichau a Ã©crit : > All builds are stalledâ¦ wazzup? Yes, there was a big mess. It looks like master jobs (used for build matrix jobs) never ends and keep an executor slots. And after a few time, no more execution is available. I upgraded Jenkins and hope that the problem will be solved. Regards, Christophe.

Jan. 20, 2014

Re: [Pharo-dev] unload all

by Sven Van Caekenberghe

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] unload all

by Luc Fabresse

Thank you very much Pavel! I am eager to go smaller using the bootstrap process ;-) #Luc 2014/1/19 Alexandre Bergel <alexandre.bergel(a)me.com> > Impressive job! > > Alexandre > > Le 18-01-2014 Ã 16:37, Pavel Krivanek <pavel.krivanek(a)gmail.com> a Ã©crit : > > 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-soleInstance > > 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 remodularizationeffort. > > Cheers, > -- Pavel > >

Jan. 20, 2014