[ANN] SWIG for Smalltalk, 1.3.21-0.22a *Dolphin Support*

New in this version:

* Dolphin 5.1 & X6 support

See:

http://commonsmalltalk.wikispaces.com/

Enjoy!

Ian

---
http://www.upright.net/ian/

Looks interesting, but the wiki pages are painfully slow to download.

This is great, Ian.  I'm surprised that your project isn't getting more
attention; there are a lot of C++ libraries out there, and manually
wrapping them in C and Smalltalk is a huge chore.

I finally used SWIG for Smalltalk this weekend -- to interface Dolphin
with PTK, a game engine.  Generating the wrappers was fairly
straightforward.  I haven't succeeded yet in getting PTK to play nicely
with Smalltalk, but that isn't a SWIG issue (I suspect that PTK assumes
its game window has its own thread).  I then tried to create wrappers
for a different engine, and didn't quite succeed (SWIG can't handle
unions defined within a class; my workarounds got rid of the warning,
but the generated code was not what I desired).

A couple of wrapper methods were missing parentheses.  For example, the
body of KWindow>>getWindowHandle was

     ^SwigTypePHWND fromPointer: PtkNI ptkNI_KWindow_getWindowHandle:
swigCPtrForKWindow  memoryOwn: true

instead of

     ^SwigTypePHWND fromPointer: (PtkNI ptkNI_KWindow_getWindowHandle:
swigCPtrForKWindow) memoryOwn: true

The <module name>EmbeddedConstants.ssi file contains multiple Enum
elements (one for every 20 constants), but only the first one is
processed by the AML importer.  I fixed this by modifying
BasicAMLImporter>>importClassElement:.

The first time, I didn't use the "stconstembed" feature.  The AML
importer choked while generating the constants because it was calling
DLL methods, and the module hadn't been initialized yet.  Once I started
using the feature, everything was fine.

I experimented with defining STNICALL as __stdcall instead of __cdecl in
stni.h.  This caused a couple of problems: (1) genconst.exe couldn't
find the outputSWIGConstants() function (BTW, an error message would be
helpful); (2) the Smalltalk code generated by the AML importer assumes
the __cdecl convention.  There's no compelling reason not to use
__cdecl; I'd simply read that __stdcall is more common and slightly more
efficient.  I guess __cdecl is more robust because it works for
functions that take a variable argument list.

I hope my nitpicking hasn't scared anyone away from SWIG for Smalltalk.
  It takes a bit of time to learn the steps if you've never used SWIG
before and you're rusty at compiling C++ projects (like me).  Ian's
documentation and examples are very helpful.  I've often avoided using a
C++ library with Smalltalk because it would take too much effort to
wrap.  Even plain ol' C interfacing is a chore if there are a lot of
functions and structures.  Also, SWIG for Smalltalk is cross-dialect, so
there is now a standard way to create external interfaces.

Cheers,
-- Aaron

Ian Upright wrote:

Aaron Wieland <[hidden email]> wrote:

>This is great, Ian.  I'm surprised that your project isn't getting more
>attention; there are a lot of C++ libraries out there, and manually
>wrapping them in C and Smalltalk is a huge chore.

Excellent, glad to see some pepople are starting to use it!

I'll take a look at this, and try to reproduce.  It should be trivial to
fix.  (and is probably a bug with the SWIG C module, or an error in the
Smalltalk smalltalk-all.swg typemaps.

>The <module name>EmbeddedConstants.ssi file contains multiple Enum
>elements (one for every 20 constants), but only the first one is
>processed by the AML importer.  I fixed this by modifying
>BasicAMLImporter>>importClassElement:.

Ahh..  Thats good to know, since I never created a test case for this.  I
suspect I'll need to fix this on all platforms, but fortunately the changed
code should remain identical accross all platforms.

>The first time, I didn't use the "stconstembed" feature.  The AML
>importer choked while generating the constants because it was calling
>DLL methods, and the module hadn't been initialized yet.  Once I started
>using the feature, everything was fine.

Yeah, there are a few issues with not using the stconstembed that I need to
fix.

>I experimented with defining STNICALL as __stdcall instead of __cdecl in
>stni.h.  This caused a couple of problems: (1) genconst.exe couldn't
>find the outputSWIGConstants() function (BTW, an error message would be
>helpful); (2) the Smalltalk code generated by the AML importer assumes
>the __cdecl convention.  There's no compelling reason not to use
>__cdecl; I'd simply read that __stdcall is more common and slightly more
>efficient.  I guess __cdecl is more robust because it works for
>functions that take a variable argument list.

True.  Perhaps I should add a switch to the AMLImporter to indicate what
kind of calling convention is preferred, and then a #define could determine
what kind of calling convention is used by the generated code.  I just
noticed that JNI uses stdcall by default, so perhaps this module should too.

In addition, the outputSWIGConstants function should probably use some kind
of fixed calling convention instead of using STNICALL.  Something I didn't
think of.  All good points!

Cheers, and thanks for the feedback!

Ian

---
http://www.upright.net/ian/