Re: [Pharo-project] CachedBlockClosure was gone on purpose?
On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck wrote: > Because it is not present in 2.0 but I couldn't find any issue about that. > Because it does not work with the block closure implementation that we have now... The thing is that a block in a method like this: [1+2] is not a literal, but it is instead compiled to bytecode that *creates* a new block at execution time. e.g. test ^[1+3] Test new test == Test new test ==> false. The reason is that blocks are realized like this (to save memory!!, you know, we just have 8GB of it in a shity laptop...): 17 <8F 00 00 04> closureNumCopied: 0 numArgs: 0 bytes 21 to 24 21 <76> pushConstant: 1 22 <20> pushConstant: 3 23 send: + 24 <7D> blockReturn 25 <7C> returnTop So if you now do a #becomeCached like this: becomeCached self becomeForward: ((CachedBlockClosure new: self size) outerContext: outerContext startpc: startpc numArgs: numArgs cachedValue: self value copiedValues: self) is will have no influence, as the next evaluation of the code containing the block will not see the #becomed block but instead the newly generated one. Damien C. was trying to write documentation and the example he tried to do just did not work (the block was always evaluated). Of course it works if you put the block in an iVar, but that then defeats the whole purpose as the idea of the caching block is to not need an ivar to cache... Again a case where we are shoot in the foot by the horrible architecture of the system. Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] CachedBlockClosure was gone on purpose?
On Nov 17, 2012, at 9:05 AM, Marcus Denker wrote: > > On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck > wrote: > >> Because it is not present in 2.0 but I couldn't find any issue about that. >> Issue was http://code.google.com/p/pharo/issues/detail?id=6708 -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] CachedBlockClosure was gone on purpose?
I replaced the implementation with one based on properties. It's in Squeak trunk and works fine. The VisualWorks style clean-block implementation is more complex but arguably not better, and being based on become: is less well suited to Squeak. On Sat, Nov 17, 2012 at 4:07 AM, Marcus Denker wrote: > > On Nov 17, 2012, at 9:05 AM, Marcus Denker wrote: > > > > > On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck < > marianop...@gmail.com> wrote: > > > >> Because it is not present in 2.0 but I couldn't find any issue about > that. > >> > > Issue was http://code.google.com/p/pharo/issues/detail?id=6708 > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot
