<div dir="ltr"><div dir="auto">Hi Marcel,</div><div dir="auto">no idea...</div><div>Look at timestamp:</div><div>eem 2/16/2016 12:42 · accessing · 2 implementors · only in change set FFI-Kernel-EstebanLorenzano.45 · </div><div dir="auto"><div>So presumably Eliot added that.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 28 mai 2020 à 17:00, marcel.taeumel <<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">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"> <br>
Hi Nicolas,<br>
<br>
what is the role of ExternalStructure class >> #pointerSize then?<br>
<br>
Best,<br>
Marcel<br>
<br>
<br>
Nicolas Cellier wrote<br>
> Hi all,<br>
> beware of FFI 'long' and 'ulong'.<br>
> They are currently meaning (32 bits) int and unsigned int!<br>
> This dates back from the 80s when there were still odd OS with segmented<br>
> memory and 16-bits int.<br>
> long was thought as a safe int32_t at that time... and still means just<br>
> that in current FFI.<br>
> <br>
> I'd like to replace them with 'int' and 'uint', but we need to ensure<br>
> backward compatibility etc...<br>
> <br>
> FFI has ExternalType signedLongLong or just 'longlong' and ExternalType<br>
> unsignedLongLong or 'ulonglong' which are 64 bits on all architectures.<br>
> See implementors of #initializeAtomicTypes #initializeFFIConstants<br>
> <br>
> If you want a type that can hold a pointer on both 32 and 64bits arch,<br>
> then<br>
> it's doable with a FFI type alias<br>
> For example I have things like this in HDF5 module<br>
> Notice the single #(fieldName fieldType) which defines an alias, while<br>
> ordinary FFI struct gets an array of #(fieldName fieldType)<br>
> (and replace Size_t with Intptr_t if the purpose is hodling a pointer,<br>
> otherwise the ayatollahs of C standard will lash you)<br>
> <br>
> ExternalStructure subclass: #'Size_t'<br>
> instanceVariableNames: ''<br>
> classVariableNames: ''<br>
> poolDictionaries: ''<br>
> category: 'HDF5-External-atomic'<br>
> <br>
> Size_t class >>fields<br>
> "Size_t defineFields"<br>
> ^Smalltalk wordSize = 4<br>
> ifTrue: [#( value 'ulong')]<br>
> ifFalse: [#( value 'ulonglong')]<br>
> <br>
> However the "fields" must be re-generated when platform changes...<br>
> I tried to automate that sometimes ago, see:<br>
> <br>
> ExternalStructure class>>install<br>
> "Resuming the image on another architecture may require a<br>
> re-compilation of structure layout."<br>
> | newPlatform |<br>
> newPlatform := Smalltalk platformName.<br>
> PreviousPlatform = newPlatform<br>
> ifFalse:<br>
> [self recompileStructures.<br>
> PreviousPlatform := newPlatform]<br>
> <br>
> It works if you switch from Win64 to MacOS64 for example...<br>
> However, this mechanism is not used yet at time of code loading, so<br>
> importing code generated on a different platform won't automatically<br>
> update<br>
> the structures (or alias) - the FFI package has no mechanism for that<br>
> (maybe we could add a hook in MC?).<br>
> <br>
> Le mer. 11 mars 2020 à 23:58, Bert Freudenberg <<br>
<br>
> bert@<br>
<br>
> > a<br>
> écrit :<br>
> <br>
>> I'd suggest to get OpenGL working outside of Croquet first:<br>
>><br>
>> <a href="http://www.squeaksource.com/CroquetGL.html" rel="noreferrer noreferrer" target="_blank">http://www.squeaksource.com/CroquetGL.html</a><br>
>><br>
>> Step 1: Verify this works in 32 bits. (assuming you are doing this on<br>
>> Linux, you can run 32 bit Squeak side-by-side with the 64 bit one)<br>
>> Step 2: Make it work in 64 bits.<br>
>><br>
>> The second step requires that you understand how FFI works, and how it<br>
>> handles e.g. pointers and integer sizes.<br>
>> I am assuming we do have a working 64 bit FFI, at least for x86_64<br>
>> machines.<br>
>><br>
>> E.g. the OGLUnix>>glExtGetProcAddress: method returns a pointer. On a 32<br>
>> bit system, that fits into a 'ulong' which is 32 bits. On a 64 bit<br>
>> system,<br>
>> a pointer is 64 bits wide so it would not fit into a 32 bit word. Now I<br>
>> don't know how many bits 'ulong' has in our 64 bit FFI, but that<br>
>> declaration may have to change. Etc. pp.<br>
>><br>
>> If you have questions about FFI then those are best directed at the<br>
>> vm-dev<br>
>> list since it is dealing with VM-level interfaces. CC'ing, please follow<br>
>> up<br>
>> there.<br>
>><br>
>> - Bert -<br>
>><br>
>> On Wed, Mar 11, 2020 at 2:54 PM gettimothy via Squeak-dev <<br>
>> <br>
<br>
> squeak-dev@.squeakfoundation<br>
<br>
>> wrote:<br>
>><br>
>>> Okey dokey,<br>
>>><br>
>>> Poking along, there is a stray glyph in OGLUnix openGLLibraryName after<br>
>>><br>
>>> openGLLibraryName<br>
>>> ^Smalltalk osVersion = 'linux'<br>
>>> ifTrue: ['libGL.so.1']<br>
>>> ifFalse: ['GL']<br>
>>><br>
>>> I removed it in my install and got past that error.<br>
>>><br>
>>> Working exclusively with Croquet(Master)...<br>
>>><br>
>>><br>
>>><br>
>>> My next error is in OGLUnixX11LE(OpenGL)>>glMatrixMode:<br>
>>><br>
>>> glMatrixMode: mode<br>
>>> "This method was automatically generated."<br>
>>> "void glMatrixMode(GLenum mode);"<br>
>>> <br>
> <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'><br>
>>> ^self externalCallFailed<br>
>>><br>
>>> The <br>
> <apicall:...><br>
> fails<br>
>>><br>
>>> How to think about this?<br>
>>><br>
>>> Is Croquet behind OpenGL latest?<br>
>>> Would teaching myself OpenGL programming be of use to the Croquet<br>
>>> project?<br>
>>><br>
>>> cheers,<br>
>>><br>
>>> tty<br>
>>><br>
>>><br>
>>><br>
>><br>
<br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://forum.world.st/Squeak-VM-f104410.html" rel="noreferrer noreferrer" target="_blank">http://forum.world.st/Squeak-VM-f104410.html</a><br>
</blockquote></div>