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?

>> 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