[plt-scheme] x != x for module names?!

Matthew, hello.

On 2010 Jan 30, at 14:39, Matthew Flatt wrote:

> At Sat, 30 Jan 2010 14:17:07 +0000, Norman Gray wrote:
>> Scheme_Object *scheme_module_name(void) {
>>  return scheme_make_symbol((char*)"Redland");
>> }
> 
> scheme_make_symbol() creates an uninterned symbol.
> Use scheme_intern_symbol().

Thanks.  I've made that change:

Scheme_Object *scheme_module_name(void) {
  return scheme_intern_symbol((char*)"Redland");
}

...and now I get a different error:

% mzscheme -e '(path->string (build-path "compiled" "native" (system-library-subpath)))'
"compiled/native/i386-macosx/3m"
% ls -l compiled/native/i386-macosx/3m
total 200
-rwxr-xr-x  1 norman  admin  101560 30 Jan 16:03 Redland_ss.dylib*
% mzscheme
Welcome to MzScheme v4.2.4 [3m], Copyright (c) 2004-2010 PLT Scheme Inc.
> (require "Redland.ss")
require: unknown module: "/Data/tools/000-Build/mzscheme-librdf-bindings/Redland.ss"

 === context ===
/Data/LocalApplications/PLT Scheme/PLT Scheme v4.2.4/collects/scheme/private/misc.ss:74:7

> ^D
% 

I'm following the instructions at the end of section 1.2.1 of <http://docs.plt-scheme.org/inside/overview.html>, here.  Those appear to be referring to the CGC mode, but since they refer to and are apparently consistent with the documentation of load/use-compiled in <http://docs.plt-scheme.org/reference/eval.html>, I'm at a bit of a loss again.

If I create a dummy Redland.ss and then touch the .dylib to be newer than it, I get the same error; if I rename both to all-lowercase and then (require "redland.ss") mzscheme objects that module 'redland' is not the same as module 'Redland' being provided, which is of course true, but confirms that the .dylib _is_ being examined here.

I've tried this with both --cgc and --3m, in case this makes a difference, but I'm aware that I'm clutching at straws here.

>> Incidentally, does anyone know if I have to include --xform with wrapper code 
>> generated from SWIG.  My impression is not, but I can't find this confirmed 
>> anywhere.
> 
> Does the SWIG-generated code include MZ_GC_DECL_REG(), etc? If so, then
> you don't need --xform. If not, my guess is that you do (but I'm not
> sure).

Righto -- it doesn't. I'll stick to --cgc rather than fight with --xform, I think.  Incidentally, the text in "1.2.2: 3m extensions" shows --xform and --cc being given together, which is not allowed.

Thanks for any further pointers.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk