On 04.12.2014 15:02, Nick Coghlan wrote:
As Ethan suggests, a clearer explanation of the current incompatibility, and what additional cache entries you would like to be able to inject may help us better understand the suggestion.
You're right. I'm sorry for being unclear.
I now have written code that compares a) a stupid custom cache, which offers the interfaces I need ("f") b) the most stupid way to combine libtco with lru_cache ("f2") c) the slightly less stupid way to combine libtco with lru_cache ("f3")
A test run computes in this order: f(6), f(6), f(4) in a) only the first computation has to be done, the other two are in cache afterwards in b) nothing can be cached in c) only exact arguments can be cached, i.e. f(6) is only calculated once, but the intermediate result that was calculated on the way is not used to have f(4) in the cache, so f(4) has to be completely recomputed.
The code is here: http://nopaste.info/a82d680210_nl.html It's a single python 3 script ready for execution. These changes, when properly split up will also find their way into the libtco git.
As you can see from the code, the interface I propose just adds two functions to the cache: cache_get and cache_put. I think that any cache should be able to provide these functions, no matter how its cache strategy or how it is implemented.
I'm sorry if my code is tldr, but I really can't think of an easy way of explaining it right now. I'll be happy to answer further questions though.
Best Regards, Constantin