March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

Benjamin can you publish a new package named Refactoring-Enviroment-Extension as you started to do. Probably too much music or cookies (or magic card discussions). Stef >> 2. The change where you move code from 'Refactoring-Enviornment' to > 'AST-Core' introduces a bad dependency. 'AST-Core' is at the lowest > level, it should not depend on anything else. Ideally the dependency > between 'Refactoring-Enviornment' to 'AST-Core' should be cut, but > that would involve a third package. In other Smalltalks the code in > question is packaged with the UI. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > <refactoring.pdf>

March 18, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

On Mar 18, 2011, at 7:29 PM, Lukas Renggli wrote: > On 18 March 2011 18:39, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Hi lukas >> >> with Stef we refactored the Browser environment: >> - now it can be parametrized by a system dictionary >> - we also move selectionIn* to the AST-Core so that Environment can be loaded independently. >> >> Could you integrate the packages in rb? > > No, please read the mail I sent this morning to the list. > > 1. 'BrowserEnvironment' is supposed to be *stateless*. > BrowserEnvironment is supposed to *always* represent exactly the same > thing. Exaclty the environment we want to browse. When I import Pharo 1.3 in Moose running in Pharo 1.2 I want to be able to refer to the environment that contain Pharo 1.3 so I just pass this environment to the browser environment and all the others tools. I do not see why I would have to have another subclass. > The only refactoring that would make sense is to extract all > senders of 'Smalltalk globals' to a separate method so that subclasses > could override it. Why? Frankly you have so absolute statements. This is good to feel like idiots: "the only refactoring that makes sense" We are making ****ALL**** the tools environment aware: SystemNavigation, Compiler, TestRunner.... so why browserEnvironment would escape to the rule? We need that to be able to browse, compile other code than currently installed and we will do it. Why having a state is a problem? Sorry but we will use this version and we will probably introduce it in core. Because we want to have all the tool chain been able to work on a given environment. > > 2. The change where you move code from 'Refactoring-Enviornment' to > 'AST-Core' introduces a bad dependency. 'AST-Core' is at the lowest > level, it should not depend on anything else. Ideally the dependency > between 'Refactoring-Enviornment' to 'AST-Core' should be cut, but > that would involve a third package. In other Smalltalks the code in > question is packaged with the UI. Correct I did not pay attention, we will introduce a third package. Now if you do not like our changes we will fork. This is sad because we tried to make sure that RB could work on them but there is no problem we can fork also RB. Just let us know. Stef

March 18, 2011

Re: [Pharo-project] Issue 3827 in pharo: parser rejects sending a message to the result of yourself

by pharo＠googlecode.com

Updates: Status: WontFix Comment #2 on issue 3827 by marcus.d...(a)gmail.com: parser rejects sending a message to the result of yourself http://code.google.com/p/pharo/issues/detail?id=3827 (No comment was entered for this change.)

March 18, 2011

[Pharo-project] [update 1.2] #12343

by Marcus Denker

12343 ----- Issue 3828: SimpleMorphic overrides system method -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 18, 2011

Re: [Pharo-project] Issue 3828 in pharo: SimpleMorphic overrides system method

by pharo＠googlecode.com

Comment #2 on issue 3828 by marcus.d...(a)gmail.com: SimpleMorphic overrides system method http://code.google.com/p/pharo/issues/detail?id=3828 in 1.2 12343 TODO: 1.3

March 18, 2011

Re: [Pharo-project] GSOC 2010 results

by StÃ©phane Ducasse

How to navigate them?What model? Because this is not because you have namespace that you do not get name clash. How to use them in presence of package? What is the impact on tools? What do we want exactly? Do we want selector namespaces? No need to answer and I have a long list. I'm thinking about namespaces since we did classboxes and so far the anwser is not easy. Because I would like to have late bound class name but this may imply to see if we can avoid to have mixin. So I think that we have more urgent things to do now. The current need is easily solved by prefixing so let us prefix. Because what I want is to be able to reuse tests but with another Collection package and so far simple namespaces do not solve that and the solution I know is far to big and its impacts are big too. Stef On Mar 18, 2011, at 5:25 PM, Marcus Denker wrote: > > On Mar 18, 2011, at 5:18 PM, Miguel CobÃ¡ wrote: > >> I think the "No" answer is more like "there are no current plans, >> because nobody has pushed it" than "the namespaces implementation is >> banned from Pharo" > > > Or: Namespaces can be done so easily wrong so that oe needs to think very carefully and > there are no braincycles left just now. > > At least, that's my view... and I think that the project indeed is very important, as it shows one > solution that we can learn from... and then we can realize something for Pharo after we > are sure we learned enough. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 18, 2011

Re: [Pharo-project] Issue 3829 in pharo: 1.2 core image needs to allow loading 1.2.1 updates

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3829 by marcus.d...(a)gmail.com: 1.2 core image needs to allow loading 1.2.1 updates http://code.google.com/p/pharo/issues/detail?id=3829 Solution: SystemVersion newVersion: 'Pharo1.2.1a'.

March 18, 2011

[Pharo-project] [ANN 1.2.1a] towards 1.2.1

by Marcus Denker

Hi, With people now finally actually looking at 1.2Core, we need to start to collect bugfixes and do a 1.2.1... So if you want to update 1.2Core, you need to SystemVersion newVersion: 'Pharo1.2.1a'. or download it from https://gforge.inria.fr/frs/download.php/28391/PharoCore-1.2.1a-12342.zip This is *not* linked as stable core... as it can break anytime. And 1.2Core does not update withour changing the version number (We might want to rethink that... but that can only be done in 1.3) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 18, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Igor Stasenko

On 18 March 2011 20:47, Lukas Renggli <renggli(a)gmail.com> wrote: > Another issue is the class GLMOrangeUITheme being in the 'Morphic' > package and an indirect subclass of UITheme that is in the 'Polymorph' > package which itself depends on the 'Morphic' package ==> circular > dependency ==> loading/unloading impossible. > it was fixed few days later... strange that for 1.2 it left with bogus organization. > Lukas > > On 18 March 2011 17:14, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: >> +1 >> >> El vie, 18-03-2011 a las 08:24 +0100, Marcus Denker escribiÃ³: >>> On Mar 18, 2011, at 8:16 AM, Lukas Renggli wrote: >>> >>> >> I would not unload packaged. >>> >> >>> >> Everything not tested is broken, and so if you do things like that I am >>> >> sure you will have problems. >>> >> >>> >> And nobody ever unloaded anything from Core. >>> > >>> > You must be joking right? In the mission you say "stable and small >>> > core", but the numbers say something entirely different: PharoCore 1.0 >>> > is 11 MB, PharoCore 1.1 is 14 MB, PharoCore 1.2 is 16 MB. I mentioned >>> > it before in this list, but I already had to unload stuff in PharoCore >>> > 1.1. Honestly, I don't really see the point of a PharoCore image if it >>> > contains more and more not unloadable non-core code. >>> > >>> Size of the image comes in part from ever growing MC history. The only >>> other big thing should be the Minimal Morphic code, which is in there >>> temporarily. >>> >>> Else: Â People are welcome to help. >>> >>> We do what we do and then we do a release even if it is imperfect. >>> Perfection is death, and delaying the release forever "because we could do better" >>> will not mean that we do better, just that we don't release ever. >>> >>> Pharo 1.2 is *not* a goal in itself. It is just a snapshot on the way to a goal. Therefore >>> it's just a mess that is tested for some month so it does not have any obvious bugs. >>> Nothing else. >>> >>> Â Â Â Marcus >>> >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >> >> -- >> Miguel CobÃ¡ >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Best regards, Igor Stasenko AKA sig.

March 18, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Lukas Renggli

Another issue is the class GLMOrangeUITheme being in the 'Morphic' package and an indirect subclass of UITheme that is in the 'Polymorph' package which itself depends on the 'Morphic' package ==> circular dependency ==> loading/unloading impossible. Lukas On 18 March 2011 17:14, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > +1 > > El vie, 18-03-2011 a las 08:24 +0100, Marcus Denker escribiÃ³: >> On Mar 18, 2011, at 8:16 AM, Lukas Renggli wrote: >> >> >> I would not unload packaged. >> >> >> >> Everything not tested is broken, and so if you do things like that I am >> >> sure you will have problems. >> >> >> >> And nobody ever unloaded anything from Core. >> > >> > You must be joking right? In the mission you say "stable and small >> > core", but the numbers say something entirely different: PharoCore 1.0 >> > is 11 MB, PharoCore 1.1 is 14 MB, PharoCore 1.2 is 16 MB. I mentioned >> > it before in this list, but I already had to unload stuff in PharoCore >> > 1.1. Honestly, I don't really see the point of a PharoCore image if it >> > contains more and more not unloadable non-core code. >> > >> Size of the image comes in part from ever growing MC history. The only >> other big thing should be the Minimal Morphic code, which is in there >> temporarily. >> >> Else: Â People are welcome to help. >> >> We do what we do and then we do a release even if it is imperfect. >> Perfection is death, and delaying the release forever "because we could do better" >> will not mean that we do better, just that we don't release ever. >> >> Pharo 1.2 is *not* a goal in itself. It is just a snapshot on the way to a goal. Therefore >> it's just a mess that is tested for some month so it does not have any obvious bugs. >> Nothing else. >> >> Â Â Â Marcus >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > -- Lukas Renggli www.lukas-renggli.ch

March 18, 2011