[NativeBoost] Generic failure errors when using nil for void* and char* arguments

Hello,

On 20 April 2012 15:59, Jan van de Sandt <[hidden email]> wrote:
For pointers, there is an options in callouts, #optCoerceNilToNull
which should be set,
then you can invoke the call with nil as argument, which will convert
it to C NULL.

By default this option is OFF, because extra check means extra cycles.

You can control a callout options by either per function call (see
NBBasicExamples>>readDoubleFrom:)
or for all methods of your class as a whole, like:

MyClass class>>ffiCalloutOptions
        "by default, return all pointers as an instance of external address "
        ^ #(
                + optReturnPtrAsExternalAddress
                + optCoerceNilToNull  "passing nil as pointer, will convert it to null(0) "
        )

> Jan.



--
Best regards,
Igor Stasenko.

Yes, now it works! Thanks Igor.

Sig,

I wonder whether that should be on by default.  I have had some real frustrations with FFI of late, and something like this might have avoided the problem.  Unless it is easily discoverable, off is almost the same as non-existent.

Any rumblings on Spock?  It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms.  It would indelicate to mention that this was supposed to happen in January<g>.  I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks.  I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks.  The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds.

I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try.

Bill

________________________________________
From: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
Sent: Friday, April 20, 2012 10:46 AM
To: [hidden email]
Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments

On 20 April 2012 15:59, Jan van de Sandt <[hidden email]> wrote:
For pointers, there is an options in callouts, #optCoerceNilToNull
which should be set,
then you can invoke the call with nil as argument, which will convert
it to C NULL.

By default this option is OFF, because extra check means extra cycles.

You can control a callout options by either per function call (see
NBBasicExamples>>readDoubleFrom:)
or for all methods of your class as a whole, like:

MyClass class>>ffiCalloutOptions
        "by default, return all pointers as an instance of external address "
        ^ #(
                + optReturnPtrAsExternalAddress
                + optCoerceNilToNull  "passing nil as pointer, will convert it to null(0) "
        )

> Jan.



--
Best regards,
Igor Stasenko.

On 20 April 2012 17:45, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig,
>
> I wonder whether that should be on by default.  I have had some real frustrations with FFI of late, and something like this might have avoided the problem.  Unless it is easily discoverable, off is almost the same as non-existent.
>

Well, it depends on POV. For the strictness of usage, i thought it is
better to pass explicitly (NBExternalAddress value: 0) than nil,
so that your code passing correct value types to function(s).
Automatic coercion and weak typing is something which i hate in C, and
try to avoid (smalltalk is strong typed language) i.e.

unsigned long a = 10000000;
char x = a;

producing only a compiler warning. and if you put:

char x = (char) a;

you can suppress it.

But this is like placing a time bomb into your code, which you never
know when it will explode.
Weak typing is common source of many errors and bugs which is hard to find.

This is one of the reasons, why i don't want nil to be a valid
argument for functions expecting pointer(s) by default. Because while
some library functions say that NULL is valid argument, on opposite
side, there another functions which expecting a valid pointer value,
and if you pass nil (as a result of not fully initialized object), you
will crash the application.

> Any rumblings on Spock?  It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms.  It would indelicate to mention that this was supposed to happen in January<g>.

Yes, i am lazy guy, who cannot do much. Sorry :)

The plans are still there: add callbacks support, add threading, unify
Alien and NB.

>I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks.  I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks.  The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds.
>
> I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try.
>

i want that everything start working too.. so i can move on oh higher
levels, since NativeBoost is infrastructural kind of project.



> Bill


--
Best regards,
Igor Stasenko.

oh, and as meta-comment,
i should add a more comprehensible error message, like
'FFI Callout failed, when trying to coerce arguments' or something like that,
instead of 'Generic failure' which is just a sign that primitive
failed and no call were performed.

But right now, just keep that in mind: every time you got a generic
error in FFI callout, first thing you should look at
is what are you passing as arguments, and what is C function expects.

--
Best regards,
Igor Stasenko.

Sig,

For the record, you are not lazy.  We'll start to live long and prosper when you get to it.

Thanks!

Bill



________________________________________
From: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
Sent: Friday, April 20, 2012 12:08 PM
To: [hidden email]
Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments

On 20 April 2012 17:45, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig,
>
> I wonder whether that should be on by default.  I have had some real frustrations with FFI of late, and something like this might have avoided the problem.  Unless it is easily discoverable, off is almost the same as non-existent.
>

Well, it depends on POV. For the strictness of usage, i thought it is
better to pass explicitly (NBExternalAddress value: 0) than nil,
so that your code passing correct value types to function(s).
Automatic coercion and weak typing is something which i hate in C, and
try to avoid (smalltalk is strong typed language) i.e.

unsigned long a = 10000000;
char x = a;

producing only a compiler warning. and if you put:

char x = (char) a;

you can suppress it.

But this is like placing a time bomb into your code, which you never
know when it will explode.
Weak typing is common source of many errors and bugs which is hard to find.

This is one of the reasons, why i don't want nil to be a valid
argument for functions expecting pointer(s) by default. Because while
some library functions say that NULL is valid argument, on opposite
side, there another functions which expecting a valid pointer value,
and if you pass nil (as a result of not fully initialized object), you
will crash the application.

> Any rumblings on Spock?  It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms.  It would indelicate to mention that this was supposed to happen in January<g>.

Yes, i am lazy guy, who cannot do much. Sorry :)

The plans are still there: add callbacks support, add threading, unify
Alien and NB.

>I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks.  I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks.  The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds.
>
> I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try.
>

i want that everything start working too.. so i can move on oh higher
levels, since NativeBoost is infrastructural kind of project.



> Bill


--
Best regards,
Igor Stasenko.