[plt-scheme] Re: Standard module resolver issue

There are two obstacles here:

 * Loading the generated program from source requires the `scheme/lang'
   reader, which normally would not be needed in an executable (since
   the code is all compiled). That's why you needed to add a link to
   the collection directory. An alternative is to build the executable
   like this:

      mzc --exe gen ++lib scheme/lang/reader gen.scm

 * The unit error comes from the fact that "test-sig.scm" is being
   instantiated twice, since it is reference through two different
   paths.

   I managed to trip over the same problem by adjusting the absolute
   path to "/tmp/test-sig.scm", but "/tmp" on my machine is a link to
   "/usr/tmp", and running `mzscheme' from the command line loaded
   "/usr/tmp/gen.scm" which in turn loaded "/usr/tmp/test-sig.scm". The
   generated module then used "/tmp/test-sig.scm". So there were two
   instances of the module, "/usr/tmp/test-sig.scm" and
   "/tmp/test-sig.scm", which means two different `test^'s, which means
   that the unit link has a mismatch.

   The same thing happens when you build an executable. For modules
   that are accessed through a path that was absolute or ultimately
   relative to the working directory, the copy in the executable lives
   in a kind of parallel filesystem. The "gen.scm" embedded in the
   executable used the copy from that parallel universe, while the
   generated module used the copy at "/home/sorgematos/Temp/".

   The simplest solution to this problem is to put "test-sig.scm" in a
   collection, so that it can be referenced in a filesystem-independent
   way. Then both the embedded module and the generated module will
   refer to the same one.

At Sat, 4 Jul 2009 00:01:38 +0100, "Paulo J. Matos" wrote:
> I managed to create a small example depicting what's happening:
> test-sig.scm:
> #lang scheme
> 
> (define-signature test^
>   (x))
> 
> (provide test^)
> ================== END
> 
> 
> gen.scm:
> #lang scheme
> 
> (require "test-sig.scm")
> 
> (define (generate)
>   (let ([filename (make-temporary-file)])
>     (call-with-output-file filename
>       #:mode 'text
>       #:exists 'replace
>       (lambda (fp)
>         (fprintf fp "#lang scheme~n~n")
>         (fprintf fp "(require (file \"/home/sorgematos/Temp/test-sig.scm\"))")
>         (fprintf fp "(provide test@)")
>         (fprintf fp "(define-unit test@ (import test^) (export)~n")
>         (fprintf fp "(* x 2)")
>         (fprintf fp ")"))); closes define-unit
>     filename))
> 
> (let* ([file (generate)]
>        [test@ (dynamic-require file 'test@)]
>        [x 5]
>        [result (invoke-unit test@ (import test^))])
>   (printf "Result: ~a~n" result))
> 
> ================== END
> 
> They are in the same directory: /home/sorgematos/Temp/
> 
> Now, running gen.scm inside DrScheme works perfectly and prints :
> Result: 10
> 
> However, in the terminal with PLT Scheme 4.2 I get the following interaction:
> sorgematos at sorgematos-laptop:~/Temp$ mzc --exe gen gen.scm
> sorgematos at sorgematos-laptop:~/Temp$ ./gen
> standard-module-name-resolver: collection not found:
> #<path:scheme/lang> in any of: (#<path:/home/sorgematos/collects>)
> sorgematos at sorgematos-laptop:~/Temp$ ln -s
> /usr/local/lib/plt/collects/ ../collects
> sorgematos at sorgematos-laptop:~/Temp$ ./gen
> define-compound-unit: unit argument expects an untagged import with
> signature test^, which this usage context does not supply
> 
>  === context ===
> /usr/local/lib/plt/collects/mzlib/private/unit-runtime.ss:66:4: loop
> /usr/local/lib/plt/collects/mzlib/private/unit-runtime.ss:132:2: check-sigs
> 
> 
> 
> Any suggestions or comments on this?
> 
> Cheers,
> 
> -- 
> Paulo Jorge Matos - pocmatos at gmail.com
> http://www.pmatos.net
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme