[plt-scheme] Re: Standard module resolver issue

From: Paulo J. Matos (pocmatos at gmail.com)
Date: Sat Jul 4 10:04:08 EDT 2009

On Sat, Jul 4, 2009 at 2:13 PM, Matthew Flatt<mflatt at cs.utah.edu> wrote:
> 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

Hi Matthew,

Thank you very much for taking your time to reply to this during weekend.
The usage of flag ++lib indeed worked for me, I didn't know about it,
now it is ok.

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

That makes sense and once the program is 'installed' in a target
computer that would the case anyway because test-sig.scm would have to
reside in a lib/ somewhere.

Thanks once again,

Have a great weekend,

Paulo Matos

> 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

Paulo Jorge Matos - pocmatos at gmail.com

Posted on the users mailing list.