FFI debugging lesson

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI debugging lesson

Schwab,Wilhelm K
I did some FFI based work in Pharo 1.0 and realized something that I found surprising; this might help others new to it.  An incorrect argument type in a call spec does not result in a compile-time error; instead it leads to "Cannot coerce arguments" at the time of the call.  FWIW.

Bill


Reply | Threaded
Open this post in threaded view
|

Re: FFI debugging lesson

Igor Stasenko
On 25 May 2010 01:34, Schwab,Wilhelm K <[hidden email]> wrote:
> I did some FFI based work in Pharo 1.0 and realized something that I found surprising; this might help others new to it.  An incorrect argument type in a call spec does not result in a compile-time error; instead it leads to "Cannot coerce arguments" at the time of the call.  FWIW.
>

Yes, i think its because at the time , when a method with FFI callout
is compiled, the type names, which specified in it
may not be present at the moment. So, a final check should be
performed at the time, when you doing an actual call.

Similarily, NB does the same, when you first calling a method, it
founds that method contains no native code,
and then during the code generation performs type checking of
arguments for generating coercions.

> Bill
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: FFI debugging lesson

Andreas.Raab
On 5/24/2010 4:25 PM, Igor Stasenko wrote:
> On 25 May 2010 01:34, Schwab,Wilhelm K<[hidden email]>  wrote:
>> I did some FFI based work in Pharo 1.0 and realized something that I found surprising; this might help others new to it.  An incorrect argument type in a call spec does not result in a compile-time error; instead it leads to "Cannot coerce arguments" at the time of the call.  FWIW.
>>
>
> Yes, i think its because at the time , when a method with FFI callout
> is compiled, the type names, which specified in it
> may not be present at the moment. So, a final check should be
> performed at the time, when you doing an actual call.

No, the number of arguments is unrelated to that. I think the issue is
really that historically the selector wasn't even preserved in the
Parser so there wasn't a good way to have that check without changing
the Parser even more. Nowadays we do have the info, so the check is
trivial to add (in fact I just did that).

Cheers,
   - Andreas