>�� �� ��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.
Right, but getting the appropriately encoded bunch of bytes is the issue. :-)
Yes, the thing is that this would require some new extensions in uFFI to support encodings.
The good point of that is that that would have a positive impact in **ALL* FFI bindings using strings (by making explicit to people that they should care about encodings :)).
��
> Maybe... Are the OSX routines exposed as C functions (that we can call through
> FFI) or they are objective-C methods/functions (that are more complicated to
> map)?
The OSX routines are exposed as C functions (and available as
Objective-C methods), see convertChars() in
platforms/unix/vm/sqUnixCharConv.c.
Nice!
On Tue, Sep 18, 2018 at 11:21:41AM +0200, Esteban Lorenzano wrote:
> > 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)
I realise of course that this could all be done in FFI, and I agree with
all Estaban's arguments in favour of FFI, my main motivation was that
the code is already in the VM, and to avoid code duplication with the
obvious benefit that if a bug is fixed it will apply everywhere.
Yeh. At the end it's a matter of debugging cycles.
Imagine making the "compile-restart" steps that you're facing while changing the plugin almost negligible in the "change-compile-restart-test" loop :).