Worskpace question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Worskpace question

Hilaire Fernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Fernando olivero-2
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Hilaire Fernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Stefan Marr-3

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


Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Guillermo Polito

On Thu, Jun 21, 2012 at 3:44 PM, Stefan Marr <[hidden email]> 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: <a href="tel:%2B32%202%20629%202974" value="+3226292974">+32 2 629 2974
Fax:   <a href="tel:%2B32%202%20629%203525" value="+3226293525">+32 2 629 3525



Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Stefan Marr-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Guillermo Polito
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:

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: <a href="tel:%2B32%202%20629%202974" value="+3226292974">+32 2 629 2974
Fax:   <a href="tel:%2B32%202%20629%203525" value="+3226293525">+32 2 629 3525



Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Sean P. DeNigris
Administrator
In reply to this post by Hilaire Fernandes
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Sean P. DeNigris
Administrator
In reply to this post by Stefan Marr-3
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."
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Worskpace question

Gary Chambers-4
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.
>