- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Worskpace question

by Gary Chambers

| m | m := Morph new. m openInWorld. m color: Color red. [1 to: 300 do: [:x | WorldState addDeferredUIMessage: [m extent: x@300]. (Delay forMilliseconds: 10) wait. ]. WorldState addDeferredUIMessage: [m delete] ] fork. would be the proper way to do things to avoid unpleasant side effects Though, for this example, you can get away with the following: | m | m := Morph new. m openInWorld. m color: Color red. 1 to: 300 do: [:x | m extent: x@300. World displayWorldSafely. (Delay forMilliseconds: 10) wait. ]. m delete Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean(a)clipperadams.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, June 21, 2012 4:51 PM Subject: Re: [Pharo-project] Worskpace question > > Hilaire Fernandes wrote >> >> To get the animation, you have to enclose the loop in a forked process, >> but it is inelegant: >> ... >> [1 to: 300 do: [:x | >> m extent: x@300. >> (Delay forMilliseconds: 10) wait. >> ]. >> m delete] fork. >> > > Hilaire, why don't you like this? It seems very straightforward. You're > doing a long-running operation and you want another thread to run > concurrently. Fork seems like the natural choice. > > The only other issue is #addDeferredUIMessage: which Guille mentioned. I'm > unclear exactly what kinds of Morphic interaction require it and haven't > been able to get a clear answer. Your sample block doesn't seem to hurt > morphic, but if you experience weirdness (like red X's), that's probably > where to look. > > Sean > > -- > View this message in context: > http://forum.world.st/Worskpace-question-tp4635656p4635943.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 21, 2012

Re: [Pharo-project] Spec version 1.0

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > > I am glad to announce the version 1.0 of Spec which introduce a couple of > nice features like: > Really cool!! And great documentation :) It was thorough and clear, except maybe using â could be confusing... -- View this message in context: http://forum.world.st/Spec-version-1-0-tp4635822p4635950.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] badDirectoryPath

by Sean P. DeNigris

Camillo Bruni-3 wrote > > I would assume mostly due to performance.... > We should be clear on the reason and put a comment. This is an unusual (cough... c-like) pattern in Smalltalk. Also, lookupDirectory:filename: returns #badDirectoryPath on primitive failure. Is that a good idea? It seems like it could lead to confusing errors ("what do you mean bad path?!?! I'm looking right at the @%#$ file!). Why not send primitiveFailed? -- View this message in context: http://forum.world.st/badDirectoryPath-tp4635913p4635948.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,win - Build # 144 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 21, 2012

Re: [Pharo-project] Worskpace question

by Sean P. DeNigris

Stefan Marr-3 wrote > >> I bet there is a Morphic API that allows you to process the next drawing >> request. >> >> Hmm, that sounds like forcing the framework... I think that having a >> second process is the right way... > > For an experiment? Getting the concurrency right in a second process sound > a lot less appealing than using `World doOneCycle`, which seems to be used > in other places for the same purpose as well: > Yes, #doOneCycle might work for an experiment... doOneCycle "see the comment in doOneCycleFor:" doOneCycleFor: "...This is a moderately private method; a better alternative is usually either to wait for events or to check the state of things from #step methods." -- View this message in context: http://forum.world.st/Worskpace-question-tp4635656p4635944.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

Re: [Pharo-project] Worskpace question

by Sean P. DeNigris

Hilaire Fernandes wrote > > To get the animation, you have to enclose the loop in a forked process, > but it is inelegant: > ... > [1 to: 300 do: [:x | > m extent: x@300. > (Delay forMilliseconds: 10) wait. > ]. > m delete] fork. > Hilaire, why don't you like this? It seems very straightforward. You're doing a long-running operation and you want another thread to run concurrently. Fork seems like the natural choice. The only other issue is #addDeferredUIMessage: which Guille mentioned. I'm unclear exactly what kinds of Morphic interaction require it and haven't been able to get a clear answer. Your sample block doesn't seem to hurt morphic, but if you experience weirdness (like red X's), that's probably where to look. Sean -- View this message in context: http://forum.world.st/Worskpace-question-tp4635656p4635943.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,win - Build # 143 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 21, 2012

Re: [Pharo-project] badDirectoryPath

by Camillo Bruni

I would assume mostly due to performance.... this #badDirectoryPath happens quite often, hence it is much faster to do a simple check On 2012-06-21, at 16:32, Esteban Lorenzano wrote: > that was changed not much time ago, and... while I don't remember exactly while it was like that, I remember there was a good reason for that > > On Jun 21, 2012, at 4:16 PM, Sean P. DeNigris wrote: > >> lookupDirectory: fullPath filename: fileName >> <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> >> ^ #badDirectoryPath >> >> Why are we returning #badDirectoryPath instead of signaling an exception, >> maybe FileDoesNotExist? >> >> -- >> View this message in context: http://forum.world.st/badDirectoryPath-tp4635913.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

June 21, 2012

Re: [Pharo-project] red cross during updates

by Sean P. DeNigris

I think I fixed it. See Issue 6099: Deprecate #value: for system progress (was red cross during updates) http://code.google.com/p/pharo/issues/detail?id=6099 -- View this message in context: http://forum.world.st/red-cross-during-updates-tp4635739p4635939.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 21, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,win - Build # 142 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 21, 2012