0007532: Problems with Blocks in Workspace

(0013771 - 54 - 74 - 74 - 74 - 74 - 74)
FrankShearar
05-15-10 18:35

What's unexpected? That you see a "t1" instead of "a"?

(0013772 - 174 - 174 - 174 - 174 - 174 - 174)
KenCausey
05-15-10 19:02

Indeed, I see nothing here unexpected. When you decompile from bytecode there is information to say that there are arguments and variables and how many, but not their names.

(0013774 - 151 - 195 - 195 - 195 - 195 - 195)
unoduetre
05-16-10 07:55

I'm really sorry. There is mistake in that code.
Please try this one:
a:=4.b:=[:a|a].c:=b value:a.
c class "BlockClosure".
c decompile "{[:t1|t1]}"

(0013775 - 248 - 294 - 294 - 294 - 294 - 294)
FrankShearar
05-16-10 11:09

There's something weird going on here, or I simply don't understand BlockClosures well enough. If you try this:

a := 4.
b := [ :n | n ]. "Note the new local var name."
c := b value: a.

then c contains 4 (the value of a), not a BlockClosure.

(0013776 - 318 - 318 - 318 - 318 - 318 - 318)
KenCausey
05-16-10 19:08

OK, now I see what you mean. If, in a workspace for example, you select the first 3 statements and execute them all at once, the result is a BlockClosure, not the value of a, 4, that you would expect. If you however execute each statement individually it works as expected. How to track down the cause I don't know.

(0013777 - 629 - 713 - 713 - 713 - 713 - 713)
KenCausey
05-16-10 19:24

Thanks to a suggestion from jmckeon on #squeak we have another data point at least, I'm not sure what it means. So once more here is the code with a problem (with all requisite whitespace).

a := 4.
b := [ :a | a ].
c := b value: a.

If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial detail). The result is that a is 4, b is a BlockClosure, and c is a BlockClosure not 4 as expected. Execute each statement separately and c is 4.

The new wrinkle is that

a := 4.
b := [ :d | d ].
c := b value: a.

when executed all at one time works as you would expect: a is 4, b is a BlockClosure, and c is 4.

(0013778 - 459 - 639 - 639 - 639 - 639 - 639)
nicolas cellier
05-16-10 20:35

Indeed, generated CompiledMethod is wrong:

29 <20> pushConstant: 4
30 <82 C1> popIntoLit: a
32 <8F 01 00 02> closureNumCopied: 0 numArgs: 1 bytes 36 to 37
36 <10> pushTemp: 0
37 <7D> blockReturn
38 <82 C2> popIntoLit: b
40 <42> pushLit: b
41 <10> pushTemp: 0
42 <CA> send: value:
43 <81 C3> storeIntoLit: c
45 <7C> returnTop

should be:

41 <41> pushLit: a

Since CompiledMethod has no temp, pushTemp: 0 can have unexpected results indeed

(0013779 - 50 - 50 - 200 - 200 - 200 - 200)
FrankShearar
05-17-10 07:40

http://source.squeak.org/trunk/Compiler-ar.141.mcz [^]

Issue History
Date Modified	Username	Field	Change
05-15-10 11:41	unoduetre	New Issue
05-15-10 18:35	FrankShearar	Note Added: 0013771
05-15-10 19:02	KenCausey	Note Added: 0013772
05-15-10 19:02	KenCausey	Status	new => feedback
05-16-10 07:55	unoduetre	Note Added: 0013774
05-16-10 11:09	FrankShearar	Note Added: 0013775
05-16-10 19:08	KenCausey	Note Added: 0013776
05-16-10 19:10	KenCausey	Description Updated
05-16-10 19:24	KenCausey	Note Added: 0013777
05-16-10 20:35	nicolas cellier	Note Added: 0013778
05-17-10 07:40	FrankShearar	Status	feedback => resolved
05-17-10 07:40	FrankShearar	Fixed in Version	=> trunk
05-17-10 07:40	FrankShearar	Resolution	open => fixed
05-17-10 07:40	FrankShearar	Assigned To	=> FrankShearar
05-17-10 07:40	FrankShearar	Note Added: 0013779
02-06-11 23:47	leves	Status	resolved => closed

Notes
(0013771 - 54 - 74 - 74 - 74 - 74 - 74) FrankShearar 05-15-10 18:35	What's unexpected? That you see a "t1" instead of "a"?

(0013772 - 174 - 174 - 174 - 174 - 174 - 174) KenCausey 05-15-10 19:02	Indeed, I see nothing here unexpected. When you decompile from bytecode there is information to say that there are arguments and variables and how many, but not their names.

(0013774 - 151 - 195 - 195 - 195 - 195 - 195) unoduetre 05-16-10 07:55	I'm really sorry. There is mistake in that code. Please try this one: a:=4.b:=[:a\|a].c:=b value:a. c class "BlockClosure". c decompile "{[:t1\|t1]}"

(0013775 - 248 - 294 - 294 - 294 - 294 - 294) FrankShearar 05-16-10 11:09	There's something weird going on here, or I simply don't understand BlockClosures well enough. If you try this: a := 4. b := [ :n \| n ]. "Note the new local var name." c := b value: a. then c contains 4 (the value of a), not a BlockClosure.

(0013776 - 318 - 318 - 318 - 318 - 318 - 318) KenCausey 05-16-10 19:08	OK, now I see what you mean. If, in a workspace for example, you select the first 3 statements and execute them all at once, the result is a BlockClosure, not the value of a, 4, that you would expect. If you however execute each statement individually it works as expected. How to track down the cause I don't know.

(0013777 - 629 - 713 - 713 - 713 - 713 - 713) KenCausey 05-16-10 19:24	Thanks to a suggestion from jmckeon on #squeak we have another data point at least, I'm not sure what it means. So once more here is the code with a problem (with all requisite whitespace). a := 4. b := [ :a \| a ]. c := b value: a. If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial detail). The result is that a is 4, b is a BlockClosure, and c is a BlockClosure not 4 as expected. Execute each statement separately and c is 4. The new wrinkle is that a := 4. b := [ :d \| d ]. c := b value: a. when executed all at one time works as you would expect: a is 4, b is a BlockClosure, and c is 4.

(0013778 - 459 - 639 - 639 - 639 - 639 - 639) nicolas cellier 05-16-10 20:35	Indeed, generated CompiledMethod is wrong: 29 <20> pushConstant: 4 30 <82 C1> popIntoLit: a 32 <8F 01 00 02> closureNumCopied: 0 numArgs: 1 bytes 36 to 37 36 <10> pushTemp: 0 37 <7D> blockReturn 38 <82 C2> popIntoLit: b 40 <42> pushLit: b 41 <10> pushTemp: 0 42 <CA> send: value: 43 <81 C3> storeIntoLit: c 45 <7C> returnTop should be: 41 <41> pushLit: a Since CompiledMethod has no temp, pushTemp: 0 can have unexpected results indeed

(0013779 - 50 - 50 - 200 - 200 - 200 - 200) FrankShearar 05-17-10 07:40	http://source.squeak.org/trunk/Compiler-ar.141.mcz [^]

Relationships