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

Best,
Marcel
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.

Best,
Marcel
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