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

[Pharo-project] End of startup script behavior changed ?
by StÃ©phane Ducasse Feb. 15, 2012

Feb. 15, 2012

Please help sven :) Begin forwarded message: > Status: Accepted > Owner: ---- > Labels: Milestone-1.4 Type-Bug > > New issue 5300 by sven.van...(a)gmail.com: End of startup script behavior changed ? > http://code.google.com/p/pharo/issues/detail?id=5300 > > Guys, > > Maybe I missed this, but did something change with the behavior at the end of a startup script between 1.3 and 1.4 ? > > It used to be that the image kept on running unless you asked it to quit explicitly, now it seems that the image automatically quits unless you keep it busy. Can someone confirm this ? Was this intentional ? > > What would be the recommended way to keep the image open ? > > Somehow something like > > [ (Delay forDuration: 1 hour) wait ] repeat. > > seems so silly, but it works. > > Thx, > > Sven

2 1

[Pharo-project] FSPath withExtension: bug
by Esteban Lorenzano Feb. 15, 2012

Feb. 15, 2012

hi, FSPath>>#withExtension: is ignoring adding extension if extension is equal to end of basename. For example, if I want to produce: (FSFilesystem disk workingDirectory / 'Host') withExtension: 'st'. I should receive: /path/to/Host.st but I actually receive: /path/to/Host that can be fixed replacing FSPath>>#withExtension: extension | basename name | basename := self basename. ^ (basename endsWith: extension) ifTrue: [ self ] ifFalse: [name := basename copyUpToLast: self extensionDelimiter. self withName: name extension: extension] with: FSPath>>#withExtension: extension | basename name | basename := self basename. ^ (basename endsWith: '.', extension) ifTrue: [ self ] ifFalse: [name := basename copyUpToLast: self extensionDelimiter. self withName: name extension: extension] but I don't know if that would be a good solution :) best, Esteban

6 7

[Pharo-project] slowly preparing 1.4: list of actions ...
by StÃ©phane Ducasse Feb. 15, 2012

Feb. 15, 2012

Hi guys I went over the script loader descriptions and built the following list of items we did (I went up to 14240). http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotFour If you could go over the list and write a small 2-3 lines, it would be really helpful. Stef

1 0

[Pharo-project] [update 1.4] #14333
by StÃ©phane Ducasse Feb. 15, 2012

Feb. 15, 2012

14333 ----- - Issue 5281: Refactor in LazyListMorph. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=5281 Stef

1 0

[Pharo-project] where is RPackageOrganiser
by Ben Coman Feb. 15, 2012

Feb. 15, 2012

I am working through the draft PBE2 chapter on Glamour [1], which has the following on page 5: PBE2CodeNavigator>>organizer ^ RPackageOrganizer default RPackageOrganizer is not in my image (Pharo-1.3-13315). How can I install this ? I have been unable to google anything useful. cheers, -ben [1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Gla…

2 1

[Pharo-project] [update 1.4] #14333
by StÃ©phane Ducasse Feb. 15, 2012

Feb. 15, 2012

14333 ----- - Issue 5281: Refactor in LazyListMorph. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=5281

1 0

[Pharo-project] [update 1.4] #14332
by StÃ©phane Ducasse Feb. 15, 2012

Feb. 15, 2012

14332 ----- - Issue 5283: Little refactor in PluggaleListMorph. Thanks Benjamin.VanRyseghem. http://code.google.com/p/pharo/issues/detail?id=5283 - Issue 5298: Infinite Loop in MenuRegistration.Thanks Benjamin.VanRyseghem. http://code.google.com/p/pharo/issues/detail?id=5298 - Issue 5288: Introduce a new method in the searching method of PluggableListMorph. Thanks Benjamin.VanRyseghem. http://code.google.com/p/pharo/issues/detail?id=5288

1 0

[Pharo-project] faster process to move to gemstone
by Camillo Bruni Feb. 15, 2012

Feb. 15, 2012

yesterday I did my daily batch conversion to gemstone and I came up with a slightly faster process. If you use gofer I fear that all the monticello versions are completely parsed before being saved / uploaded. I tried to avoid this using wget to download all the versions and then script the upload ========================================================================== # bash, takes around 1min vs 10mins with gofer wget --mirror --page-requisites http://www.squeaksource.com/Citezen/ # pharo f := FSFilesystem disk workingDirectory / 'www.squeaksource.com' / 'Citezen'. files := f glob: [ :f| f basename endsWith: '.mcz']. files do: [ :file ||entity stream| stream := file readStream. (entity := ZnStreamingEntity type: ZnMimeType applicationOctetStream) stream: stream; contentLength: stream size. Transcript show: file; cr. "upload the version to gemstone" ZnClient new systemPolicy; beOneShot; signalProgress: true; ifFail: [ :exception | Transcript show: file basename; show: ' '; print: exception ]; username: 'XXX' password: 'XXX'; entity: entity; url: ( 'http://ss3.gemstone.com/ss/citezen/', file basename); put ] displayingProgress: 'Uploading mzcs' ========================================================================== best cami

2 3

Re: [Pharo-project] Are Objects really hard?
by Marcus Denker Feb. 15, 2012

Feb. 15, 2012

On Feb 13, 2012, at 2:47 PM, Guido Stepken wrote: > I did analyse some of these "memory pumping effects" in Pharo. Come from overuse of "inheritance", that causes big objects with hundreds of methods to be created and garbaged, just for short tasks. > The number of methods do not influence *at all* the size on an object. Methods are on the class, the object point to its class, no need to allocate *any* memory. The only thing that costs memory is *state*. Marcus -- Marcus Denker -- http://marcusdenker.de

17 48

[Pharo-project] Enhancement: Browsing SLICE dependencies with tree view in Monticello Repository Inspector
by Ben Coman Feb. 15, 2012

Feb. 15, 2012

I originally thought something was wrong when I could not browse the code of a SLICE using Monticello. After hunting around I found [1] saying this is expected behaviour. However I then suggest the following enhancement: Have the right-pane of the Monticello Repositoy Inspector be a tree view, such that dependencies are the children which can then be <Browsed> together from the one place, rather than having to chase them manually. This seems more intuitive usage, especially for those not familiar with what slices are. (I had to hunt around for 5 minutes to find out) What do you think? cheers, -ben [1] http://code.google.com/p/pharo/issues/detail?id=1606 says " <Browse> in MC only browses the contents of the *selected* package - not of dependent packages. Therefore the slice package always looks empty, because it actually is empty."

2 2