From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: port-filename and path canonicalization Date: Thu, 22 Apr 2010 14:50:57 +0200 Message-ID: <874oj37iry.fsf@gnu.org> References: <878w8jyr3w.fsf@gnu.org> <87iq7mrrj0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1271940678 23534 80.91.229.12 (22 Apr 2010 12:51:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2010 12:51:18 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Apr 22 14:51:14 2010 connect(): No such file or directory Return-path: Envelope-to: guile-devel@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 1O4vs9-0001Wr-Dr for guile-devel@m.gmane.org; Thu, 22 Apr 2010 14:51:13 +0200 Original-Received: from localhost ([127.0.0.1]:54229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4vs8-0008JJ-Fb for guile-devel@m.gmane.org; Thu, 22 Apr 2010 08:51:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4vs1-0008JE-9N for guile-devel@gnu.org; Thu, 22 Apr 2010 08:51:05 -0400 Original-Received: from [140.186.70.92] (port=34498 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4vry-0008J5-Vu for guile-devel@gnu.org; Thu, 22 Apr 2010 08:51:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4vrw-000669-SB for guile-devel@gnu.org; Thu, 22 Apr 2010 08:51:02 -0400 Original-Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]:40817) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4vrw-00065r-Id for guile-devel@gnu.org; Thu, 22 Apr 2010 08:51:00 -0400 X-IronPort-AV: E=Sophos;i="4.52,256,1270418400"; d="scan'208";a="61095505" Original-Received: from laptop-147-210-128-170.labri.fr (HELO nixey) ([147.210.128.170]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 22 Apr 2010 14:50:59 +0200 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 3 =?iso-8859-1?Q?Flor=E9al?= an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: (Andy Wingo's message of "Thu, 22 Apr 2010 13:10:55 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10289 Archived-At: Hi, Andy Wingo writes: > On Tue 20 Apr 2010 18:57, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >>> 2. I think a fluid is still necessary, because a file being >>> compiled can do an `include' or `include-from-path', or even >>> `open-input-file' in a macro, and all these cases you would want the >>> same %file-port-name-canonicalization to take effect. >> >> Indeed, this one is tricky. >> >> I still think it=E2=80=99s application-specific, though. How about call= ing the >> fluid, say, %compiler-file-name-canonicalization instead? :-) > > Are you proposing that all file-opening functions check the > %compiler-file-name-canonicalization fluid? No, I=E2=80=99m talking about file-opening functions of the compiler, which include =E2=80=98compile-file=E2=80=99, =E2=80=98include=E2=80=99, etc. > If you build out-of-source, you might end up with > > guile-tools compile -o ice-9/boot-9.go ../../modules/ice-9/boot-9.scm > > So the file you open is "../../modules/ice-9/boot-9.scm", but you want > to give it a "relative canonicalization" -- in this case > "ice-9/boot-9.scm" is the canonicalization of > ../../modules/ice-9/boot-9.scm, *relative* to "../../modules" (or indeed > to "/home/wingo/src/guile/modules"). OK, understood. >>> So you'd have to do a set-port-filename! on the port, mucking up your >>> code -- and how would you decide what to set? In N places you'd have to >>> duplicate fport_canonicalize_filename, and you'd probably have to make >>> scm_i_relativize_path public. >> >> I failed to get the transition at =E2=80=9CSo=E2=80=9D. :-) >> >> What does scm_i_relativize_path do? (It lacks a leading comment, hint >> hint. ;-)) BTW, my understanding is that scm_i_relativize_path does lexical =E2=80=9Crelativization=E2=80=9D, which doesn=E2=80=99t work on POSIX and G= NU systems where =E2=80=98..=E2=80=99 resolution is /not/ lexical. (See for details.) The following should work: --8<---------------cut here---------------start------------->8--- (define (relativize-path path dir) ;; Return PATH relative to DIR or #f on failure. (let ((path (canonicalize-path path)) (dir (canonicalize-path dir))) (and=3D> (string-prefix-length dir path) (lambda (start) (substring path (+ 1 start) (string-length path)))))) scheme@(guile-user)> (relativize-path "../guile/module/ice-9/boot-9.scm" "m= odule") "ice-9/boot-9.scm" scheme@(guile-user)> (relativize-path "module/ice-9/boot-9.scm" "../guile/m= odule") "ice-9/boot-9.scm" --8<---------------cut here---------------end--------------->8--- It still does lexical relativization but does so after canonicalization of both arguments. > you would have to do: > > (define (open-input-file* path) > (let ((p (open-input-file path))) > (case (fluid-ref %file-port-name-canonicalization) > ((absolute) > (set-port-filename! p (canonicalize-path path))) > ((relative) > (set-port-filename! p (relativize-path (canonicalize-path path) = %load-path)))) > p)) > > which is a bit ugly; e.g. include-from-path would need to do this, as > would any third-party equivalent of include-from-path, and even > down to the open-file level. Yuk. Wouldn=E2=80=99t it suffice if only =E2=80=98compile-file=E2=80=99, =E2=80= =98include=E2=80=99, and =E2=80=98include-from-path=E2=80=99 relativize paths? Thanks, Ludo=E2=80=99.