- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3299 in pharo: [Kernel Dependencies] Object Extension
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Status: Accepted Owner: Benjamin.VanRyseghem.Pharo New issue 3299 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Object Extension http://code.google.com/p/pharo/issues/detail?id=3299 Create extension to UIManager confirm:Or:Cancel: inform: confirm: primitiveError:

1 4

[Pharo-project] Issue 3298 in pharo: [Kernel Dependencies] Object >> #cannotReturn
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Status: Accepted Owner: Benjamin.VanRyseghem.Pharo New issue 3298 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Object >> #cannotReturn http://code.google.com/p/pharo/issues/detail?id=3298 Strange dependence to ToolSet

1 4

[Pharo-project] Issue 3807 in pharo: FileIn from FileContentsBrowser is broken when in presence of reorganize
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Status: Closed Owner: stephane...@gmail.com Labels: Milestone-1.3 New issue 3807 by stephane...@gmail.com: FileIn from FileContentsBrowser is broken when in presence of reorganize http://code.google.com/p/pharo/issues/detail?id=3807 We spent some time with Benjamin and probably the problem is that a ChangeRecord is not tagged as a reorganize. Now the code is so bad and circumvoluted that we decided to remove the possibility to file in code from the FileContentsBrowser and that the user performs a new drag and drop and select file in (which works). We do that because like that we make sure that the integrators do not get confused with different options and one breaking on reorganize in presence of class extension and MC recategorization.

1 0

[Pharo-project] About the sprint saturday 12
by StÃ©phane Ducasse March 12, 2011

March 12, 2011

Hi guys and participants of the school, we proposed to organize a spring saturday 12 so that you can get involved and get the feel of a fun coding party. Now we need to know if you plan to participate so that we can reserve a room and prepare something for lunch. So could you reply to this email so that we know what we should prepare. Stef

6 14

[Pharo-project] Issue 3795 in pharo: MC repository
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Status: Accepted Owner: stephane...@gmail.com New issue 3795 by stephane...@gmail.com: MC repository http://code.google.com/p/pharo/issues/detail?id=3795 -------- Original Message -------- Subject: [squeak-dev] sustainable Monticello Date: Tue, 8 Mar 2011 15:33:19 -0600 From: Chris Muller <asqueaker(a)gmail.com> Reply-To: ma.chris.m(a)gmail.com, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> This will probably be a long post, but I would like to tell you about the Monticello upgrades I'm about to move to the trunk. Monticello has several repository types: MCRepository #('creationTemplate' 'storeDiffs') MCDictionaryRepository #('description' 'dict') MCFileBasedRepository #('cache' 'allFileNames') MCDirectoryRepository #('directory') MCCacheRepository #('packageCaches' 'seenFiles') MCSubDirectoryRepository #() MCFtpRepository #('host' 'directory' 'user' 'password' 'connection') MCHttpRepository #('location' 'user' 'password' 'readerCache') MCSMCacheRepository #('smCache') MCGOODSRepository #('hostname' 'port' 'connection') MCWriteOnlyRepository #() MCSMReleaseRepository #('packageName' 'user' 'password') MCSmtpRepository #('email') but MCFileBasedRepository is the one that has been given all of the focus, the other repository types have been ignored over the years. MCHttpRepository is the one that interfaces with SqueakSource, and MCDirectoryRepository are pretty much the only types being used. I know this because external users of MCRepository API, like the Repository-browser tools and MC-Configurations and Installer; these are all using API's that are specific to MCFileBasedRepository - not generally understood by the other repository-types or the abstract API in MCRepository. This is worthy of concern because of the access-limitations of a MCFileBasedRepository. Unlike a MCGOODSRepository, for example, a file-system-based repository cannot efficiently meet the demands of being a MCRepository without, at some points, needing to enumerating ALL version names (files) in its file-system location. As the number of versions in a repository reaches 1-million and beyond, performance will grind to a halt due to the number of files that must be constantly downloaded into RAM (another area of unscalability and unsustainability related to FileBased Repository's). A purging of old versions could be done, but a philosophy of Monticello, from the outset, has been that repository's are intended to contain "all" of version history. I have therefore reworked the MCRepository API's and external tools to talk using only an API that is understood by any repository that implements the methods identified as #subclassResponsibility in MCRepository. This minimally-required API is now: #allPackageNames - answer a list of package names in this repository. #basicStoreVersion: - add a Version to this repository. #includesVersionNamed: - does a version with this name exist in this repository? #versionNamed: - answer the first Version object with the given name. #versionNamesForPackageNamed: - answer the version names for the given package name. #versionWithInfo:ifAbsent: - answer the Version object with the given unique VersionInfo In deference to the limitations of FileBasedRepository's, we only ask for the _names_ of things rather than the whole object, because the names are all that is needed to satisfy tool requirements, except in cases where we need a single Version object (like loading). FileBased cannot access the Version objects quickly, just the (file)names (incl. author & version-number). During the process of this refactoring, I was able to signficantly improve the coherence of the code. It was really, really bad in some areas. I've also verified the viability of this API by updating MCMagmaRepository, and demonstrating using Magma as a totally-sustainable and scalable MC repository. Employing a Magma-based Repository also affords some additional benefits, which I will describe in a separate follow-up mail. I think SqueakSource will eventually have to change to something more scalable. At least now we have have a viable alternative, and with much cleaner MC code in the process. Please load my latest versions of Monticello, MonticelloConfigurations, Installer and Tests from the Inbox and let me know if you experience any issues. You should not see any difference in day-to-day operations. - Chris

1 1

[Pharo-project] [update 1.3] #13079
by StÃ©phane Ducasse March 12, 2011

March 12, 2011

13079 ----- - Issue 3600: Enhancement : Refactorings and tests on Balloon-Collections. Thanks HJO :) and Henrik Johanssen. Stef

1 0

[Pharo-project] Issue 3600 in pharo: Enhancement : Refactorings and tests on Balloon-Collections.
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Status: New Owner: ---- New issue 3600 by daliot...@gmail.com: Enhancement : Refactorings and tests on Balloon-Collections. http://code.google.com/p/pharo/issues/detail?id=3600 Refactoring is mainly about moval of a set of methods that PointArray and ShortPointArray share its definition. Both classes does not share common superclass, therefore a helper class named "FriendOfPointArray"is introduced. Attachments: Balloon-hjo.73.mcz 83.0 KB

1 2

[Pharo-project] Issue 3732 in pharo: default omni browser size bigger
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Status: Accepted Owner: guillerm...@gmail.com Labels: Milestone-1.2-DevImage New issue 3732 by guillerm...@gmail.com: default omni browser size bigger http://code.google.com/p/pharo/issues/detail?id=3732 please :)

1 5

Re: [Pharo-project] Issue 1959 in pharo: Replace isSomething by is: #
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Comment #10 on issue 1959 by stephane...@gmail.com: Replace isSomething by is: # http://code.google.com/p/pharo/issues/detail?id=1959 We should probably revert this is: because this is a bad idiom.

1 0

Re: [Pharo-project] Issue 2058 in pharo: Code styling to Workspace
by pharo＠googlecode.com March 12, 2011

March 12, 2011

Comment #6 on issue 2058 by stephane...@gmail.com: Code styling to Workspace http://code.google.com/p/pharo/issues/detail?id=2058 Probably not needed anymore.

1 0