> On 18 Sep 2018, at 10:42, Henrik Sperre Johansen
> <[email protected]> wrote:
>
> Guillermo Polito wrote
>> On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant <
>
>> akgrant0710@
>
>> >
>> wrote:
>>
>>> Hi Esteban, Guille and Everyone,
>>>
>>> I haven't looked at using FFI much, however it is easy to imagine that
>>> different file encoding rules on different platforms will make writing
>>> FFI calls more difficult,
>>
>>
>> Well not really (from my point of view :))
>> From the point of view of the FFI call an encoded string is just a bunch
>> of
>> bytes. FFI does not do any interpretation of them.
>
> It *would* be pretty handy for adding some auto-conversion into the
> marshaller based on parameter encoding options though... (other than
> filename, could be done in smalltalk using exisiting encoders)
>
> self
> ffiCall: #(bool saveContentsToFile(String fileName, String contents))
> options: #(+stringEncodings( fileName return , platformAPI contents)
This is cool.
What I do not like is to rely on primitives to do that encoding.
This should be in image… using FFI if needed (this is all because we want to
rely less and less on plugins :P)
Esteban
>
> (And yes, I've probably badly mangled the options syntax)
>
> Is much less verbose than having to manually convert Strings to the proper
> platform Unicode encodings before calling.
> Depends a bit on whether the primitive argument is
> Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one has
> to convert first anyways.
>
> It's not like this isn't a pain point, there are plenty of currently used
> API's that are broken if you try to use non-ascii.
>
> Cheers,
> Henry
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
