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
>

-- 
Best regards,
Igor Stasenko AKA sig.