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

[Marcel Taeumel]

Maybe this helps:

FFISmallStruct1 externalType ~~ FFISmallStruct1.
FFISmallStruct1 externalType == (ExternalType structTypeNamed: FFISmallStruct1 className).
FFISmallStruct1 externalType referentClass == FFISmallStruct1.


FFISmallStruct1 new isKindOf: ExternalStructure.
FFISmallStruct1 externalType isKindOf: ExternalType.

ExternalTypeAlias inheritsFrom: ExternalStructure. "!!!"

Best,
Marcel
Am 19.06.2020 16:01:53 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Nicolas.

>ExternalStructureFoo (the class, not an instance) acts as an ExternalType
> surrogate.

Well, only by name. Not by object identity.

> ExternalType structTypeNamed: #FFISmallStruct1.
> It will answer FFISmallStruct1, so FFISmallStruct1 is a type somehow, a
> structType more exactly (or a type alias).

Well, #structTypeNamed: answers an instance of ExternalType whose referentClass points to the structure class, which is FFISmallStruct in this example.

Yet, the VM / plugin does not care about the name here. It only cares about instances of ExternalType and to which referentClass those types point.

Best,
Marcel
Am 19.06.2020 15:58:59 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
Le ven. 19 juin 2020 à 15:46, Marcel Taeumel a
écrit :

>
> 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.
>
> I see what you mean.
But, that's not exactly how it works.
ExternalStructureFoo (the class, not an instance) acts as an ExternalType
surrogate.
See:
ExternalType structTypeNamed: #FFISmallStruct1.
It will answer FFISmallStruct1, so FFISmallStruct1 is a type somehow, a
structType more exactly (or a type alias).

I suggest to use that as ExternalData type whenever we have a pointer to a
FFISmallStruct1 or an array of FFISmallStruct1.
It also make FFI type checking super easy, because we already pass the
FFISmallStruct1 as argClass (only when passing struct by value by now, but
I suggest extending it when passing FFISmallStruct1 *, which currently is
not even possible - we have to declare void *)


> 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 ...
>
>



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

 






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.

I see what you mean.
But, that's not exactly how it works.
ExternalStructureFoo (the class, not an instance) acts as an ExternalType surrogate.
See:
    ExternalType structTypeNamed: #FFISmallStruct1.
It will answer FFISmallStruct1, so FFISmallStruct1 is a type somehow, a structType more exactly (or a type alias).


I suggest to use that as ExternalData type whenever we have a pointer to a FFISmallStruct1 or an array of FFISmallStruct1.
It also make FFI type checking super easy, because we already pass the FFISmallStruct1 as argClass (only when passing struct by value by now, but I suggest extending it when passing FFISmallStruct1 *, which currently is not even possible - we have to declare void *)



> 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 [mailto: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 ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200619/8022455c/attachment-0001.html>