[plt-scheme] Problem defining PLT Scheme modules in C

At Tue,  2 Sep 2003 18:04:40 -0300, "carlos.scheidegger" wrote:
> I then create a test-module.ss file:
> 
> (module test-module mzscheme
>   (provide (all-defined))
>   (define test (dynamic-require "ext.so" 'test)))

`dynamic-require' won't work on an extension file directly. But if you
put the extension in a
  (build-path "compiled" "native" (system-library-subpath))
subdirectory and then use
  (dyanmic-require "ext.ss" 'test)
it should work, even though the file "ext.ss" doesn't exist. It works
because `dynamic-require' uses `load-relative/use-compiled', which
searches for the extension.

> 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")

The second `require' doesn't give you an error because it doesn't
re-execute the body of "test-module.ss". In general, only the first
`require' executes the body.

> 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))

In this case, the code is loaded, but `load-extension' is just a
function --- it doesn't lexically bind anything inside the module.

> 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).

Right - the trick is to put the extension in a suitable sub-directory
(as described above).

Hope that helps,
Matthew