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 |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
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
|
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 <[hidden email]> wrote: Hi: |
Administrator
|
In reply to this post by Hilaire Fernandes
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
Cheers,
Sean |
Administrator
|
In reply to this post by Stefan Marr-3
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."
Cheers,
Sean |
In reply to this post by Sean P. DeNigris
| 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" <[hidden email]> To: <[hidden email]> 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. > |
Free forum by Nabble | Edit this page |