[erlang-questions] [erlang-patches] EEP Light: Option to override private key lookup when using Erlang ssh client

[Björn-Egil Dahlberg]

If it's
https://github.com/iguberman/otp/commit/1968f7207e8f80e77d0c2c4e3b50d018cdf8359b
you are nearly there.

You must prefix your function with the module name, in this case 'binary_'.
i.e.

BIF_RETTYPE *binary_*free_refc_bin_1(BIF_ALIST_1){

 ...

}

Aside: Your in dangerous water with your BIF but I guess you know that.

// Björn-Egil

2015-11-12 20:01 GMT+01:00 Irina Guberman <irina.guberman@REDACTED>:

> Hello dear Erlang developers,
>
> I would tremendously appreciate any help or if anyone can point me to
> someone who can help with linking Erlang/OTP.   I created an experimental
> BIF in my own fork of erlang/otp, but can't get past linking stage (on Mac: Undefined
> symbols for architecture x86_64,  but same thing happens on ubuntu 14.04)
>  even though I checked everywhere and my BIF seems to be everywhere an
> existing BIF from the same module is (with same naming  conventions and
> all).   I don't know where to post this question either (Erlang Central
> didn't work which is understandable, it's not like people are creating BIFs
> everyday), I'm so desperate I'm about to post it on Twitter ;)
>
> Thanks a million for reading this message and even more so for pointing me
> to where I can get help with this!
>
> Irina.
>
>
>
>
> On Thu, Nov 12, 2015 at 12:19 PM, Hans Nilsson R <
> hans.r.nilsson@REDACTED> wrote:
>
>> Great!  If there also is documentation and a test case the likelihood of
>> acceptance is higher :)
>> -Hans
>>
>> On 11/12/2015 06:31 PM, Vipin Nair wrote:
>> > Hello Hans,
>> >
>> >> A more general way to pass options to the key callback module would be
>> >> to introduce a second form of the key_cb option:
>> >>   -  keep todays {key_cb, Module::atom()} to keep compatibility
>> >>   -  introduce the variant {key_cb, {Module::atom(), ModuleOptions}}
>> >> [...]
>> >> In that way it is possible to write a callback module with whatever is
>> >> needed as private options.
>> >
>> > This will work! In retrospect, I should have done this instead. This is
>> much
>> > simpler and solves my problem. I'll send a new pull request with the
>> suggested
>> > implementation. Thanks!
>> >
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
>>
>>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151113/d10b5143/attachment.htm>