On Thu, 07 Jan 2010 03:12:14 +0200, Igor Stasenko <siguctua at gmail.com>  
wrote:

> 2010/1/6 vagy <vagy at freemail.gr>:
>> On Tue, 05 Jan 2010 22:13:28 +0200, Andreas Raab <andreas.raab at gmx.de>
>> wrote:
>>
>>> vagy wrote:
>>>>
>>>> Thanx for the tip. I saw your code, though i was thinking more
>>>> along the lines of having a standard DoubleArray implementation in the
>>>> image
>>>> as we have for 32bit Floats. I just saw that FloatArray is  
>>>> implemented in
>>>> terms of variableWordSubclass but there is no  
>>>> variableDoubleWordSubclass
>>>> which, at first glance, may make the whole issue of having a standard
>>>> DoubleArray non trivial. I think we need the opinion of a VM expert  
>>>> here.
>>>> In any way, what do you think about having a standard DoubleArray?
>>>
>>> You're right it's nontrivial, at least for the current object model.  
>>> Many
>>> platforms have 8 byte alignment requirements for doubles and our oops  
>>> are
>>> only 4 byte aligned. This is the main reason why there isn't a double  
>>> array
>>> - since garbage collector will move objects around there is absolutely  
>>> no
>>> guarantee that the double array will be 8 byte aligned. And having a  
>>> double
>>> array that the code in the VM needs to shift to align properly would
>>> completely defeat the purpose of having it in the first place. This may
>>> change with the move to 64 bit or perhaps with some of Eliot's ideas  
>>> about
>>> changing the object format, but it's nothing that is going to happen  
>>> in the
>>> short term.
>>>
>>> Cheers,
>>>   - Andreas
>>
>> I see, thanx for the info. Well then i'll put DoubleArrays on hold for  
>> now
>> and craft something special for my project's use case.
>> Did you take a look at the other issues i raised about FFI? (i can't  
>> paste a
>> link to the relevant message at the moment because the message archive
>> server
>> is down). But I would definitely like a word from you before going on  
>> with
>> it.
>> In a nutshell:
>> - Being able to change single values (and not only the values contained  
>> in
>> Arrays)
>>  when passed down to C through pointer arguments
>>  (for instance if you pass down an Integer through a long* argument, FFI
>> tells
>>  you that you cant treat an Integer like a pointer, when the intended  
>> usage
>> is
>>  treating it like in C, i.e. change the value of the pointed memory)
>> - Have FFI helper functions (that a C client can link against) that  
>> create
>>  whatever Smalltalk Arrays FFI is able to handle (this is inspired from
>> Java's JNI)
>> - Expose interpreterProxy through FFI for advanced uses (sic!) :-)
>>  (Though i don't completely understand the consequences of that and it  
>> feels
>> a little
>>  bit dangerous)
>>
>
> Not a bit more dangerous than FFI itself :)
>
> By changing a module-loading logic a bit (in sqNamedPrims.c -
> findAndLoadModule() function)
> to attempt to call the setInterpreter() function if it available, even
> for FFI module.
>
> Then all you have to do in your module is to define that function, and
> you can use it to
> store pointer to VM API, which will let you create squeak objects and
> have fun :)
>
>> Cheers
>>  - Vagelis
>>
>

Wrt making interpreterProxy available to C code i am fond of Igor's
"don't call us we'll call you" approach but i am also lazy and i like
Andreas's comment about avoiding VM hackery :-).
So what do think about putting this calling code in FFI? Which means
no VM hackery, plus FFI knows all about modules and how to call their
exported functions (so implementation is probably teaching FFI
to do this extra call at initialization i guess), plus we wont have
to implement such functionality (in some plugin) every time we need it
since it will be in standard FFI available to all future uses.

What do you think about the other two concerns of mine? (see above)

Cheers
  - Vagelis