Hi Henry,
On Tue, Sep 18, 2018 at 1:43 AM 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)
>
> (And yes, I've probably badly mangled the options syntax)
>
Why not go for some generic escape sequence that can inject Smalltalk code
into the marshaling? Right now e.g.
primExport: aName value: aValue
^ self ffiCall: #(void moz_preferences_set_bool (short* aName, bool aValue))
is compiled as
primExport: arg1 value: arg2
| tmp1 tmp2 |
'<an unprintable nonliteral value>'
invokeWithArguments:
{(tmp2 := arg1 packToArity: 1).
arg2}
where '<an unprintable nonliteral value>' is the ExternalFunction object
(it could usefully print itself ass a literal and then decompilation would
be meaningful; there is already code in the Squeak FFI repository).
Let's say one added {}'s as characters that can't ever appear in C
parameter lists (of course and alas []'s can because of arrays)≥ Then you
could perhaps write
primExport: aName value: aValue
^ self ffiCall: #(void moz_preferences_set_bool ( { short* aName }
asUTF8String, bool aValue))
and have that generate a send of asUTF8String to arg1 or tmp2. One could
surround the whole thing to apply a coercion to the return value, but
there's no need because one can write e.g.
primExport: aName value: aValue
^(self ffiCall: #(void moz_preferences_set_bool ( { short* aName }
asUTF8String, bool aValue))) fromUTF8String
So then there would be a generic mechanism for in jetting Smalltalk code
into the marshaling and one could develop the string encoding support
independently from the FFI. The options syntax however requires parsing
support, more documentation, and constant extension to support new
facilities, etc.
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
>
>
--
_,,,^..^,,,_
best, Eliot
