[Vm-dev] [squeak-dev] Usability of Squeak FFI for anything serious...

[Nicolas Cellier]

2018-04-13 21:28 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
>
>
> On Fri, Apr 13, 2018 at 10:59 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>>
>> 2018-04-13 17:08 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>> Hi Nicolas,
>>>
>>>
>>> On Apr 13, 2018, at 7:01 AM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> So I started to improve the Squeak FFI:
>>> -1) I corrected pointer arithmetic on 64 bits
>>> http://source.squeak.org/FFI/FFI-Kernel-nice.48.diff
>>> -2) I prepared the possibility of having automated layout spec updates
>>> http://source.squeak.org/FFI/FFI-Kernel-nice.49.diff
>>>
>>> Note that the FFI plugin by itself did not change.
>>> The next steps should be to provide support for native platform
>>> alignment of fields and unions.
>>> I'll focus on these when i can.
>>>
>>>
>>> I shall join you as soon as I am able.  Right now I have a pressing
>>> task, but within a few weeks I should be able to help.
>>>
>>>
>> Hi Eliot,
>> thanks.
>> I think that I can manage the easiest image side issues, but as soon as a
>> feature will require an evolution of the plugin, your review is mandatory,
>> as well as coordination with Pharo team, Backward compatibility counts and
>> Esteban spent enough time on UFFI, so this will mean either unifying our
>> forces or forking a plugin!
>>
>
> Sounds good.  A fork is to be avoided at all costs.  I don't see any
> pressure for a fork though because the plugin is essentially defined by the
> platform's ABI and Andreas' design for the type specification language is
> sufficiently general.  Am I missing something?  (Esteban are you reading?)
>
>
With my current understanding, two essential features are missing in the
type compiledSpec:
- multiple indirection pointers (I've got an example of these in HDF5)
- fixed size arrays in struct members (I've got an example in HDF5 too!)

For now, we can workaround with
- void * declaration and human crafted pointer handling
- unrolled array members (1 member per array slot!)

A modification of FFI would be necessary only for enforcing type checking.
I don't plan anything right now, and I agree that doing so with backward
compatibility is by far preferred.

2018-04-12 23:27 GMT+02:00 Denis Kudriashov <dionisiydk at gmail.com>:
>>>
>>>> Hi
>>>>
>>>> There is project TalkFFI <https://github.com/estebanlm/TalkFFI> from
>>>> Ciprian Teodorov.
>>>>
>>>> 2018-04-12 22:50 GMT+02:00 Bert Freudenberg <bert at freudenbergs.de>:
>>>>
>>>>> On 12 April 2018 at 22:34, Nicolas Cellier <
>>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> There are at least two problems:
>>>>>> - documentation (lack of)
>>>>>> - limitations (unions, pointer on pointer on ...)
>>>>>> - automation (I said at least two, not at most)
>>>>>>
>>>>>> For the first problem, I opened the SO issues. Not ideal, but it's a
>>>>>> start.
>>>>>> For the second, I'll see if I can do something...
>>>>>> For the third, I did import some .h header with VW DLLCC, and I'm in
>>>>>> the process of translating to other dialects.
>>>>>> It's easier because Smalltalk syntax is order of magnitudes smaller
>>>>>> than C syntax.
>>>>>>
>>>>>
>>>>> ​I always thought it should be fairly straightforward to make a FFI
>>>>> bindings generator using SWIG (http://www.swig.org/).
>>>>>
>>>>> SWIG parses C headers and outputs XML. Starting from that XML should
>>>>> be way easier than trying to parse C ourselves.
>>>>>
>>>>> ​- Bert -​
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180413/76b1f797/attachment.html>