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

Extra video volunteer(s) needed FOSDEM smalltalk devroom 2014-2-1

by Stephan Eggermont

All presentations at the FOSDEM smalltalk devroom are to be recorded. https://fosdem.org/2014/schedule/track/smalltalk/ Currently we have only one volunteer to help with that, making it a very demanding task. Anyone able and willing to help us out? Instructions on what and how to do are available, no prior experience is needed. Please contact me directly Cheers, Stephan Eggermont

Jan. 19, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by Benjamin

> Hi Ben, > > I've gave that a go and had some success, but it raised an architectural question I ask near the end. I've documented my investigation here in case it is of use to others new to Spec or the Spec documentation being developed. Spec documentation is actually under heavy construction :) May I keep this content for further quotation? > So the question this leads up to is... > Should child ComposableModels all reference the same WindowModel as their owner? The thing is, the isnât var window doesnât point to the same, but the method `window` does :) Could you try something like: PhLTitledTreeModel>>repository: aRepository repositoryHolder value: aRepository. self repository whenChangedSend: #refresh to: self. "<--subscription-of-concern" self refresh. self whenBuiltDo: [ self window whenClosed: [ self repository unsubscribe: self ] ] Thanks for your investigation :) Ben

Jan. 19, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by btc＠openinworld.com

Jan. 19, 2014

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

by Alexandre Bergel

Currently we do not have a proper support of sparklines. But this is in our roadmap. Cheers, Alexandre On Jan 19, 2014, at 6:15 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 19 Jan 2014, at 00:30, 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). >> > Very niceâ¦ using visualisation everywhere in the IDE could be extremely interestingâ¦ > Does graphET already have support for Sparklines? > > http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic_id=1 > > This could be interesting to embed small visuals like that everywhere (not just for time related > thingsâ¦). > > Of course I have no idea for what for realâ¦ ;-) > > Marcus > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 19, 2014

MNU on PointerExplorer (build menu)

by Nicolai Hess

Can someone take a look at 12458 <https://pharo.fogbugz.com/default.asp?12458> PointerExplorer MNU MenuMorph>>addGroup: (Ben ?) The problem is that it mixes MenuMorph and MenuModel based menu creation. I couldn't find a way to go one OR the other way. So I add the MenuItems from the MenuModel manually. Not nice, but it works. Slice for this case is in the Inbox but I don't mark the issue as solved, yet. Not that important, just if you have time. Nicolai

Jan. 19, 2014

Re: [Pharo-dev] unload all

by Esteban Lorenzano

On 19 Jan 2014, at 12:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I guess that once we will use git it will go away. Does anybody know if this is a correct assmption? yes, is correct :) alll that information can live outside the image without actually lose of information (it will be there, when we need it). > > On 19 Jan 2014, at 10:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Very very nice! I integrate issue 12679. >> >> Yes, Monticello meta dataâ¦ we should check this issue: >> >> https://pharo.fogbugz.com/f/cases/2711/Monticello-wastes-significant-amount… >> >> (but in general it is not good to have meta data of a versioning system in the imageâ¦ it needs to be on disk, and the history on >> disk needs to not by in thousands of zip filesâ¦). >> >> On 18 Jan 2014, at 20:38, 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 >>> >> >

Jan. 19, 2014

Re: [Pharo-dev] unload all

by Esteban Lorenzano

wow. Impressive work, Pavel. Thank you very very very much :) this will be super useful for Pharo 4. Esteban On 18 Jan 2014, at 20: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 >

Jan. 19, 2014

Re: [Pharo-dev] unload all

by StÃ©phane Ducasse

I guess that once we will use git it will go away. Does anybody know if this is a correct assmption? On 19 Jan 2014, at 10:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Very very nice! I integrate issue 12679. > > Yes, Monticello meta dataâ¦ we should check this issue: > > https://pharo.fogbugz.com/f/cases/2711/Monticello-wastes-significant-amount… > > (but in general it is not good to have meta data of a versioning system in the imageâ¦ it needs to be on disk, and the history on > disk needs to not by in thousands of zip filesâ¦). > > On 18 Jan 2014, at 20:38, 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 >> >

Jan. 19, 2014

Re: [Pharo-dev] unload all

by StÃ©phane Ducasse

On 19 Jan 2014, at 09:19, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Ben, can you take care of your child? ;-) I'm not against making UserManager part of the kernel packages, or better only Monticello prerequisity. But we need to separate the UI part. Yes and the UI part is not stable. So we should remove it from 30 for now. > > -- Pavel > > > 2014/1/18 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > COOOOOOOLLLLLLL !!!!!! > > 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 >> > >

Jan. 19, 2014

Re: [Pharo-dev] IncompatibleLayoutConflict with NativeBoost in recent #30700

by Torsten Bergmann

Igor wrote >send me a .zip file containing everything prepared vm+image+dll+doit >in workspace to reproduce it, so i can take a look. Thanks Igor for the offer! Meanwhile Masashi Umezawa created a fix already and uploaded a new version to MetaRepoForPharo30. I tried in Pharo3.0 Latest update: #30707 and also this example works. Really cool - now Pharo30 has yet another NoSQL option available! Nice for small deployments. Have fun T.

Jan. 19, 2014