strange bug in squeak 4.2 & 4.3 alpha running Cog, MTCog and regular VMs on a Mac

When I run the following code, I start to get  MNU:
UndefinedObject>>containsPoint   errors.

http://pastebin.com/TTDmSnZS

The errors show up with Intel Macs running Mac OS X 19.6.8 using  Squeak
4.2 all-in-one, Cog with Squeak4.2-10966 and CogMT2489 and Cog2489 with
both Squeak 4.3alpha-11314 and Squeak4.3alpha11636.

In order to get the errors open Squeak, open a workspace and transcript
and paste teh above code into the workspace. Select the part above the
"++++++++...+++++++" and do-it

then select the part within  the two comments (myGrid delete. Smalltalk
garbageCollect) and do-it.

then iterate manually with i = 2 through 10 and evaluate the lower half
of the code (below the comments)

Eventually you get one or more MNU: UndefinedObject>>containsPoint  errors


When I do THIS code: http://pastebin.com/Mp0aZLUj

the errors seem to go away, but the overhead of the 1000+ GC calls is
way too much.

Suggestions? I was testing to see if I could prototype a 2D shooter in
Squeak using morphs for the bitmaps when the bug showed up.

Thanks.


Lawson

On 06.09.2011, at 04:44, Lawson English wrote:

> When I run the following code, I start to get  MNU: UndefinedObject>>containsPoint   errors.
>
> http://pastebin.com/TTDmSnZS

Not a bug. Morphic is single-threaded and not re-entrant. You must not call any morphic methods from a forked process. If you do, you get exactly those kind of errors.

Instead of forking, use the step mechanism for animation. This is what you would use in a real application.

For prototyping in a workspace, do not fork, but insert a "World doOneCycleNow" in the loop. This should never be used in production code. Here is what this would look like with your example:

n := 100.
myRectArray := (1 to: n) collect: [:i | RectangleMorph new].
rnd := [(-500 to: 500) atRandom].
myGrid := PasteUpMorph new openInWorld.
myGrid extent: 1100@1100.
myRectArray do: [:m | myGrid addMorph: m].
p := myGrid center.
Transcript show: ([
        1000 timesRepeat: [
                myRectArray do: [:m | m center: p + (rnd value@rnd value)].
                World doOneCycleNow].
] timeToRun); cr.
myGrid delete.

On my machine this loop takes 5 seconds, so that's 200 fps (animating 100 objects for 1000 frames).

- Bert -

On 9/6/11 3:47 AM, Bert Freudenberg wrote:
Thanks. I really should have know better.

L

> For prototyping in a workspace, do not fork, but insert a "World doOneCycleNow" in the loop. This should never be used in production code. Here is what this would look like with

Thanks for sharing your Morphic wisdom.  May I ask for your thoughts
on WorldState class>>#addDeferredUIMessage: for background Morphic
operations..?

On 07.09.2011, at 04:42, Chris Muller wrote:

>> For prototyping in a workspace, do not fork, but insert a "World doOneCycleNow" in the loop. This should never be used in production code. Here is what this would look like with
>
> Thanks for sharing your Morphic wisdom.  May I ask for your thoughts
> on WorldState class>>#addDeferredUIMessage: for background Morphic
> operations..?

That's the official way to communicate with Morphic from a different process, yes. The block argument will be evaluated within the Morphic process on the next world cycle, so this is safe.

However, this is not how you would typically do animation in Morphic (in contrast to some other UI frameworks that use timer threads for that). For animation you would override the step method.

- Bert -