[Pharo-project] Pointer types

Schwab,Wilhelm K bschwab at anest.ufl.edu
Thu Oct 7 06:35:25 EDT 2010


Sig,

Ultimately, I will have to simply try this, but it reminds me of something that I can't place.  Have you considered using a dictionary or other type of collection to store the types?  A new handler would then be created and finally hooked into the system by sending a message to connect it; opposite on removal.  It might turn out to be very much one-to-one so that what I am wondering about does not apply.

Anything that can be double* can also be used with void*.  How does that work?

Bill





________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
Sent: Thursday, October 07, 2010 12:41 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Pointer types

On 7 October 2010 01:27, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
> Sig,
>
> Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI?  That's ok, just want to know if there is an applicable lesson on FFI to be extracted.
>
> You say the NB callout generator knows nothing about types.  Is that how it should be?  The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime.  Maybe all it takes is a scan for a suitable handler before or after the method is compiled.  I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions.  IIRC, Andreas patched the compiler to report the bogus types.
>
>
> "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias:
>
> MyClass>>externalTypeAlias: aTypeName
>   aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ].
>   ^ nil
>
> Then, any method which contains an FFI callout in MyClass, will use that alias."
>
> What is MyClass in the above?  Is it the class holding the callout method, or it elsewhere in the chain?  I ask because it could be a sore spot for maintenance/pluggability.  I'm wondering how you and I would independently add such instructions.  If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other.  Make sense?  My hunch is that you have it handled.
>

Its in an any class, which using FFI callouts. We can stomp on each
other if you define aliases in Object class :)
But this won't be a good idea, isnt?
NBExternalType subclasses defining coercions between ST oops and
concrete C type, they are not for defining aliases.

>
> Bill
>
>
> ________________________________________
> From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
> Sent: Monday, October 04, 2010 7:36 AM
> To: Pharo-project at lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Pointer types
>
> On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
>> Sig,
>>
>> You mentioned something that might be useful, depending on where it lives.  Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess.  Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them.
>>
>> Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call?  If not FFI, how does NB handle it?
>>
>
> In NB, there is a type system, which implements C<->Smalltalk coercions.
> The responsibility of type coercions taken by a subclasses of NBExternalType,
> so NB callout code generator actually knows nothing about types and
> how to coerce them.
>
> To create own custom type, you need to subclass from NBExternalType
> and override methods which responsible for coercions.
> There you can define any kind of operations , what needs to be done in
> order to push value on stack, or
> convert it to some smalltalk object.
>
> Then, in your DoubleArray class, simply implement a message on a class side:
>
> asNBExternalType: gen
>
>        ^ MyDoubleArrayExternalType new
>
>
> And then, in FFI callouts you can use a class name directly:
>
> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr)
>
> etc.
>
> Or, if you want make double* type to use it as a DoubleArray, then you
> can add an alias:
>
> MyClass>>externalTypeAlias: aTypeName
>   aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ].
>   ^ nil
>
> Then, any method which contains an FFI callout in MyClass,
> will use that alias. So, you can write callout as:
>
> double* foo (double *arr, double ** arrPtrPtr)
>
> but it will be understood as:
>
> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr)
>
>
> About handling pointers.. well for smalltalk there is no pointers, just objects.
> So, in NB NBExternalType keeps two things:
>  - a value type
>  - a pointer arity
>
>
> So, for example, when you specifying type, like:
> char ***
>
> a value type will be char
> and pointer arity will be 3.
>
> It is up to NBExternalType subclass how to push values whose pointer arity > 0.
> By default, if pointerArity > 0, then it is treated as a pointer,
> which can be either: - nil, ByteArray, or NBExternalAddress
>
>
>> Bill
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Pharo-dev mailing list