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

Re: [Pharo-project] Issue 3575 in pharo: [Failing Tests] Obsolete classes after tests

by pharo＠googlecode.com

Updates: Status: Closed Comment #11 on issue 3575 by marcus.d...(a)gmail.com: [Failing Tests] Obsolete classes after tests http://code.google.com/p/pharo/issues/detail?id=3575 (No comment was entered for this change.)

March 18, 2011

Re: [Pharo-project] Issue 1914 in pharo: Should check the comments added to packageinfo by andreas in squeak

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 1914 by marcus.d...(a)gmail.com: Should check the comments added to packageinfo by andreas in squeak http://code.google.com/p/pharo/issues/detail?id=1914 PackageInfo will be replaced by RPackage soon

March 18, 2011

Re: [Pharo-project] Issue 953 in pharo: PackageInfo could be much faster

by pharo＠googlecode.com

Updates: Status: Closed Comment #21 on issue 953 by marcus.d...(a)gmail.com: PackageInfo could be much faster http://code.google.com/p/pharo/issues/detail?id=953 PackageInfo will be replaced by RPackage soon. (In addition, this bug report was not looked at for >6 Months) Therefore I will close this entry.

March 18, 2011

Re: [Pharo-project] GSOC 2010 results

by Alexandre Bergel

+1 Alexandre On 18 Mar 2011, at 16:16, StÃ©phane Ducasse wrote: > > 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. >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 18, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by Lukas Renggli

>> 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. You clearly break the following methods and potentially all 55 references to BrowserEnvironment: - BrowserEnvironment>>#copyEmpty - BrowserEnvironment>>#& - BrowserEnvironment>>#I - BrowserEnvironment>>#not - BrowserEnvironment>>#isSystem - ClassEnvironment>>#classesDo: - SelectorEnvironment>>#classesDo: Not sure how you are going to meaningfully fix these when BrowserEnvironment can point to different environments? I can only repeat myself: BrowserEnvironment encapsulates the complete system (world). All that you can potentially see within a given image at a given time. If you have Pharo 1.2 and Pharo 1.3 in your image then BrowserEnvironment would enumerate Object from Pharo 1.2 and Object from Pharo 1.3. > 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. I don't know why you get angry? I am just telling you how John Brant and Don Roberts implemented the system. Just fundamentally changing core classes of a framework without understanding the implications doesn't help. If you don't believe me ask John or compare the code with the one in VisualWorks where you could actually have different system versions at the same time in the image. So again: If you want a view onto your namespace create a BrowserEnvironmentWrapper subclass that holds a reference to your namespace like PackageEnvironment with its package. That is how it is ment to be done. Lukas -- Lukas Renggli www.lukas-renggli.ch

March 18, 2011

[Pharo-project] need your attention: Package

by StÃ©phane Ducasse

Hi guys we need to think about package: right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted. - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories. Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching. So if you have suggestion please talk now. Stef

March 18, 2011

[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