Ad hoc use of a NIF

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Ad hoc use of a NIF

Harris, Robert
Hi,

For the sake of example, I have a library with two files:  a.erl and
b.erl, where a.erl is accompanied by a NIF.  I am constrained by the
need to construct b.erl using the output of a function contained in the
NIF.

I was planning to have the make process (called from rebar) for a's NIF
use an escript to load it in order to generate b.erl.  This doesn't work
because, as far as I can tell, I can't load a NIF from the shell.

Could anyone recommend a clean solution?

Robert
Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Reply | Threaded
Open this post in threaded view
|

Re: Ad hoc use of a NIF

Roger Lipscombe-2
On Tue, 24 Mar 2020 at 10:33, Harris, Robert
<[hidden email]> wrote:
> I was planning to have the make process (called from rebar) for a's NIF
> use an escript to load it in order to generate b.erl.  This doesn't work
> because, as far as I can tell, I can't load a NIF from the shell.

No, you can't. The module that loads the NIF needs to match the
declaration in the NIF. More precisely: the name of the calling module
must match the first argument to ERL_NIF_INIT.

But: you could load 'a' from the shell (or from escript), and invoke
it that way, no?
Reply | Threaded
Open this post in threaded view
|

Re: Ad hoc use of a NIF

Ali Sabil
In reply to this post by Harris, Robert


On Tue, 24 Mar 2020 at 11:33, Harris, Robert <[hidden email]> wrote:
Hi,

For the sake of example, I have a library with two files:  a.erl and
b.erl, where a.erl is accompanied by a NIF.  I am constrained by the
need to construct b.erl using the output of a function contained in the
NIF.

I was planning to have the make process (called from rebar) for a's NIF
use an escript to load it in order to generate b.erl.  This doesn't work
because, as far as I can tell, I can't load a NIF from the shell.

Could anyone recommend a clean solution?

Did you consider generating the `b' module at runtime, without in fact ever
creating a `b.erl' file?
 
Robert
Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited
.
Reply | Threaded
Open this post in threaded view
|

Re: Ad hoc use of a NIF

Harris, Robert
In reply to this post by Roger Lipscombe-2
On 24 Mar 2020, at 10:37, Roger Lipscombe <[hidden email]> wrote:

>
> On Tue, 24 Mar 2020 at 10:33, Harris, Robert
> <[hidden email]> wrote:
>> I was planning to have the make process (called from rebar) for a's NIF
>> use an escript to load it in order to generate b.erl.  This doesn't work
>> because, as far as I can tell, I can't load a NIF from the shell.
>
> No, you can't. The module that loads the NIF needs to match the
> declaration in the NIF. More precisely: the name of the calling module
> must match the first argument to ERL_NIF_INIT.
>
> But: you could load 'a' from the shell (or from escript), and invoke
> it that way, no?

Thanks;  it's useful to know that what I was trying was impossible.

a and b are both compiled via rebar3;  I don't think (but am not
certain) that I can configure the compilation to ensure the correct
order and then interpose between the two.

At the moment I'm using rebar's pre-hooks option to invoke the NIF
compilation, which ensures that I do at least have that before building
the Erlang modules.

Robert
Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Reply | Threaded
Open this post in threaded view
|

Re: Ad hoc use of a NIF

Harris, Robert
In reply to this post by Ali Sabil


> On 24 Mar 2020, at 15:14, Ali Sabil <[hidden email]> wrote:
>
> On Tue, 24 Mar 2020 at 11:33, Harris, Robert <[hidden email]> wrote:
> Hi,
>
> For the sake of example, I have a library with two files:  a.erl and
> b.erl, where a.erl is accompanied by a NIF.  I am constrained by the
> need to construct b.erl using the output of a function contained in the
> NIF.
>
> I was planning to have the make process (called from rebar) for a's NIF
> use an escript to load it in order to generate b.erl.  This doesn't work
> because, as far as I can tell, I can't load a NIF from the shell.
>
> Could anyone recommend a clean solution?
>
> Did you consider generating the `b' module at runtime, without in fact ever
> creating a `b.erl' file?

My original description was perhaps over simplified.  By "b.erl" I
really mean a pair of leex/yeec files for which there are not (I
believe) dynamic alternatives.

Robert
Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.