Trouble using (current-filename)

Trouble using (current-filename)

[Mark H Weaver]

I put the following test module in my load path:

  (define-module (current-filename-fail)
    :export (my-filename))
  (define my-filename (current-filename))
  (define (force-a-warning-message) (identity 1 2 3))

And this is what I see with Guile 2.0.5:

  GNU Guile 2.0.5
  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 (current-filename-fail)
  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
  ;;;       or pass the --no-auto-compile argument to disable.
  ;;; compiling /home/mhw/guile-modules/current-filename-fail.scm
  ;;; current-filename-fail.scm:4:34: warning: possibly wrong number of arguments to `identity'
  ;;; compiled /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/current-filename-fail.scm.go
  scheme@(guile-user)> my-filename
  $1 = #f

The (force-a-warning-message) line shows that source information is
available.  The same thing happens if I remove that line, or if I try
with stable-2.0.

What am I doing wrong?

    Thanks,
      Mark

Re: Trouble using (current-filename)

[Andy Wingo]

Hi Mark :)

On Tue 14 Feb 2012 19:57, Mark H Weaver <mhw@netris.org> writes:

>   scheme@(guile-user)> my-filename
>   $1 = #f

I get this result regardless of whether or not the (identity 1 2 3) is
there, at least with master; but perhaps that is to be expected, given
what you say:

> The same thing happens if I remove that line, or if I try with
> stable-2.0.
>
> What am I doing wrong?

Nothing, of course :)  But, when I annotate current-filename to be like
this:

  (define-syntax current-filename
    (lambda (x)
      "A macro that expands to the current filename: the filename that
  the (current-filename) form appears in.  Expands to #f if this
  information is unavailable."
      (false-if-exception
       (pk 'canonicalized (canonicalize-path (pk 'filename (assq-ref (syntax-source x) 'filename)))))))

I see that:

scheme@(guile-user)> ,use (current-filename-fail)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /tmp/current-filename-fail.scm

;;; (filename "current-filename-fail.scm")
;;; compiled /home/wingo/src/guile-master/cache/guile/ccache/2.2-LE-8-3.0/tmp/current-filename-fail.scm.go
scheme@(guile-user)> my-filename 
$1 = #f

So we see that the canonicalize-path call failed, as indeed it would.

Not sure what the right thing is here.  It seems to depend on whether
the file is relative to the path or the current working directory.  You
have any thoughts here?

Andy
-- 
http://wingolog.org/

Re: Trouble using (current-filename)

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

>   (define-syntax current-filename
>     (lambda (x)
>       "A macro that expands to the current filename: the filename that
>   the (current-filename) form appears in.  Expands to #f if this
>   information is unavailable."
>       (false-if-exception
>        (pk 'canonicalized (canonicalize-path (pk 'filename (assq-ref (syntax-source x) 'filename)))))))

What about not canonicalizing the file name?

After all, C’s __FILE__ isn’t canonicalized in any way, and
canonicalization is sometimes undesirable (you don’t necessarily want to
dump the absolute path of a temporary source directory in binaries.)

Thanks,
Ludo’.

Re: Trouble using (current-filename)

[Andy Wingo]

On Thu 16 Feb 2012 22:34, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>>   (define-syntax current-filename
>>     (lambda (x)
>>       "A macro that expands to the current filename: the filename that
>>   the (current-filename) form appears in.  Expands to #f if this
>>   information is unavailable."
>>       (false-if-exception
>>        (pk 'canonicalized (canonicalize-path (pk 'filename (assq-ref (syntax-source x) 'filename)))))))
>
> What about not canonicalizing the file name?

That makes this recipe not work:

     (add-to-load-path (dirname (current-filename)))

I think the canonicalize-path was added after Neil's concerns about
add-to-load-path.  We could take it out if that's the thing to do;
dunno.

A
-- 
http://wingolog.org/

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Thu 16 Feb 2012 22:34, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>>   (define-syntax current-filename
>>>     (lambda (x)
>>>       "A macro that expands to the current filename: the filename that
>>>   the (current-filename) form appears in.  Expands to #f if this
>>>   information is unavailable."
>>>       (false-if-exception
>>>        (pk 'canonicalized (canonicalize-path (pk 'filename (assq-ref (syntax-source x) 'filename)))))))
>>
>> What about not canonicalizing the file name?
>
> That makes this recipe not work:
>
>      (add-to-load-path (dirname (current-filename)))
>
> I think the canonicalize-path was added after Neil's concerns about
> add-to-load-path.  We could take it out if that's the thing to do;
> dunno.

Would it work to let the user call it themself if needed, like:

  (add-to-load-path (dirname (canonicalize-path (current-filename))))

Thanks,
Ludo’.

Re: Trouble using (current-filename)

[Andy Wingo]

On Fri 17 Feb 2012 23:49, ludo@gnu.org (Ludovic Courtès) writes:

> Would it work to let the user call it themself if needed, like:
>
>   (add-to-load-path (dirname (canonicalize-path (current-filename))))

I would rather have current-filename do a

  (or (false-if-exception (canonicalize-path p)) p)

Current-filename sounds like it should do the right thing, if possible.

Andy
-- 
http://wingolog.org/

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Fri 17 Feb 2012 23:49, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Would it work to let the user call it themself if needed, like:
>>
>>   (add-to-load-path (dirname (canonicalize-path (current-filename))))
>
> I would rather have current-filename do a
>
>   (or (false-if-exception (canonicalize-path p)) p)
>
> Current-filename sounds like it should do the right thing, if possible.

I think it’s often undesirable.

Suppose you want to use ‘current-filename’ in an ‘assert’ macro, for
instance: what you want is a hint, not an absolute path, since that path
is likely to be invalid at the time you see it (for instance, it could
point to the source tree on a build machine of your distro.)

Furthermore, including absolute paths by default makes builds
non-deterministic: two users would get different binaries, just because
they built things under a different directory.

Thus, I’d rather let users call ‘canonicalize-path’ when they know what
they’re doing, and know that they actually need it.

WDYT?

Thanks,
Ludo’.

Re: Trouble using (current-filename)

[Andy Wingo]

Hi,

On Sun 19 Feb 2012 15:10, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>> On Fri 17 Feb 2012 23:49, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Would it work to let the user call it themself if needed, like:
>>>
>>>   (add-to-load-path (dirname (canonicalize-path (current-filename))))
>>
>> I would rather have current-filename do a
>>
>>   (or (false-if-exception (canonicalize-path p)) p)
>>
>> Current-filename sounds like it should do the right thing, if possible.
>
> I think it’s often undesirable.
>
> Suppose you want to use ‘current-filename’ in an ‘assert’ macro, for
> instance: what you want is a hint, not an absolute path, since that path
> is likely to be invalid at the time you see it (for instance, it could
> point to the source tree on a build machine of your distro.)
>
> Furthermore, including absolute paths by default makes builds
> non-deterministic: two users would get different binaries, just because
> they built things under a different directory.
>
> Thus, I’d rather let users call ‘canonicalize-path’ when they know what
> they’re doing, and know that they actually need it.
>
> WDYT?

I'm fine with that, but I think you are concerned more about code in
modules (compiled in one location, installed and run from another) than
for local scripts.

See Neil's use case here:

  http://thread.gmane.org/gmane.lisp.guile.devel/13440/focus=13621

Can we do something that makes sense for both cases?  For example, we
might canonicalize-path only if we don't find the filename within the
current load path.

Andy
-- 
http://wingolog.org/

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

> On Sun 19 Feb 2012 15:10, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>> On Fri 17 Feb 2012 23:49, ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Would it work to let the user call it themself if needed, like:
>>>>
>>>>   (add-to-load-path (dirname (canonicalize-path (current-filename))))
>>>
>>> I would rather have current-filename do a
>>>
>>>   (or (false-if-exception (canonicalize-path p)) p)
>>>
>>> Current-filename sounds like it should do the right thing, if possible.
>>
>> I think it’s often undesirable.
>>
>> Suppose you want to use ‘current-filename’ in an ‘assert’ macro, for
>> instance: what you want is a hint, not an absolute path, since that path
>> is likely to be invalid at the time you see it (for instance, it could
>> point to the source tree on a build machine of your distro.)
>>
>> Furthermore, including absolute paths by default makes builds
>> non-deterministic: two users would get different binaries, just because
>> they built things under a different directory.
>>
>> Thus, I’d rather let users call ‘canonicalize-path’ when they know what
>> they’re doing, and know that they actually need it.
>>
>> WDYT?
>
> I'm fine with that, but I think you are concerned more about code in
> modules (compiled in one location, installed and run from another) than
> for local scripts.

Yes.

> See Neil's use case here:
>
>   http://thread.gmane.org/gmane.lisp.guile.devel/13440/focus=13621
>
> Can we do something that makes sense for both cases?

Well, (add-to-load-path (dirname (canonicalize-path (current-filename)))) ?

Yes it’s verbose, but it’s predictable and clearly specified.

Ludo’.

Re: Trouble using (current-filename)

[Andy Wingo]

On Sun 19 Feb 2012 22:02, ludo@gnu.org (Ludovic Courtès) writes:

>> See Neil's use case here:
>>
>>   http://thread.gmane.org/gmane.lisp.guile.devel/13440/focus=13621
>>
>> Can we do something that makes sense for both cases?
>
> Well, (add-to-load-path (dirname (canonicalize-path (current-filename)))) ?
>
> Yes it’s verbose, but it’s predictable and clearly specified.

It's terribly verbose, IMO.  If we can do something better for those
users, we should.  What did you think of my other suggestion about
searching for the file in the load path, and only canonicalizing if it
was not found in the load path?  (If it is found in the load path, then
it would be returned in its relative form.)

Andy
-- 
http://wingolog.org/

Re: Trouble using (current-filename)

[Noah Lavine]

What about having two bits of syntax, current-filename and
current-file-path? Or better yet, current-filename and
current-file-directory, with the guarantee that (string-append
(current-file-directory) path-separator (current-filename)) points to
the file when it was compiled?

It is more intuitive to me that (current-filename) would return only
the file name, with no other path components, and that I would use
some other form to get those.

Noah

On Sun, Feb 19, 2012 at 4:23 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Sun 19 Feb 2012 22:02, ludo@gnu.org (Ludovic Courtès) writes:
>
>>> See Neil's use case here:
>>>
>>>   http://thread.gmane.org/gmane.lisp.guile.devel/13440/focus=13621
>>>
>>> Can we do something that makes sense for both cases?
>>
>> Well, (add-to-load-path (dirname (canonicalize-path (current-filename)))) ?
>>
>> Yes it’s verbose, but it’s predictable and clearly specified.
>
> It's terribly verbose, IMO.  If we can do something better for those
> users, we should.  What did you think of my other suggestion about
> searching for the file in the load path, and only canonicalizing if it
> was not found in the load path?  (If it is found in the load path, then
> it would be returned in its relative form.)
>
> Andy
> --
> http://wingolog.org/
>

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hi,

Noah Lavine <noah.b.lavine@gmail.com> skribis:

> What about having two bits of syntax, current-filename and
> current-file-path? Or better yet, current-filename and
> current-file-directory, with the guarantee that (string-append
> (current-file-directory) path-separator (current-filename)) points to
> the file when it was compiled?

+1!

Ludo’.

Re: Trouble using (current-filename)

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:
> Not sure what the right thing is here.  It seems to depend on whether
> the file is relative to the path or the current working directory.  You
> have any thoughts here?

Why don't the source properties include the full pathname?  If there are
places where it's desirable to strip some of the path components, then
perhaps that should be done somewhere else.  Once the information is
lost, it cannot be reliably recovered, and someone might need it.

    Thanks,
      Mark

Re: Trouble using (current-filename)

[Neil Jerram]

Sorry for chipping in late to this discussion.

ludo@gnu.org (Ludovic Courtès) writes:

> I think it’s often undesirable.
>
> Suppose you want to use ‘current-filename’ in an ‘assert’ macro, for
> instance: what you want is a hint, not an absolute path, since that path
> is likely to be invalid at the time you see it (for instance, it could
> point to the source tree on a build machine of your distro.)

Or suppose that a script and accompanying module set is compiled in the
build tree, then installed or relocated elsewhere.  In this case, what
I'd be looking for, with this

 (add-to-load-path ...)

stuff, would be to discover the location of the running script file
_now_, and to construct a load path element relative to that.  If I'm
understanding correctly, 'current-filename' would give me the wrong
answer in that case too, because it would have the
pre-install/relocation location.

Perhaps after all the right thing, for my use case, is something based
on (car (command-line)) and (getcwd).  I currently have this
'compatibility definition' for Guile 1.8.x:

      (define (current-filename)
	(let* ((script (car (command-line)))
	       (scriptdir (dirname script))
	       (absdir (cond ((string=? scriptdir ".")
			      (getcwd))
			     ((string-match "^/" scriptdir)
			      scriptdir)
			     (else
			      (in-vicinity (getcwd) scriptdir)))))
	  (in-vicinity scriptdir (basename script))))

But maybe that's the better solution for 2.x as well.

Regards,
      Neil

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hi Neil!

Neil Jerram <neil@ossau.homelinux.net> skribis:

> Perhaps after all the right thing, for my use case, is something based
> on (car (command-line)) and (getcwd).  I currently have this
> 'compatibility definition' for Guile 1.8.x:
>
>       (define (current-filename)
> 	(let* ((script (car (command-line)))
> 	       (scriptdir (dirname script))
> 	       (absdir (cond ((string=? scriptdir ".")
> 			      (getcwd))
> 			     ((string-match "^/" scriptdir)
> 			      scriptdir)
> 			     (else
> 			      (in-vicinity (getcwd) scriptdir)))))
> 	  (in-vicinity scriptdir (basename script))))
>
> But maybe that's the better solution for 2.x as well.

Yes, for that case, you definitely want something that happens at
run-time, pretty much like $ORIGIN in ELF files.

Thanks,
Ludo’.

Re: Trouble using (current-filename)

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Neil!
>
> Neil Jerram <neil@ossau.homelinux.net> skribis:
>
>> Perhaps after all the right thing, for my use case, is something based
>> on (car (command-line)) and (getcwd).  I currently have this
>> 'compatibility definition' for Guile 1.8.x:
>>
>>       (define (current-filename)
>> 	(let* ((script (car (command-line)))
>> 	       (scriptdir (dirname script))
>> 	       (absdir (cond ((string=? scriptdir ".")
>> 			      (getcwd))
>> 			     ((string-match "^/" scriptdir)
>> 			      scriptdir)
>> 			     (else
>> 			      (in-vicinity (getcwd) scriptdir)))))
>> 	  (in-vicinity scriptdir (basename script))))
>>
>> But maybe that's the better solution for 2.x as well.
>
> Yes, for that case, you definitely want something that happens at
> run-time, pretty much like $ORIGIN in ELF files.

OK thanks.  I think that means you can disregard my use case when
considering the future of 'current-filename', then.

       Neil

Re: Trouble using (current-filename)

[Noah Lavine]

Hello,

What ever happened to this issue? Is it considered resolved now, or is
there more to do?

And if it's not resolved, what do people think of having more than one
piece of syntax?

Noah

On Tue, Feb 21, 2012 at 4:00 PM, Neil Jerram <neil@ossau.homelinux.net> wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Neil!
>>
>> Neil Jerram <neil@ossau.homelinux.net> skribis:
>>
>>> Perhaps after all the right thing, for my use case, is something based
>>> on (car (command-line)) and (getcwd).  I currently have this
>>> 'compatibility definition' for Guile 1.8.x:
>>>
>>>       (define (current-filename)
>>>      (let* ((script (car (command-line)))
>>>             (scriptdir (dirname script))
>>>             (absdir (cond ((string=? scriptdir ".")
>>>                            (getcwd))
>>>                           ((string-match "^/" scriptdir)
>>>                            scriptdir)
>>>                           (else
>>>                            (in-vicinity (getcwd) scriptdir)))))
>>>        (in-vicinity scriptdir (basename script))))
>>>
>>> But maybe that's the better solution for 2.x as well.
>>
>> Yes, for that case, you definitely want something that happens at
>> run-time, pretty much like $ORIGIN in ELF files.
>
> OK thanks.  I think that means you can disregard my use case when
> considering the future of 'current-filename', then.
>
>       Neil
>

Re: Trouble using (current-filename)

[Neil Jerram]

Noah Lavine <noah.b.lavine@gmail.com> writes:

> Hello,
>
> What ever happened to this issue? Is it considered resolved now, or is
> there more to do?

For my use case it's resolved, in the sense that I really needed a
runtime directory that may not be the same as the source compilation
location; and hence 'current-filename' wasn't the right solution after
all.

For other use cases, I guess it depends what those are.

     Neil

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hello,

So if my recollection is correct, the ‘canonicalize-path’ call in
‘current-filename’, which was controversial, can now be removed.

Andy: WDYT?

Ludo’.

Re: Trouble using (current-filename)

[Andy Wingo]

On Thu 15 Mar 2012 17:41, ludo@gnu.org (Ludovic Courtès) writes:

> So if my recollection is correct, the ‘canonicalize-path’ call in
> ‘current-filename’, which was controversial, can now be removed.
>
> Andy: WDYT?

Well it's not what I wanted, but I don't care much.  Please fix the
documentation as well and add a note about the incompatible change to
the NEWS.

Cheers,

Andy
-- 
http://wingolog.org/

Re: Trouble using (current-filename)

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Thu 15 Mar 2012 17:41, ludo@gnu.org (Ludovic Courtès) writes:
>
>> So if my recollection is correct, the ‘canonicalize-path’ call in
>> ‘current-filename’, which was controversial, can now be removed.
>>
>> Andy: WDYT?
>
> Well it's not what I wanted, but I don't care much.

I thought it hadn’t made it into a release, but apparently it did,
so I guess we’re stuck.

Ludo’.