<div dir="ltr"><div>Hi all,</div><div>beware of FFI 'long' and 'ulong'.</div><div>They are currently meaning (32 bits) int and unsigned int!</div><div>This dates back from the 80s when there were still odd OS with segmented memory and 16-bits int.</div><div>long was thought as a safe int32_t at that time... and still means just that in current FFI.</div><div><br></div><div>I'd like to replace them with 'int' and 'uint', but we need to ensure backward compatibility etc...<br></div><div><br></div><div>FFI has ExternalType signedLongLong or just 'longlong' and ExternalType unsignedLongLong or 'ulonglong' which are 64 bits on all architectures.</div><div>See implementors of #initializeAtomicTypes #initializeFFIConstants</div><div><br></div><div>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</div><div>For example I have things like this in HDF5 module</div><div>Notice the single #(fieldName fieldType) which defines an alias, while ordinary FFI struct gets an array of #(fieldName fieldType)</div><div>(and replace Size_t with Intptr_t if the purpose is hodling a pointer, otherwise the ayatollahs of C standard will lash you)<br></div><div><br></div><div>ExternalStructure subclass: #'Size_t'<br>    instanceVariableNames: ''<br>    classVariableNames: ''<br>    poolDictionaries: ''<br>    category: 'HDF5-External-atomic'</div><div><br></div><div>Size_t class >>fields<br>    "Size_t defineFields"<br>    ^Smalltalk wordSize = 4<br>        ifTrue: [#( value 'ulong')]<br>        ifFalse: [#( value 'ulonglong')]</div><div><br></div><div>However the "fields" must be re-generated when platform changes...</div><div>I tried to automate that sometimes ago, see:<br></div><div><br></div><div>ExternalStructure class>>install<br>          "Resuming the image on another architecture may require a re-compilation of structure layout."<br>          | newPlatform |<br>     newPlatform := Smalltalk platformName.<br>           PreviousPlatform = newPlatform<br>                        ifFalse:<br>                                  [self recompileStructures.<br>            PreviousPlatform := newPlatform]</div><div><br></div><div>It works if you switch from Win64 to MacOS64 for example...<br></div><div>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?).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 11 mars 2020 à 23:58, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.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"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I'd suggest to get OpenGL working outside of Croquet first:<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><a href="http://www.squeaksource.com/CroquetGL.html" target="_blank">http://www.squeaksource.com/CroquetGL.html</a><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">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)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Step 2: Make it work in 64 bits.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">The second step requires that you understand how FFI works, and how it handles e.g. pointers and integer sizes.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">I am assuming we do have a working 64 bit FFI, at least for x86_64 machines.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">E.g. the OGLUnix>><span style="text-align:justify;font-family:Arial,Helvetica,sans-serif">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.</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><span style="text-align:justify;font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><span style="text-align:justify;font-family:Arial,Helvetica,sans-serif">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.</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">- Bert -</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 2:54 PM gettimothy via Squeak-dev <<a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:10pt"><div>Okey dokey,<br></div><div><br></div><div>Poking along, there is a stray glyph in OGLUnix openGLLibraryName after<br></div><blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)"><div><div>openGLLibraryName<br></div><div>^Smalltalk osVersion = 'linux'<br></div><div>ifTrue: ['libGL.so.1']<br></div><div>ifFalse: ['GL']<br></div></div></blockquote><div>I removed it in my install and got past that error.<br></div><div><br></div><div>Working exclusively with Croquet(Master)...<br></div><div><br></div><div><br></div><div><br></div><div>My next error is in OGLUnixX11LE(OpenGL)>>glMatrixMode: <br></div><blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)"><div><div>glMatrixMode: mode<br></div><div>"This method was automatically generated."<br></div><div>"void glMatrixMode(GLenum mode);"<br></div><div><apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'><br></div><div>^self externalCallFailed<br></div></div></blockquote><div>The <apicall:...> fails<br></div><div><br></div><div>How to think about this?<br></div><div><br></div><div>Is Croquet behind OpenGL latest?<br></div><div>Would teaching myself OpenGL programming be of use to the Croquet project?<br></div><div><br></div><div>cheers,<br></div><div><br></div><div>tty</div></div><br></div><br>
</blockquote></div></div>
<br>
</blockquote></div>