Re: [Pharo-project] Worskpace question
I don't think its related to the processes priority. Can you provide more code of the DrGeoCanvas>>#initialize ? Because, the following works just fine, by evaluating the first two lines, or the complete script. m := Morph new. m openInWorld. m color: Color red. m extent: 300@300. m delete Fernando On Wed, Jun 20, 2012 at 12:16 PM, Hilaire Fer nandes <hilaire.fernandes@edu.ge.ch> wrote:
DHello,
I have a question regarding the Workspace when you execute code from there.
Let me show with an example:
I want to execute code instantiating an empty DrGeo sketch (a morph) then create programmatically content:
|canvas| canvas := DrGeoCanvas new. canvas segment: 5@4 to: 10@20. canvas vector: 0@0 to: 2@2. ...
The line with DrGeoCanavas creates and opens a new morph of a DrGeo sketch.
My problem is: the morph only shows up on screen when the whole Workspace code is executed. I would like the canvas morph to show up when instantiated then get the construction code done step by step in the screen.
Is the workspace code executed with higher priority than the user interface thread?
Thanks
Hilaire
-- Dr. Geo -- http://www.drgeo.eu
But try this code, and you will get my point: | m | m := Morph new. m openInWorld. m color: Color red. 1 to: 300 do: [:x | m extent: x@300. (Delay forMilliseconds: 10) wait. ]. m delete. I want to see the animation of the growing morph. Instead I get nothing. To get the animation, you have to enclose the loop in a forked process, but it is inelegant: | m | m := Morph new. m openInWorld. m color: Color red. [1 to: 300 do: [:x | m extent: x@300. (Delay forMilliseconds: 10) wait. ]. m delete] fork. Hilaire On 20/06/2012 13:23, Fernando Olivero wrote:
I don't think its related to the processes priority.
Can you provide more code of the DrGeoCanvas>>#initialize ?
Because, the following works just fine, by evaluating the first two lines, or the complete script.
m := Morph new. m openInWorld.
m color: Color red. m extent: 300@300.
m delete
Fernando
On Wed, Jun 20, 2012 at 12:16 PM, Hilaire Fer nandes <hilaire.fernandes@edu.ge.ch> wrote:
DHello,
I have a question regarding the Workspace when you execute code from there.
Let me show with an example:
I want to execute code instantiating an empty DrGeo sketch (a morph) then create programmatically content:
|canvas| canvas := DrGeoCanvas new. canvas segment: 5@4 to: 10@20. canvas vector: 0@0 to: 2@2. ...
The line with DrGeoCanavas creates and opens a new morph of a DrGeo sketch.
My problem is: the morph only shows up on screen when the whole Workspace code is executed. I would like the canvas morph to show up when instantiated then get the construction code done step by step in the screen.
Is the workspace code executed with higher priority than the user interface thread?
Thanks
Hilaire
-- Dr. Geo -- http://www.drgeo.eu
-- Dr. Geo -- http://www.drgeo.eu
On 21 Jun 2012, at 15:11, Hilaire Fernandes wrote:
I want to see the animation of the growing morph. Instead I get nothing.
To get the animation, you have to enclose the loop in a forked process, but it is inelegant:
Isn't the doIt evaluated in the UI processes? I bet there is a Morphic API that allows you to process the next drawing request. If the doIt is not evaluated in the UI process, just to a `Processor yield` after every step you want to see. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On Thu, Jun 21, 2012 at 3:44 PM, Stefan Marr <smalltalk@stefan-marr.de>wrote:
On 21 Jun 2012, at 15:11, Hilaire Fernandes wrote:
I want to see the animation of the growing morph. Instead I get nothing.
To get the animation, you have to enclose the loop in a forked process, but it is inelegant:
Isn't the doIt evaluated in the UI processes?
It is!
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...
If the doIt is not evaluated in the UI process, just to a `Processor yield` after every step you want to see.
Sometimes, when processing in different process, the correct way is to send updates to the UI process through World addDeferredUIMessage: [ ... ] Cheers, Guille
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi: On 21 Jun 2012, at 15:57, Guillermo Polito 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: MorphicUIManager>>#spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess resume Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Maybe for a 5' experiment is well :). But World doOneCycle do handle events also, not just rendering, what should lead to a wrong state :). I don't forbid anybody to use it, just tell him to think about it :P. On Thu, Jun 21, 2012 at 4:13 PM, Stefan Marr <smalltalk@stefan-marr.de>wrote:
Hi:
On 21 Jun 2012, at 15:57, Guillermo Polito 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:
MorphicUIManager>>#spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess resume
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
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.
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.
| 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@clipperadams.com> To: <pharo-project@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.
participants (6)
-
Fernando Olivero -
Gary Chambers -
Guillermo Polito -
Hilaire Fernandes -
Sean P. DeNigris -
Stefan Marr