> 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-model-general.html >>> >>> 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:[email protected] | 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 >>> <[email protected]> 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 >>> >> > >
