[squeak-dev] FFI: FFI-Kernel-nice.118.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Mon Jun 22 08:30:37 UTC 2020

Hi Nicolas,

> I'd like to simply write (MyStruct new: 25) to get an array of 25 MyStruct.
> I DO NOT want to see the ExternalData, it's an implementation detail blurring the intentions.

Then you would just hide what I just proposed behind #new: in your struct. :-) I just argued to not put 
#allocate: in ExternalType.

However, you want to treat MyStruct to be able to answer an array of itself. This is not okay. Well, it might be C-style, but not Smalltalk-style. We should try to find a connection between C-world and Smalltalk-world. Would you do that with "Morph new: 25"? Expect an array of 25 morphs?

If you want to have an array, ExternalData is the closes we have at the moment. It can directly work like Collection.

So, #new: (or similar) is a thing you want to implement in ExternalData, not MyStruct.

Well ... if you insist on creating an array of MyStruct through MyStruct .... I would at least not use #new: but rather #newArray: ... 

> I want to see/handle my domain specific "objects" DIRECTLY.

Sure. But having an array of your domain specific objects is handled via ExternalData. ExternalData is like Collection (or Array).

Am 22.06.2020 10:21:23 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
Hi Marcel,
The idea is to manipulate the alias or structures types as if they were classes.

I already can write MyStruct new, and pass that to an external function call.
I'd like to simply write (MyStruct new: 25) to get an array of 25 MyStruct.
I DO NOT want to see the ExternalData, it's an implementation detail blurring the intentions.

I want to see/handle my domain specific "objects" DIRECTLY.
That's what I manipulate in function signatures, etc...

Since external types are not exactly classes, i prefer to have another vocabulary in place of new:.
In VW DLLCC, the selectors malloc malloc: calloc calloc: gcMalloc gcMalloc: are sent to the CType.

Unlike us, DLLCC does not allocate in objectMemory, always on the heap.
So having the C vocabulary is logical for them.

Allocating in ObjectMemory is one essential feature of Squeak FFI.
That's why I prefer not use C vocabulary.
#allocate: is something in between.
I know that it is already used on the low level for ExternalAddress, which is unfortunate.

Le lun. 22 juin 2020 à 09:31, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

Hi Nicolas.

I like the idea of having #allocate: ... but maybe not in ExternalType:

- The term "allocate:" is somewhat reserved for heap memory from the SqueakFFI perspective; See ExternalAddress class >> #allocate:.
- The counterpart #free is missing ... which means that, maybe, both #allocate: and #free should be implemented in ExternalData, not ExternalType

What about such a this programming interface:

data := ExternalData
   fromHandle: nil
   type: MyStruct externalType asPointerType.
data allocate.
myStruct := data asExternalStructure.

You could also copy it back to object memory:

myStruct := data getExternalStructure. "get/pull/fetch ...."
data free.

You are proposing a way to start off in object memory. Maybe like this:

data := ExternalData
   fromHandle: nil "maybe optional?"
   type: MyStruct externalType asPointerType.
data allocateLocal.
myStruct := data asExternalStructure.

Then we don't need to call #free. See how #allocate and #allocateLocal in ExternalData could mirror #new and #externalNew of ExternalStructure?

There is really an interesting releationship between ExternalStructure (incl. ExternalUnion/ExternalTypeAlias/ExternalPackedStructure) and ExternalData. Can you see it? ^__^

Arrays could be similar:

data := ExternalData type: Externaltype int32_t asPointerType.
data size: 20.
data allocate. "or #allocateLocal"

Now you would have an array of 20 integers. :-) Note that #allocate: with argument could inline that #size: call.

Am 21.06.2020 13:20:44 schrieb commits at source.squeak.org [mailto:commits at source.squeak.org] <commits at source.squeak.org [mailto:commits at source.squeak.org]>:
Nicolas Cellier uploaded a new version of FFI-Kernel to project FFI:
http://source.squeak.org/FFI/FFI-Kernel-nice.118.mcz [http://source.squeak.org/FFI/FFI-Kernel-nice.118.mcz]

==================== Summary ====================

Name: FFI-Kernel-nice.118
Author: nice
Time: 21 June 2020, 1:20:34.369348 pm
UUID: a8c48997-991d-4e32-9b67-6d93fc0dabe0
Ancestors: FFI-Kernel-mt.117

Add the ability to allocate: an ExternalType or an ExternalStructure/Alias.

It's equivalent to new: but we want a specific idiom, C types are not exactly classes.

Add the ability to compare aliases (at least for equality)

=============== Diff against FFI-Kernel-mt.117 ===============

Item was added:
+ ----- Method: ExternalStructure class>>allocate: (in category 'instance creation') -----
+ allocate: anInteger
+ "Create an ExternalData with enough room for storing an array of size anInteger of such structure"
+ ^self externalType allocate: anInteger!

Item was added:
+ ----- Method: ExternalType>>allocate: (in category 'external data') -----
+ allocate: anInteger
+ "Allocate space for containing an array of size anInteger of this dataType"
+ | handle |
+ handle := ByteArray new: self byteSize * anInteger.
+ ^(ExternalData fromHandle: handle type: self) size: anInteger!

Item was added:
+ ----- Method: ExternalTypeAlias>>= (in category 'comparing') -----
+ = anExternalTypeAlias
+ ^self class = anExternalTypeAlias class and: [self value = anExternalTypeAlias value]!

Item was added:
+ ----- Method: ExternalTypeAlias>>hash (in category 'comparing') -----
+ hash
+ ^self class hash hashMultiply bitXor: self value hash!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200622/da7c6e86/attachment.html>

More information about the Squeak-dev mailing list