[plt-scheme] Re: Standard module resolver issue
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
http://www.pmatos.net