- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Issue 2247 in pharo: MessageNotUnderstood: NewInspector class>>openOn:withEvalPane:withLabel:

by pharo＠googlecode.com

Updates: Status: Started Labels: -Milestone-1.1 Milestone-1.2-DevImage Comment #4 on issue 2247 by marcus.denker: MessageNotUnderstood: NewInspector class>>openOn:withEvalPane:withLabel: http://code.google.com/p/pharo/issues/detail?id=2247 The problem is the NewInspector. Dev 1.2 should be build without it.

Dec. 13, 2010

Re: [Pharo-project] Is SmallInteger a really too dangerous class?

by Mariano Martinez Peck

Ups....you are right bill, my example was wrong....it should be: SmallInteger class >> initialize self addInstVarName: 'Zaraza'. On Mon, Dec 13, 2010 at 10:05 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 13, 2010 at 9:42 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> Mariano, >> >> SmallInteger is handled as (in Dolphin parlance) as an immediate object, >> meaning that they are encoded entirely in the object pointer; as such, they >> can't have instance variables. Object cannot have ivs either, because it >> has subclasses that are so constrained. >> > > Hi Bill, thanks. Yes, in SqueakVM it is the same...but I am adding an > instVar to the SmallInteger CLASS, not to their instances ;) > but still...,maybe the VM assumes that the SmallInteger CLASS is of certain > fixed size. > > mariano > > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano >> Martinez Peck [marianopeck(a)gmail.com] >> Sent: Monday, December 13, 2010 3:16 PM >> To: Pharo Development; Squeak Development Discussion Virtual Machine >> Subject: [Pharo-project] Is SmallInteger a really too dangerous class? >> >> Hi folks. Sorry for the cross-post, I am not sure if it is image or vm >> problem. >> >> If I implement this: >> >> SmallInteger >> initialize >> self addInstVarName: 'Zaraza'. >> >> I have the error: 'SmallInteger cannot be changed' >> >> This is because SmallInteger is in the ClassBuilder >> tooDangerousClasses >> and the error is in ClassBuilder >> name: className inEnvironment: env >> subclassOf: newSuper type: type instanceVariableNames: instVarString >> classVariableNames: classVarString poolDictionaries: poolString category: >> category unsafe: unsafe >> >> Now....since this is Smalltalk, I can just comment something, continue, or >> any other kind of hack so that I can add class variables to SmallInetger. >> For my CompiledMethod proxies stuff, I am using SmallIntegers and I have >> some crashes (one is due to a corrupt heap and Eliot said something about >> sizes)...I wonder if this is related to this...So the question is: is >> really SMallInteger a too dangerous class so that it cannot be changed? not >> even adding a class variable??? does the VM assume that the class >> SmallInetger has a fixed size? if true, where? >> >> Thanks in advance >> >> Mariano >> >> >

Dec. 13, 2010