In 30456, I'm in the process of porting the Tiling Window Manager. I'm experiencing this confusing error... TWMDockingBarMorph DNU @ In DockingBarMorph>>updatePosition there is the following code: self isAdheringToLeft ifTrue: [| usedHeight usedWidth | usedHeight := self usedHeightByPredominantDockingBarsOfChastes: #(#top ). usedWidth := self usedWidthByPredominantDockingBarsOfChastes: #(#left ). (usedHeight isNumber not or: [usedWidth isNumber]) ifFalse: [ Halt once ]. usedHeight := 1000. usedWidth := 100. self topLeft: self owner topLeft - margin + (usedWidth @ usedHeight)]. Pharo is saying that usedWidth = aTWMDockingBarMorph, even though it's set to a number (for debugging) in the preceding statement. Any ideas? Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-is-this-possible-tp4713857.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Oct 11, 2013, at 4:13 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
In 30456, I'm in the process of porting the Tiling Window Manager. I'm experiencing this confusing error...
TWMDockingBarMorph DNU @
In DockingBarMorph>>updatePosition there is the following code:
self isAdheringToLeft ifTrue: [| usedHeight usedWidth | usedHeight := self usedHeightByPredominantDockingBarsOfChastes: #(#top ). usedWidth := self usedWidthByPredominantDockingBarsOfChastes: #(#left ). (usedHeight isNumber not or: [usedWidth isNumber]) ifFalse: [ Halt once ]. usedHeight := 1000. usedWidth := 100. self topLeft: self owner topLeft - margin + (usedWidth @ usedHeight)].
Pharo is saying that usedWidth = aTWMDockingBarMorph, even though it's set to a number (for debugging) in the preceding statement. Any ideas?
Yes, it is on my list to look at this. there is already a report. https://pharo.fogbugz.com/f/cases/11611/Pharo3-0-DockingBarMorph-updatePosit... I will have a look... Marcus
I am experiencing some problem with the debugger giving the value of the wrong variable, like switching them somehow Ben On Oct 11, 2013, at 4:12 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
In 30456, I'm in the process of porting the Tiling Window Manager. I'm experiencing this confusing error...
TWMDockingBarMorph DNU @
In DockingBarMorph>>updatePosition there is the following code:
self isAdheringToLeft ifTrue: [| usedHeight usedWidth | usedHeight := self usedHeightByPredominantDockingBarsOfChastes: #(#top ). usedWidth := self usedWidthByPredominantDockingBarsOfChastes: #(#left ). (usedHeight isNumber not or: [usedWidth isNumber]) ifFalse: [ Halt once ]. usedHeight := 1000. usedWidth := 100. self topLeft: self owner topLeft - margin + (usedWidth @ usedHeight)].
Pharo is saying that usedWidth = aTWMDockingBarMorph, even though it's set to a number (for debugging) in the preceding statement. Any ideas?
Thanks.
----- Cheers, Sean -- View this message in context: http://forum.world.st/How-is-this-possible-tp4713857.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Oct 11, 2013, at 4:19 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
I am experiencing some problem with the debugger giving the value of the wrong variable, like switching them somehow
Yes, that is another bug I am looking at⦠a quite strange one related to being in the wrong scope in the debugger when stepping. Marcus
On Oct 11, 2013, at 4:13 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
In 30456, I'm in the process of porting the Tiling Window Manager. I'm experiencing this confusing error...
TWMDockingBarMorph DNU @
In DockingBarMorph>>updatePosition there is the following code:
self isAdheringToLeft ifTrue: [| usedHeight usedWidth | usedHeight := self usedHeightByPredominantDockingBarsOfChastes: #(#top ). usedWidth := self usedWidthByPredominantDockingBarsOfChastes: #(#left ). (usedHeight isNumber not or: [usedWidth isNumber]) ifFalse: [ Halt once ]. usedHeight := 1000. usedWidth := 100. self topLeft: self owner topLeft - margin + (usedWidth @ usedHeight)].
Pharo is saying that usedWidth = aTWMDockingBarMorph, even though it's set to a number (for debugging) in the preceding statement. Any ideas?
So it seems the compiler (the semantic analysis phase, I think) does something wrong with defined temps in ifTrue: and other optimized blocks. I will -> commit an update where the code moves the temps to the method -> then fix the compiler next week Marcus
Marcus Denker-4 wrote
I will -> commit an update where the code moves the temps to the method -> then fix the compiler next week
Thanks, Marcus! ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-is-this-possible-tp4713857p4713931.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Marcus Denker-4 wrote
I will -> commit an update where the code moves the temps to the method -> then fix the compiler next week
Are there issues for these? I want to track the status because the TWM port to 3.0 is on hold until it's fixed... ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-is-this-possible-tp4713857p4716682.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 24 Oct 2013, at 07:12, Sean P. DeNigris <sean@clipperadams.com> wrote:
Marcus Denker-4 wrote
I will -> commit an update where the code moves the temps to the method -> then fix the compiler next week
Are there issues for these? I want to track the status because the TWM port to 3.0 is on hold until it's fixed...
I did the workaround literally within hours⦠so this is closed already. I donât remember if I put an issue for the second, but there is a TODO on my list "In Bug Tracker: bug temps in ifTrue:â which is the next on the list⦠I did not dare to fix it with the Opal RegressionTester crashing the VM, which I fixed yesterday. Marcus
participants (3)
-
Benjamin -
Marcus Denker -
Sean P. DeNigris