Swig and MzScheme's _scheme_get_type_name

[Paul Fernhout <pdfernhout@kurtz-fernhout.com>]

I'm using DrScheme 103 and Swig 1.3 (Alpha 3) 
  http://www.swig.org/
to wrap a DLL. 

I get everything to work, defining a new data type for a structure
passed around, except I needed to comment out some of the following
lines to make it compile.:

void *swig_get_c_pointer(Scheme_Object *so, char *c_type) {
    Scheme_Type st = SCHEME_TYPE(so);
    //char *type_name = scheme_get_type_name(st);
    //if(strcmp(type_name, c_type))
    //scheme_signal_error("wrong type in foreign object %s", type_name);

    return (void *) ((swig_proxy *) so)->object;
}

This was because "_scheme_get_type_name" can't be found by the linker.
Any thoughts on what I might be doing wrong? I have rebuilt mzdyn.obj
myself (required as I use for VC 5.0), and the OBJ does not appear to
contain a reference to the function.

With those error checking lines commented out (which basically area
safety check to ensure the pointer passed into the functions is of the
correct type) everything seems to run.

I also get the error when I try to build the simple Swig example for
MzScheme.

For the curious, the DLL is a C version of the Pointrel Data Repository
System I wrote:         
  http://www.pointrel.com/ 
I also wrote a MzScheme version of that (which uses a FileIO dll which I
wrote to support it) but I decided it would probably be easier to
support one DLL called by multiple languages. I've now got source
versions in Python, Squeak Smalltalk, Delphi Pascal, Java, MzScheme, and
C -- although some of them are slightly incompatible in API and file
format. I also have wrappers in Python and now MzScheme for a C DLL
(under windows).

The value of linking something like the Pointrel system into MzScheme is
that it can function as a lightweight object-oriented repository, such
as for storing help documents, source code versions, metadata, and so on
in one big repository file. This is a more efficient use of disk space
as opposed to all those little MzScheme help files now on my system
which take up 4K each (due to disk cluster size issues). Also, the
repository could in theory also gzip the text of such files, providing a
further size reduction. Also, this means one could ship an application
with all the support files in one big repository (makes for less
clutter). (Yes, obviously then you need to trust the integrity of the
data repository...) However, the bigger issue beyond file size is really
storing metadata and arbitrary associations to data.

(Now if I just knew how to hook the DrScheme file handling routines to
redirect them when desired into my repository system without having to
rebuild DrScheme...)

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com