[plt-scheme] Problem defining PLT Scheme modules in C
Hello all.
I am trying to create some modules for MzScheme using the C
extension mechanisms, and I am experimenting some strange
behavior. My example is so simple that I'll post the source
here. I'm using PLT Scheme 205, and the problems show up in both
Windows and Unix versions.
First I created a C extension called ext.c, like this:
/*--------------------------------------------------------------------
-------*/
#include <escheme.h>
#include <stdio.h>
Scheme_Object *scm_test(void *p, int c, Scheme_Object **v)
{
printf("Test was called\n");
return scheme_void;
}
Scheme_Object *scheme_reload(Scheme_Env *env)
{
Scheme_Env *mod_env;
Scheme_Object *proc;
mod_env = scheme_primitive_module(scheme_intern_symbol("ext"),
env);
proc = scheme_make_closed_prim_w_arity
(scm_test, "test", "test", 0, 0);
scheme_add_global("test", proc, mod_env);
scheme_finish_primitive_module(mod_env);
return scheme_void;
}
Scheme_Object *scheme_initialize(Scheme_Env *env)
{
return scheme_reload(env);
}
Scheme_Object *scheme_module_name(void)
{
return scheme_intern_symbol("ext");
}
/*--------------------------------------------------------------------
-------*/
The shared object is created using mzc (with the appropriate .o and
.so extensions for unix, or .obj and .dll for windows).
I then create a test-module.ss file:
(module test-module mzscheme
(provide (all-defined))
(define test (dynamic-require "ext.so" 'test)))
Here are some example interaction logs:
Welcome to MzScheme version 205, Copyright (c) 1995-2003 PLT
> (require "test-module.ss")
default-load-handler: expected a `module' declaration for `ext',
found: something else in: /home/scheidegger/code/tests/ext.so
> (require "test-module.ss")
> (test)
reference to uninitialized module identifier: test in module:
|,/home/scheidegger/code/tests/test-module|
>
If I change "ext.so" to "ext.ss" in the example above, I get the
following behavior:
Welcome to MzScheme version 205, Copyright (c) 1995-2003 PLT
> (require "test-module.ss")
default-load-handler: cannot open input file:
"/home/scheidegger/code/tests/ext.ss" (No such file or directory;
errno=2)
> (require "test-module.ss")
> (test)
reference to uninitialized module identifier: test in module:
|,/home/scheidegger/code/tests/test-module|
>
Loading the module directly at the top-level works:
Welcome to MzScheme version 205, Copyright (c) 1995-2003 PLT
> (load-extension "ext.so")
> (require ext)
> (test)
Test was called
>
On the other hand, trying to load it inside a
module does not work, like this (let's call it "test-module2.ss"):
(module test-module2 mzscheme
(provide (all-defined))
(load-extension "ext.so")
(require ext))
The interaction goes like this:
Welcome to MzScheme version 205, Copyright (c) 1995-2003 PLT
> (require "test-module2.ss")
require: unknown module: ext
>
There are many weird things happening. The first of them is the fact
that if I try to require the module a second time, it does not give me
an error. The second strange thing I've noticed is that the sgl
collections seem to require an inexistent gl-prims.ss. I suppose the
module resolver tries to change the extension, so I've tried the two
alternatives (Neither of them worked, as you can see above). I've also
tried some other different random combinations of load-extension and
require, to no success.
Is there something absurdly stupid in what I'm trying to do? I modeled
my tests after the sgl collection, which seems to define the modules
and C extensions the way I did. Is there some magic happening behind
the curtains in the MzLib require's?
Thanks in advance for any help,
Carlos Eduardo Scheidegger