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 nat
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 w
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/nat
On 17.08.2011 16:58, Matthew Flatt wrote:
Thanks, Matthew, it works!
I think that "ihash.scm" is being compiled twice: once when you use
`mzc' on "ihash.scm" and again when using `mzc' on
"config-enumerators.scm", assuming that you move the ".zo" files into
place only after compiling both of them
I think that "ihash.scm" is being compiled twice: once when you use
`mzc' on "ihash.scm" and again when using `mzc' on
"config-enumerators.scm", assuming that you move the ".zo" files into
place only after compiling both of them. Unfortunately, due to the way
contracts expand, compiling a source fi
Hi!
I'm having a problem with byte-compiled modules and contracts. There are
2 files, ihash.scm and config-enumerators.scm, both are compiled with
PLTCOLLECTS=/opt/dozor/racket/lib/racket/collects:/home/timur/develop/projects/dozor/build
LD_LIBRARY_PATH=/opt/dozor/racket/lib:$$LD_LIBRARY_PAT
6 matches
Mail list logo
