Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003299 [Croquet] Hedgehog major always 03-13-06 19:14 03-15-06 22:53
Reporter howardstearns View Status public  
Assigned To
Priority normal Resolution open  
Status confirmed  
Summary 0003299: future messages compile as futureSend instead of futureDo
Description There places where an unused future in tail position of an if branch gets compiled as futureSend instead of futureDo:
       TAvatarUser>>pointerControl:redButton:
             - last line of redButton ifFalse:
             - last line of pointer selectedTarget ifNotNil:
       TXRay>resetSelected last line of the three itTrue: inside of ifNotNil: branches that end in future sends.

There are undoubtedly more. The ones cited cause the islands export and nameMap tables to grow as reported in 3297
     
Additional Information These can be short-term fixed by inserting a nil no-op in the tail position of these branches, but the longer-term issue is fixing the #future compiler.
Attached Files

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

related to 0005695new  future in tail-position of block - core packages 
related to 0005696new  future in tail-position of block - demo packages 
related to 0005697new  future in tail-position of block - contrib packages: Minnesota 
related to 0005796new  internal future sends 
child of 0003298confirmed  futureSend futures never go away 

- Notes
(0004459 - 569 - 671 - 671 - 671 - 671 - 671)
andreas
03-14-06 02:35

 Interestingly, the bug is not as easy to fix as I first thought. Mainly because in a pattern of the form:
  block := [foo future bar].
it can't be decided at the point of compilation whether the return value of the block is being used or not, e.g., whether:
  block value. "no return needed"
  result := block value. "return value needed"
Unfortunately this also applies to seemingly trivial expressions like
  foo ifNotNil:[foo future bar].
where the compiler could (with additional analysis) determine the use beforehand (since the pattern is compiled inline).
 
(0004493 - 58 - 58 - 58 - 58 - 58 - 58)
andreas
03-15-06 22:53

 Just confirming this bug as it may take a while to fix it.
 

- Issue History
Date Modified Username Field Change
03-13-06 19:14 howardstearns New Issue
03-13-06 19:17 howardstearns Category Any => Hedgehog
03-13-06 19:18 howardstearns Relationship added child of 0003298
03-14-06 02:35 andreas Note Added: 0004459
03-15-06 22:53 andreas Note Added: 0004493
03-15-06 22:53 andreas Status new => confirmed
01-03-07 06:29 howardstearns Relationship added related to 0005695
01-03-07 06:30 howardstearns Relationship added related to 0005696
01-03-07 06:31 howardstearns Relationship added related to 0005697
01-20-07 19:58 howardstearns Relationship added related to 0005796

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