Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007532 [Squeak] Tools minor always 05-15-10 11:41 02-06-11 23:47
Reporter unoduetre View Status public  
Assigned To FrankShearar
Priority normal Resolution fixed  
Status closed   Product Version 4.1
Summary 0007532: Problems with Blocks in Workspace
Description Following code in Workspace behaves unexpectedly:

a:=4. b:=[:a|a]. b value: a.
c class "BlockClosure"
c decompile "{[:t1 | t1]}"

Select the entire first line (3 statements) and do-it or print-it for all of them at once. If they are executed separately it works as expected.

Edit: Modified by KenCausey to be clearer. This negates the relevance of the first 2 notes below.
Additional Information
Attached Files

- Relationships

- 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 [^]
 

- 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


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
71 total queries executed.
48 unique queries executed.
Powered by Mantis Bugtracker