Re: [bug-gnulib] Re: [PATCH] mmap-anon.m4: use proper macro condition

2005-05-01 Thread Mark D. Baushke
Hi Folks,

I have not seen any discussion or commit on this patch suggested by
Moriyoshi Koizumi [EMAIL PROTECTED] (originally submitted to the
bug-cvs list and forwarded by me) which allows MacOS X (10.2.x and
10.3.x) to properly be able to '#define HAVE_MAP_ANONYMOUS 1' along with

This lets us get rid of the configure lines:

cat conftest.$ac_ext _ACEOF
/* end confdefs.h.  */
#include sys/mman.h
#ifdef MAP_ANON
I cant identify this map.


and replace them with

cat conftest.$ac_ext _ACEOF
/* end confdefs.h.  */

#include sys/mman.h
#ifdef MAP_ANON
I cant identify this map.


which at least is valid C code.

Please install it in GNULIB.

-- Mark

Index: m4/mmap-anon.m4
RCS file: /cvsroot/gnulib/gnulib/m4/mmap-anon.m4,v
retrieving revision 1.4
diff -u -p -r1.4 mmap-anon.m4
--- m4/mmap-anon.m4 7 Mar 2005 17:29:29 -   1.4
+++ m4/mmap-anon.m4 1 May 2005 14:58:15 -
@@ -27,8 +27,8 @@ AC_DEFUN([gl_FUNC_MMAP_ANON],
-if test $gl_have_mmap_anonymous = no; then
+if test $gl_have_mmap_anonymous != yes; then
+  AC_EGREP_CPP([I cant identify this map.], [
 #include sys/mman.h
 #ifdef MAP_ANON
 I cant identify this map.

Bug-cvs mailing list

Re: cvs abusing stderr?

2005-05-01 Thread Derek Price
Hash: SHA1


 but I am sure that it can
 read from cvs' stdout instead of stderr, too.

 Yes, it *could*. But at the moment it expects this particular input
from stderr and all (?) other versions of CVS servers send it at stderr.
There are already too much differences between GNU CVS and CVSNT...

 Wouldn't it be more consistent to reserve stderr for
 error messages, and to write log messages to stdout,
 as usual?

 It would be more consistent, if the client-server protocol (and this is
what we are talking about) would send the information in a unambiguous
format and translate it *at client side* in human readable text.
Unfortunately, the CVS server already converts it to human readable
format and the more advanced clients need to parse it, which is not
possible correctly in all cases (e.g. imagine file names with spaces and
the output of the 'cvs history' command).

Hrm.  What about using GNU gettext and tweaking the MT responses to
transmit messages as GNU gettext message keys and values to sub?  The
gettext hooks are already in the feature release of CVS but it would be
a lot of work.  MT should adapt pretty well since the client/server
protocol contract already states that MT stuff can be printed as is if
the client doesn't understand, though temporarily it might shuffle some
output away from stderr.  For example:

MT +error
MT gettext This is an error message about a problem with
MT filename path/to/file.c
MT gettext on
MT datetime 2005-04-29 17:18 -
MT gettext .  Do something about it.
MT newline
MT -error

Could be either printed verbatim, in legible english, by a client, or
converted to a call to gettext like:

gettext (This is an error message about a problem with %1 on %2. 
Do something about it., var1, var2);

Or, at least I think so.  I'm not sure how easy it is to dynamically
construct the gettext key, but I imagine someone must have run up
against a problem like this already.

A gettext conversion has been on my nice to see list for awhile now
anyhow.  It would be nice to see a complete patch.

This all reminds me, I've been idly considering the advantages of
importing either the lightweight Expat XML parsing library or Gnome's
lightweight libxml and moving, eventually, to an XML format for
configuration files, trigger script input (since under the current
scheme, info passed to the trigger scripts are limited to whatever
environment limits are inherited from the shell, often 4096 bytes, I

XML would be simpler, more consistent, more extensible, and would solve
a lot of existing problems involving spaces in file names and whatnot,
possibly even unicode characters in paths.

I was also idly wondering about converting the client/server protocol as
well, though I don't know much about what it means to have a two-way
protocol using XML.  Perhaps XMLRPC or the like would provide a clue?

Anyhow, I wasn't planning on doing any of this anytime soon, I just
thought it might be useful to see what sort of early discussions I could
start on the subjects.


Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird -


Bug-cvs mailing list