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

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

by Marcus Denker

On 24 Nov 2013, at 21:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 24 Nov 2013, at 21:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 24 Nov 2013, at 21:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> well well well >>> >> >> Code that is not used breaks. I do not know how to change that. I really do not. >> > > I do not think that it is realistic to keep the old Browser alive. It will mean that we have > to change it for everythingâ¦ Protocols already now. Later someone needs to change > it to use RPackage instead of System Categoriesâ¦ this will be quite some workâ¦ > and how will we get that debugged if we donât use it? I really canât do it. Itâs beyond my capabilities. Marcus

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

>> 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. No :) He will not be the guy that will have to fight with bugs in Opal but you. He would have been right if we would have a script or a way to create a new opal that can compile another one. I'm in favor to remove the old compiler and the old browser but only when we are in a situation where we can continue to work fast. > 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. Just start to compile in a different environment is a first step in that direction. without a fully environment based system there are solutions but they will take time. Stef

Nov. 24, 2013

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

by Marcus Denker

On 24 Nov 2013, at 21:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 24 Nov 2013, at 21:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> well well well >> > > Code that is not used breaks. I do not know how to change that. I really do not. > I do not think that it is realistic to keep the old Browser alive. It will mean that we have to change it for everythingâ¦ Protocols already now. Later someone needs to change it to use RPackage instead of System Categoriesâ¦ this will be quite some workâ¦ Marcus

Nov. 24, 2013

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

by Camille Teruel

On 24 nov. 2013, at 21:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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â¦ That's work in progress :) > 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 StÃ©phane Ducasse

> I donât consider that a problem, on the contrary: eating your own dog food is good. It is a problem. For example, for opal better have in place a mechanism to change it (for example having a process to duplicate it with a different name or make sure that it can compile in a separate environnement) before removing the old one because else if we get a breaking change then it will force us to rollback. For code browser this is the same. It is always smart to have a really simple working in any circumstances. Alain was thinking about that too. Because else when you cannot edit or debug code you are dead. We worked with igor fixing all the LayoutFrame in the system and when we broke (because you always break soetmghitn) the lyout of the browser it was less fun. This is not the question of not eating your own dog food since I'm not using emacs to edit Pharo right now and I would hate to be forced to do it. but if we do not pay attention to our tools and the idea of reflection withitn them then this is what will happen. Right now I cannot fix the Browser in the image. So I opened another one. Stef > > 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] EyeInspector looks broken

by Tudor Girba

With the GTDebugger, this works fine and a debugger pops up properly. Doru On Sun, Nov 24, 2013 at 9:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > > >> Smalltalk tools openBrowser > > > > > > > >> produces an emergency evaluator. > >> => annoying. > >> > > > > > > yes. I will have a look. > > > > Smalltalk tools browser open > > sure I took this example because I was guessing the name of the method > hoping I would get a debugger not an emergency evaluator. > > > works, Smalltak tools does not implement openBrowser, what we see is > side effect of the #DNU handling > > of ToolRegistry. (a bug in that). > > the bug is in EyeInspector > > > > > Marcus > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 24, 2013

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

by Benjamin

On 24 Nov 2013, at 21:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. Why loading it if there was a conflict ? Ben > >> 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

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

by Marcus Denker

On 24 Nov 2013, at 21:46, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > The slice SLICE-Issue-12179-Nautilus-Add-package-filter-input-box-JurajKubelka.3 > already contains the fix. But whenever I try to merge with the image 30593, it says merge conflict. > The solution is to say "Use incoming versionâ. I do not know how to do it better. As soon as an issue is integrated, it is better to submit a new change (new issue) based on the new image. Much easier to handle. Marcus

Nov. 24, 2013

Re: [Pharo-dev] Better layout definition in new Nautilus Browser with filter dialog

by Benjamin

I will do that tomorrow :P Do not hesitate to bump me if you forget :) Ben On 24 Nov 2013, at 21:38, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > 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] SLICE-Issue-12179-Nautilus-Add-package-filter-input-box

by Juraj Kubelka

The slice SLICE-Issue-12179-Nautilus-Add-package-filter-input-box-JurajKubelka.3 already contains the fix. But whenever I try to merge with the image 30593, it says merge conflict. The solution is to say "Use incoming versionâ. I do not know how to do it better. Cheers, Jura El 24-11-2013, a las 17:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > 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