[Vm-dev] FFI Plugin | Proposal: Add #doesNotCoerce:for: (like #doesNotUnderstand:)
Marcel Taeumel
marcel.taeumel at hpi.de
Fri Jun 19 13:46:30 UTC 2020
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/1e96cee4/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/1e96cee4/attachment-0001.png>
More information about the Vm-dev
mailing list