<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        Hi all!<div><br></div><div>What would be the "best English" for such a mechanism?</div><div><br></div><div>anExternalLibrary doesNotCoerce: aCallArg for: aMessage.</div><div><span style="font-size: 13.3333px">anExternalLibrary doesNotCoerce: aCallArg in: aMessage.</span><br></div><div><div>anExternalLibrary cannotCoerce: aCallArg for: aMessage.</div><div><span style="font-size: 13.3333px">anExternalLibrary cannotCoerce: aCallArg in: aMessage.</span><br></div><div>...</div></div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 19.06.2020 15:46:30 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Nicolas.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">- enable ExternalData to have an ExternalStructure or ExternalTypeAlias as </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">type inst. var.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">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.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">That's good. :-)</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">"type" in ExternalData must always be an instance of ExternalType.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">> </span></span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">This way, we can make FFI a bit safer than using those void *</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Sounds good.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Best,</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Marcel</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">P.S.: I think I messed up with the name "ExternalTypeAlias". Hmpf. Because is a subclass of ExternalStructure, not ExternalType. Well. :-)</span></span></div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 19.06.2020 15:09:01 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel,
<br>Forget about FFIPlugin it's legacy
<br>
<br>I'm currently changing ThreadedFFIPlugin to:
<br>- enable passing ExternalData as atomicType by value
<br> The use case is the one of ExternalVariable
<br>- enable ExternalData to have an ExternalStructure or ExternalTypeAlias as
<br>type inst. var.
<br> and enable passing that to a corresponding
<br>ExternalStructure/ExternalStructure pointer/ExternalTypeAlias/
<br>ExternalTypeAlias pointer
<br>- returning a new ExternalTypeAlias when returning such type by value
<br>
<br>This way, we can make FFI a bit safer than using those void *
<br>
<br>
<br>Le ven. 19 juin 2020 à 13:45, Marcel Taeumel <marcel.taeumel@hpi.de> a
<br>écrit :
<br>
<br>>
<br>> Hi all, again. :-)
<br>>
<br>> I am aware that such a mechanism would have to be implemented in 2-times-7
<br>> different places:
<br>>
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 19.06.2020 13:15:40 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:
<br>> Hi all!
<br>>
<br>> We have #doesNotUnderstand:, which is sent to the receiver when a message
<br>> cannot be understood. Default reaction in Object is to raise
<br>> MessageNotUnderstood exception.
<br>>
<br>> What if we could have a similar mechanism for FFI calls:
<br>> #doesNotCoerce:for:. The receiver would be the one that made that call,
<br>> should be an instance of ExternalLibrary, but could be any object. The
<br>> arguments would be a pair of (argObject, argType) and the message (like the
<br>> argument for doesNotUnderstand:) that represents the FFI call.
<br>>
<br>> The pair of (argObject, argType) could be expressed as FFICallArgument:
<br>>
<br>> FFICallArgument
<br>>    argObject  ... <object>
<br>>    argType ... <externaltype>
<br>>
<br>> I suppose that such a new class would have to be reserved in the special
<br>> objects array. An alternative would be to just use Array. Keep it simple.
<br>> ;-)
<br>>
<br>> Default reaction could be to implement #doesNotCoerce:for: in Object (as
<br>> *FFI-Kernel extension) to raise FFICallArgumentNotCoerced exception (to be
<br>> implemented). Also, we could implement manual coercion in ExternaLibrary
<br>> to, for example, wrap atomics into their aliasing structures.
<br>>
<br>> ExternalLibrary >> #doesNotCoerce: callArg for: message
<br>>    | argObject argType argIndex wrappedArg |
<br>>    argObject := callArg first. "or argObject accessor"
<br>>    argType := callArg second. "or argType accessor"
<br>>    argIndex := message arguments indexOf: argObject.
<br>>    wrappedArg := argType referentClass fromHandle: argObject.
<br>>    message arguments beWritableObject. "Just in case ;-)"
<br>>    message at: argIndex put: wrappedArg.
<br>>    ^ message sendTo: self
<br>>
<br>> Please share your thoughts. :-)
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>>
<br><div dir="ltr"><div>Hi Marcel,</div><div>Forget about FFIPlugin it's legacy</div><div><br></div><div>I'm currently changing ThreadedFFIPlugin to:</div><div>- enable passing ExternalData as atomicType by value</div><div> The use case is the one of ExternalVariable</div><div>- enable ExternalData to have an ExternalStructure or ExternalTypeAlias as type inst. var.</div><div> and enable passing that to a corresponding ExternalStructure/ExternalStructure pointer/ExternalTypeAlias/ ExternalTypeAlias pointer</div><div>- returning a new ExternalTypeAlias when returning such type by value<br></div><div><br></div><div>This way, we can make FFI a bit safer than using those void *</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 19 juin 2020 à 13:45, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex;min-width: 500px"> <div><div id="gmail-m_7855815963219822473__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0)">
<br>                                        Hi all, again. :-)<div><br></div><div>I am aware that such a mechanism would have to be implemented in 2-times-7 different places:</div><div><img id="gmail-m_7855815963219822473bc47896d-300c-45f4-9151-bc9cb22d9e1a" src="cid:172cca9df8fcb971f161" width="auto"></img><br></div><div><br></div><div>Best,</div><div>Marcel</div><div></div><blockquote type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 19.06.2020 13:15:40 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="gmail-m_7855815963219822473__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0)">Hi all!<div></div><div><br></div><div>We have #doesNotUnderstand:, which is sent to the receiver when a message cannot be understood. Default reaction in Object is to raise MessageNotUnderstood exception.</div><div><br></div><div>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.</div><div><br></div><div>The pair of (argObject, argType) could be expressed as FFICallArgument:</div><div><br></div><div>FFICallArgument</div><div>   argObject  ... <Object></div><div>   argType ... <ExternalType></div><div><br></div><div>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. ;-)</div><div><br></div><div>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.</div><div><br></div><div>ExternalLibrary >> #doesNotCoerce: callArg for: message</div><div>   | argObject argType argIndex wrappedArg |</div><div>   argObject := callArg first. "or argObject accessor"</div><div>   argType := callArg second. "or argType accessor"</div><div>   argIndex := message arguments indexOf: argObject.</div><div>   wrappedArg := argType referentClass fromHandle: argObject.</div><div>   message arguments beWritableObject. "Just in case ;-)"</div><div>   message at: argIndex put: wrappedArg.</div><div>   ^ message sendTo: self</div><div><br></div><div>Please share your thoughts. :-)</div><div><br></div><div>Best,</div><div>Marcel</div></div></div></blockquote>
<br>                                        </div></div></blockquote></div>
<br></externaltype></object></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></div></blockquote></div></div></blockquote></div>