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

Re: [Pharo-project] FileSystem. Possible FSReference rename

by Denis Kudriashov

I think FSLocator and FSReference are same objects: FSReference = fileSystem + path FSLocator = "some origin object" + path. I think "some origin object" can be implemented as special FSRelativeFileSystem. And fileLocator became fileReference. Now in "FSLocator vmDirectory" "some origin object" is symbol. And FileLocator>>resolve method perform some complex stuff through FSResolver hierarchy logic. What is purpose of FSResolver hierarchy? What is purpose of #resolve: and #resolve methods? Why so many classes (in FileSystem) implement it: FSLocator, FSReferece, FSPath, FSFileSystem, FSResolver? 2011/2/24 Max Leske <maxleske(a)gmail.com> > Maybe I'm just retelling a story but there is already a class called > FSLocator. If FSReference would be renamed to FSLocation I think FSLocator > would have to be renamed too. > > Max > > > On 23.02.2011, at 00:28, StÃ©phane Ducasse wrote: > > > > > On Feb 21, 2011, at 2:54 PM, Denis Kudriashov wrote: > > > >> Hello, > >> > >> I hear many people does not like name FSReference in FileSystem package. > Me too. Its not clear to me. But it is main object for end user. > >> Maybe we can rename it to FSLocation? > > > > FSReference = FSSystem + FSPath > > So may be it could be renamed FSLocation. > > > >> > >> I frequently name variables that point to some file/dir like > imagesLocation, settingsLocation and others. Therefore it is natural to me > have FSLocation instead FSReference. > >> What do you think? > >> > > > > > > >

Feb. 24, 2011

Re: [Pharo-project] SilverSmalltalk

by Max Leske

wow! cool! On 24.02.2011, at 22:38, Alexandre Bergel wrote: > You're probably aware of it. I found it impressive > http://www.silversmalltalk.com/ > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Feb. 24, 2011

Re: [Pharo-project] Is repository down for Magma?

by Chris Muller

Hi, please copy me or the Magma list if you want me to see things soonish. I saw this by luck. > Unfortunately for all us, Chris deleted without notice, the versions Incidentally, notice was posted on the Magma mailing list: http://lists.squeakfoundation.org/pipermail/magma/2011-February/001728.html You can find the new actual load-scripts clicking the link provided in that message. Also, nothing has been deleted from MagmaTester yet, so all of the old packages are still there. However, I want to clean that up pretty soon too.. > from Magma repository that were used by the Metacello configuration to > install Magma. So Magma isn't installable with Metacello anymore. > > Last weekend I started a ground up rewrite for ConfigurationOfMagma with > support only for 1.2 (easier than fix the versions 1.1r43 1.1r44 that Yes, don't worry about those old Magma versions. I won't be supporting them anymore either. > could be installed with the configuration) but after creating > ConfigurationOfMaBase, ConfigurationOfMaClientServer and the new > ConfigurationOfMagma (everything loaded correctly) I got stuck by the > fact that the new Magma 1.2 is Squeak specific at the moment (it uses > WeakOrderedCollection that Chris pushed to Squeak trunk in december 2010 > and that is not in Pharo 1.1, nor in Pharo 1.2). Incidentally, http://lists.squeakfoundation.org/pipermail/magma/2010-November/001612.html To incorporate this into Pharo, see the changes in Squeak between: Collections-ul.403 and Collections-cmm.404. The changes are very simple. Basically, we simply allow the OrderedCollection's internal 'array' to be specified by its #arrayType, instead of being hard-coded to an Array. This allows WeakOrderedCollection to exist by only one single method, an override of #arrayType on the class-side to specify WeakArray. I do hope Pharo will incorporate these changes and gain the benefit of a weak OrderedCollection, not to mention, Magma...! C'mon Pharo, the total gain in code-size is just one Class with a single one-line method, plus one extra one-line method on OC. > So, I could to publish > the new ConfigurationOfMagma to the metacello repository and you'll can > install Magma but it won't run anymore. True, WeakOrderedCollection is crucial for the new proxy bulk-become performance improvement. > (I have had time to check the > WeakOrderedCollection issue only, I don't know if after fixing that > other issues will remain because I haven't gone that far). Me either, we have to get this addressed first. Would someone in Pharo help me lobby for this? > The way I am going to fix this, at least for Pharo 1.1.1 and Pharo 1.2, > is to put the changes that Magma needs in a separate package somewhere > (maybe PharoInbox or PharoTaskForces) and use it as a dependency in > ConfigurationOfMagma. This way it will work correctly. But I will do it > until tomorrow night. Ok. I hope if we can get past WeakOrderedCollection there won't be any more special changes needed, but we'll have to see. Thanks Miguel! - Chris

Feb. 24, 2011

[Pharo-project] SilverSmalltalk

by Alexandre Bergel

You're probably aware of it. I found it impressive http://www.silversmalltalk.com/ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 24, 2011

Re: [Pharo-project] Issue 3752 in pharo: [bug+fix] Symbol>>allInstances should answer all symbols

by pharo＠googlecode.com

Comment #1 on issue 3752 by nicolas....(a)gmail.com: [bug+fix] Symbol>>allInstances should answer all symbols http://code.google.com/p/pharo/issues/detail?id=3752 Why should Symbol behave differently from other classes ? Symbol is an abstract class, just like String. It has no instances. Doing to Symbol what you won't do to SequenceableCollection sounds unfair. You already have two ways to collect #allSubInstances, the slow one (4 words before) which scans the whole object memory, and the fast one allSymbols which just consult the well known registry of Symbols. Yes, for maintaining unicity of symbols, a global registry is necessary, so please why not use it rather than bending the meaning of a generic reflexion message ? Only my 2c opinion. See also http://bugs.squeak.org/view.php?id=6584

Feb. 24, 2011

Re: [Pharo-project] Pharo mailing list weekly summary #3

by Alexandre Bergel

FranÃ§ois, this is really cool Alexandre On 24 Feb 2011, at 17:08, Francois Stephany wrote: > Hi guys, > > I've posted the summary for this week: > http://articles.tulipemoutarde.be/pharo-mailing-list-weekly-summary-3 > > I was away so I certainly forgot some important stuff. Please tell me if I did. > > I've seen that I'm now in Planet Smalltalk, thanks to the one who registered me ! > > > See you next week, > Francois > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 24, 2011

Re: [Pharo-project] FileSystem. Possible FSReference rename

by Max Leske

Maybe I'm just retelling a story but there is already a class called FSLocator. If FSReference would be renamed to FSLocation I think FSLocator would have to be renamed too. Max On 23.02.2011, at 00:28, StÃ©phane Ducasse wrote: > > On Feb 21, 2011, at 2:54 PM, Denis Kudriashov wrote: > >> Hello, >> >> I hear many people does not like name FSReference in FileSystem package. Me too. Its not clear to me. But it is main object for end user. >> Maybe we can rename it to FSLocation? > > FSReference = FSSystem + FSPath > So may be it could be renamed FSLocation. > >> >> I frequently name variables that point to some file/dir like imagesLocation, settingsLocation and others. Therefore it is natural to me have FSLocation instead FSReference. >> What do you think? >> > >

Feb. 24, 2011

[Pharo-project] [update 1.3] #13064

by Marcus Denker

13064 ----- Issue 3350: Network Tests Issue 3694: Balloon message should be opaque for better readability -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 24, 2011

Re: [Pharo-project] Issue 3515 in pharo: Failing Test: RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3515 by renggli: Failing Test: RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod http://code.google.com/p/pharo/issues/detail?id=3515 This is integrated in Refactoring-Tests-Core-lr.51.

Feb. 24, 2011

Re: [Pharo-project] Issue 3694 in pharo: Balloon message should be opaque for better readability

by pharo＠googlecode.com

Updates: Status: Closed Comment #6 on issue 3694 by marcus.d...(a)gmail.com: Balloon message should be opaque for better readability http://code.google.com/p/pharo/issues/detail?id=3694 in 1.3 13064

Feb. 24, 2011