couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Windows build blocked by khash NIF
Date Mon, 13 Jul 2015 16:51:03 GMT
Also, for the record I'd like to stick with phash2 rather than the
term_to_binary approach and our own hash function as Erlang has done a
fair amount of tweaking to make their hash function work well on terms
as I understand it.

On Mon, Jul 13, 2015 at 11:50 AM, Paul Davis
<paul.joseph.davis@gmail.com> wrote:
> Sorry, was away on vacation last week.
>
> The back story on that make_hash2 is at [1].
>
> Given that the patch never landed we can fall back to the proposed
> work around there. We can just call erlang:phash2/1 on each key and
> pass that into the NIF. While it won't allow us to easily reimplement
> ETS it should be more than fine for this case.
>
> [1] http://erlang.org/pipermail/erlang-patches/2013-February/003532.html
>
> On Sun, Jul 12, 2015 at 5:30 PM, Robert Samuel Newson
> <rnewson@apache.org> wrote:
>> How about this;
>>
>> 1) When built on Windows, the khash_hash_fun insists that the key term is an erlang
binary and we hash that.
>>
>> 2) When built on Windows, the functions in khash.erl call term_to_binary before calling
down to the NIF functions.
>>
>> B.
>>
>> sketch;
>>
>> #ifndef _WIN32
>> hash_val_t
>> khash_hash_fun(const void* obj)
>> {
>>     khnode_t* node = (khnode_t*) obj;
>>     return (hash_val_t) make_hash2(node->key);
>> }
>> #else
>> hash_val_t
>> khash_hash_fun(const void* obj)
>> {
>>     khnode_t* node = (khnode_t*) obj;
>>     Eterm term = node->key;
>>     if (ERL_IS_BINARY(term)) {
>>       void* data = ERL_BIN_PTR(term);
>>       int len =  ERL_BIN_SIZE(term);
>>       return hash(data, len); // TODO, write hash function
>>     }
>>     else {
>>         return (hash_val_t) make_hash2(node->key);
>>     }
>> }
>> #endif
>>
>>
>>> On 12 Jul 2015, at 09:14, Nick North <north.n@gmail.com> wrote:
>>>
>>> I'm with Dave - it would be acceptable to ship a modified BEAM if it's a
>>> short-term measure. It's not great, but better than not having Windows
>>> support.
>>>
>>> Nick
>>>
>>> On Sun, 12 Jul 2015 at 08:35 Dave Cottlehuber <dch@apache.org> wrote:
>>>
>>>>
>>>> On Sun, 12 Jul 2015, at 09:21 AM, Dave Cottlehuber wrote:
>>>>> On Sun, 12 Jul 2015, at 08:35 AM, Joan Touzet wrote:
>>>>>> I scoured the mailing lists but was unable to find any sort of patch
>>>>>> for this, submitted or not. It's certainly not landed in v18.0.x.
>>>>>>
>>>>>> Perhaps Paul is aware of the patch as a starting place at least?
>>>>
>>>> Um I should also say that in the distant past, I built & shipped
>>>> modified BEAMs, although that was just to fix up patches that had been
>>>> accepted but not released. e.g.
>>>> http://people.apache.org/~dch/snapshots/1.1.1/
>>>>
>>>> So I'm not averse to that if we have a patch that's been submitted
>>>> upstream and a reasonable expectation of success. In my experience there
>>>> are only a handful of people who have built from source on Windows...
>>>>
>>>> —
>>>>  Dave Cottlehuber
>>>>  dch@apache.org
>>>>  Sent from my Couch
>>>>
>>

Mime
View raw message