- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] Remote debugging tools

by Pavel Krivanek

2016-07-29 10:20 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Norbert. > > 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> I see big room for optimizations here. >> Look at very small unit of communication: delivering integer result (from >> [1+2] evaluation). Following object is responsible for this: >> >> request := SeamlessDeliverResultRequest result: >> (SeamlessReturnValueResult with: 3) to: (SeamlessRequestContextReference >> id: 4 peerId: UUID new) . >> stream := ByteArray new writeStream. >> FLSerializer newDefault serialize: request on: stream. >> bytes := stream contents. >> bytes size. "==> 412" >> (ObjectTraveler on: request ) countReferences "==>10" >> >> >> Last line shows that only 10 objects consists full object graph of >> request. And Fuel serialization takes for it 412 bytes. >> It definitely could be improved with specialized serialization protocol. >> Also it could allow object traversal once which will lead to another >> performance improvements. >> > > I start implement optimized protocol and I got really nice results. I > reduce size of packet in my example to 16 bytes. I not measure performance > yet but it should be better too. Also new protocol will allow application > specific optimisations. > So soon we will have really usable tools for your case with slow network. > Nice!

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Denis Kudriashov

Hi Norbert. 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > I see big room for optimizations here. > Look at very small unit of communication: delivering integer result (from > [1+2] evaluation). Following object is responsible for this: > > request := SeamlessDeliverResultRequest result: (SeamlessReturnValueResult > with: 3) to: (SeamlessRequestContextReference id: 4 peerId: UUID new) . > stream := ByteArray new writeStream. > FLSerializer newDefault serialize: request on: stream. > bytes := stream contents. > bytes size. "==> 412" > (ObjectTraveler on: request ) countReferences "==>10" > > > Last line shows that only 10 objects consists full object graph of > request. And Fuel serialization takes for it 412 bytes. > It definitely could be improved with specialized serialization protocol. > Also it could allow object traversal once which will lead to another > performance improvements. > I start implement optimized protocol and I got really nice results. I reduce size of packet in my example to 16 bytes. I not measure performance yet but it should be better too. Also new protocol will allow application specific optimisations. So soon we will have really usable tools for your case with slow network.

July 29, 2016

Re: [Pharo-dev] newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)

by stepharo

Yes I saw it too. Stef Le 28/7/16 Ã 23:30, Dale Henrichs a Ã©crit : > Thanks Nicolai ... that looks exactly like my problem ... I see that > this report is from earlier in July, so it presumably will crop up > randomly .. > > Dale > > On 07/28/2016 02:24 PM, Nicolai Hess wrote: >> Hi Dale, >> >> I think this problem already exists in Pharo 5.0, see bug report >> 18706 >> <https://pharo.fogbugz.com/f/cases/18706/Build-of-Pharo5-is-broken> >> Build of Pharo5 is broken >> >> >> >> 2016-07-28 22:58 GMT+02:00 Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>: >> >> Three additional pieces of info ... >> >> 1. 'canvas' is an instance variable in the WorldState instance >> and is probably a stale instance along with a stale process >> 2. If I bring up the image headful, I get no errors and then if I >> save it, the load works properly ... >> 3. If I run the load on Pharo.image directly without the initial >> ` ./pharo Pharo.image save xxx`, it loads properly >> >> This sequence is in a script that I ship to end users, so if >> `./pharo Pharo.image save xxx` is intended to work, I will wait >> patiently for a bugfix (and submit a bug if necessary -- I >> originally thought that this might have been recently introduced, >> but now I think that this is a bug that is possibly just recently >> exposed) otherwise, I'll have to rewrite the scripts to not rely >> on `./pharo Pharo.image save xxx`. >> >> Dale >> >> On 07/28/2016 01:49 PM, Dale Henrichs wrote: >> >> This sequence of commands was working yesterday and is broken >> today: >> >> ./pharo Pharo.image save xxx; ./pharo xxx.image --quit >> --save ./boom.st <http://boom.st> >> >> The contents of boom.st <http://boom.st> is the following: >> >> Metacello new >> baseline: 'Metacello'; >> repository: >> 'github://dalehenrich/metacello-work:master/repository'; >> onConflict: [:ex | ex allow]; >> load: #( 'batch' ). >> >> I've attached to PharoDebug.log ... The Pharo.image is >> freshly downloaded along with the vm. Needless to say, the >> expression above works when run with a GUI. Oddly enough the >> receiver of #finish looks to be a temp named 'canvas' in the >> middle of the WorkState>>displayWorld:submorphs: method ... >> two lines earlier the' canvas' temp had to have a valid >> value, so this has the look of a zombie process of some sort >> that is being brought to life at the wrong moment ... >> >> stdout for the run follows. >> >> Dale >> >> foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image >> --quit --save ./boom.st <http://boom.st> >> Error: MessageNotUnderstood: receiver of "finish" is nil >> UndefinedObject(Object)>>error: >> [ :err :rcvr | >> | errCtx errMorph | >> errCtx := thisContext. >> [ errCtx := errCtx sender. >> "Search the sender chain to find the morph causing the problem" >> [ errCtx notNil and: [ errCtx receiver isMorph not ] ] >> whileTrue: [ errCtx := errCtx sender ]. >> "If we're at the root of the context chain then we have a >> fatal drawing problem" >> errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. >> errMorph := errCtx receiver. >> "If the morph causing the problem has already the #drawError >> flag set, >> then search for the next morph above in the >> caller chain." >> errMorph hasProperty: #errorOnDraw ] whileTrue. >> errMorph setProperty: #errorOnDraw toValue: true. >> "Install the old error handler, so we can re-raise the error" >> rcvr error: err ] in WorldState>>displayWorldSafely: in >> Block: [ :err :rcvr | ... >> BlockClosure>>cull:cull: >> [ :ex | errorHandlerBlock cull: ex description cull: ex >> receiver ] in BlockClosure>>ifError: in Block: [ :ex | >> errorHandlerBlock cull: ex description cul...etc... >> BlockClosure>>cull: >> Context>>evaluateSignal: >> Context>>handleSignal: >> MessageNotUnderstood(Exception)>>signal >> UndefinedObject(Object)>>doesNotUnderstand: #finish >> WorldState>>displayWorld:submorphs: >> WorldMorph>>displayWorld >> [ aWorld displayWorld ] in WorldState>>displayWorldSafely: in >> Block: [ aWorld displayWorld ] >> BlockClosure>>on:do: >> BlockClosure>>ifError: >> WorldState>>displayWorldSafely: >> WorldState>>doOneCycleNowFor: >> WorldState>>doOneCycleFor: >> WorldMorph>>doOneCycle >> [ [ World doOneCycle. >> Processor yield. >> false ] whileFalse: [ ] ] in >> MorphicUIManager>>spawnNewProcess in Block: [ [ World >> doOneCycle.... >> [ self value. >> Processor terminateActive ] in BlockClosure>>newProcess in >> Block: [ self value.... >> >> >> >> >

July 29, 2016

Re: [Pharo-dev] Bizarre Text Selection in Pharo 5.0

by Max Leske

> On 29 Jul 2016, at 03:01, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >> Yes, regularly :) > > Arghh. This is a big-time workflow killer. Is there an issue or should I > create one? I found this case [1], but itâs old and doesnât describe our specific problem I think. Please open a new issue (you can add me to the notification list). Cheers, Max 1: https://pharo.fogbugz.com/f/cases/4579/check-cursor-movement-selection-prov… > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bizarre-Text-Selection-in-Pharo-5-0-tp4908498p4908572… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 29, 2016

copyAllTo:

by Hilaire

copyAllTo: does not do what its comment says: '/tmp/toto/titi' asFileReference ensureCreateDirectory. '/tmp/dest' asFileReference ensureCreateDirectory. '/tmp/toto' asFileReference copyAllTo: '/tmp/dest' asFileReference 'toto' directory is not copied contrary to what wrote the method comment. What is wrong, the comment or the method? Hilaire copyAllTo: aResolvable "Performs a deep copy of the receiver, to a location specified by the argument. If the receiver is a file, the file will be copied; if a directory, the directory and its contents will be copied recursively. The argument must be a reference that doesn't exist; it will be created by the copy." -- Dr. Geo http://drgeo.eu

July 29, 2016

Re: [Pharo-dev] Bizarre Text Selection in Pharo 5.0

by Sean P. DeNigris

Max Leske wrote > Yes, regularly :) Arghh. This is a big-time workflow killer. Is there an issue or should I create one? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bizarre-Text-Selection-in-Pharo-5-0-tp4908498p4908572… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 29, 2016

Re: [Pharo-dev] newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)

by Dale Henrichs

Thanks Nicolai ... that looks exactly like my problem ... I see that this report is from earlier in July, so it presumably will crop up randomly .. Dale On 07/28/2016 02:24 PM, Nicolai Hess wrote: > Hi Dale, > > I think this problem already exists in Pharo 5.0, see bug report > 18706 > <https://pharo.fogbugz.com/f/cases/18706/Build-of-Pharo5-is-broken> > Build of Pharo5 is broken > > > > 2016-07-28 22:58 GMT+02:00 Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>>: > > Three additional pieces of info ... > > 1. 'canvas' is an instance variable in the WorldState instance and > is probably a stale instance along with a stale process > 2. If I bring up the image headful, I get no errors and then if I > save it, the load works properly ... > 3. If I run the load on Pharo.image directly without the initial ` > ./pharo Pharo.image save xxx`, it loads properly > > This sequence is in a script that I ship to end users, so if > `./pharo Pharo.image save xxx` is intended to work, I will wait > patiently for a bugfix (and submit a bug if necessary -- I > originally thought that this might have been recently introduced, > but now I think that this is a bug that is possibly just recently > exposed) otherwise, I'll have to rewrite the scripts to not rely > on `./pharo Pharo.image save xxx`. > > Dale > > On 07/28/2016 01:49 PM, Dale Henrichs wrote: > > This sequence of commands was working yesterday and is broken > today: > > ./pharo Pharo.image save xxx; ./pharo xxx.image --quit > --save ./boom.st <http://boom.st> > > The contents of boom.st <http://boom.st> is the following: > > Metacello new > baseline: 'Metacello'; > repository: > 'github://dalehenrich/metacello-work:master/repository'; > onConflict: [:ex | ex allow]; > load: #( 'batch' ). > > I've attached to PharoDebug.log ... The Pharo.image is freshly > downloaded along with the vm. Needless to say, the expression > above works when run with a GUI. Oddly enough the receiver of > #finish looks to be a temp named 'canvas' in the middle of the > WorkState>>displayWorld:submorphs: method ... two lines > earlier the' canvas' temp had to have a valid value, so this > has the look of a zombie process of some sort that is being > brought to life at the wrong moment ... > > stdout for the run follows. > > Dale > > foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image > --quit --save ./boom.st <http://boom.st> > Error: MessageNotUnderstood: receiver of "finish" is nil > UndefinedObject(Object)>>error: > [ :err :rcvr | > | errCtx errMorph | > errCtx := thisContext. > [ errCtx := errCtx sender. > "Search the sender chain to find the morph causing the problem" > [ errCtx notNil and: [ errCtx receiver isMorph not ] ] > whileTrue: [ errCtx := errCtx sender ]. > "If we're at the root of the context chain then we have a > fatal drawing problem" > errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. > errMorph := errCtx receiver. > "If the morph causing the problem has already the #drawError > flag set, > then search for the next morph above in the caller > chain." > errMorph hasProperty: #errorOnDraw ] whileTrue. > errMorph setProperty: #errorOnDraw toValue: true. > "Install the old error handler, so we can re-raise the error" > rcvr error: err ] in WorldState>>displayWorldSafely: in Block: > [ :err :rcvr | ... > BlockClosure>>cull:cull: > [ :ex | errorHandlerBlock cull: ex description cull: ex > receiver ] in BlockClosure>>ifError: in Block: [ :ex | > errorHandlerBlock cull: ex description cul...etc... > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > MessageNotUnderstood(Exception)>>signal > UndefinedObject(Object)>>doesNotUnderstand: #finish > WorldState>>displayWorld:submorphs: > WorldMorph>>displayWorld > [ aWorld displayWorld ] in WorldState>>displayWorldSafely: in > Block: [ aWorld displayWorld ] > BlockClosure>>on:do: > BlockClosure>>ifError: > WorldState>>displayWorldSafely: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > [ [ World doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in > MorphicUIManager>>spawnNewProcess in Block: [ [ World > doOneCycle.... > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess in > Block: [ self value.... > > > >

July 28, 2016

Re: [Pharo-dev] newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)

by Nicolai Hess

Hi Dale, I think this problem already exists in Pharo 5.0, see bug report 18706 <https://pharo.fogbugz.com/f/cases/18706/Build-of-Pharo5-is-broken> Build of Pharo5 is broken 2016-07-28 22:58 GMT+02:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > Three additional pieces of info ... > > 1. 'canvas' is an instance variable in the WorldState instance and is > probably a stale instance along with a stale process > 2. If I bring up the image headful, I get no errors and then if I save it, > the load works properly ... > 3. If I run the load on Pharo.image directly without the initial ` ./pharo > Pharo.image save xxx`, it loads properly > > This sequence is in a script that I ship to end users, so if `./pharo > Pharo.image save xxx` is intended to work, I will wait patiently for a > bugfix (and submit a bug if necessary -- I originally thought that this > might have been recently introduced, but now I think that this is a bug > that is possibly just recently exposed) otherwise, I'll have to rewrite the > scripts to not rely on `./pharo Pharo.image save xxx`. > > Dale > > On 07/28/2016 01:49 PM, Dale Henrichs wrote: > >> This sequence of commands was working yesterday and is broken today: >> >> ./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st >> >> The contents of boom.st is the following: >> >> Metacello new >> baseline: 'Metacello'; >> repository: >> 'github://dalehenrich/metacello-work:master/repository'; >> onConflict: [:ex | ex allow]; >> load: #( 'batch' ). >> >> I've attached to PharoDebug.log ... The Pharo.image is freshly downloaded >> along with the vm. Needless to say, the expression above works when run >> with a GUI. Oddly enough the receiver of #finish looks to be a temp named >> 'canvas' in the middle of the WorkState>>displayWorld:submorphs: method ... >> two lines earlier the' canvas' temp had to have a valid value, so this has >> the look of a zombie process of some sort that is being brought to life at >> the wrong moment ... >> >> stdout for the run follows. >> >> Dale >> >> foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save >> ./boom.st >> Error: MessageNotUnderstood: receiver of "finish" is nil >> UndefinedObject(Object)>>error: >> [ :err :rcvr | >> | errCtx errMorph | >> errCtx := thisContext. >> [ errCtx := errCtx sender. >> "Search the sender chain to find the morph causing the problem" >> [ errCtx notNil and: [ errCtx receiver isMorph not ] ] >> whileTrue: [ errCtx := errCtx sender ]. >> "If we're at the root of the context chain then we have a fatal drawing >> problem" >> errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. >> errMorph := errCtx receiver. >> "If the morph causing the problem has already the #drawError flag set, >> then search for the next morph above in the caller chain." >> errMorph hasProperty: #errorOnDraw ] whileTrue. >> errMorph setProperty: #errorOnDraw toValue: true. >> "Install the old error handler, so we can re-raise the error" >> rcvr error: err ] in WorldState>>displayWorldSafely: in Block: [ :err >> :rcvr | ... >> BlockClosure>>cull:cull: >> [ :ex | errorHandlerBlock cull: ex description cull: ex receiver ] in >> BlockClosure>>ifError: in Block: [ :ex | errorHandlerBlock cull: ex >> description cul...etc... >> BlockClosure>>cull: >> Context>>evaluateSignal: >> Context>>handleSignal: >> MessageNotUnderstood(Exception)>>signal >> UndefinedObject(Object)>>doesNotUnderstand: #finish >> WorldState>>displayWorld:submorphs: >> WorldMorph>>displayWorld >> [ aWorld displayWorld ] in WorldState>>displayWorldSafely: in Block: [ >> aWorld displayWorld ] >> BlockClosure>>on:do: >> BlockClosure>>ifError: >> WorldState>>displayWorldSafely: >> WorldState>>doOneCycleNowFor: >> WorldState>>doOneCycleFor: >> WorldMorph>>doOneCycle >> [ [ World doOneCycle. >> Processor yield. >> false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: >> [ [ World doOneCycle.... >> [ self value. >> Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self >> value.... >> >> > >

July 28, 2016

Re: [Pharo-dev] newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)

by Dale Henrichs

Three additional pieces of info ... 1. 'canvas' is an instance variable in the WorldState instance and is probably a stale instance along with a stale process 2. If I bring up the image headful, I get no errors and then if I save it, the load works properly ... 3. If I run the load on Pharo.image directly without the initial ` ./pharo Pharo.image save xxx`, it loads properly This sequence is in a script that I ship to end users, so if `./pharo Pharo.image save xxx` is intended to work, I will wait patiently for a bugfix (and submit a bug if necessary -- I originally thought that this might have been recently introduced, but now I think that this is a bug that is possibly just recently exposed) otherwise, I'll have to rewrite the scripts to not rely on `./pharo Pharo.image save xxx`. Dale On 07/28/2016 01:49 PM, Dale Henrichs wrote: > This sequence of commands was working yesterday and is broken today: > > ./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st > > The contents of boom.st is the following: > > Metacello new > baseline: 'Metacello'; > repository: > 'github://dalehenrich/metacello-work:master/repository'; > onConflict: [:ex | ex allow]; > load: #( 'batch' ). > > I've attached to PharoDebug.log ... The Pharo.image is freshly > downloaded along with the vm. Needless to say, the expression above > works when run with a GUI. Oddly enough the receiver of #finish looks > to be a temp named 'canvas' in the middle of the > WorkState>>displayWorld:submorphs: method ... two lines earlier the' > canvas' temp had to have a valid value, so this has the look of a > zombie process of some sort that is being brought to life at the wrong > moment ... > > stdout for the run follows. > > Dale > > foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image --quit > --save ./boom.st > Error: MessageNotUnderstood: receiver of "finish" is nil > UndefinedObject(Object)>>error: > [ :err :rcvr | > | errCtx errMorph | > errCtx := thisContext. > [ errCtx := errCtx sender. > "Search the sender chain to find the morph causing the problem" > [ errCtx notNil and: [ errCtx receiver isMorph not ] ] > whileTrue: [ errCtx := errCtx sender ]. > "If we're at the root of the context chain then we have a fatal > drawing problem" > errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. > errMorph := errCtx receiver. > "If the morph causing the problem has already the #drawError flag set, > then search for the next morph above in the caller chain." > errMorph hasProperty: #errorOnDraw ] whileTrue. > errMorph setProperty: #errorOnDraw toValue: true. > "Install the old error handler, so we can re-raise the error" > rcvr error: err ] in WorldState>>displayWorldSafely: in Block: [ :err > :rcvr | ... > BlockClosure>>cull:cull: > [ :ex | errorHandlerBlock cull: ex description cull: ex receiver ] in > BlockClosure>>ifError: in Block: [ :ex | errorHandlerBlock cull: ex > description cul...etc... > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > MessageNotUnderstood(Exception)>>signal > UndefinedObject(Object)>>doesNotUnderstand: #finish > WorldState>>displayWorld:submorphs: > WorldMorph>>displayWorld > [ aWorld displayWorld ] in WorldState>>displayWorldSafely: in Block: [ > aWorld displayWorld ] > BlockClosure>>on:do: > BlockClosure>>ifError: > WorldState>>displayWorldSafely: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > [ [ World doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in > Block: [ [ World doOneCycle.... > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess in Block: [ > self value.... >

July 28, 2016

newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)

by Dale Henrichs

This sequence of commands was working yesterday and is broken today: ./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st The contents of boom.st is the following: Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; onConflict: [:ex | ex allow]; load: #( 'batch' ). I've attached to PharoDebug.log ... The Pharo.image is freshly downloaded along with the vm. Needless to say, the expression above works when run with a GUI. Oddly enough the receiver of #finish looks to be a temp named 'canvas' in the middle of the WorkState>>displayWorld:submorphs: method ... two lines earlier the' canvas' temp had to have a valid value, so this has the look of a zombie process of some sort that is being brought to life at the wrong moment ... stdout for the run follows. Dale foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st Error: MessageNotUnderstood: receiver of "finish" is nil UndefinedObject(Object)>>error: [ :err :rcvr | | errCtx errMorph | errCtx := thisContext. [ errCtx := errCtx sender. "Search the sender chain to find the morph causing the problem" [ errCtx notNil and: [ errCtx receiver isMorph not ] ] whileTrue: [ errCtx := errCtx sender ]. "If we're at the root of the context chain then we have a fatal drawing problem" errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. errMorph := errCtx receiver. "If the morph causing the problem has already the #drawError flag set, then search for the next morph above in the caller chain." errMorph hasProperty: #errorOnDraw ] whileTrue. errMorph setProperty: #errorOnDraw toValue: true. "Install the old error handler, so we can re-raise the error" rcvr error: err ] in WorldState>>displayWorldSafely: in Block: [ :err :rcvr | ... BlockClosure>>cull:cull: [ :ex | errorHandlerBlock cull: ex description cull: ex receiver ] in BlockClosure>>ifError: in Block: [ :ex | errorHandlerBlock cull: ex description cul...etc... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: MessageNotUnderstood(Exception)>>signal UndefinedObject(Object)>>doesNotUnderstand: #finish WorldState>>displayWorld:submorphs: WorldMorph>>displayWorld [ aWorld displayWorld ] in WorldState>>displayWorldSafely: in Block: [ aWorld displayWorld ] BlockClosure>>on:do: BlockClosure>>ifError: WorldState>>displayWorldSafely: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle [ [ World doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ World doOneCycle.... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value....

July 28, 2016