April 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Slow image

by astares＠gmx.de

Anyone with a win32 system able to confirm that the new image slows heavily down as descibed in [1] using the procedure in [2]? After a first rough test I think it happens after the "Delay" fixes from update 10287/10288 Thx T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-April/007910.html [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-April/007934.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

April 28, 2009

Re: [Pharo-project] Preference initialization

by Michael Rueger

On Tue, Apr 28, 2009 at 9:15 AM, Alain Plantec <alain.plantec(a)free.fr> wrote: > If I well understand, the problem is as follow: > You have a preference which value is a class (InputSensor). > The problem is that the class InputSensor can be removed or changed, > letting your preference value > point to AnObsoleteInputSensor. You would like to be warned that > InputSensor is used as a preference value > when you're about to remove that class. > Do I understand well ? Yes and no. ;-) I don't think classes should be referenced directly as preference values, but that is a different discussion. In my case it was the changeInformee inst var that pointed to that class. And that inst var can only be set programmatically. But, there is no code in the system that does that anymore. > For such a situation, the new setting package can provide the > initialization code you would like with the help of a SettingStyle. > A SettingStyle only responsibility is to provide a load method which, > when evaluated, re-generates > settings. > We could have a "current" SettingStyle always up-to-date and which would > be automatically changed (generating of the load method) > every time a setting value is changed. Of course, then, a simple setting > change would be time consuming > but I guess this is not very important because settings are set rarely. > > what do you think ? I think that would be overkill. Preference initialization code doesn't need to be able to create the current settings, only a default set of settings. But your proposal have me a different idea how to solve the problem for preference values: For references to objects or classes in the value entry it would help to have the class reference search also go through the preference values. That way you would get informed of references to a class from preferences before removing the class. There are probably other well known locations that should be checked (e.g. Object Dependents). Michael

April 28, 2009

Re: [Pharo-project] Preference initialization

by Alain Plantec

Michael Rueger a Ã©crit : > Hi all, > > while working on the sensor fix I ran across the problem that there is > no initialization code for current preference settings, a typical side > effect of working with an image. > > Problem is, that references, in my case to the class InputSensor, can't > be found by the usual cross reference methods. > > IMHO we should come up with "something" so we can re-generate the > current preferences from code if needed. That initialization code would > also provide the necessary cross references. > > Not sure how that plays with the pragma preference stuff... > If I well understand, the problem is as follow: You have a preference which value is a class (InputSensor). The problem is that the class InputSensor can be removed or changed, letting your preference value point to AnObsoleteInputSensor. You would like to be warned that InputSensor is used as a preference value when you're about to remove that class. Do I understand well ? For such a situation, the new setting package can provide the initialization code you would like with the help of a SettingStyle. A SettingStyle only responsibility is to provide a load method which, when evaluated, re-generates settings. We could have a "current" SettingStyle always up-to-date and which would be automatically changed (generating of the load method) every time a setting value is changed. Of course, then, a simple setting change would be time consuming but I guess this is not very important because settings are set rarely. what do you think ? alain > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

April 28, 2009

[Pharo-project] Suspending process fix

by Igor Stasenko

Hello, i trying to provide a fix to the issue http://bugs.squeak.org/view.php?id=6822 what is needed to make following code work w/o error: |sema proc | sema := Semaphore new. proc := [ sema wait. self error: 'should not be there' ] fork. Processor yield. proc suspend. proc resume. The problem here, is that once you issue a #suspend on a process it puts nil to its myList ivar, ignoring the fact that it could be waiting on semaphore. This leads to disconnecting the process from semaphore, and any subsequent 'sema signal' will be simply lost: suspend | oldList | <primitive: 88> "primitive will fail, if receiver is not active process, which is just our case" myList ifNil:[^nil]. oldList := myList. myList := nil. oldList remove: self ifAbsent:[]. ^oldList the possible fix would be: - add an instance variable to Process, say 'semaphore'. - fix the #suspend to following: suspend | oldList | <primitive: 88> "primitive will fail, if receiver is not active process, which is just our case" myList ifNil:[^nil]. oldList := myList. myList := nil. oldList remove: self ifAbsent:[]. oldList isKindOf: Semaphore ifTrue: [ semaphore := oldList ]. ^oldList - then, in the #resume resume suspendedContext ifNil: [^ self primitiveFailed]. semaphore ifNotNil: [ semaphore resumeWaiting: self. semaphore := nil. ^ self. ] ^ self primitiveResume and Semaphore>>resumeWaiting: aProcess excessSignals>0 ifTrue: [excessSignals := excessSignals-1. aProcess primitiveResume. "resume immediately" ] ifFalse: [self addLastLink: aProcess] ---------- An attached file is the changeset which makes following test to work w/o failure: |sema proc bool | bool := true. sema := Semaphore new. proc := [ sema wait. bool ifTrue: [self error: 'should not be there']. Transcript show: 'semaphore signaled' ] fork. Processor yield. proc newSuspend. proc newResume. self assert: (sema last == proc). bool := false. sema signal. P.S. i didn't checked how this fix will affect other things around processes, like mentioned by Mike: Note that Process>>signalException: (as of in Squeak 3.8, it may be fixed in later versions?) relies on this broken behaviour. -- Best regards, Igor Stasenko AKA sig.

April 28, 2009

Re: [Pharo-project] Preference initialization

by Igor Stasenko

2009/4/27 Michael Rueger <m.rueger(a)acm.org>: > Hi all, > > while working on the sensor fix I ran across the problem that there is > no initialization code for current preference settings, a typical side > effect of working with an image. > > Problem is, that references, in my case to the class InputSensor, can't > be found by the usual cross reference methods. > > IMHO we should come up with "something" so we can re-generate the > current preferences from code if needed. That initialization code would > also provide the necessary cross references. > You're right. An image should not contain artifacts, which can be reproduced only by wizardry (manual doits). > Not sure how that plays with the pragma preference stuff... > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 27, 2009

Re: [Pharo-project] Preference initialization

by Nicolas Cellier

Hehe, a lot of class initialization code could be removed once used... That would make the system even harder to understand/change. Among obvious reasons why this kind of code should be kept somewhere else than a doIt in a forgettable changeLog: - going toward a more modular system... - ...that can enable a change of UI, - making system easier to understand by making some object relationships explicit, - and being able to build an image ex-nihilo You gain a +(5 raisedToTheSuperPowerOf: 5) (Don't try and evaluate it) Integer>>#raisedToTheSuperPowerOf: anInteger anInteger < 0 ifTrue: [^self error: 'requires a positive integer argument']. anInteger = 0 ifTrue: [^1]. anInteger = 1 ifTrue: [^self]. ^self raisedTo: (self raisedToTheSuperPowerOf: anInteger - 1) Nicolas 2009/4/27 Michael Rueger <m.rueger(a)acm.org>: > Hi all, > > while working on the sensor fix I ran across the problem that there is > no initialization code for current preference settings, a typical side > effect of working with an image. > > Problem is, that references, in my case to the class InputSensor, can't > be found by the usual cross reference methods. > > IMHO we should come up with "something" so we can re-generate the > current preferences from code if needed. That initialization code would > also provide the necessary cross references. > > Not sure how that plays with the pragma preference stuff... > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 27, 2009

Re: [Pharo-project] Random failures with Linux VM

by Michael Rueger

On Mon, Apr 27, 2009 at 10:18 PM, Bryce Kampjes <bryce(a)kampjes.demon.co.uk> wrote: > I'll try to reproduce your exact problem here. The problem is that it is truly random. I just worked a few hours and everything seemed ok. just an idea: it could be related to the network code, as a least the failure in my case seemed to occur relatively early when checking the repositories. Michael

April 27, 2009

Re: [Pharo-project] Recent changes to Pharo

by Victor Rodriguez

On Fri, Apr 17, 2009 at 10:15 PM, Scott Gibson <wsgibson(a)windstream.net> wrote: > I have noticed with the newer releases (pharo0.1-10277dev09.04.2 and > pharo0.1-10279dev09.04.3) there, which seemed to me, to be fixes/ > improvements that were lost from the earlier (Pharo0.1Core-10268cl and > pharo0.1-10268dev09.04.1) releases. Â These following occur for both > the Mac and Windows platforms: Hello Scott, This message is not related to Pharo, but rather to messages I keep getting about "please release container X". I think you may have included me in a message by mistake. I hope you can do something to stop these messages. Kind regards, Victor Rodriguez. > #1) Running "(1 to: 100) do: [:each | Transcript show: each; cr]" is > near instantaneous in the Transcript window compared to the more > recent releases. > > #2) For the process "the UI process" in the Process Browser - when > "the UI process" is selected processes actually show up but not in the > more recent releases. > > #3) The debugger buttons are once again centered and squished in the > middle of the debugging window. Â Is this actually now the norm? > > I am not sure exactly what is expected for these in Pharo's current > state but it seemed that perhaps some fixes had reverted and I should > submit issues for them. Â Was version 10268 the anomaly or are these > actual issues? > > > Thanks! > Scott > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 27, 2009

Re: [Pharo-project] Random failures with Linux VM

by Bryce Kampjes

On Mon, 2009-04-27 at 22:08 +0200, Michael Rueger wrote: > On Mon, Apr 27, 2009 at 10:04 PM, Bryce Kampjes > <bryce(a)kampjes.demon.co.uk> wrote: > > > > What version of Ubuntu are you using? I'm running 8.04 here and it's > > stable. > > 8.04 (I think, don't have access right now). > > I wonder if it could be something with running in VirtualBox, but that > seems rather far fetched. I'll try to reproduce your exact problem here. Bryce

April 27, 2009

Re: [Pharo-project] Random failures with Linux VM

by Michael Rueger

On Mon, Apr 27, 2009 at 10:04 PM, Bryce Kampjes <bryce(a)kampjes.demon.co.uk> wrote: > What version of Ubuntu are you using? I'm running 8.04 here and it's > stable. 8.04 (I think, don't have access right now). I wonder if it could be something with running in VirtualBox, but that seems rather far fetched. Michael

April 27, 2009