<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Nicolas, hi Eliot.<div><br></div><div>> <span style="font-size: 10pt">If you want a type that can hold a pointer on both 32 and </span><span class="bold highlight search-highlight" style="font-size: 10pt">64bits</span><span style="font-size: 10pt"> arch, then it's doable with a FFI type alias</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">You can just make an alias to a void*. It will have the right size. The only drawback would be that you might get an issue with argument coercion.</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">#(nil 'void*')<br></span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Your "type alias struct" will wrap around ExternalData<void*>. Why bother with ulong/ulonglong. Only if you want to work with integers in the image, you might want to use ulong or ulonglong depending on the #wordSize.</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">I think I will add 'word' as a type name in ExternalType's class-side "type constants" in Squeak FFI. Then you can use it in FFI call defs and struct-field defs:</span></div><div><span style="font-size: 10pt"><br></span></div><div><div style="">ExternalType class >> #word</div><div style=""><span style="white-space:pre"> </span>"Use this atomic-type alias if the external library works with opaque handles that are different on 32bit and 64bit. On a platform change, all FFI calls will be re-compiled and this method is called again by the parser."</div><div style=""><span style="white-space:pre"> </span></div><div style=""><span style="white-space:pre"> </span>^ FFIPlatformDescription current wordSize = 4</div><div style=""><span style="white-space:pre"> </span>ifTrue: [self unsignedLong]</div><div style=""><span style="white-space: pre;"> </span>ifFalse: [self unsignedLongLong]</div></div><div style=""><br></div><div style="">... maybe parts in the FFI plugin are faster with ulong/ulonglong compared to void* compared to type alias to void*... I don't know.</div><div style=""><br></div><div style="">Best,</div><div style="">Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 30.05.2020 18:00:33 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
So, if the atomic types and structure types are initialized, they make use of ExternalType class >> #pointerSpec to store the size of the pointer in the #headerWord, which is the first element of an external type's 'compiledSpec'. For atomic types, this happens when the FFI package is loaded.<div><br></div><div>For structure types, this happens when a an external structure is mentioned for the first time in an FFI call method or in during compilation of another external structure's fields. See ExternalType class >> #newTypeNamed:force:. Squeak's Smalltalk parser or the compile logic in ExternalStructure invokes that type creation respectively..<div><br></div><div>Currently, if a platform change at system startup is detected, all atomic types and structure types are updated --- which implies a call to #pointerSpec in ExternalType class >> #initializeStructureTypes.</div><div><br></div><div>Now, what could be the situation where a struct-pointer type had the wrong pointer size? During development, your platform does not magically change the #wordSize. When loading code, methods in the external struct might be wrong (bc. Monticello does not trigger that field re-definition) BUT any external struct-pointer type that is already in the image must have the right size. And for new external struct-pointer types, it should work as explained above.</div><div><br></div><div>So, I think we should make the following changes:</div><div>- Remove ExternalType >> #asPointerType: (! note the colon !)</div><div>- Remove ExternalType >> #pointerSize:</div><div>- Change ExternalType >> #pointerSize to just read the compiledSpec</div><div>- Update all sends to #asPointerType: to #asPointerType and assume that the current pointer-type instances have the right size, as described above.</div><div><br></div><div>Best,</div><div>Marcel</div><div><br></div><div class="mb_sig"></div>
</div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 30.05.2020 15:59:31 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">But if it is obsolete now, nuke it.</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I cannot tell. That information is stored in the external type's compiledSpec to be used from within the FFI plugin I suppose.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 29.05.2020 00:15:25 schrieb Eliot Miranda <eliot.miranda@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> On Thu, May 28, 2020 at 11:33 AM Nicolas Cellier <><br>nicolas.cellier.aka.nice@gmail.com> wrote:
<br>
<br>>
<br>> Hi Marcel,
<br>> no idea...
<br>> Look at timestamp:
<br>> eem 2/16/2016 12:42 · accessing · 2 implementors · only in change set
<br>> FFI-Kernel-EstebanLorenzano.45 ·
<br>> So presumably Eliot added that.
<br>>
<br>
<br>Perhaps. I don't remember. But if it is obsolete now, nuke it.
<br>
<br>
<br>>
<br>> Le jeu. 28 mai 2020 à 17:00, marcel.taeumel <marcel.taeumel@hpi.de> a
<br>> écrit :
<br>>
<br>>>
<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>>> >> http://www.squeaksource.com/CroquetGL.html
<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
<br>>> 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
<br>>> 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
<br>>> 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: http://forum.world.st/Squeak-VM-f104410.html
<br>>>
<br>>
<br>
<br>--
<br>_,,,^..^,,,_
<br>best, Eliot
<br><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 28, 2020 at 11:33 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left-width: 1px;border-left-style: solid;border-left-color: rgb(204,204,204);padding-left: 1ex;min-width: 500px"> <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></blockquote><div><br></div><div>Perhaps. I don't remember. But if it is obsolete now, nuke it.</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left-width: 1px;border-left-style: solid;border-left-color: rgb(204,204,204);padding-left: 1ex;min-width: 500px"><div dir="ltr"><div dir="auto"><div></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-width: 1px;border-left-style: solid;border-left-color: rgb(204,204,204);padding-left: 1ex;min-width: 500px"> <br>
<br>Hi Nicolas,<br>
<br><br>
<br>what is the role of ExternalStructure class >> #pointerSize then?<br>
<br><br>
<br>Best,<br>
<br>Marcel<br>
<br><br>
<br><br>
<br>Nicolas Cellier wrote<br>
<br>> Hi all,<br>
<br>> beware of FFI 'long' and 'ulong'.<br>
<br>> They are currently meaning (32 bits) int and unsigned int!<br>
<br>> This dates back from the 80s when there were still odd OS with segmented<br>
<br>> memory and 16-bits int.<br>
<br>> long was thought as a safe int32_t at that time... and still means just<br>
<br>> that in current FFI.<br>
<br>> <br>
<br>> I'd like to replace them with 'int' and 'uint', but we need to ensure<br>
<br>> backward compatibility etc...<br>
<br>> <br>
<br>> FFI has ExternalType signedLongLong or just 'longlong' and ExternalType<br>
<br>> unsignedLongLong or 'ulonglong' which are 64 bits on all architectures.<br>
<br>> See implementors of #initializeAtomicTypes #initializeFFIConstants<br>
<br>> <br>
<br>> If you want a type that can hold a pointer on both 32 and 64bits arch,<br>
<br>> then<br>
<br>> it's doable with a FFI type alias<br>
<br>> For example I have things like this in HDF5 module<br>
<br>> Notice the single #(fieldName fieldType) which defines an alias, while<br>
<br>> ordinary FFI struct gets an array of #(fieldName fieldType)<br>
<br>> (and replace Size_t with Intptr_t if the purpose is hodling a pointer,<br>
<br>> otherwise the ayatollahs of C standard will lash you)<br>
<br>> <br>
<br>> ExternalStructure subclass: #'Size_t'<br>
<br>> instanceVariableNames: ''<br>
<br>> classVariableNames: ''<br>
<br>> poolDictionaries: ''<br>
<br>> category: 'HDF5-External-atomic'<br>
<br>> <br>
<br>> Size_t class >>fields<br>
<br>> "Size_t defineFields"<br>
<br>> ^Smalltalk wordSize = 4<br>
<br>> ifTrue: [#( value 'ulong')]<br>
<br>> ifFalse: [#( value 'ulonglong')]<br>
<br>> <br>
<br>> However the "fields" must be re-generated when platform changes...<br>
<br>> I tried to automate that sometimes ago, see:<br>
<br>> <br>
<br>> ExternalStructure class>>install<br>
<br>> "Resuming the image on another architecture may require a<br>
<br>> re-compilation of structure layout."<br>
<br>> | newPlatform |<br>
<br>> newPlatform := Smalltalk platformName.<br>
<br>> PreviousPlatform = newPlatform<br>
<br>> ifFalse:<br>
<br>> [self recompileStructures.<br>
<br>> PreviousPlatform := newPlatform]<br>
<br>> <br>
<br>> It works if you switch from Win64 to MacOS64 for example...<br>
<br>> However, this mechanism is not used yet at time of code loading, so<br>
<br>> importing code generated on a different platform won't automatically<br>
<br>> update<br>
<br>> the structures (or alias) - the FFI package has no mechanism for that<br>
<br>> (maybe we could add a hook in MC?).<br>
<br>> <br>
<br>> Le mer. 11 mars 2020 à 23:58, Bert Freudenberg <<br>
<br><br>
<br>> bert@<br>
<br><br>
<br>> > a<br>
<br>> écrit :<br>
<br>> <br>
<br>>> I'd suggest to get OpenGL working outside of Croquet first:<br>
<br>>><br>
<br>>> <a href="http://www.squeaksource.com/CroquetGL.html" rel="noreferrer noreferrer" target="_blank">http://www.squeaksource.com/CroquetGL.html</a><br>
<br>>><br>
<br>>> Step 1: Verify this works in 32 bits. (assuming you are doing this on<br>
<br>>> Linux, you can run 32 bit Squeak side-by-side with the 64 bit one)<br>
<br>>> Step 2: Make it work in 64 bits.<br>
<br>>><br>
<br>>> The second step requires that you understand how FFI works, and how it<br>
<br>>> handles e.g. pointers and integer sizes.<br>
<br>>> I am assuming we do have a working 64 bit FFI, at least for x86_64<br>
<br>>> machines.<br>
<br>>><br>
<br>>> E.g. the OGLUnix>>glExtGetProcAddress: method returns a pointer. On a 32<br>
<br>>> bit system, that fits into a 'ulong' which is 32 bits. On a 64 bit<br>
<br>>> system,<br>
<br>>> a pointer is 64 bits wide so it would not fit into a 32 bit word. Now I<br>
<br>>> don't know how many bits 'ulong' has in our 64 bit FFI, but that<br>
<br>>> declaration may have to change. Etc. pp.<br>
<br>>><br>
<br>>> If you have questions about FFI then those are best directed at the<br>
<br>>> vm-dev<br>
<br>>> list since it is dealing with VM-level interfaces. CC'ing, please follow<br>
<br>>> up<br>
<br>>> there.<br>
<br>>><br>
<br>>> - Bert -<br>
<br>>><br>
<br>>> On Wed, Mar 11, 2020 at 2:54 PM gettimothy via Squeak-dev <<br>
<br>>> <br>
<br><br>
<br>> squeak-dev@.squeakfoundation<br>
<br><br>
<br>>> wrote:<br>
<br>>><br>
<br>>>> Okey dokey,<br>
<br>>>><br>
<br>>>> Poking along, there is a stray glyph in OGLUnix openGLLibraryName after<br>
<br>>>><br>
<br>>>> openGLLibraryName<br>
<br>>>> ^Smalltalk osVersion = 'linux'<br>
<br>>>> ifTrue: ['libGL.so.1']<br>
<br>>>> ifFalse: ['GL']<br>
<br>>>><br>
<br>>>> I removed it in my install and got past that error.<br>
<br>>>><br>
<br>>>> Working exclusively with Croquet(Master)...<br>
<br>>>><br>
<br>>>><br>
<br>>>><br>
<br>>>> My next error is in OGLUnixX11LE(OpenGL)>>glMatrixMode:<br>
<br>>>><br>
<br>>>> glMatrixMode: mode<br>
<br>>>> "This method was automatically generated."<br>
<br>>>> "void glMatrixMode(GLenum mode);"<br>
<br>>>> <br>
<br>> <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'><br>
<br>>>> ^self externalCallFailed<br>
<br>>>><br>
<br>>>> The <br>
<br>> <apicall:...><br>
<br>> fails<br>
<br>>>><br>
<br>>>> How to think about this?<br>
<br>>>><br>
<br>>>> Is Croquet behind OpenGL latest?<br>
<br>>>> Would teaching myself OpenGL programming be of use to the Croquet<br>
<br>>>> project?<br>
<br>>>><br>
<br>>>> cheers,<br>
<br>>>><br>
<br>>>> tty<br>
<br>>>><br>
<br>>>><br>
<br>>>><br>
<br>>><br>
<br><br>
<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>
<br></blockquote></div>
<br></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size: 10pt;border-collapse: separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
<br></apicall:...></apicall:></marcel.taeumel@hpi.de></div></blockquote>
</div></div></blockquote></div></div></blockquote></div>