[Vm-dev] FFI Plugin | Proposal: Add #doesNotCoerce:for: (like #doesNotUnderstand:)

[Marcel Taeumel]

Hi all!

What would be the "best English" for such a mechanism?

anExternalLibrary doesNotCoerce: aCallArg for: aMessage.
anExternalLibrary doesNotCoerce: aCallArg in: aMessage.

anExternalLibrary cannotCoerce: aCallArg for: aMessage.
anExternalLibrary cannotCoerce: aCallArg in: aMessage.

...

Best,
Marcel
Am 19.06.2020 15:46:30 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Nicolas.

> - enable ExternalData to have an ExternalStructure or ExternalTypeAlias as type inst. var.

This does not sound right. But I think you mean that "type" in ExternalData could be a struct type and the plugin would automatically coerce it correctly.

That's good. :-)

"type" in ExternalData must always be an instance of ExternalType.

> This way, we can make FFI a bit safer than using those void *

Sounds good.

Best,
Marcel

P.S.: I think I messed up with the name "ExternalTypeAlias". Hmpf. Because is a subclass of ExternalStructure, not ExternalType. Well. :-)
Am 19.06.2020 15:09:01 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
Hi Marcel,
Forget about FFIPlugin it's legacy

I'm currently changing ThreadedFFIPlugin to:
- enable passing ExternalData as atomicType by value
The use case is the one of ExternalVariable
- enable ExternalData to have an ExternalStructure or ExternalTypeAlias as
type inst. var.
and enable passing that to a corresponding
ExternalStructure/ExternalStructure pointer/ExternalTypeAlias/
ExternalTypeAlias pointer
- returning a new ExternalTypeAlias when returning such type by value

This way, we can make FFI a bit safer than using those void *


Le ven. 19 juin 2020 à 13:45, Marcel Taeumel a
écrit :

>
> Hi all, again. :-)
>
> I am aware that such a mechanism would have to be implemented in 2-times-7
> different places:
>
>
> Best,
> Marcel
>
> Am 19.06.2020 13:15:40 schrieb Marcel Taeumel :
> Hi all!
>
> We have #doesNotUnderstand:, which is sent to the receiver when a message
> cannot be understood. Default reaction in Object is to raise
> MessageNotUnderstood exception.
>
> What if we could have a similar mechanism for FFI calls:
> #doesNotCoerce:for:. The receiver would be the one that made that call,
> should be an instance of ExternalLibrary, but could be any object. The
> arguments would be a pair of (argObject, argType) and the message (like the
> argument for doesNotUnderstand:) that represents the FFI call.
>
> The pair of (argObject, argType) could be expressed as FFICallArgument:
>
> FFICallArgument
> argObject ...
> argType ...
>
> I suppose that such a new class would have to be reserved in the special
> objects array. An alternative would be to just use Array. Keep it simple.
> ;-)
>
> Default reaction could be to implement #doesNotCoerce:for: in Object (as
> *FFI-Kernel extension) to raise FFICallArgumentNotCoerced exception (to be
> implemented). Also, we could implement manual coercion in ExternaLibrary
> to, for example, wrap atomics into their aliasing structures.
>
> ExternalLibrary >> #doesNotCoerce: callArg for: message
> | argObject argType argIndex wrappedArg |
> argObject := callArg first. "or argObject accessor"
> argType := callArg second. "or argType accessor"
> argIndex := message arguments indexOf: argObject.
> wrappedArg := argType referentClass fromHandle: argObject.
> message arguments beWritableObject. "Just in case ;-)"
> message at: argIndex put: wrappedArg.
> ^ message sendTo: self
>
> Please share your thoughts. :-)
>
> Best,
> Marcel
>
>

Hi Marcel,
Forget about FFIPlugin it's legacy

I'm currently changing ThreadedFFIPlugin to:
- enable passing ExternalData as atomicType by value
 The use case is the one of ExternalVariable
- enable ExternalData to have an ExternalStructure or ExternalTypeAlias as type inst. var.
 and enable passing that to a corresponding ExternalStructure/ExternalStructure pointer/ExternalTypeAlias/ ExternalTypeAlias pointer
- returning a new ExternalTypeAlias when returning such type by value


This way, we can make FFI a bit safer than using those void *


Le ven. 19 juin 2020 à 13:45, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

 

Hi all, again. :-)

I am aware that such a mechanism would have to be implemented in 2-times-7 different places:


Best,
Marcel

Am 19.06.2020 13:15:40 schrieb Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]>:
Hi all!

We have #doesNotUnderstand:, which is sent to the receiver when a message cannot be understood. Default reaction in Object is to raise MessageNotUnderstood exception.

What if we could have a similar mechanism for FFI calls: #doesNotCoerce:for:. The receiver would be the one that made that call, should be an instance of ExternalLibrary, but could be any object. The arguments would be a pair of (argObject, argType) and the message (like the argument for doesNotUnderstand:) that represents the FFI call.

The pair of (argObject, argType) could be expressed as FFICallArgument:

FFICallArgument
   argObject  ... <Object>
   argType ... <ExternalType>

I suppose that such a new class would have to be reserved in the special objects array. An alternative would be to just use Array. Keep it simple. ;-)

Default reaction could be to implement #doesNotCoerce:for: in Object (as *FFI-Kernel extension) to raise FFICallArgumentNotCoerced exception (to be implemented). Also, we could implement manual coercion in ExternaLibrary to, for example, wrap atomics into their aliasing structures.

ExternalLibrary >> #doesNotCoerce: callArg for: message
   | argObject argType argIndex wrappedArg |
   argObject := callArg first. "or argObject accessor"
   argType := callArg second. "or argType accessor"
   argIndex := message arguments indexOf: argObject.
   wrappedArg := argType referentClass fromHandle: argObject.
   message arguments beWritableObject. "Just in case ;-)"
   message at: argIndex put: wrappedArg.
   ^ message sendTo: self

Please share your thoughts. :-)

Best,
Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200619/10dca1d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32538 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200619/10dca1d8/attachment-0001.png>