From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.user Subject: Re: Modules Date: Sun, 30 Jan 2011 12:42:07 +0100 Message-ID: References: <20101208124502.5f25b64d@halmanfloyd> <20110129131315.506f1e8c@halmanfloyd> <87tygrcnbf.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296391030 7156 80.91.229.12 (30 Jan 2011 12:37:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 30 Jan 2011 12:37:10 +0000 (UTC) Cc: guile-user@gnu.org To: Neil Jerram Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 30 13:37:06 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PjWWf-0008KW-HC for guile-user@m.gmane.org; Sun, 30 Jan 2011 13:37:05 +0100 Original-Received: from localhost ([127.0.0.1]:60378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjWWe-0002fl-U6 for guile-user@m.gmane.org; Sun, 30 Jan 2011 07:37:05 -0500 Original-Received: from [140.186.70.92] (port=50024 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjWWY-0002bT-3V for guile-user@gnu.org; Sun, 30 Jan 2011 07:36:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PjWWT-0002W7-TD for guile-user@gnu.org; Sun, 30 Jan 2011 07:36:57 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:56529 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PjWWT-0002Vu-QN for guile-user@gnu.org; Sun, 30 Jan 2011 07:36:53 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B806632A8; Sun, 30 Jan 2011 07:37:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=CiKVvpJTRtbbw7qCqyf5DEZ8tH0=; b=XAStoi 31xs08K9+dtmEenOH57r5K+NxEFwsOVt/vumpQrQocJKA++esucBqVQLz+ieJd8j 9bn6Sx0wQjTBhqwhdYbqFDwhRD5gdMPZbmYLVj/B4MdPFuZeSYE7X3GqS2i4WswJ rhnHefd90eyLGorcvD8J7zHIp4hwLOrVJijxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=rjz5xbdn4hig73fiMNjIkLrTcJL/ssox dEruQpsUVlzO0s4tWHEAuVKQBf5pXqp9pkhG3R06g7S8yMp3mG3boexVUszCOsy/ W7k777Zhk2SUAP0lDPHg+qShnQ9kod62Ss9lW4QYgyWSd3OOzwKqgU/G8GVfo5j3 p60BO1wsz8Y= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 9713832A6; Sun, 30 Jan 2011 07:37:42 -0500 (EST) Original-Received: from unquote.localdomain (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9114F328A; Sun, 30 Jan 2011 07:37:39 -0500 (EST) In-Reply-To: <87tygrcnbf.fsf@ossau.uklinux.net> (Neil Jerram's message of "Sat, 29 Jan 2011 23:17:08 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Pobox-Relay-ID: BB41BA5E-2C6D-11E0-A3D2-BC4EF3E828EC-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 64.74.157.62 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8403 Archived-At: Hi Neil, On Sun 30 Jan 2011 00:17, Neil Jerram writes: > Andy Wingo writes: > >> If you are using modules, they are already in one global namespace, >> the various roots of which are in the %load-path and/or >> %load-compiled-path. (resolve-module '(foo bar)) should work >> regardless of what file calls it. > > If the modules are installed, that's true. What if they are not? In that case you have to modify the load path, somehow. I have been doing this with scripts that add to $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH. (Which is another thing to note; if you have an autotooled project, the .go files go in the $builddir.) So if I'm hacking against an uninstalled tekuti, for example, I run my code within ~/src/tekuti/env. > For scripts that use uninstalled modules, then, some kind of solution is > needed; ideally one that works for both 1.8 and 1.9/2.0, allows the code > needed to live in a single common file, rather than duplicated at the > top of each script; and continues to work if the script+module tree as a > whole is moved to a different place in the filesystem. Also I think > it's preferable if the solution is a Guile one, as opposed to based on > the #! line, or needing a shell script wrapper. How would it look? I guess I am unclear on the actual problem being solved here :) Let's consider that I am hacking on my "analysis" script, which lives at ~/src/foo/analysis. I guess it's helping me in my "foo" project. Now the script gets too big; time to split into modules. How to do that? We have basically one option of a path to automatically add to the load path: ~/src/foo. It seems tractable, unless we start to consider installing the script to /usr/bin, combined with the presence of "" in the default load-extensions list, in which case the unexpected interactions with other members of that path look daunting. No, I think that the script itself will need to indicate some path to add to the load path. What you can do, perhaps, is add a macro: (define-syntax add-relative-load-path (lambda (x) (syntax-case x () ((_ path) (string? (syntax->datum #'path)) (let* ((src (syntax-source #'x)) (current-file (or (and src (assq-ref src 'filename)) (error "Could not determine current file name"))) (vicinity (dirname (canonicalize-path current-file))) (path-elt (in-vicinity vicinity (syntax->datum #'path)))) #`(eval-when (compile load eval) (set! %load-path (cons #,path-elt %load-path)))))))) Then in "analysis", you could `(add-relative-load-path ".")'. But... If you compile a .go, then install both .scm and .go somewhere, the installed .go file will reference the build path, which was inserted into the source via the current-file business. (You could argue that this is precisely the case that we are _not_ interested in, given that currently we only install .go files for files that are in the load path. But I guess we should figure out a better autocompilation story for files in $bindir.) It _is_ true that we need to figure out what's going on with (current-load-port) in 1.9, but it's not clear what to do, exactly, when you have compiled files; you could not have the corresponding .scm at all, or in any case when you've loaded the .go you don't actually have a port to the .scm, and in fact if the file was loaded via `load-from-path' you don't know exactly where the .scm is at all. Perhaps we should residualize into the .go whether the file was compiled for `load' or for `load-from-path', and what was the original path of the file. > Good point, thanks for the reminder about that. But (for 1.9/2.0) > `include' will always be well-defined and reliably relative to the > containing file's name, won't it? Yes, at expansion time. But note the .scm/.go installation case; and also note that the code that chooses when to use a .go over a .scm doesn't know anything about dependencies, currently, so a change to an included file doesn't trigger recompilation of the includer. Andy -- http://wingolog.org/