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

Fri Jun 19 15:14:45 UTC 2020

Le ven. 19 juin 2020 à 16:02, Marcel Taeumel <marcel.taeumel at hpi.de> a
écrit :

>
> 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.
>
>
> Ah sorry, my mistake.
I indeed need to go thru referentClass to achieve what I was thinking of.
Thanks!

> 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.
>
Since we pass argClass, we can simply check against ExternalData type
referentClass.

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