On 20.09.2011 19:59, Matthew Flatt wrote: Matthew,
that "wild guess" was the exact solution, thanks :).
I'm not clear on your example in this case. Can you say more about what "mime-parser.scm" contains as well as the native library that it's using? I have one wild guess, which is that the native library includes a call to scheme_eval() on `struct:exn:fail'. If so, then maybe the current namespace when the library is normally loaded happens to be initialized with `racket/base' bindings, while the current namespace when the module is loaded via `raco make' is in its default empty state. If that wild guess happens to be right, then scheme_builtin_value("struct:exn:fail") might be the right alternative. At Tue, 20 Sep 2011 19:36:06 +0400, Timur Sufiev wrote:On 18.08.2011 10:40, Timur Sufiev wrote: Matthew, another question about "raco make": when compiling via mzc, one can specify so-library as module in require clause, e.g. (require (lib "mzmimer" "jet")) and it is correctly resolved to "/opt/dozor/racket/lib/racket/collects/jetinfo/compiled/native/i386-linux/3m/mz mimer.so" and succesfully loaded. But the same module-path being processed by raco make produces the following error: /opt/dozor/racket/bin/raco make mime-parser.scm #f::0: compile: unbound identifier (and no #%top syntax transformer is bound) in: struct:exn:fail === context === standard-module-name-resolver /opt/dozor/racket/lib/racket/collects/compiler/cm.rkt:279:0: compile-zo* Could you point out how to specify module-path to so-library to make "raco make" compile it?
-- С уважением, Суфиев Тимур _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
