- Pharo-dev - lists.pharo.org

[Pharo-project] Any south american in this list?

by Alexandre Bergel

I am pretty sure that yes. Would you mind to ping me? I will visit Argentina (La Plata / Bueno Ares) at the end of July. A Pharo party may be organized? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2009

Re: [Pharo-project] Cmd-D does not work anymore?

by Alexandre Bergel

Image: the last Core, a plain 281. VM: Squeak 4.1.0beta1U Cheers, Alexandre On 28 Apr 2009, at 11:48, Michael Rueger wrote: > Alexandre Bergel wrote: >> I found this pretty handy. I can have a look at it if nobody yet >> did so. > > which image and VM version and platform are you using? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2009

Re: [Pharo-project] Cmd-D does not work anymore?

by Michael Rueger

Alexandre Bergel wrote: > I found this pretty handy. I can have a look at it if nobody yet did so. which image and VM version and platform are you using? Michael

April 28, 2009

[Pharo-project] Cmd-D does not work anymore?

by Alexandre Bergel

I found this pretty handy. I can have a look at it if nobody yet did so. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2009

[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