<div dir="ltr"><div>Well, we have void *, it's opaque enough.</div><div>In this case, the storage area must be allocated on heap by some foreign function, and a pointer to it passed back as handle.</div><div>The problem with void * is that it is not specific enough.</div><div>We thus generally create a type alias. A type alias is a subclass of ExternalStructure. As such, the class name can be used as a type specification in external function interface.</div><div>An aliased type differs from a regular struct by the fields definition at class side.</div><div>While structure has fields made of an array of pairs #( #(memberName ffiType) ), an aliased type as a single array #( nil ffiType ).</div><div>Using nil avoids creating an accessor. The ffiType can be an integer large enough to hold a pointer (intptr_t, but we do not support that in FFI) - See WinHandle in the FFI-Win32 examples - or 'void *' (I think it may work, but it's a long time since I did not test).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 12 mars 2020 à 15:21, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.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="auto"><div>Would it be possible to include an opaque "pointer" basic type in the FFI, to prevent reinventing the wheel in each project? It should reshape accordingly with the platform. If not possible, what are the hurdles?</div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> schrieb am Do., 12. März 2020, 13:21:<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>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" rel="noreferrer" target="_blank">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 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 style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><a href="http://www.squeaksource.com/CroquetGL.html" rel="noreferrer" target="_blank">http://www.squeaksource.com/CroquetGL.html</a><br></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div 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 style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Step 2: Make it work in 64 bits.</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div 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 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 style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div 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 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 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 style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div 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" rel="noreferrer" 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>
</blockquote></div></div></div>
<br>
</blockquote></div></div>