July 2016 - Pharo-dev - lists.pharo.org

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

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

by Max Leske

> On 28 Jul 2016, at 19:31, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > It seems impossible that no one has encountered this, but I didn't find > anything on the mailing list. When I select text in Nautilus code pane and > then e.g. press $[ to add brackets around the selection smartly, the > selection shifts and one of the brackets ends up in the wrong place. Anyone > else running into this? Yes, regularly :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bizarre-Text-Selection-in-Pharo-5-0-tp4908498.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 28, 2016

Re: [Pharo-dev] Odd Commits to Soup Repo

by Paul DeBruicker

Sure you can delete mcz from Smalltalkhub. Or at least the Web UI offers a 'Delete .mcz' button, which appears to work. Sign in Navigate to the project Click on Commits Find the MCZ you want to delete Click the name of the MCZ Click the "Delete .mcz" button It should then be deleted. As a test I deleted ConfigurationOfAutomaticMethodCategorizer-StephaneDucasse.4, Pharo-Launcher-Core-DamienCassou.21, and ConfigurationOfPharoLauncher-DamienCassou.9 from the PharoExtras/Soup repo Or did you mean something else? Hope this helps Paul stepharo wrote > Yes but we cannot remove file in Smalltalkhub repo. > > > Stef > > > Le 28/7/16 Ã 18:47, Sean P. DeNigris a Ã©crit : >> I found ConfigurationOfPharoLauncher-DamienCassou.9 & >> Pharo-Launcher-Core-DamienCassou.21 there. I assume they were uploaded by >> mistake... >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Odd-Commits-to-Soup-Repo-tp4908492.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> -- View this message in context: http://forum.world.st/Odd-Commits-to-Soup-Repo-tp4908492p4908538.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 28, 2016

Re: [Pharo-dev] Odd Commits to Soup Repo

by stepharo

Yes but we cannot remove file in Smalltalkhub repo. Stef Le 28/7/16 Ã 18:47, Sean P. DeNigris a Ã©crit : > I found ConfigurationOfPharoLauncher-DamienCassou.9 & > Pharo-Launcher-Core-DamienCassou.21 there. I assume they were uploaded by > mistake... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Odd-Commits-to-Soup-Repo-tp4908492.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

July 28, 2016

Re: [Pharo-dev] Accept in Debugger Meltdown in Pharo 5.0

by Tudor Girba

Interesting read. I think it is not related, but a relevant issue anyway. Thanks for reposting the report. Doru > On Jul 27, 2016, at 3:16 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Doru, > > I think my "empty debugger problem"[1] is related ... of course I haven't seen the problem again and after trashing 3 or 4 rebuilds, I was able to code my way out of the problem and haven't seen it since .... > > Dale > > [1] http://forum.world.st/Empty-debugger-Pharo-5-0-td4907374.html > > > On 7/27/16 1:20 AM, Tudor Girba wrote: >> That is not good. Did it happen repeatedly, or only once? Do you remember the situation? >> >> Cheers, >> Doru >> >> >>> On Jul 27, 2016, at 8:49 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I know that christophe and me got it too. >>> >>> Stef >>> >>> >>> Le 26/7/16 Ã 19:00, Sean P. DeNigris a Ã©crit : >>>> <http://forum.world.st/file/n4908072/Screenshot_2016-07-26_13.png> >>>> >>>> Mac spinning beachball of death followed after about a minute by "... quit >>>> unexpectedly". Bugforeveryoneorjustme? >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> View this message in context: http://forum.world.st/Accept-in-Debugger-Meltdown-in-Pharo-5-0-tp4908072.ht… >>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>>> >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Presenting is storytelling." >> >> > > -- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."

July 28, 2016

Re: [Pharo-dev] Accept in Debugger Meltdown in Pharo 5.0

by Tudor Girba

Thanks. It is important. Doru > On Jul 28, 2016, at 4:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> So, could you describe what you did in more details? > > I think it had to do with the combination of [messing with Magritte > internals] + [Magritte GT integration]. I'll keep you posted if I find out > more. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Accept-in-Debugger-Meltdown-in-Pharo-5-0-tp4908072p49… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

July 28, 2016