Add data type mapping between FFI and Lua values #1059
Conversation
From the README:
Ever been annoyed that you can't create a hash table where the keys are
FFI values, like raw IPv4 addresses, but the values are Lua objects?
Well of course you can key a normal Lua table by any Lua value, but the
key is looked up by identity and not by value, which is rarely what you
want. `foo[lib.protocol.ipv4:pton('1.2.3.4')]` will not be the same as
`foo[lib.protocol.ipv4:pton('1.2.3.4')]`, as the `pton` call produces a
fresh value every time. What you usually want with FFI-keyed tables is
to be able to look up the entry by value, not by identity.
Well never fear, *cltable* is here. A cltable is a data type that
associates FFI keys with any old Lua value. When you look up a key in a
cltable, the key is matched by-value.
|
seems i forgot to add Igalia@580d8c7 to this branch |
If no hash_fn is given, ctable will provide one.
|
@eugeneia would you perhaps mind having a look at this one? No rush though, I just wanted to get it on board one of the upstream trains :) |
| cltable.values[entry.value] = value | ||
| if value ~= nil then | ||
| cltable.keys:remove_ptr(entry) | ||
| -- FIXME: Leaking the slot in the values array. |
There was a problem hiding this comment.
Wait, shouldn’t this be value == nil, as in “if value is nil, delete the entry and set the corresponding key in the backing table to nil, too”.
There was a problem hiding this comment.
On second look the latter is performed unconditionally.
| end | ||
| end | ||
|
|
||
| function selftest() |
There was a problem hiding this comment.
As per the above I would suggest to test deletion here.
| @@ -91,8 +91,9 @@ end | |||
| -- FIXME: For now the value_type option is required, but in the future | |||
| -- we should allow for a nil value type to create a set instead of a | |||
| -- map. | |||
| local required_params = set('key_type', 'value_type', 'hash_fn') | |||
| local required_params = set('key_type', 'value_type') | |||
There was a problem hiding this comment.
In theory you could use the new core.lib.parse function for this.
|
Fixed nit, good catch :) Also it turns out the slot is not leaked. The next slot will be allocated at Re ctable and parameters it is a good idea for later :) |
Make "offset" arg to lseek a signed integer
From the README:
Ever been annoyed that you can't create a hash table where the keys are
FFI values, like raw IPv4 addresses, but the values are Lua objects?
Well of course you can key a normal Lua table by any Lua value, but the
key is looked up by identity and not by value, which is rarely what you
want.
foo[lib.protocol.ipv4:pton('1.2.3.4')]will not be the same asfoo[lib.protocol.ipv4:pton('1.2.3.4')], as theptoncall produces afresh value every time. What you usually want with FFI-keyed tables is
to be able to look up the entry by value, not by identity.
Well never fear, cltable is here. A cltable is a data type that
associates FFI keys with any old Lua value. When you look up a key in a
cltable, the key is matched by-value.