Two things: a. I see a remark about making that cache-mapping weak. What would that help (it contains strings only)? b. Where did the docs go? I can't seem to find them anywhere.
Two things: a. I see a remark about making that cache-mapping weak. What would that help (it contains strings only)?
If the mapping were to be weak, any strings only referenced from the mapping would be freed whenever the mapping hashtable needs to grow.
b. Where did the docs go? I can't seem to find them anywhere.
AFAIK, I copied the current docs to __builtin.Nettle.Hash.SCRAM; it should show up at the intended places due to inherits, but I haven't tried building the docs in a while.
/grubba
b. Where did the docs go? I can't seem to find them anywhere.
AFAIK, I copied the current docs to __builtin.Nettle.Hash.SCRAM; it should show up at the intended places due to inherits, but I haven't tried building the docs in a while.
I just tried building the docs, and SCRAM showed up where I expected (ie listed under the Classes heading for eg Crypto.SHA256 with the SCRAM doc in refdoc/modref/ex/predef_3A_3A/__builtin/Nettle/Hash/SCRAM.html
/grubba
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Two things: a. I see a remark about making that cache-mapping weak. What would that help (it contains strings only)?
If the mapping were to be weak, any strings only referenced from the mapping would be freed whenever the mapping hashtable needs to grow.
Ok, tested it, and can confirm that it works. Shouldn't this be documented somewhere?
Anyway, in this case, I decided that it might not be what we want. Typically you either connect to a lot of places, but do not reconnect a lot. Or you reconnect to a few places a lot. So having a hard maximum on the cached numbers is fine. If we'd make it weak, and skip the sizecheck, it would grow in exponential steps, which is undesirable for long running servers that connect a lot.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Stephen R. van den Berg