December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3411 in pharo: FileDIrectory - search methods - unnecessary code & unclear use of read only

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3411 by rhaw...(a)plymouth.ac.uk: FileDIrectory - search methods - unnecessary code & unclear use of read only http://code.google.com/p/pharo/issues/detail?id=3411 In FileDirectory, category 'search', the method: withAllFilesDo: fileStreamBlock andDirectoriesDo: directoryBlock - has a line that I think does nothing: directoryBlock value: dir. - inexplicably makes reference to read only files for reasons that are not encapsulated in the method title, and which appear to be irrelevant to the purpose. (Well, I can't see the point!) That method is called from the method: filesContaining: searchString caseSensitive: aBoolean - but that is apparently unused (there are no senders).

Dec. 14, 2010

Re: [Pharo-project] TODO for 1.2...

by Guillermo Polito

Marcus, Here we have a "blue" build: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/11/ How did you manage that? :P Did you remove the test run from the build? Guille On Mon, Dec 13, 2010 at 1:54 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Open Bugs: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2 > > Failing Tests: > > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… > > > and a failing build of non-Core: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/8/console > > > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Dec. 14, 2010

Re: [Pharo-project] super initialize is not a good idea for Behaviors ; )

by Mariano Martinez Peck

On Mon, Dec 13, 2010 at 11:33 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 12/13/2010 03:28 PM, Mariano Martinez Peck wrote: > >> Hi folks. After a couple of hours of trying to find a problem, I finally >> come to the cause: using super initialize is not always good. >> When I implement #initialize, I ALWAYS do "super initialize" in the >> first line of such method. Today, I found a problem while doing this in >> class side #initialize. >> > > You should only super init on the instance side, not the class side; pretty > sure this is a well known issue. > heheheh I leart it today, in the "hard way" ;) thanks ramon > -- > Ramon Leon > http://onsmalltalk.com > >

Dec. 13, 2010

Re: [Pharo-project] super initialize is not a good idea for Behaviors ; )

by Ramon Leon

On 12/13/2010 03:28 PM, Mariano Martinez Peck wrote: > Hi folks. After a couple of hours of trying to find a problem, I finally > come to the cause: using super initialize is not always good. > When I implement #initialize, I ALWAYS do "super initialize" in the > first line of such method. Today, I found a problem while doing this in > class side #initialize. You should only super init on the instance side, not the class side; pretty sure this is a well known issue. -- Ramon Leon http://onsmalltalk.com

Dec. 13, 2010

[Pharo-project] super initialize is not a good idea for Behaviors ; )

by Mariano Martinez Peck

Hi folks. After a couple of hours of trying to find a problem, I finally come to the cause: using super initialize is not always good. When I implement #initialize, I ALWAYS do "super initialize" in the first line of such method. Today, I found a problem while doing this in class side #initialize. I have a particular class and I did: MyClass class >> initialize super initialize. "My own specific code to run" But when sending MyClass initialize, I discovered that the "super initialize" did something I wasnt aware: Behavior >> initialize "moved here from the class side's #new" super initialize. superclass := Object. "no longer sending any messages, some of them crash the VM" methodDict := self emptyMethodDictionary. format := Object format in my case MyClass has subclass from ProtoObject, not Object. And of course, I got an empy method dictionary...etc. So...I just wanted to share my problem to avoid other's one. Cheers Mariano

Dec. 13, 2010

[Pharo-project] Background changer script kills Pharo

by Tony Fleig

I tried using the following background changer for Pharo (from http://book.pharo-project.org/book/CustomizingPharo/PuttingABackgroundPictu…) All was well and it nicely changed the background image to various images from socwall.com. I walked away and when I came back, Pharo was no longer running. To make a long story short, on Linux and OS X (I did not try Windows), after some period of time, regardless of whether I am actively using Pharo, Pharo either hangs (becomes unresponsive to input, using 100% CPU, images no longer changing) or disappears abruptly. I tried several variations of the script, including loading images from a local directory (i.e. no network code at all) and even loading images into an ImagePreview morph. In all cases, Pharo eventually either aborts or hangs. I have found nothing in the logs to indicate what happened -- no entries at the time of the abort or hang at all. Decreasing the delay seems to make it happen sooner; I can usually make it happen within 15 minutes of execution with a 2 second delay. It seems to happen more quickly when changing the background image than in an ImagePreview morph. I monitored Pharo's memory usage and it increased from 106 MB to 109 MB during the execution. Plenty of free memory on the system. My questions are: 1. How to debug this? Log to a file to see where it is hanging? 2. How to regain control of a hung Pharo. I tried Cmd-<everything> to no avail. 3. Does anyone have any idea what might be happening? Some resource being used up, a race condition, etc.? Here's the original script [[[ | rx str url form | str := (HTTPSocket httpGet: 'http://www.socwall.com/browse/index.php?wpLimit=1&wpSortby=8') contents. rx := '.*(http\://.+tb_.+\.jpg).*' asRegex. url := (rx matches: str) ifTrue: str := (rx subexpression: 2) copyWithRegex: 'tb_' matchesReplacedWith: '' ] ifFalse: [ nil ]. url ifNotNil: [ form := ImageReadWriter formFromStream: (HTTPSocket httpGet: url). World backgroundImage: form layout: #scaled]] on: Error do: [:ex| ]. 1 minute asDelay wait ] repeat ] newProcess name: 'Random background changer'; priority: Processor userBackgroundPriority; resume Regards, TF

Dec. 13, 2010

[Pharo-project] Issue 3410 in pharo: Remove NEwInspector from Dev

by pharo＠googlecode.com

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2-DevImage New issue 3410 by marcus.denker: Remove NEwInspector from Dev http://code.google.com/p/pharo/issues/detail?id=3410 NEwInspector should not be part of dev. Reason: Inspector needs to be minimal. Explorer is for tree-like display. In addition: Inspector is core functionality, an inspector added in -dev is far too buggy.

Dec. 13, 2010

[Pharo-project] Issue 3409 in pharo: KillTextConstants class and package needs to be removed

by pharo＠googlecode.com

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2 New issue 3409 by marcus.denker: KillTextConstants class and package needs to be removed http://code.google.com/p/pharo/issues/detail?id=3409 KillTextConstants class and package needs to be removed

Dec. 13, 2010

[Pharo-project] Issue 3408 in pharo: Remove an unsent message from DialogItemsChooserUI (reference to non-existing ivar)

by pharo＠googlecode.com

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3408 by marcus.denker: Remove an unsent message from DialogItemsChooserUI (reference to non-existing ivar) http://code.google.com/p/pharo/issues/detail?id=3408 Remove an unsent message from DialogItemsChooserUI (reference to non-existing ivar) Attachments: SmallCleans.1.cs 632 bytes

Dec. 13, 2010

Re: [Pharo-project] Issue 3271 in pharo: r isLiteralSymbol: #<= is broken

by pharo＠googlecode.com

Comment #1 on issue 3271 by nicolas.cellier.aka.nice: r isLiteralSymbol: #<= is broken http://code.google.com/p/pharo/issues/detail?id=3271 Also works in Squeak

Dec. 13, 2010