Le jeu. 12 mars 2020 à 13:21, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> Hi all,
> beware of FFI 'long' and 'ulong'.
> They are currently meaning (32 bits) int and unsigned int!
> This dates back from the 80s when there were still odd OS with segmented
> memory and 16-bits int.
> long was thought as a safe int32_t at that time... and still means just
> that in current FFI.
>
> I'd like to replace them with 'int' and 'uint', but we need to ensure
> backward compatibility etc...
>
> FFI has ExternalType signedLongLong or just 'longlong' and ExternalType
> unsignedLongLong or 'ulonglong' which are 64 bits on all architectures.
> See implementors of #initializeAtomicTypes #initializeFFIConstants
>
> If you want a type that can hold a pointer on both 32 and 64bits arch,
> then it's doable with a FFI type alias
> For example I have things like this in HDF5 module
> Notice the single #(fieldName fieldType) which defines an alias, while
> ordinary FFI struct gets an array of #(fieldName fieldType)
> (and replace Size_t with Intptr_t if the purpose is hodling a pointer,
> otherwise the ayatollahs of C standard will lash you)
>
> ExternalStructure subclass: #'Size_t'
>     instanceVariableNames: ''
>     classVariableNames: ''
>     poolDictionaries: ''
>     category: 'HDF5-External-atomic'
>
> Size_t class >>fields
>     "Size_t defineFields"
>     ^Smalltalk wordSize = 4
>         ifTrue: [#( value 'ulong')]
>         ifFalse: [#( value 'ulonglong')]
>
> However the "fields" must be re-generated when platform changes...
> I tried to automate that sometimes ago, see:
>
> ExternalStructure class>>install
>      "Resuming the image on another architecture may require a
> re-compilation of structure layout."
>      | newPlatform |
>      newPlatform := Smalltalk platformName.
>      PreviousPlatform = newPlatform
>          ifFalse:
>              [self recompileStructures.
>             PreviousPlatform := newPlatform]
>
> It works if you switch from Win64 to MacOS64 for example...
> However, this mechanism is not used yet at time of code loading, so
> importing code generated on a different platform won't automatically update
> the structures (or alias) - the FFI package has no mechanism for that
> (maybe we could add a hook in MC?).
>
> Hmm, there is already a MC hook that recompiles the field spec (it sends
#compileFields).
But it does not re-generate field accessors (self compileFields: fieldSpec
withAccessors: #never.)
Further calls to checkFieldLayoutChange don't recompile the fields either,
because the compiledSpec is now up-to-date "thanks" to MC hook.

I think I did that purposedly for avoiding a bunch of 'only timestamp
changed', but this was not the right solution for cross-platform support.
Since Eliot has also protected spurious recompilation thru
#maybeCompileAccessor:withSelector: it's safer to regenerate the accessors.
I do change that now in
https://source.squeak.org/FFI/FFI-Kernel-nice.68.diff


> Le mer. 11 mars 2020 à 23:58, Bert Freudenberg <bert at freudenbergs.de> a
> écrit :
>
>> I'd suggest to get OpenGL working outside of Croquet first:
>>
>> http://www.squeaksource.com/CroquetGL.html
>>
>> Step 1: Verify this works in 32 bits. (assuming you are doing this on
>> Linux, you can run 32 bit Squeak side-by-side with the 64 bit one)
>> Step 2: Make it work in 64 bits.
>>
>> The second step requires that you understand how FFI works, and how it
>> handles e.g. pointers and integer sizes.
>> I am assuming we do have a working 64 bit FFI, at least for x86_64
>> machines.
>>
>> E.g. the OGLUnix>>glExtGetProcAddress: method returns a pointer. On a 32
>> bit system, that fits into a 'ulong' which is 32 bits. On a 64 bit system,
>> a pointer is 64 bits wide so it would not fit into a 32 bit word. Now I
>> don't know how many bits 'ulong' has in our 64 bit FFI, but that
>> declaration may have to change. Etc. pp.
>>
>> If you have questions about FFI then those are best directed at the
>> vm-dev list since it is dealing with VM-level interfaces. CC'ing, please
>> follow up there.
>>
>> - Bert -
>>
>> On Wed, Mar 11, 2020 at 2:54 PM gettimothy via Squeak-dev <
>> squeak-dev at lists.squeakfoundation.org> wrote:
>>
>>> Okey dokey,
>>>
>>> Poking along, there is a stray glyph in OGLUnix openGLLibraryName after
>>>
>>> openGLLibraryName
>>> ^Smalltalk osVersion = 'linux'
>>> ifTrue: ['libGL.so.1']
>>> ifFalse: ['GL']
>>>
>>> I removed it in my install and got past that error.
>>>
>>> Working exclusively with Croquet(Master)...
>>>
>>>
>>>
>>> My next error is in OGLUnixX11LE(OpenGL)>>glMatrixMode:
>>>
>>> glMatrixMode: mode
>>> "This method was automatically generated."
>>> "void glMatrixMode(GLenum mode);"
>>> <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'>
>>> ^self externalCallFailed
>>>
>>> The <apicall:...> fails
>>>
>>> How to think about this?
>>>
>>> Is Croquet behind OpenGL latest?
>>> Would teaching myself OpenGL programming be of use to the Croquet
>>> project?
>>>
>>> cheers,
>>>
>>> tty
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200312/535aad82/attachment.html>