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

Re: [Pharo-dev] why can't we select the browser we want to use anymore via the window menu?

by Marcus Denker

On 24 Nov 2013, at 21:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 24 Nov 2013, at 21:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> No you should not. 30 is really usable and we are in alpha. >> Now removing the old code browser is a goal but we should not fool ourselves. >> Once all the tools are based on Spec, breaking/changing spec will let us without back door. > > I donât consider that a problem, on the contrary: eating your own dog food is good. > > BTW, in the past (old tools, old frameworks) the problem was the same. When Camille last week tried to convince me to kill the old Compiler *now* I said âbut itâs so nice to be able to switch when changing the newâ. He replied: âBut there was just one old Compiler, wasnât there?â And he is right. What we need to do for real is to support multiple versions of code in the same imageâ¦ or multiple images where one can remote-devlope the other. This would solve the problem for real. Marcus

Nov. 24, 2013

Re: [Pharo-dev] why can't we select the browser we want to use anymore via the window menu?

by Sven Van Caekenberghe

On 24 Nov 2013, at 21:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No you should not. 30 is really usable and we are in alpha. > Now removing the old code browser is a goal but we should not fool ourselves. > Once all the tools are based on Spec, breaking/changing spec will let us without back door. I donât consider that a problem, on the contrary: eating your own dog food is good. BTW, in the past (old tools, old frameworks) the problem was the same. Yes, that means increased responsibility, so what ? If I break Zinc, nobody can load or commit code any more - though. > Stef > >> This makes think of the tick tock model of Intel improvements. >> >> http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-… >> >> Looks like with 2.0 and 3.0 we are going to have two "tick"s in a row. That may be too much. >> >> I am afraid even trying out 3.0 when reading about all the moving parts that are changing in all corners. >> >> Phil >> >> >> >> --- >> Philippe Back >> Dramatic Performance Improvements >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 >> Mail:phil@highoctane.be | Web: http://philippeback.eu >> Blog: http://philippeback.be | Twitter: @philippeback >> Youtube: http://www.youtube.com/user/philippeback/videos >> >> High Octane SPRL >> rue cour Boisacq 101 | 1301 Bierges | Belgium >> >> Pharo Consortium Member - http://consortium.pharo.org/ >> Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com >> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller >> >> >> >> >> On Sun, Nov 24, 2013 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> It would be good not to clean without a clear vision. >> For example we cannot register an old browser to browse code via the menu of a window. >> Now let us think two minutes to see if you can get my point: >> >> - I want to unload nautilus, rb, keymapping, athens, Ecompletion, Gofer, NativeBoost, Zinc, â¦.. >> and reload them via their configuration so that we can manage Pharo with configurations. >> >> - Right now we LOST yes LOST the configurations of most of the part of the systems (I just spendt several afternoon >> on the one of RB in the past and now guess what) because >> we do not have a process to use them and we are afraid to have 10 packages and 10 classes more in the system. >> I do not understand why we do not start to put the configuration inside the image. To me this is totally stupid >> not to do it. >> >> - Now without a browser this is nearly impossible to work. So we will remove the old browser >> but we should go slowly because else I will you do it with emacs outside the image to see if you succeed. >> >> So it would be good to focus on real impacting changes. >> >> Stef >> >

Nov. 24, 2013

Re: [Pharo-dev] why can't we select the browser we want to use anymore via the window menu?

by StÃ©phane Ducasse

On Nov 24, 2013, at 9:33 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 24 Nov 2013, at 21:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I am using Pharo 3.0 in production and it is highly reliable. >> > > I think, too, that Pharo 3 is *amazingly* stable considering what we changed. > > I am actually quite proud of it. me too. Now I just ask for a bit of care else this will be much more difficult to arrive to bootstrap. If we do not make sure that we can unload and reload package for examples. Stef > > Marcus >

Nov. 24, 2013

Re: [Pharo-dev] SLICE-Issue-12179-Nautilus-Add-package-filter-input-box

by StÃ©phane Ducasse

submit a fix. > I would like, but I have not found out how. I will take care of it and ask in mailing list. > > Anyway, I am not sure if it was well integrated. There was a conflict and I fully loaded your code. So I do not see how it could be different. But with computer science everything is possible. > I have just downloaded image 30593 and I can see in PackageTreeNautilusUI>>buildFirstColumn: line > > ^ firstColumn := PanelMorph new > > it should be without instance variable: > > ^ PanelMorph new > > Thanks, > Jura > > El 24-11-2013, a las 17:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > >> Cool. >> Juraj could you fix the layout because it is not aligned and a bit too high, it should be probably based on the default font. >> >> Stef >> On Nov 24, 2013, at 9:15 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >>> Hi Alexandre! >>> >>> StÃ©phane have just integrated it. You can download latest version and use it :-) >>> >>> Just to let you know. You can write regular expressions in the input field. An useful example can be (everything is case insensitive): >>> ^Roassal â¦ packages which start by name Roassal >>> ^Roassal|Mondrian â¦ packages which start by name Roassal or contains name Mondrian (there is pipe | between the words) >>> ^(Roassal|Mondrian) >>> ^Roassal|^Mondrian â¦ packages which start by name Roassal or by name Mondrian >>> ^Ro.*Test â¦ any package which start by name Ro and contains word Test >>> >>> Basically if someone writes regular expression which is not valid, it displays all packages. >>> >>> Cheers, >>> Jura >>> >>> El 24-11-2013, a las 11:16, Alexandre Bergel <alexandre.bergel(a)me.com> escribiÃ³: >>> >>>> Hi! >>>> >>>> I think the following should be part of Pharo: >>>> SLICE-Issue-12179-Nautilus-Add-package-filter-input-box-JurajKubelka.1 >>>> >>>> I have been using for some times already and it works pretty well. I have also reviewed the code. >>>> This slice makes me much much more productive. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>> >> >

Nov. 24, 2013

Better layout definition in new Nautilus Browser with filter dialog

by Juraj Kubelka

Hi I do not know how to do the better layout of input package filter which was integrated to latest Pharo 3.0 image. It is defined in method PackageTreeNautilusUI>>buildFirstColumn: (it means package column) And code looks like: ^ PanelMorph new changeProportionalLayout; addMorph: self buildPackageSearch â <ââ this is new filter input dialog" fullFrame: ((0@0 corner: 1(a)0.1)) â and his layout definition" addMorph: self buildList â <ââ this is package listâ fullFrame: ((0(a)0.1 corner: 1@1) asLayoutFrame bottomOffset: -25); â and his layout definition" addMorph: buttons â <ââ Hierarchy button" fullFrame: ((0@1 corner: 1@1) asLayoutFrame topOffset: -25); â and his layout" hResizing: #spaceFill; vResizing: #spaceFill; yourself. So, now filter dialog and package list are flexible and change their height according to window size. I have tried to define input dialog of fixed size (according to font size), but I do not know how. Any suggestion? Thanks, Jura

Nov. 24, 2013

Re: [Pharo-dev] why can't we select the browser we want to use anymore via the window menu?

by Sven Van Caekenberghe

On 24 Nov 2013, at 21:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 24 Nov 2013, at 21:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I am using Pharo 3.0 in production and it is highly reliable. >> > > I think, too, that Pharo 3 is *amazingly* stable considering what we changed. > > I am actually quite proud of it. > > Marcus +1

Nov. 24, 2013

Re: [Pharo-dev] SLICE-Issue-12179-Nautilus-Add-package-filter-input-box

by Juraj Kubelka

Ok, thank you Marcus. Jura El 24-11-2013, a las 17:36, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > On 24 Nov 2013, at 21:29, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> I would like, but I have not found out how. I will take care of it and ask in mailing list. >> >> Anyway, I am not sure if it was well integrated. I have just downloaded image 30593 and I can see in PackageTreeNautilusUI>>buildFirstColumn: line >> >> ^ firstColumn := PanelMorph new >> >> it should be without instance variable: >> >> ^ PanelMorph new >> > > If you would have put the status on âFix review neededâ the monkey would have found thisâ¦ > > The reason is that there was a code critic clean done of Nautilus where the critic tools found that firstColumn was just assigned and never > read. Therefore it was possible to just remove it (and secondColumn). > > This change was done after you did your Sliceâ¦ therefore your code was right when it was done but out-dated in the meantime. > > (itâs easy to fix *and* it was catcher by the testsâ¦ so nothing bad happened) > > Marcus

Nov. 24, 2013

Re: [Pharo-dev] Browser does not work at all anymore... I fixed it but...

by StÃ©phane Ducasse

too me it looks like we are violating the fact that a list IS NOT A SET. Categorizer>>allMethodSelectors "give a list of all method selectors." ^ elementArray copy sort ClassOrganization>>allMethodSelectors ^ protocolOrganizer allMethods ProtocolOrganizer>>allMethods ^ self protocols gather: [:p | p methods ]. gather: aBlock "This method is kept for compatibility reasons, use flatCollect instead." ^ self flatCollect: aBlock. Note that it would be good to have a comment in this second method. Because now I do not know. initialize super initialize. protocols := IdentitySet new. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ allProtocol := AllProtocol protocolOrganizer: self. So I would suggest that allMethods return something with an order. Esteban??? ProtocolOrganizer>>allMethods ^ self protocols gather: [:p | p methods ]. => ProtocolOrganizer>>allMethods ^ (self protocols gather: [:p | p methods ]) asArray Stef On Nov 24, 2013, at 9:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > well well well > > messageList > "Answer an Array of the message selectors of the currently selected message category, provided that the messageCategoryListIndex is in proper range. Otherwise, answer an empty Array If messageCategoryListIndex is found to be larger than the number of categories (it happens!), it is reset to zero." > | sel | > (sel := self messageCategoryListSelection) ifNil: [ > ^ self classOrMetaClassOrganizer > ifNil: [Array new] > ifNotNil: [self classOrMetaClassOrganizer allMethodSelectors] > ]. > > ^ (self classOrMetaClassOrganizer listAtCategoryNumber: messageCategoryListIndex) > ifNil: [messageCategoryListIndex := 0. Array new] > > it looks like messageList or allMethodSelectors got changed and do not return anymore an indexable collection. > So I will fix that too. > > Stef > > > > On Nov 24, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Smalltalk tools register: Browser as: #browser >> Smalltalk tools openClassBrowser >> >> >> >> PluggableListMorph was not robust enough >> Apparently when getListSelector returns a set (like messageList now in 3.0 then getList breaks >> >> getList >> "Answer the list to be displayed. Caches the returned list in the 'list' ivar" >> getListSelector == nil ifTrue: [^ #()]. >> list := model perform: getListSelector. >> list == nil ifTrue: [^ #()]. >> list := list collectWithIndex: [ :item :index | self wrapItem: item index: index ]. >> ^ list >> >> => fix the problem. I will produce a slice. And I think that the messageList returning a set is a mistake too. >> >> getList >> "Answer the list to be displayed. Caches the returned list in the 'list' ivar" >> getListSelector == nil ifTrue: [^ #()]. >> list := (model perform: getListSelector) asArray. >> list == nil ifTrue: [^ #()]. >> list := list collectWithIndex: [ :item :index | self wrapItem: item index: index ]. >> ^ list >> >> Stf >

Nov. 24, 2013

Re: [Pharo-dev] SLICE-Issue-12179-Nautilus-Add-package-filter-input-box

by Marcus Denker

On 24 Nov 2013, at 21:29, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > I would like, but I have not found out how. I will take care of it and ask in mailing list. > > Anyway, I am not sure if it was well integrated. I have just downloaded image 30593 and I can see in PackageTreeNautilusUI>>buildFirstColumn: line > > ^ firstColumn := PanelMorph new > > it should be without instance variable: > > ^ PanelMorph new > If you would have put the status on âFix review neededâ the monkey would have found thisâ¦ The reason is that there was a code critic clean done of Nautilus where the critic tools found that firstColumn was just assigned and never read. Therefore it was possible to just remove it (and secondColumn). This change was done after you did your Sliceâ¦ therefore your code was right when it was done but out-dated in the meantime. (itâs easy to fix *and* it was catcher by the testsâ¦ so nothing bad happened) Marcus

Nov. 24, 2013

Re: [Pharo-dev] why can't we select the browser we want to use anymore via the window menu?

by Marcus Denker

On 24 Nov 2013, at 21:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I am using Pharo 3.0 in production and it is highly reliable. > I think, too, that Pharo 3 is *amazingly* stable considering what we changed. I am actually quite proud of it. Marcus

Nov. 24, 2013