- Pharo-dev - lists.pharo.org

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

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