Re: Windows file name separators

2014-06-10 Thread Eli Zaretskii
> From: l...@gnu.org (Ludovic Courtès)
> Date: Mon, 09 Jun 2014 21:42:36 +0200
> 
> Eli Zaretskii  skribis:
> 
> > 3. load.test fails:
> >
> >  FAIL: load.test: search-path for "foo.scm" yields "dir1/foo.scm"
> >
> >(The messages are misleading: "yields" should be "should yield".)
> >
> >The test fails because:
> >
> > . it compares file names with equal?, which fails when Windows
> >   file names with mixed forward and backslashes are used, and/or
> >   when the files differ but for letter case
> >
> > . the expected result uses a relative file name of temp-dir, while
> >   search-path returns absolute file names
> >
> >Fixed by using "/" to create a file name from its parts in load.c:
> >
> > --- libguile/load.c~2014-02-28 23:01:27 +0200
> > +++ libguile/load.c 2014-06-08 13:27:24 +0300
> > @@ -452,11 +452,15 @@ scm_c_string_has_an_ext (char *str, size
> >return 0;
> >  }
> >  
> > +#if 0
> >  #ifdef __MINGW32__
> >  #define FILE_NAME_SEPARATOR_STRING "\\"
> >  #else
> >  #define FILE_NAME_SEPARATOR_STRING "/"
> >  #endif
> > +#else
> > +#define FILE_NAME_SEPARATOR_STRING "/"
> > +#endif
> >  
> >  static int
> >  is_file_name_separator (SCM c)
> >
> >I don't see any reasons to use the backslashes when constructing
> >Windows file names.  Unless someone can tell why using backslashes
> >is a good idea, I propose to remove the Windows setting of
> >FILE_NAME_SEPARATOR_STRING.
> 
> I’m confused: this was added in 4bab7f01 precisely to support MinGW or
> Windows.  Similarly, boot-9.scm has ‘file-name-separator-string’ and
> related stuff.  This was the result of the discussion at
> .

Sorry, that's my fault: I didn't explain the problem in enough detail.

There's nothing wrong with the 4bab7f01 commit per se (and you will
see that its only part that I changed is the definition of
FILE_NAME_SEPARATOR_STRING for MinGW).  The problem is not in that
commit, it is elsewhere: in Scheme code, in this case in the test
suite, that compares file names as simple strings.  Such comparisons
fail if the file names differ by the style of directory separators:
one uses forward slashes, the other backslashes, or some mix thereof.

Now, FILE_NAME_SEPARATOR_STRING is used only for constructing file
names from their parts.  It is not used for testing a particular
file-name character for being a directory separator.  Therefore, we
can discard the separate definition of FILE_NAME_SEPARATOR_STRING for
Windows, and use "/" on all platforms.  This makes the problem of
comparing file names easier, and in particular lets Guile pass
load.test.  But it doesn't solve the problem entirely.

To solve this problem completely, we need a function that
canonicalizes a file name wrt directory separators -- converts all
backslashes to forward slashes.  Does Guile have such a function?  If
it does, then comparing the canonicalized file names will work
reliably on Windows.

I hope I made myself clear this time.

Thanks.

P.S. Please CC me on your responses, as I'm not subscribed to the
list, so I need to download the list archives in order to reply.




Re: Windows file name separators

2014-06-30 Thread Ludovic Courtès
Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Date: Mon, 09 Jun 2014 21:42:36 +0200
>> 
>> Eli Zaretskii  skribis:
>> 
>> > 3. load.test fails:
>> >
>> >  FAIL: load.test: search-path for "foo.scm" yields "dir1/foo.scm"
>> >
>> >(The messages are misleading: "yields" should be "should yield".)
>> >
>> >The test fails because:
>> >
>> > . it compares file names with equal?, which fails when Windows
>> >   file names with mixed forward and backslashes are used, and/or
>> >   when the files differ but for letter case
>> >
>> > . the expected result uses a relative file name of temp-dir, while
>> >   search-path returns absolute file names
>> >
>> >Fixed by using "/" to create a file name from its parts in load.c:
>> >
>> > --- libguile/load.c~   2014-02-28 23:01:27 +0200
>> > +++ libguile/load.c2014-06-08 13:27:24 +0300
>> > @@ -452,11 +452,15 @@ scm_c_string_has_an_ext (char *str, size
>> >return 0;
>> >  }
>> >  
>> > +#if 0
>> >  #ifdef __MINGW32__
>> >  #define FILE_NAME_SEPARATOR_STRING "\\"
>> >  #else
>> >  #define FILE_NAME_SEPARATOR_STRING "/"
>> >  #endif
>> > +#else
>> > +#define FILE_NAME_SEPARATOR_STRING "/"
>> > +#endif
>> >  
>> >  static int
>> >  is_file_name_separator (SCM c)
>> >
>> >I don't see any reasons to use the backslashes when constructing
>> >Windows file names.  Unless someone can tell why using backslashes
>> >is a good idea, I propose to remove the Windows setting of
>> >FILE_NAME_SEPARATOR_STRING.
>> 
>> I’m confused: this was added in 4bab7f01 precisely to support MinGW or
>> Windows.  Similarly, boot-9.scm has ‘file-name-separator-string’ and
>> related stuff.  This was the result of the discussion at
>> .
>
> Sorry, that's my fault: I didn't explain the problem in enough detail.
>
> There's nothing wrong with the 4bab7f01 commit per se (and you will
> see that its only part that I changed is the definition of
> FILE_NAME_SEPARATOR_STRING for MinGW).  The problem is not in that
> commit, it is elsewhere: in Scheme code, in this case in the test
> suite, that compares file names as simple strings.  Such comparisons
> fail if the file names differ by the style of directory separators:
> one uses forward slashes, the other backslashes, or some mix thereof.
>
> Now, FILE_NAME_SEPARATOR_STRING is used only for constructing file
> names from their parts.  It is not used for testing a particular
> file-name character for being a directory separator.  Therefore, we
> can discard the separate definition of FILE_NAME_SEPARATOR_STRING for
> Windows, and use "/" on all platforms.  This makes the problem of
> comparing file names easier, and in particular lets Guile pass
> load.test.  But it doesn't solve the problem entirely.

OK.  This and your other message clarify things, thanks.

> To solve this problem completely, we need a function that
> canonicalizes a file name wrt directory separators -- converts all
> backslashes to forward slashes.  Does Guile have such a function?

My understanding of your other message is that you now advocate trying
hard to stick to slashes instead of backslashes, in which case a file
name canonicalization function is practically unnecessary, right?

Thanks,
Ludo’.



Re: Windows file name separators

2014-06-30 Thread Eli Zaretskii
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel@gnu.org
> Date: Mon, 30 Jun 2014 13:15:44 +0200
> 
> > To solve this problem completely, we need a function that
> > canonicalizes a file name wrt directory separators -- converts all
> > backslashes to forward slashes.  Does Guile have such a function?
> 
> My understanding of your other message is that you now advocate trying
> hard to stick to slashes instead of backslashes, in which case a file
> name canonicalization function is practically unnecessary, right?

Yes, I think so -- provided that I indeed succeeded in finding all the
places where file names and path lists are created from directories
returned by C APIs.  You are in a better position to judge that, as I
still have only a very vague idea about which part of Guile does what,
both in C and in Scheme.

In Emacs, some of the file and directory names recorded during the
build and startup come from argv[0] and from prefix-relative directory
names computed by configure.  Is there something similar in Guile, and
if so, where do I find that?




Re: Windows file name separators

2014-07-01 Thread Ludovic Courtès
Eli Zaretskii  skribis:

> In Emacs, some of the file and directory names recorded during the
> build and startup come from argv[0] and from prefix-relative directory
> names computed by configure.  Is there something similar in Guile, and
> if so, where do I find that?

The default %load-path uses absolute directory names based on what
./configure computed.  argv[0] isn’t used to derive file names.

Ludo’.



Re: Windows file name separators

2014-07-01 Thread Eli Zaretskii
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel@gnu.org
> Date: Tue, 01 Jul 2014 11:36:32 +0200
> 
> Eli Zaretskii  skribis:
> 
> > In Emacs, some of the file and directory names recorded during the
> > build and startup come from argv[0] and from prefix-relative directory
> > names computed by configure.  Is there something similar in Guile, and
> > if so, where do I find that?
> 
> The default %load-path uses absolute directory names based on what
> ./configure computed.

Thanks.  Where do I find the code which does that?  I'd like to review
it with the issue at hand in mind.




Re: Windows file name separators

2014-07-01 Thread Ludovic Courtès
Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: guile-devel@gnu.org
>> Date: Tue, 01 Jul 2014 11:36:32 +0200
>> 
>> Eli Zaretskii  skribis:
>> 
>> > In Emacs, some of the file and directory names recorded during the
>> > build and startup come from argv[0] and from prefix-relative directory
>> > names computed by configure.  Is there something similar in Guile, and
>> > if so, where do I find that?
>> 
>> The default %load-path uses absolute directory names based on what
>> ./configure computed.
>
> Thanks.  Where do I find the code which does that?  I'd like to review
> it with the issue at hand in mind.

You can look at load.c, and in particular scm_init_load_path.

Ludo’.



Re: Windows file name separators

2014-07-02 Thread Eli Zaretskii
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel@gnu.org
> Date: Tue, 01 Jul 2014 17:38:04 +0200
> 
> Eli Zaretskii  skribis:
> 
> >> From: l...@gnu.org (Ludovic Courtès)
> >> Cc: guile-devel@gnu.org
> >> Date: Tue, 01 Jul 2014 11:36:32 +0200
> >> 
> >> Eli Zaretskii  skribis:
> >> 
> >> > In Emacs, some of the file and directory names recorded during the
> >> > build and startup come from argv[0] and from prefix-relative directory
> >> > names computed by configure.  Is there something similar in Guile, and
> >> > if so, where do I find that?
> >> 
> >> The default %load-path uses absolute directory names based on what
> >> ./configure computed.
> >
> > Thanks.  Where do I find the code which does that?  I'd like to review
> > it with the issue at hand in mind.
> 
> You can look at load.c, and in particular scm_init_load_path.

OK, thanks for the pointer.

I've reviewed the related code, and below is what I suggest to push.
(This supersedes what I sent in
http://lists.gnu.org/archive/html/guile-devel/2014-06/msg00066.html.)

--- libguile/load.c~0   2014-02-28 23:01:27 +0200
+++ libguile/load.c 2014-07-02 19:00:50 +0300
@@ -277,6 +277,37 @@ SCM_DEFINE (scm_parse_path_with_ellipsis
 }
 #undef FUNC_NAME
 
+static char *
+getenv_path (const char *name)
+{
+  char *val = getenv (name);
+
+#ifdef __MINGW32__
+  if (val)
+{
+  char *p = val;
+
+  /* Replace backslashes with forward slashes, so that Scheme code
+always gets d:/foo/bar style file names.  This avoids
+multiple subtle problems with comparing file names as strings
+and with redirections in /bin/sh command lines.  Note that
+this destructively modifies the environment variables, so
+both scm_getenv and subprocesses will see the values with
+forward slashes.  But that is OK, since these variables are
+Guile-specific, and having scm_getenv return the same value
+as used by the callers of getenv_path is good for
+consistency and file-name comparison.  */
+  while (*p)
+   {
+ if (*p == '\\')
+   *p = '/';
+ p++;
+   }
+}
+#endif
+
+  return val;
+}
 
 /* Initialize the global variable %load-path, given the value of the
SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -289,7 +320,7 @@ scm_init_load_path ()
   SCM cpath = SCM_EOL;
 
 #ifdef SCM_LIBRARY_DIR
-  env = getenv ("GUILE_SYSTEM_PATH");
+  env = getenv_path ("GUILE_SYSTEM_PATH");
   if (env && strcmp (env, "") == 0)
 /* special-case interpret system-path=="" as meaning no system path instead
of '("") */
@@ -302,7 +333,7 @@ scm_init_load_path ()
scm_from_locale_string (SCM_GLOBAL_SITE_DIR),
scm_from_locale_string (SCM_PKGDATA_DIR));
 
-  env = getenv ("GUILE_SYSTEM_COMPILED_PATH");
+  env = getenv_path ("GUILE_SYSTEM_COMPILED_PATH");
   if (env && strcmp (env, "") == 0)
 /* like above */
 ; 
@@ -345,14 +376,30 @@ scm_init_load_path ()
   cachedir[0] = 0;
 
 if (cachedir[0])
-  *scm_loc_compile_fallback_path = scm_from_locale_string (cachedir);
+  {
+#ifdef __MINGW32__
+   /* We don't use getenv_path for FALLBACK_DIR because those
+  variables are not Guile-specific, so we want to leave them
+  intact in the environment.  This is especially relevant for
+  LOCALAPPDATA and APPDATA.  */
+   char *p = cachedir;
+
+   while (*p)
+ {
+   if (*p == '\\')
+ *p = '/';
+   p++;
+ }
+#endif
+   *scm_loc_compile_fallback_path = scm_from_locale_string (cachedir);
+  }
   }
 
-  env = getenv ("GUILE_LOAD_PATH");
+  env = getenv_path ("GUILE_LOAD_PATH");
   if (env)
 path = scm_parse_path_with_ellipsis (scm_from_locale_string (env), path);
 
-  env = getenv ("GUILE_LOAD_COMPILED_PATH");
+  env = getenv_path ("GUILE_LOAD_COMPILED_PATH");
   if (env)
 cpath = scm_parse_path_with_ellipsis (scm_from_locale_string (env), cpath);
 
@@ -452,11 +499,10 @@ scm_c_string_has_an_ext (char *str, size
   return 0;
 }
 
-#ifdef __MINGW32__
-#define FILE_NAME_SEPARATOR_STRING "\\"
-#else
+/* Defined as "/" for Unix and Windows alike, so that file names
+   constructed by the functions in this module wind up with Unix-style
+   forward slashes as directory separators.  */
 #define FILE_NAME_SEPARATOR_STRING "/"
-#endif
 
 static int
 is_file_name_separator (SCM c)
@@ -877,7 +923,7 @@ canonical_suffix (SCM fname)
 
   /* CANON should be absolute.  */
   canon = scm_canonicalize_path (fname);
-  
+
 #ifdef __MINGW32__
   {
 size_t len = scm_c_string_length (canon);



--- libguile/filesys.c~02014-02-28 23:01:27 +0200
+++ libguile/filesys.c  2014-06-29 18:13:30 +0300
@@ -1235,6 +1235,19 @@ SCM_DEFINE (scm_getcwd, "getcwd", 0, 0,
   errno = save_errno;
   SCM_SYSERROR;
 }
+#ifdef __MINGW32__
+  if (rv)
+{
+  char *p = wd;
+
+  while (*p)
+   {
+ if (*p == '

Re: Windows file name separators

2014-07-02 Thread Ludovic Courtès
Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: guile-devel@gnu.org
>> Date: Tue, 01 Jul 2014 17:38:04 +0200
>> 
>> Eli Zaretskii  skribis:
>> 
>> >> From: l...@gnu.org (Ludovic Courtès)
>> >> Cc: guile-devel@gnu.org
>> >> Date: Tue, 01 Jul 2014 11:36:32 +0200
>> >> 
>> >> Eli Zaretskii  skribis:
>> >> 
>> >> > In Emacs, some of the file and directory names recorded during the
>> >> > build and startup come from argv[0] and from prefix-relative directory
>> >> > names computed by configure.  Is there something similar in Guile, and
>> >> > if so, where do I find that?
>> >> 
>> >> The default %load-path uses absolute directory names based on what
>> >> ./configure computed.
>> >
>> > Thanks.  Where do I find the code which does that?  I'd like to review
>> > it with the issue at hand in mind.
>> 
>> You can look at load.c, and in particular scm_init_load_path.
>
> OK, thanks for the pointer.

Looks good.

> I've reviewed the related code, and below is what I suggest to push.
> (This supersedes what I sent in
> http://lists.gnu.org/archive/html/guile-devel/2014-06/msg00066.html.)

Overall looks good.  Some comments:

> --- libguile/load.c~0 2014-02-28 23:01:27 +0200
> +++ libguile/load.c   2014-07-02 19:00:50 +0300
> @@ -277,6 +277,37 @@ SCM_DEFINE (scm_parse_path_with_ellipsis
>  }
>  #undef FUNC_NAME
>  
> +static char *
> +getenv_path (const char *name)

What about making it ‘canonicalize_file_name_separators’, and change
callers to do:

  thing = canonicalize_file_name_separators (getenv ("PATH"))

Also please add a “docstring” above the function.

[...]

> --- libguile/filesys.c~0  2014-02-28 23:01:27 +0200
> +++ libguile/filesys.c2014-06-29 18:13:30 +0300
> @@ -1235,6 +1235,19 @@ SCM_DEFINE (scm_getcwd, "getcwd", 0, 0,
>errno = save_errno;
>SCM_SYSERROR;
>  }
> +#ifdef __MINGW32__
> +  if (rv)
> +{
> +  char *p = wd;
> +
> +  while (*p)
> + {
> +   if (*p == '\\')
> + *p = '/';
> +   p++;
> + }
> +}
> +#endif

Maybe this could be replaced by an unconditional call to
canonicalize_file_name_separators?

In that case, that function actually needs to be called
scm_i_canonicalize_file_name_separators and declared SCM_INTERNAL.

> --- libguile/init.c~0 2014-02-28 23:01:27 +0200
> +++ libguile/init.c   2014-07-02 18:51:04 +0300
> @@ -310,6 +310,17 @@ scm_boot_guile (int argc, char ** argv,
>  {
>void *res;
>struct main_func_closure c;
> +#ifdef __MINGW32__
> +  /* Convert backslashes in argv[0] to forward slashes.  */
> +  char *p = argv[0];
> +
> +  while (*p)
> +{
> +  if (*p == '\\')
> + *p = '/';
> +  p++;
> +}
> +#endif

Ditto.

Thanks,
Ludo’.



Re: Windows file name separators

2014-07-02 Thread Ludovic Courtès
Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: guile-devel@gnu.org
>> Date: Tue, 01 Jul 2014 17:38:04 +0200

[...]

>> You can look at load.c, and in particular scm_init_load_path.
>
> OK, thanks for the pointer.
>
> I've reviewed the related code, and below is what I suggest to push.
> (This supersedes what I sent in
> http://lists.gnu.org/archive/html/guile-devel/2014-06/msg00066.html.)

Also, could you add tests for that?  Namely, a ‘search-path’ use that
currently returns a file name with backslashes, and will now return a
file name with forward slashes.

Thanks,
Ludo’.



Re: Windows file name separators

2014-07-03 Thread Eli Zaretskii
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel@gnu.org
> Date: Wed, 02 Jul 2014 22:57:41 +0200
> 
> Eli Zaretskii  skribis:
> 
> >> From: l...@gnu.org (Ludovic Courtès)
> >> Cc: guile-devel@gnu.org
> >> Date: Tue, 01 Jul 2014 17:38:04 +0200
> 
> [...]
> 
> >> You can look at load.c, and in particular scm_init_load_path.
> >
> > OK, thanks for the pointer.
> >
> > I've reviewed the related code, and below is what I suggest to push.
> > (This supersedes what I sent in
> > http://lists.gnu.org/archive/html/guile-devel/2014-06/msg00066.html.)
> 
> Also, could you add tests for that?  Namely, a ‘search-path’ use that
> currently returns a file name with backslashes, and will now return a
> file name with forward slashes.

Is the below OK?

--- libguile/load.c~0   2014-02-28 23:01:27 +0200
+++ libguile/load.c 2014-07-03 09:58:29 +0300
@@ -277,6 +277,41 @@ SCM_DEFINE (scm_parse_path_with_ellipsis
 }
 #undef FUNC_NAME
 
+/* On Posix hosts, just return PATH unaltered.  On Windows,
+   destructively replace all backslashes in PATH with Unix-style
+   forward slashes, so that Scheme code always gets d:/foo/bar style
+   file names.  This avoids multiple subtle problems with comparing
+   file names as strings, and with redirections in /bin/sh command
+   lines.
+
+   Note that, if PATH is result of a call to 'getenv', this
+   destructively modifies the environment variables, so both
+   scm_getenv and subprocesses will afterwards see the values with
+   forward slashes.  That is OK as long as applied to Guile-specific
+   environment variables, since having scm_getenv return the same
+   value as used by the callers of this function is good for
+   consistency and file-name comparison.  Avoid using this function on
+   values returned by 'getenv' for general-purpose environment
+   variables; instead, make a copy of the value and work on that.  */
+SCM_INTERNAL char *
+scm_i_mirror_backslashes (char *path)
+{
+#ifdef __MINGW32__
+  if (path)
+{
+  char *p = path;
+
+  while (*p)
+   {
+ if (*p == '\\')
+   *p = '/';
+ p++;
+   }
+}
+#endif
+
+  return path;
+}
 
 /* Initialize the global variable %load-path, given the value of the
SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -289,7 +324,7 @@ scm_init_load_path ()
   SCM cpath = SCM_EOL;
 
 #ifdef SCM_LIBRARY_DIR
-  env = getenv ("GUILE_SYSTEM_PATH");
+  env = scm_i_mirror_backslashes (getenv ("GUILE_SYSTEM_PATH"));
   if (env && strcmp (env, "") == 0)
 /* special-case interpret system-path=="" as meaning no system path instead
of '("") */
@@ -302,7 +337,7 @@ scm_init_load_path ()
scm_from_locale_string (SCM_GLOBAL_SITE_DIR),
scm_from_locale_string (SCM_PKGDATA_DIR));
 
-  env = getenv ("GUILE_SYSTEM_COMPILED_PATH");
+  env = scm_i_mirror_backslashes (getenv ("GUILE_SYSTEM_COMPILED_PATH"));
   if (env && strcmp (env, "") == 0)
 /* like above */
 ; 
@@ -345,14 +380,17 @@ scm_init_load_path ()
   cachedir[0] = 0;
 
 if (cachedir[0])
-  *scm_loc_compile_fallback_path = scm_from_locale_string (cachedir);
+  {
+   scm_i_mirror_backslashes (cachedir);
+   *scm_loc_compile_fallback_path = scm_from_locale_string (cachedir);
+  }
   }
 
-  env = getenv ("GUILE_LOAD_PATH");
+  env = scm_i_mirror_backslashes (getenv ("GUILE_LOAD_PATH"));
   if (env)
 path = scm_parse_path_with_ellipsis (scm_from_locale_string (env), path);
 
-  env = getenv ("GUILE_LOAD_COMPILED_PATH");
+  env = scm_i_mirror_backslashes (getenv ("GUILE_LOAD_COMPILED_PATH"));
   if (env)
 cpath = scm_parse_path_with_ellipsis (scm_from_locale_string (env), cpath);
 
@@ -452,11 +490,10 @@ scm_c_string_has_an_ext (char *str, size
   return 0;
 }
 
-#ifdef __MINGW32__
-#define FILE_NAME_SEPARATOR_STRING "\\"
-#else
+/* Defined as "/" for Unix and Windows alike, so that file names
+   constructed by the functions in this module wind up with Unix-style
+   forward slashes as directory separators.  */
 #define FILE_NAME_SEPARATOR_STRING "/"
-#endif
 
 static int
 is_file_name_separator (SCM c)
@@ -877,7 +914,7 @@ canonical_suffix (SCM fname)
 
   /* CANON should be absolute.  */
   canon = scm_canonicalize_path (fname);
-  
+
 #ifdef __MINGW32__
   {
 size_t len = scm_c_string_length (canon);


--- libguile/load.h~0   2013-03-19 00:30:13 +0200
+++ libguile/load.h 2014-07-03 09:59:17 +0300
@@ -44,6 +44,7 @@ SCM_INTERNAL void scm_init_load_path (vo
 SCM_INTERNAL void scm_init_load (void);
 SCM_INTERNAL void scm_init_load_should_auto_compile (void);
 SCM_INTERNAL void scm_init_eval_in_scheme (void);
+SCM_INTERNAL char *scm_i_mirror_backslashes (char *path);
 
 #endif  /* SCM_LOAD_H */
 


--- libguile/filesys.c~02014-02-28 23:01:27 +0200
+++ libguile/filesys.c  2014-07-03 10:03:25 +0300
@@ -51,6 +51,7 @@
 
 #include "libguile/validate.h"
 #include "libguile/filesys.h"
+#include "libguile/load.h" /* for scm_i_mirror_

Re: Windows file name separators

2014-07-03 Thread Ludovic Courtès
Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: guile-devel@gnu.org
>> Date: Wed, 02 Jul 2014 22:57:41 +0200
>> 
>> Eli Zaretskii  skribis:
>> 
>> >> From: l...@gnu.org (Ludovic Courtès)
>> >> Cc: guile-devel@gnu.org
>> >> Date: Tue, 01 Jul 2014 17:38:04 +0200
>> 
>> [...]
>> 
>> >> You can look at load.c, and in particular scm_init_load_path.
>> >
>> > OK, thanks for the pointer.
>> >
>> > I've reviewed the related code, and below is what I suggest to push.
>> > (This supersedes what I sent in
>> > http://lists.gnu.org/archive/html/guile-devel/2014-06/msg00066.html.)
>> 
>> Also, could you add tests for that?  Namely, a ‘search-path’ use that
>> currently returns a file name with backslashes, and will now return a
>> file name with forward slashes.
>
> Is the below OK?

Looks good to me, OK to push.

[...]

> --- test-suite/tests/ports.test~2 2014-06-29 16:06:51 +0300
> +++ test-suite/tests/ports.test   2014-07-03 10:55:30 +0300
> @@ -1866,6 +1865,17 @@
>  (with-fluids ((%file-port-name-canonicalization 'absolute))
>(port-filename (open-input-file (%search-load-path "ice-9/q.scm"))
>  
> +(with-test-prefix "file name separators"
> +
> +  (pass-if "no backslash separators in Windows file names"
> +;; In Guile 2.0.11 and earlier, %load-path on Windows could
> +;; include file names with backslashes, and `getcwd' on Windows
> +;; would always return a directory name with backslashes.
> +(or (not (file-name-separator? #\\))
> + (with-load-path (cons (getcwd) %load-path)
> +   (not (string-index (%search-load-path (basename (test-file)))
> +  #\\))

No tabs in Scheme files please (if you use Emacs, there’s a
.dir-locals.el that should set it up correctly.)

Thanks!

Ludo’.



Re: Windows file name separators

2014-07-03 Thread Eli Zaretskii
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel@gnu.org
> Date: Thu, 03 Jul 2014 19:11:41 +0200
> 
> > Is the below OK?
> 
> Looks good to me, OK to push.

Done.

> > --- test-suite/tests/ports.test~2   2014-06-29 16:06:51 +0300
> > +++ test-suite/tests/ports.test 2014-07-03 10:55:30 +0300
> > @@ -1866,6 +1865,17 @@
> >  (with-fluids ((%file-port-name-canonicalization 'absolute))
> >(port-filename (open-input-file (%search-load-path 
> > "ice-9/q.scm"))
> >  
> > +(with-test-prefix "file name separators"
> > +
> > +  (pass-if "no backslash separators in Windows file names"
> > +;; In Guile 2.0.11 and earlier, %load-path on Windows could
> > +;; include file names with backslashes, and `getcwd' on Windows
> > +;; would always return a directory name with backslashes.
> > +(or (not (file-name-separator? #\\))
> > +   (with-load-path (cons (getcwd) %load-path)
> > + (not (string-index (%search-load-path (basename (test-file)))
> > +#\\))
> 
> No tabs in Scheme files please (if you use Emacs, there’s a
> .dir-locals.el that should set it up correctly.)

.dir-locals don't affect patch application by Patch.

Btw, there are quite a few *.test files with tabs.  I untabified the
ones I modified recently (even if tabs were in places I didn't
modify), but there are more left.  JFYI.




Re: Windows file name separators

2014-07-07 Thread Mark H Weaver
Eli Zaretskii  writes:
> Btw, there are quite a few *.test files with tabs.  I untabified the
> ones I modified recently (even if tabs were in places I didn't
> modify), but there are more left.  JFYI.

Please, in the future let's discuss this before you push large-scale
whitespace changes like this.  In the past such proposals have been
rejected.  They make merges difficult.

Thanks,
  Mark



Re: Windows file name separators

2014-07-07 Thread Eli Zaretskii
> From: Mark H Weaver 
> Cc: l...@gnu.org (Ludovic Courtès),  guile-devel@gnu.org
> Date: Mon, 07 Jul 2014 16:53:04 -0400
> 
> Eli Zaretskii  writes:
> > Btw, there are quite a few *.test files with tabs.  I untabified the
> > ones I modified recently (even if tabs were in places I didn't
> > modify), but there are more left.  JFYI.
> 
> Please, in the future let's discuss this before you push large-scale
> whitespace changes like this.  In the past such proposals have been
> rejected.  They make merges difficult.

That's why I pushed changes only in the files where tabs were caused
by my recent modifications.