2010/1/5 vagy <vagy at freemail.gr>:
> Igor Stasenko wrote:
>>
>> The difference between FloatArray and Array of floats (or array of
>> arbitrary objects)
>> is in storage format. While first storing a number of native
>> floating-point values, edigible for C,
>> while second stores references to other objects (oop-s).
>
> Indeed and this means that we can change values in C land when they
> are contained in said Arrays (ByteArray, FloatArray, IntegerArray, etc)
> but not when sent down as single values, which strikes me as kinda
> inconsistent, at least from an FFI usage point of view.
> A bit OT, speaking of FloatArray, it changes the Floats you put into it
> into single precision. So currently it is impossible to pass to C an array
> of double precision Floats. Shouldn't the image also have a DoubleArray for
> that purpose?
>

See how I did this in Smallapack-Collections
http://www.squeaksource.com/Smallapack.html
I created an ExternalArray and various subclasses.

Nicolas

>>> Another thing that isn't clear to me is if its possible to have FFI
>>> create
>>> Smalltalk objects
>>> in behalf of a requesting client. In Java's JNI for instance one can say:
>>>
>>>  jni->NewFloatArray(length of the array);
>
>
>> in that case, i think, you'd better create a VM plugin, which having
>> an access to something similar to 'jni'
>> object, which in squeak is called 'interpreterProxy'.
>
> If i understood correctly, writing a plugin with the sole purpose
> of giving access to interpreterProxy seems overkill. I would like to
> have this as standard functionality provided by FFI (and i am willing
> to implement it if you (guys) see it as valuable.
> If on the other hand you meant writing a plugin and completely bypassing
> FFI, i would rather not do it until i exhaust all possibilities with FFI
> because, modulo the issues we are talking about here, it serves my needs
> excellently.
>
>> Thinking about it, i came to interesting idea, that really, we could
>> pass a pointer to interpreterProxy
>> variable to FFI function, so, potentially, it could make use of VM API
>> functions to create objects, or access existing ones.
>
> Yeap, plus have a bunch of utility routines for creating arrays.
> There is some code in FFI thats along those lines, FFI can create
> Strings (because it knows how to copy the data from a null terminated
> C char array, see ffiReturnCStringFrom).
> Symmetrically, we can extend FFI to create Arrays of all possible basic
> types for us, let the client fill those appropriately, and then let
> FFI return the oop up to the image as usual.
>
>> I don't know if that will be ever used, since writing a plugin looks
>> much more appropriate in that case.
>
> In my scenarios it would be useful, hopefully its generally useful :-)
>
> To sum up my thoughts/propositions:
>  - extend FFI with a bunch of functions that create Arrays of predefined
> size
>   of all possible C types
>  - extend FFI to provide access to the VM (via interpreterProxy) for all
>   possible unforeseen usages and needs that aren't served by FFI's existing
>   functionality
>  - (not directly FFI related) create DoubleArray object in image.
>
> I hope all these are technically feasible...
>
> Cheers
>  - Vagelis
>
>