Hello, I see what you are trying to do, and I agree that it should be possible. I have set up the same situation as you: trying to load a module, failing, adding it to my path, trying again, and failing again. Here's what I've figured out:
- resolve-module fails on the module, when I think it should succeed. that's because - try-autoload-module fails on the module, when again I think it should succeed. and that's because - autoload-done-or-in-progress? returns #t for the module, when I think it should return #f. specifically, the module is marked as done, and therefore try-module-autoload won't look for it any more. - the module was marked as autoloaded because that's what try-module-autoload does: it *always* marks its module as autoloaded, even if it wasn't found. As a workaround, remove your module from the list "autoloads-done". (actually, there will be a pair in that list, where the cdr of the pair is the name of the module as a string. remove that.) In the long term, Andy and Ludo, what is the right way to fix this? Should try-module-autoload not mark unfound modules as autoloaded? Or maybe there should be a special function that says "retry this module, starting from the beginning". Maybe it could even be part of reload-module. Best, Noah On Fri, Jan 18, 2013 at 11:15 PM, Diogo F. S. Ramos <diogo...@gmail.com>wrote: > Nala Ginrut <nalagin...@gmail.com> writes: > > > Why you need to load the module without giving its path? > > Sorry, I should have added some more context. > > While I'm working with the REPL, sometimes I forget to add the path to a > module before trying to use it. It's a mistake. So, after trying to load > the module with `use-modules', and failing, I remember that I have to > add the path to the module. So I add the path to the module with > `add-to-load-path' and I try again to evaluate > `use-modules'. Unfortunately it does not load it and I'm stuck. To fix > it, I end up restarting the REPL and adding the path _before_ trying to > load it, as it's the right way to do it. > > Here is an example with my typical mistake: > > $ cat /tmp/foo/bar.scm > (define-module (foo bar)) > > (define-public (hello) > (display "hello, world") > (newline)) > $ guile > GNU Guile 2.0.5-deb+1-1 > Copyright (C) 1995-2012 Free Software Foundation, Inc. > > Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. > This program is free software, and you are welcome to redistribute it > under certain conditions; type `,show c' for details. > > Enter `,help' for help. > scheme@(guile-user)> (use-modules (foo bar)) > While compiling expression: > ERROR: no code for module (foo bar) > scheme@(guile-user)> (add-to-load-path "/tmp") > scheme@(guile-user)> (use-modules (foo bar)) > While compiling expression: > ERROR: no code for module (foo bar) > scheme@(guile-user)> (hello) > ;;; <stdin>:4:0: warning: possibly unbound variable `hello' > <unnamed port>:4:0: In procedure #<procedure e3f580 at <current input>:4:0 > ()>: > <unnamed port>:4:0: In procedure module-lookup: Unbound variable: hello > > Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. > scheme@(guile-user) [1]> > > The question is: Is there a way to recover from this mistake in my live > REPL session? > >
