Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] 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 Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version trunk Product Version 4.1
  Product Build
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.
Steps To Reproduce
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