From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Loading a module before and after adding a load path Date: Fri, 18 Jan 2013 23:32:35 -0500 Message-ID: References: <87bocmxzax.fsf@supernova.vialactea> <1358565467.2720.35.camel@Renee-desktop.suse> <87ip6tx0yf.fsf@supernova.vialactea> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b2e107f9d85c004d39cb7f0 X-Trace: ger.gmane.org 1358569965 22479 80.91.229.3 (19 Jan 2013 04:32:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2013 04:32:45 +0000 (UTC) Cc: Guile Mailing List , guile-devel To: "Diogo F. S. Ramos" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 19 05:33:04 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TwQ74-00032K-Kh for guile-user@m.gmane.org; Sat, 19 Jan 2013 05:33:02 +0100 Original-Received: from localhost ([::1]:54080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwQ6n-0005DT-Pr for guile-user@m.gmane.org; Fri, 18 Jan 2013 23:32:45 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwQ6h-0005DE-DM for guile-user@gnu.org; Fri, 18 Jan 2013 23:32:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TwQ6f-0004mv-UT for guile-user@gnu.org; Fri, 18 Jan 2013 23:32:39 -0500 Original-Received: from mail-pb0-f50.google.com ([209.85.160.50]:32971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwQ6f-0004mo-Ke; Fri, 18 Jan 2013 23:32:37 -0500 Original-Received: by mail-pb0-f50.google.com with SMTP id wz7so2395839pbc.37 for ; Fri, 18 Jan 2013 20:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gb1buIzfuqeXFP95zTJElw5q/X4vcwT1NWDdj7z1f5c=; b=iTz7gOBolTrH7q5acQ3FZm9BeKAJgSi7EoWROne/g2F7sMp1qDqJvmKNbmyjtIHnwy A9DYr0xYh88lmq8J+TCfmBH4SDiKEjOl1v92R2eb93bMkCE3IU2cO5kFDDpO+Qb/bBKk DcAEuzjcNFyHJmDbfxsWpvduAQBmti8pJfJw1tn1qqaZhF3AAF7kAC5WKNaRwbkBRGMw WnvIJLay4DMrJ0PevMNwiYhGwIEeDPIZO+Q9DE1fENuxVhfPw8h3AMmKmQr7TDIag8e9 x2GctDH3Drg89xRgweDpeNsuqaYaS70yc2fbP8gmwDBCUferRrNVOyL47KfCsEZ44uTq fw2A== X-Received: by 10.68.244.169 with SMTP id xh9mr11301765pbc.52.1358569955755; Fri, 18 Jan 2013 20:32:35 -0800 (PST) Original-Received: by 10.68.242.73 with HTTP; Fri, 18 Jan 2013 20:32:35 -0800 (PST) In-Reply-To: <87ip6tx0yf.fsf@supernova.vialactea> X-Google-Sender-Auth: VJAxjjhvmaP9FgN3MNkriCEZGzw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.50 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:9887 gmane.lisp.guile.devel:15473 Archived-At: --047d7b2e107f9d85c004d39cb7f0 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > Nala Ginrut 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) > ;;; :4:0: warning: possibly unbound variable `hello' > :4:0: In procedure #:4:0 > ()>: > :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? > > --047d7b2e107f9d85c004d39cb7f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I see what you are trying to do,= and I agree that it should be possible. I have set up the same situation a= s 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 thin= k it should succeed. that's because
- try-autoload-modu= le 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, an= d therefore try-module-autoload won't look for it any more.
- the module was marked as autoloaded because that's what try-module-au= toload does: it *always* marks its module as autoloaded, even if it wasn= 9;t found.

As a workaround, remove you= r 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 a= s a string. remove that.)

In the long term, Andy and Ludo, what is th= e right way to fix this? Should try-module-autoload not mark unfound module= s as autoloaded? Or maybe there should be a special function that says &quo= t;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 &l= t;diogofsr@gmail.co= m> wrote:
Nala Ginrut <nalaginrut@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 loa= d
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)
=A0 (display "hello, world")
=A0 (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: hel= lo

Entering a new prompt. =A0Type `,bt' for a backtrace or `,q' to con= tinue.
scheme@(guile-user) [1]>

The question is: Is there a way to recover from this mistake in my live
REPL session?


--047d7b2e107f9d85c004d39cb7f0--