- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3831 in pharo: 1.2 full image workspace has description on how to load O2

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3831 by marcus.d...(a)gmail.com: 1.2 full image workspace has description on how to load O2 http://code.google.com/p/pharo/issues/detail?id=3831 ... but O2 does not work in 1.2 So we should remove the description.

March 18, 2011

[Pharo-project] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3830 by marcus.d...(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 Why does this just like that start to fail after nunning for days without problems? Autotest.Tests.Core.AutotestTestHitCounter.testHitCountIncrements

March 18, 2011

Re: [Pharo-project] Issue 3426 in pharo: shouldBePrintedAsLiteral instead of isLiteral

by pharo＠googlecode.com

Updates: Status: FixedWaitingToBePharoed Labels: -Milestone-1.3 Comment #4 on issue 3426 by marcus.d...(a)gmail.com: shouldBePrintedAsLiteral instead of isLiteral http://code.google.com/p/pharo/issues/detail?id=3426 Next action: make a changeset or slice

March 18, 2011

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

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3828 by marcus.d...(a)gmail.com: SimpleMorphic overrides system method http://code.google.com/p/pharo/issues/detail?id=3828 in 13097

March 18, 2011

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