Re: [PATCH] tests/test-xalloc-die.sh: Use $EXEEXT.

2010-01-13 Thread Simon Josefsson 
Bruno Haible br...@clisp.org writes:

 Simon Josefsson wrote:
 diff --git a/tests/test-xalloc-die.sh b/tests/test-xalloc-die.sh
 index 03bad60..80d6208 100755
 --- a/tests/test-xalloc-die.sh
 +++ b/tests/test-xalloc-die.sh
 @@ -18,7 +18,7 @@
  
  . ${srcdir=.}/init.sh; path_prepend_ .
  
 -test-xalloc-die 2 err  out
 +test-xalloc-die${EXEEXT} 2 err  out
  case $? in
1) ;;
*) Exit 1;;

 Under which circumstances is this needed? Jim said in [1]:
   there's no more need for the $EXE suffix,
since we're using PATH.

Is PATH sufficient for cross-compiled MinGW?  Anyway here is how to
trigger the problem:

j...@mocca:~/src/gnulib master$ rm -rf m  gnulib-tool --create-testdir --dir 
m --with-tests pread  cd m  ./configure --host=i586-mingw32msvc 
--build=i686-pc-linux-gnu  make check
...
./test-pread.sh: line 5: test-pread: command not found
FAIL: test-pread.sh

/Simon

Re: glob on Windows systems

2010-01-13 Thread John W. Eaton 
On  9-Jan-2010, Bruno Haible wrote:

| Hi John,
| 
| John W. Eaton wrote:
|  Looking at lib/glob.c in the gnulib sources, there is some
|  Windows-specific code, so it looks like it is intended to work on
|  Windows systems
| 
|  Is glob.c expected to work on Windows systems?
| 
| At least it passes its unit test on mingw.
| 
|  but there are some things that don't look quite 
|  right.  For example, it does not seem to uniformly use backslash as a
|  directory separator
| 
| Probably this is because backslash is used as an escape character, if
| GLOB_NOESCAPE is not specified among the flags.
| 
|  Should it accept \, /, or both as the directory separator?  I suppose if
|  it allows \ as the directory separator, then GLOB_NOESCAPE would
|  always have to be set.
| 
| You say it.

I think my Windows users would be happy to live without GLOB_NOESCAPE
if they could use \ as the directory separator in the character
strings they send to glob and if they could also expect to get
character strings back from glob that use \ as the directory
separator.

But OK, it looks like it would be somewhat painful to fix this in
the glob function itself.  I suppose instead the best thing is to
write a wrapper to use on Windows systems that first transforms all \
characters to /, calls glob, then converts them back in the resulting
strings...

|  and if WINDOWS32 is defined, it looks for 
|  HOMEDRIVE and HOMEPATH instead of calling some Windows API function
| 
| That's the old Windows95 way of doing it, but it works also on Windows XP.
| On Windows XP, you can also do getenv(USERPROFILE).
| 
|  (maybe GetUserProfileDirectory?).
| 
| This would work as well. But why call a function that requires linking
| with userenv.dll [1], when you can get the same information with getenv?

OK.

Thanks,

jwe

Re: Cygwin build report on Windows XP

2010-01-13 Thread Simon Josefsson 
Simon Josefsson si...@josefsson.org writes:

 I'll try to set the machine up to build it once per day or so, depending
 on how long it takes.

Another report is available at:

http://autobuild.josefsson.org/gnulib/log-201001130336758941000.txt

It has the same failures as before since it didn't use the absolutely
latest gnulib.

The build times are interesting:

gnulib-tool: 324 minutes
./configure: 36 minutes
make check: 34 minutes

Now, gnulib-tool invokes run ./configure too, but that seems like just a
small fraction of the time it spends.

This is on a Intel Atom N270 laptop, I'll try re-installing this as a
virtual machine on a more powerful machine.

/Simon

Re: [PATCH] tests/test-xalloc-die.sh: Use $EXEEXT.

2010-01-13 Thread Jim Meyering 
Simon Josefsson wrote:
 Bruno Haible br...@clisp.org writes:
 Simon Josefsson wrote:
 diff --git a/tests/test-xalloc-die.sh b/tests/test-xalloc-die.sh
 index 03bad60..80d6208 100755
 --- a/tests/test-xalloc-die.sh
 +++ b/tests/test-xalloc-die.sh
 @@ -18,7 +18,7 @@

  . ${srcdir=.}/init.sh; path_prepend_ .

 -test-xalloc-die 2 err  out
 +test-xalloc-die${EXEEXT} 2 err  out
  case $? in
1) ;;
*) Exit 1;;

 Under which circumstances is this needed? Jim said in [1]:
   there's no more need for the $EXE suffix,
since we're using PATH.

 Is PATH sufficient for cross-compiled MinGW?  Anyway here is how to
 trigger the problem:

 j...@mocca:~/src/gnulib master$ rm -rf m  gnulib-tool --create-testdir 
 --dir m --with-tests pread  cd m  ./configure --host=i586-mingw32msvc 
 --build=i686-pc-linux-gnu  make check
 ...
 ./test-pread.sh: line 5: test-pread: command not found
 FAIL: test-pread.sh

I didn't account for that use case.
I wonder if there is some way to write/use a command-not-found
handler to automate the error-prone add-$EXE-suffix at run-time.

If at all possible, I would like to avoid the invasive change
of adding the $EXE suffix to every just-built-binary invocation
in every test script.

If the $EXE suffix is not required in that particular case,
an alternative would be to create a temporary directory, D,
and populate it with links of the form program -../.../program.exe
(or simply copies, if ln isn't an option) and then prepend D: to PATH.

Re: [PATCH] tests/test-xalloc-die.sh: Use $EXEEXT.

2010-01-13 Thread Eric Blake 
According to Jim Meyering on 1/13/2010 3:19 AM:
 I didn't account for that use case.
 I wonder if there is some way to write/use a command-not-found
 handler to automate the error-prone add-$EXE-suffix at run-time.
 
 If at all possible, I would like to avoid the invasive change
 of adding the $EXE suffix to every just-built-binary invocation
 in every test script.

mingw and cygwin handle it just fine, but my reading (although not my
experience) seems to imply that BeOS requires the .exe suffix.  Wine is
another case where the suffix is (currently) important.  But I do agree
that it would be much nicer if wine could do things automatically rather
than appending EXE in all of gnulib.

 If the $EXE suffix is not required in that particular case,
 an alternative would be to create a temporary directory, D,
 and populate it with links of the form program -../.../program.exe
 (or simply copies, if ln isn't an option) and then prepend D: to PATH.

Hmm.  It would have to be done with care.  On cygwin, you can't (easily)
create both foo and foo.exe in the same directory, so it would have to be
via separate directories.  And on mingw, there are no symlinks, but copies
of an executable without an .exe suffix are unlikely to be run.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] tests/test-xalloc-die.sh: Use $EXEEXT.

2010-01-13 Thread Jim Meyering 
Eric Blake wrote:

 According to Jim Meyering on 1/13/2010 3:19 AM:
 I didn't account for that use case.
 I wonder if there is some way to write/use a command-not-found
 handler to automate the error-prone add-$EXE-suffix at run-time.

 If at all possible, I would like to avoid the invasive change
 of adding the $EXE suffix to every just-built-binary invocation
 in every test script.

 mingw and cygwin handle it just fine, but my reading (although not my
 experience) seems to imply that BeOS requires the .exe suffix.  Wine is
 another case where the suffix is (currently) important.  But I do agree
 that it would be much nicer if wine could do things automatically rather
 than appending EXE in all of gnulib.

 If the $EXE suffix is not required in that particular case,
 an alternative would be to create a temporary directory, D,
 and populate it with links of the form program -../.../program.exe

I meant program.exe - .../original
or program.exe as a copy of the original.

 (or simply copies, if ln isn't an option) and then prepend D: to PATH.

Re: [bug-patch] GNU Patch 2.6.1 fails to build on Darwin

2010-01-13 Thread Andreas Gruenbacher 
Hello,

On Monday 11 January 2010 02:45:41 pm Ludovic Courtès wrote:
 Hello,
 
 Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]:

does the latest version on ftp://alpha.gnu.org/gnu/patch/ work for you?

Thanks,
Andreas

Re: [PATCH] tests/test-xalloc-die.sh: Use $EXEEXT.

2010-01-13 Thread Bruno Haible 
Eric Blake wrote:
 BeOS requires the .exe suffix.

No, on BeOS there is no problem: EXEEXT is empty there.

 Wine is another case where the suffix is (currently) important.

Then let's add the extension. It's an idiom that is not difficult to
follow:
  1. use ${EXEEXT} when executing a compiled program,
  2. in the module description, add
   TESTS_ENVIRONMENT += EXEEXT='@EXEEXT@'

We have been doing this for several years already.

Bruno

Re: Cygwin build report on Windows XP

2010-01-13 Thread Ralf Wildenhues 
Hello,

* Simon Josefsson wrote on Wed, Jan 13, 2010 at 10:49:19AM CET:
 The build times are interesting:
 
 gnulib-tool: 324 minutes
 ./configure: 36 minutes
 make check: 34 minutes
 
 Now, gnulib-tool invokes run ./configure too, but that seems like just a
 small fraction of the time it spends.

I would volunteer to dig out and forward-port my gnulib-tool
optimization patches that cut its execution time in half,
if there is a nonzero chance of them being accepted.  Last time,
Bruno rejected them as unmaintainable.

(FWIW, I'd also volunteer to maintain that part of the code.)

Cheers,
Ralf

Re: [PATCH] tests/test-xalloc-die.sh: Use $EXEEXT.

2010-01-13 Thread Simon Josefsson 
Jim Meyering j...@meyering.net writes:

 I wonder if there is some way to write/use a command-not-found
 handler to automate the error-prone add-$EXE-suffix at run-time.

We could create a macro in init.sh that needs to be used when invoking a
program, but I think it would be as error-prone as $EXEEXT (it needs to
be used at all places that invokes a built program, just like $EXEEXT)
only uglier -- after all, use of $EXEEXT is quite widespread and well
understood.

 If at all possible, I would like to avoid the invasive change
 of adding the $EXE suffix to every just-built-binary invocation
 in every test script.

If it is possible to portable, it would be nice.  But I don't think the
cost of supporting $EXEEXT is that extreme -- the problem is easy to
detect by doing builds using MinGW/Wine which I'm already doing.

/Simon

Re: Cygwin build report on Windows XP

2010-01-13 Thread Simon Josefsson 
Ralf Wildenhues ralf.wildenh...@gmx.de writes:

 Hello,

 * Simon Josefsson wrote on Wed, Jan 13, 2010 at 10:49:19AM CET:
 The build times are interesting:
 
 gnulib-tool: 324 minutes
 ./configure: 36 minutes
 make check: 34 minutes
 
 Now, gnulib-tool invokes run ./configure too, but that seems like just a
 small fraction of the time it spends.

 I would volunteer to dig out and forward-port my gnulib-tool
 optimization patches that cut its execution time in half,
 if there is a nonzero chance of them being accepted.  Last time,
 Bruno rejected them as unmaintainable.

Do you have a pointer to the old discussion?  I think it would be useful
to have a maintained tool like that, even if it is not the official
gnulib-tool.  Of course, any build failures needs to be double-checked
against gnulib-tool to understand if the problem is in the optimized
gnulib-tool or in some module.

/Simon

Re: Cygwin build report on Windows XP

2010-01-13 Thread Ralf Wildenhues 
* Simon Josefsson wrote on Thu, Jan 14, 2010 at 08:07:41AM CET:
 Ralf Wildenhues writes:
  I would volunteer to dig out and forward-port my gnulib-tool
  optimization patches that cut its execution time in half,
  if there is a nonzero chance of them being accepted.  Last time,
  Bruno rejected them as unmaintainable.
 
 Do you have a pointer to the old discussion?

http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/16147

Part of the changes were included, so I guess the remaining speedup
would amount to about 40% without implementing any new ideas.

Cheers,
Ralf

Re: [PATCH] mbswidth: add new functions to handle tabs

2010-01-13 Thread Joel E. Denny 
Hi Bruno,

Thanks for your response.

On Thu, 14 Jan 2010, Bruno Haible wrote:

 This functionality is not yet in gnulib. But I don't think it's general
 enough: Today you want to support tabs. Tomorrow you'll want to support
 line numbers and '\v' characters. Next week someone will want to support
 paragraph separator characters.

Those extensions all seem beyond the concept of a width, so are we 
moving into a new module?

Before I get to your proposal, I want to understand one issue from Paul's 
original code.  Can the byte \t ever occur within a multibyte sequence?  
For that matter, can the byte \n or \r?  That is, is there anything 
incorrect about looking for \t, \n, and \r in a simple loop over bytes and 
then calling mbsnwidth for the bytes in between?

 Instead of adding more and more variants of mbswidth, I think we should
 make a bigger step and offer a customizable variant. It will take a
 function pointer as argument, that gets passed a control character.
 People will not want to handle many encodings within this function;
 therefore its argument should be a Unicode character. This leads to a
 function like this:

Sounds reasonable.

  I also considered providing a means to compute line numbers at the same 
  time.
 
 With a little change of the interface, it can accommodate this use-case too:
 
   /* Compute and store in *COLUMN_P the current column at the end of the
  given STRING, assuming it starts at the initial value of *COLUMN_P.
  FUNC handles control characters.  */
   extern void mbs_update_column (const char *string, int *column_p,
  void (*func) (ucs4_t uc, int *column_p);
 
 For computing line numbers, one would pass an int(*)[2] as column_p.

 The implementation of this function should walk across the string until
 it finds the first non-ASCII control character.

Are you saying that mbs_update_column would basically be mbsnwidth but 
would invoke func whenever the existing iscntrl or iswcntrl invocation 
returns true?  Why do you say non-ASCII?  For example, \n is ASCII 10, and 
mbs_update_column should invoke func upon encountering \n.

I'm now thinking I can use mbs_update_column to help me with issuing 
complaints about NUL bytes.  Other users might wish to issue complaints 
about other unhandled control characters.  However, I'd want to be able to 
pass the current file name to func, and your prototype doesn't give me a 
way to do this.  This prototype is a bit more flexible:

  void mbs_update_column (const char *buf, size_t nbytes,
  void *data, int *column_p,
  void (*func) (ucs4_t uc, void *data));

In my case, I'd invoke:

  mbs_update_column (string, n, loc, loc-end.column, func);

Someone interested only in columns could invoke:

  mbs_update_column (string, n, column, column, func);

For just rows and columns:

  mbs_update_column (string, n, row_col_array, row_col_array[1], func);

 At this point it converts to Unicode using the u32_conv_from_encoding 
 function, so that it gets a correspondence between multibyte characters 
 and Unicode characters.

I've never used u32_conv_from_encoding.  Should we make the value that 
mbsn_update_column specifies for u32_conv_from_encoding's fromcode 
argument configurable?  Is there a chance we'll encounter unconvertible 
characters?  If so, should we set the iconv_ilseq_handler argument to 
iconveh_error and skip them?  Or should this be configurable?

mbs_update_column doesn't seem like the best name when it's capable of 
handling more than columns.  What about something like mbs_locate and 
mbs_locate_mem?

  +   BUF[0] is assumed to appear at screen column COLUMN_INIT (origin 1).
 
 In an API, column numbers should start with 0. Origin-1 column numbers
 can be implemented by adding 1 just before printing the column number.
 Ratiionale: Half of the editors used origin-0 column numbers and half of
 the software use origin-1 column numbers. Therefore you need to
 accommodate both conventions.

The GNU coding standards recommend origin 1 for error messages, and I 
didn't realize it was customary to make APIs the opposite.  Of course, 
either origin can be converted to the other, so I can live with either.