Hi Ben,
Disclaimer: I haven't gone through the code, but this is my understanding.
On Tue., 30 Oct. 2018, 14:26 Ben Coman, btc@openinworld.com wrote:
On Tue, 30 Oct 2018 at 20:22, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Oct 30, 2018, at 4:57 AM, Ben Coman btc@openinworld.com wrote:
Those implementations can come later. Right now the plugin doesn’t simulate anyway. You’re right I could have written them then and there, but I would rather do real o es than simple failing stubs. If I find that I can’t simulate without stubs I’ll add them. Feel free to provide them if you’re motivated. I should have just fixed the digitCompare: issue but got carried away...
I'm still missing something basic, but guessing... the "inSmalltalk:" part is what is performed by the simulator?
and the "cCode:" is generated into a C-code-call that expects that function linked in from a library?
and now there is no simulation and "b3dxAllocateTexture:_:_:_:" is generated to C-code-call?
So is there a mechanism that any unknown message (i.e. "b3dxAllocateTexture:_:_:_:") is generated to a C-code-call?
Not quite. There is a table of special messages, e.g ifTrue:ifFalse: is converted to the normal C if else statement.
Every other message send is converted to a function call. The function is either internal, i.e. Supplied by another method, or external (which the linker should find).
Cheers, Alistair (on phone)