udefined shell vars
I see in configure script output: ./configure: line 34058: test: =: unary operator expected ./configure: line 34061: test: =: unary operator expected I traced this back to m4/gnulib-comp.m4: if test $REPLACE_REALLOC_FOR_CALLOC_GNU = 1; then func_gl_gnulib_m4code_682e609604ccaac6be382e4ee3a4eaec fi if test $REPLACE_REALLOC_FOR_CALLOC_POSIX = 1; then func_gl_gnulib_m4code_682e609604ccaac6be382e4ee3a4eaec fi It seems those REPLACE...(GNU|POSIX) vars are not defined (assigned with a value) anywhere in the configure script. When i quote them "$REPLACE..." and re-run the configure script, there is no more error. What am i missing? -- Thien-Thi Nguyen --- (defun responsep (query) ; (2022) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
snippets/unused-parameter
I just now updated a local gnulib tree and re-ran autogen.sh (for GNU RCS), and i see: Notice from module snippet/unused-parameter: This module is obsolete. The gnulib.info documentation mentions "obsolete" in several places, but it seems to be oriented toward gnulib hackers rather than users. My question is: What should i do w/ this module? (a) Leave it alone -- "obsolete" is not "broken". (b) Remove it from the imported list of modules, and implement macro ‘RCS_UNUSED’ w/o gnulib. (c) "Fix" things somehow so that the message no longer appears. Related question: Where can i find info on how/why this module became obsolete? It's a pretty ironic thing that happened here. :-D -- Thien-Thi Nguyen --- (defun responsep (query) ; (2022) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
libunistring version detection w/ "configure -C"
At <https://bugs.gnunet.org/view.php?id=6722>, there is a patch to libunistring version detection w/ "configure -C". Does that look right? It seems strange to me. -- Thien-Thi Nguyen --- (defun responsep (query) ; (2021) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
Re: rcs configure hang
() Florian Weimer () Mon, 09 Nov 2020 10:14:00 +0100 Would you be able to share details of the file system used (XFS or something else?) and the kernel version (uname -a, rpm -q kernel)? Do you use virtualization or containers? I would like to see if I can reproduce it internally. Ping. (Any news?) -- Thien-Thi Nguyen --- (defun responsep (query) ; (2021) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
[PATCH] Fix omission from 741631c9b012baab1725e43557fabf384d71f169
Please find attached: From c7152f4a69dc4966a728e82cd2a035a11b720e9f Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen Date: Fri, 25 Dec 2020 18:27:37 -0500 Subject: [PATCH] Fix omission from 741631c9b012baab1725e43557fabf384d71f169 * MODULES.html.sh (func_all_modules): Do s/free/free-posix/. --- MODULES.html.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MODULES.html.sh b/MODULES.html.sh index 7e7cdae3e..85e8d3065 100755 --- a/MODULES.html.sh +++ b/MODULES.html.sh @@ -1700,7 +1700,7 @@ func_all_modules () func_begin_table func_module calloc-gnu func_module eealloc - func_module free + func_module free-posix func_module malloc-gnu func_module realloc-gnu func_module reallocarray -- 2.29.2 a patch that does: * MODULES.html.sh (func_all_modules): Do s/free/free-posix/. -- Thien-Thi Nguyen --- (defun responsep (query) ; (2020) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
fix typo in 39be62df3b9b2453392109f4b6c4bb418e8d175a
The commit, titled: c-dtoastr, c-ldtoastr: new modules omits the trailing "r" in "c-ldtoastr" in MODULES.html.sh. Here's a patch: MODULES.html.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MODULES.html.sh b/MODULES.html.sh index 11a4a7746..a8a629e29 100755 --- a/MODULES.html.sh +++ b/MODULES.html.sh @@ -2319,7 +2319,7 @@ func_all_modules () func_begin_table func_module c-dtoastr - func_module c-ldtoast + func_module c-ldtoastr func_module dtoastr func_module ftoastr func_module intprops -- Thien-Thi Nguyen signature.asc Description: PGP signature
Re: [PATCH 1/6] parse-datetime, posixtm: avoid uninit access
() Paul Eggert <egg...@cs.ucla.edu> () Mon, 25 Sep 2017 18:29:08 -0700 Do not access uninitialized storage, even though the resulting value is never used. [...] - tm0 = tm; + tm0.tm_sec = tm.tm_sec; + tm0.tm_min = tm.tm_min; + tm0.tm_hour = tm.tm_hour; + tm0.tm_mday = tm.tm_mday; + tm0.tm_mon = tm.tm_mon; + tm0.tm_year = tm.tm_year; + tm0.tm_isdst = tm.tm_isdst; Start = mktime_z (tz, ); These changes look like a step backward in code readability, which could prompt a naive programmer to propose their reversion in the future (ping-pong problem). Maybe add a preemptive comment, or factor the assignments into a macro (w/ comment)? -- Thien-Thi Nguyen --- (defun responsep (query) (pcase (context query) (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
Re: [PATCH] gnulib-tool: new option --gnu-make
() Paul Eggert <egg...@cs.ucla.edu> () Sun, 12 Mar 2017 19:19:43 -0700 + if false && $gnu_make; then Typo? -- Thien-Thi Nguyen --- (defun responsep (query) (pcase (context query) (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
Re: update-copyright ‘--help’ and ‘--version’
() Karl Berry <k...@freefriends.org> () Mon, 23 May 2016 20:56:23 GMT [get around ‘-i’ somehow] (see perlrun) Thanks. On the other hand, I wouldn't argue that --help/--version support is so important for this script that it is worth any complication (let alone a wrapper). I agree, it's not so important. However, ‘PROG --help’ is useful (at least for me), saving me a few minutes every once in a while, and satisfying my (perhaps small-minded) craving for consistency in GNU(ish) program behavior. -- Thien-Thi Nguyen --- (if you're human and you know it) read my lisp: (defun responsep (type via) (case type (technical (eq 'mailing-list via)) ...)) -- GPG key: 4C807502 signature.asc Description: PGP signature
update-copyright ‘--help’ and ‘--version’
For anyone interested, here is a small update-copyright wrapper that supports ‘--help’ and ‘--version’: #!/bin/sh actual=$HOME/build/GNU/gnulib/build-aux/update-copyright if [ x"$1" = x--help ] ; then printf 'Usage: %s FILE...\n\n' `basename $0` sed -e '/arguments to this script/,/^$/!d' \ -e 's/^#//' \ -e 's/^ //' \ $actual exit 0 fi if [ x"$1" = x--version ] ; then sed '/^my .VERSION/!d' $actual exit 0 fi exec $actual "$@" # update-copyright ends here Originally i looked into modifying update-copyright directly, but was defeated by Perl's ‘-i’ support (which, IIUC, says to take all script args as filenames, hence leaving no room for the script to check/handle args specially). Any hints on a Perl-only solution greatly appreciated! -- Thien-Thi Nguyen --- (if you're human and you know it) read my lisp: (defun responsep (type via) (case type (technical (eq 'mailing-list via)) ...)) -- GPG key: 4C807502 signature.asc Description: PGP signature
Re: Fwd: Re: error_at_line, request to add
() Paul Eggert egg...@cs.ucla.edu () Mon, 09 Mar 2015 10:03:06 -0700 By tradition, Gnulib never installs anything. Perhaps that tradition should change but it should be a conscious change, presumably one supported by the infrastructure. Gnulib is always changing, so installing gnulib.info guarantees that it becomes obsolete on the next update. Personally, i symlinked gnulib.info to $(infodir) and then did install-info on it (which just updates $(infodir)/dir, contrary to what its name might have you believe). That way, the info system has access to gnulib.info, w/o it actually being installed. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: gl_DISABLE_THREADS placement
() Thien-Thi Nguyen t...@gnu.org () Sun, 25 Jan 2015 12:09:42 +0100 [annoying archeology] If i can [satisfy curiosity] i'm willing to [...] contribute to gnulib a @(sub-) section of texinfo, so the last question is: Would gnulib accept such a contribution? Another idea is to presume the two-methods status-quo is a mistake and rebase one method on the other. For example: configure.ac | 14 ++ 1 file changed, 14 insertions(+) diff --git a/configure.ac b/configure.ac index b7fa3b4..8334f21 100644 --- a/configure.ac +++ b/configure.ac @@ -26,6 +26,19 @@ AC_CONFIG_AUX_DIR([build-aux]) AM_INIT_AUTOMAKE([1.12.2 no-define no-dist-gzip dist-lzip dist-xz serial-tests]) AS_CASE([$PACKAGE_VERSION],[*.*.*],[pretest_p=yes],[pretest_p=no]) + +dnl PROPOSED_gl_DISABLE_THREADS +dnl -- +dnl Arranges for threads to be not used by default. +dnl This should be called *before* gl_INIT. +dnl The user can still override it at installation time, by using the +dnl configure option '--enable-threads'. + +AC_DEFUN([PROPOSED_gl_DISABLE_THREADS], [ + m4_define([gl_THREADLIB_DEFAULT_NO],[]) dnl hmmm +]) + + # syntax terrors AC_DEFUN([RCS_SET_MAYBE],[dnl @@ -257,6 +270,7 @@ AS_IF([test x$EXEEXT = x],[:], [The extension (including leading dot) of executable files.])]) # gnulib +PROPOSED_gl_DISABLE_THREADS gl_EARLY gl_INIT Any objections if i work up a patch based on this approach (i.e., rewrite ‘gl_DISABLE_THREADS’ and add docs)? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: gl_DISABLE_THREADS placement
() Paul Eggert egg...@cs.ucla.edu () Sat, 24 Jan 2015 13:21:50 -0800 Thien-Thi Nguyen wrote: - Is there any way to get ./configure --help to output: --disable-threads build without multithread safety (default) Without having looked at it, I suspect you need to change Gnulib to do that. It sounds like a worthwhile change. Hmm, the initial comments in threadlib.m4 suggest another way to obtain the disable by default state. So, this: AC_DEFUN([gl_THREADLIB_DEFAULT_NO],[]) dnl hmmm gl_EARLY gl_INIT is also valid, and as a bonus, omits the --disable-threads line in the ./configure --help output completely. Cool. Thus, my doubts now shift from implementation to design: - Why are there two methods? - What is the preferred method? (Why?) - What would be a good scenario to use the non-preferred method? - (if answer to why two methods is it was a mistake) What are the long-term plans to rectify? If i can get authoritative answers to these questions, i'm willing to summarize them, and contribute to gnulib a @(sub-) section of texinfo, so the last question is: Would gnulib accept such a contribution? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
gl_DISABLE_THREADS placement
I understand that adding ‘gl_DISABLE_THREADS’ to configure.ac causes module ‘threadlib’ (specifically file threadlib.m4) to generate a configure script that runs as if ‘--disable-threads’ had been included on the command-line. Is this correct? My questions are: - Where to add ‘gl_DISABLE_THREADS’? Some light experimentation w/ gl_EARLY gl_DISABLE_THREADS gl_INIT seems to yield the desired result, but i wonder if i'm missing something (either now or latent). - Is there any way to get ./configure --help to output: --disable-threadsbuild without multithread safety (default) instead of the current: --disable-threadsbuild without multithread safety ? This would be a (small) hint for the user, i think. Background: GNU RCS is single-threaded, but until: http://lists.gnu.org/archive/html/bug-rcs/2015-01/msg0.html there were no reported problems w/ the default-enabled state. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [PATCH] posixtm: avoid compiler warning in a better way
() Paul Eggert egg...@cs.ucla.edu () Wed, 10 Dec 2014 00:01:05 -0800 We could, but why bother? The strchr call is easier to understand and makes for less machine code. Is there a performance advantage as well for ‘strchr’? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [PATCH] posixtm: avoid compiler warning in a better way
() Paul Eggert egg...@cs.ucla.edu () Wed, 10 Dec 2014 00:44:59 -0800 Thien-Thi Nguyen wrote: Is there a performance advantage as well for ‘strchr’? Well, the call is smaller, and that's a performance win. :-) Seriously, though, it doesn't matter: this code is never a performance bottleneck, so simplicity is more important than efficiency here. OK. Thanks for explaining. I guess i'll try to temper my knee-jerk ‘strchr’ is evil reaction in the future. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [PATCH] posixtm: avoid compiler warning in a better way
() Paul Eggert egg...@cs.ucla.edu () Tue, 9 Dec 2014 18:12:51 -0800 + dot = strchr (s, '.'); Can we use ‘memchr (s, '.', s_len)’ here? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [PATCH] parse-datetime: Avoid pointer difference.
In similar vein, for lib/vasnprintf.c...
From d36b1b0fc4b40b9346e4d8d4b46ed8976a59352b Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen t...@gnu.org
Date: Sun, 31 Aug 2014 10:27:36 +0200
Subject: [PATCH] vasnprintf: Avoid signed/unsigned comparison warning.
* lib/vasnprintf.c (VASNPRINTF): To calculate padding,
compare end addr of generated string w/ maximum end addr.
---
ChangeLog| 6 ++
lib/vasnprintf.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index c48ca83..c466e87 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2014-08-31 Thien-Thi Nguyen t...@gnu.org (tiny change)
+
+ vasnprintf: Avoid signed/unsigned comparison warning.
+ * lib/vasnprintf.c (VASNPRINTF): To calculate padding,
+ compare end addr of generated string w/ maximum end addr.
+
2013-08-30 Mats Erik Andersson g...@gisladisker.se (tiny change)
parse-datetime: Avoid pointer difference.
diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c
index f2ccc1c..6ca47eb 100644
--- a/lib/vasnprintf.c
+++ b/lib/vasnprintf.c
@@ -3356,7 +3356,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
}
/* The generated string now extends from tmp to p, with the
zero padding insertion point being at pad_ptr. */
-if (has_width p - tmp width)
+if (has_width p tmp + width)
{
size_t pad = width - (p - tmp);
DCHAR_T *end = p + pad;
--
1.9.1
--
Thien-Thi Nguyen
GPG key: 4C807502
(if you're human and you know it)
read my lisp: (responsep (questions 'technical)
(not (via 'mailing-list)))
= nil
signature.asc
Description: PGP signature
Re: gnulib vasnprintf change introduced a bug
() Paul Eggert egg...@cs.ucla.edu () Sun, 31 Aug 2014 19:23:53 -0700 The recent change [...] introduced a bug because 'tmp + width' has undefined behavior if the resulting pointer would fall outside the containing buffer (this is true even though the pointer is not dereferenced). I believe the C11 spec describes this behavior in §6.5.6 ¶8, Additive Operators (in my draft copy, at least). Is that correct? Anywhere else i should look to learn more? [...] better to use -Wno-sign-compare, as the signal-to-noise ratio with -Wsign-compare is too high, and it's too tempting to introduce bugs such as this one. Yes, i surely fell for it. That being said, I worked around this problem with the attached further patch, which fixes somewhat-related issues that I also noticed. Thanks. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
updated make-html script
A while back, probably 2010, i posted a script to compose the file MODULES.html, the goal being (then as well as now) to not have to wait for MODULES.html.sh to complete, and to give the old computer's disk drive a break... Please find attached an updated version, that includes new sections ‘c11_sup’ and ‘c11_core_properties’: make-html Description: application/emacs-lisp Despite some implementation technique changes, the design largely remains a mimic of MODULES.html.sh, and in fact, now digs out section titles from it directly. To play, save it to the root dir of a gnulib working tree, chmod +x it, read the Commentary, and run it. IIRC, the previous post was not well-received due to some diffidence about the script interpreter (i.e., Emacs). No worries. If you like it, great; if you don't, great; if you find a bug, let me know and i'll fix it. That's all. :-D -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [PATCH 0/5] obstacks
() Alan Modra amo...@gmail.com () Fri, 29 Aug 2014 11:15:57 +0930 On Mon, Aug 04, 2014 at 02:16:06PM +0930, Alan Modra wrote: On Sat, Jul 26, 2014 at 03:27:07PM +0930, Alan Modra wrote: This patch series gives obstacks some much needed TLC. The first patch http://lists.gnu.org/archive/html/bug-gnulib/2014-07/msg00106.html Ping. It's been over a week, and I haven't seen any comments on the bulk of the patch series Now over a month. GNU RCS (which i maintain, sporadically) uses obstacks, so i looked over the m.l. archive. There were indeed several comments. Do you have something else (specific) in mind? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: 'static' in array-size func parm
() Paul Eggert egg...@cs.ucla.edu () Fri, 08 Aug 2014 23:49:54 -0700 OK, I added it just now. Thanks. GNU RCS now uses it: http://git.sv.gnu.org/cgit/rcs.git/commit/?h=pid=0b7eed81ba -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: 'static' in array-size func parm
() Paul Eggert egg...@cs.ucla.edu () Thu, 07 Aug 2014 17:44:00 -0700 First, I partially addressed this problem in 2006 in gnulib's AC_C_VARARRAYS macro (sorry, I forgot about this until today). No worries. Second, the C standardization committee addressed it in a different way, in C11's __STDC_NO_VLA__ macro. So just now I fixed gnulib to do things the C11 way. RCS should be able to use the vararrays module of the updated gnulib, and then do something like this: [VLA_ELEMS] I prefer the name VLA_ELEMS to ARSZ_FN_PARM, as it's shorter and more mnemonic to people who are used to the standard terminology. Sounds good to me. It might be helpful to have a gnulib module that implements VLA_ELEMS, such as in the attached patch; what do you think? (I haven't installed it.) The more gnulib does, the less RCS has to do, so i'm in favor of this approach (including module ‘vla’). You say partially, so i infer that buggy compiler detection remains an RCS responsibility (and that doing so via configure-time test is still the best way). Is that correct? If not, what do you mean by partially? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: 'static' in array-size func parm
() Paul Eggert egg...@cs.ucla.edu () Fri, 08 Aug 2014 00:57:37 -0700 Partially because the vararrays module merely defines __STDC_NO_VLA__ a la C11. The new module would define VLA_ELEMS, which would be the rest of the job that gnulib could reasonably do. IIUC, as it is proposed, RCS would still have to do that test and then re-‘#define VLA_ELEMS’: #if BUGGY #undef VLA_ELEMS #define VLA_ELEMS(x) #endif I think it would be more useful to expand the scope of module ‘vla’ to do the configure-time test, too, such that RCS can simply include it and use ‘VLA_ELEMS’ unconditionally. Buggy compiler workarounds are under gnulib purview, after all, right? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: 'static' in array-size func parm
() Paul Eggert egg...@cs.ucla.edu () Fri, 08 Aug 2014 12:54:14 -0700 Thien-Thi Nguyen wrote: IIUC, as it is proposed, RCS would still have to do that test and then re-‘#define VLA_ELEMS’: No, because if RCS uses Gnulib's vararrays module, the test will be done correctly, and will catch the Solaris 10 bug. Cool. I see that now, looking at m4/vararrays.m4. Actually, all that RCS should have to do is use the vla module; this module should bring in vararrays automatically. I assume it's using gnulib-tool? Yes. In this case, i eagerly await gnulib module ‘vla’ and will switch RCS to use it (and ‘VLA_ELEMS’). -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
'static' in array-size func parm
I recently learned that GCC 3.4.3 on Solaris 10 cannot compile:
int
last (int count, int all[static count])
{
return all[count - 1];
}
(valid C99, AFAIU), and have changed GNU RCS to work around the
situation, in the form of a configure-time test[0], a simple cpp
macro[1], and then various uses[2] of the macro.
[0] http://git.sv.gnu.org/cgit/rcs.git/commit/?id=c5909f7785
[1] http://git.sv.gnu.org/cgit/rcs.git/commit/?id=3efe2d4c96
[2] http://git.sv.gnu.org/cgit/rcs.git/commit/?id=ab84450872
http://git.sv.gnu.org/cgit/rcs.git/commit/?id=3e1ae8c823
Would this stuff (appropriately massaged) be interesting to gnulib?
--
Thien-Thi Nguyen
GPG key: 4C807502
(if you're human and you know it)
read my lisp: (responsep (questions 'technical)
(not (via 'mailing-list)))
= nil
signature.asc
Description: PGP signature
Re: 'static' in array-size func parm
() Paul Eggert egg...@cs.ucla.edu
() Wed, 06 Aug 2014 09:16:48 -0700
I'd be interested in getting this to work in gnulib, but
unfortunately it doesn't work yet with RCS so let's fix that first.
OK.
Actually, GCC 3.4.3 *can* compile that. [particulars]
Please try the following program instead:
int
last (int count, int all[static count])
{
return all[count - 1];
}
int
last1 (int count, int all[static count])
{
return all[count - 1];
}
I have installed that change. Does it result in ...no now?
Perhaps I should also mention that the bug occurs with -O2 but does
not occur when GCC is not optimizing. This should work with the
configure-time test, though, as it's built with -O2.
Thanks, that is useful, for mention in README (also installed).
--
Thien-Thi Nguyen
GPG key: 4C807502
(if you're human and you know it)
read my lisp: (responsep (questions 'technical)
(not (via 'mailing-list)))
= nil
signature.asc
Description: PGP signature
Re: 'static' in array-size func parm
() Paul Eggert egg...@cs.ucla.edu () Wed, 06 Aug 2014 17:14:48 -0700 bug does not occur with nested functions Thanks for catching this. In my rush, i neglected to read ‘AC_COMPILE_IFELSE’ docs carefully. I have now moved the func defs into the PROLOGUE and added a BODY. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: sig2str and str2sig use in C++
() Daniel J Sebald daniel.seb...@ieee.org () Tue, 04 Jun 2013 12:35:00 -0500 I seem to recall a paper several years back that argued against this approach based on ldso issues. Drat, can't dredge the details... I tried searching the Internet for such issues, but couldn't find any. What do you recall as being the loader problem? The extern part? Or use of a null string for termination? OK, found it. How to Write Shared Libraries by Ulrich Drepper, version 4.0, section 2.4.3 Arrays of Data Pointers. See also the programs in Appendix B. I think the problem is (relatively) high constant ldso overhead for a rarely-used facility. However, i'm not sure if those concerns are relevant in this context. If not, sorry for the noise! -- Thien-Thi Nguyen GPG key: 4C807502 pgpeaHS7VR1gG.pgp Description: PGP signature
Re: sig2str and str2sig use in C++
() Paul Eggert egg...@cs.ucla.edu () Mon, 03 Jun 2013 15:28:24 -0700 extern char const allsigstr[]; This would consist of a concatenation of null-terminated strings, one per name, terminated by an empty string. [compile time wins] I seem to recall a paper several years back that argued against this approach based on ldso issues. Drat, can't dredge the details... -- Thien-Thi Nguyen GPG key: 4C807502 pgpFSqG3QwPuY.pgp Description: PGP signature
Re: [PATCH] bootstrap: AC_INIT may have up to five fields
() Sami Kerola kerol...@iki.fi () Wed, 8 May 2013 20:33:03 +0100 [sed script] Instead of trying to mimic autoconf, why not ask it directly for the ‘AC_INIT’ field values, formatted in some convenient way? For example: unravel-ac-init Description: Bourne shell script -- Thien-Thi Nguyen GPG key: 4C807502 pgpAqhKlUXMrO.pgp Description: PGP signature
Re: errno -- errno name ?
() Bruno Haible br...@clisp.org () Wed, 8 Jun 2011 16:37:03 +0200 Accretion: the coral reef's algorithm. ;-) Would you be willing to create a gnulib module from this, for Sam? For Sam and anyone else interested, sure. What needs to be done? Create a .h file with the specification of the function. Create a .c file with the implementation. Decide whether to copy the mksyms script into gnulib or use a different approach. Create a module description. Polish, test, and finally submit the result here. Is there still any interest in this work? -- Thien-Thi Nguyen GPG key: 4C807502 pgp5UkjD8xkec.pgp Description: PGP signature
Re: [off-list] CVS pains
() k...@freefriends.org (Karl Berry) () Thu, 13 Dec 2012 22:53:55 GMT 1) It's not a matter of just changing savannah. There are numerous (*numerous*) processes involved with web pages repositories, most of which are written, maintained, and controlled by the FSF sysadmins, not Savannah. FSF sysadmin time is always at a premium. Probably the slog away from CVS could be made easier if those scripts (i presume) were more widely available. Unless there are some glaring security concerns (embedded passwords, e.g.), i think making a dist tarball (released under GPLv3+) of the lot would be a good first step. Then, Someone w/ time and inclination can coordiinate Others w/ time and inclination to go through the basic refactoring exercise: abstract, generalize appropriately, deploy in test env, fix design bugs, switch backend from CVS to Git (pretty please :-D), deploy in test env, fix implementation bugs, loop until thumbs-up for deployment in real env. This still requires coordination w/ the sysadmin(s), but at least a good amount of the work can be shouldered collectively, and more importantly, away from the GNU servers until the fruit is ripe. No source, no seed! (Maybe such a tarball is already available -- if so, sorry for the noise and where can i find this tarball?) I used to do sysadmin work (VAX/VMS) and would have wept w/ joy if GNU hackers (a formidable bunch) were to apply their skills to my mundane tasks. What i could have learned (that is, aside from most hackers' disdain for VMS :-D)! Maybe we find ourselves in a similar situation now. -- Thien-Thi Nguyen . GPG key: 4C807502 . NB: ttn at glug dot org is not me . . (and has not been since 2007 or so) . .ACCEPT NO SUBSTITUTES . ... please send technical questions to mailing lists ... pgpAEVEkELYCX.pgp Description: PGP signature
Re: [PATCH] bootstrap: use a more consistent error reporting scheme.
() Akim Demaille a...@lrde.epita.fr
() Fri, 6 Jul 2012 16:40:37 +0200
But we have to worry about ',' in $me, which is $0, not
its basename. Do you want me (Akim, not the variable)
to change me (the variable, not Akim; not that I am
immutable) to basename and use / in the sed command,
instead of ','?
# warnf_ FORMAT-STRING ARG1...
warnf_ ()
{
warnf_format_=$1
shift
printf $warnf_format_ $@ | sed s,^,$me: , 2
}
Instead of these contortions, what about:
printf %s: $warnf_format $me $@
?
Re: [PATCH] bootstrap: use a more consistent error reporting scheme.
() Jim Meyering j...@meyering.net () Fri, 06 Jul 2012 17:49:03 +0200 We want warnf '%s\n' a b c d to print this (as printf would do): $me: a $me: b $me: c $me: d With that added %s: , and with $me inserted into the list of arguments, we'd get this: $me: a b: c d: $me Thanks for explaining it; i understand the contortions now.
Re: gnulib-tool and --with-tests
() Bruno Haible br...@clisp.org () Thu, 21 Jun 2012 22:46:02 +0200 gnulib-tool: --create-[mega]testdir, --[mega]test implies --with-tests. Apparently, ‘--with-tests’ is implied (somehow) by ‘--update’ as well (but that is incompatible (why?) with ‘--conditional-dependencies’): http://hydra.nixos.org/build/2724974/log/tail-reload I suppose a workaround would be to specify ‘--without-tests’ in the gnulib-tool invocation: http://git.savannah.gnu.org/cgit/rcs.git/tree/autogen.sh#n21 but that strikes me as inelegant. Am i missing something?
Re: [PATCH] maint.mk: prohibit common grammar error: all these
() Jim Meyering j...@meyering.net () Mon, 11 Jun 2012 10:05:29 +0200 In your opinion, do any those uses in gnulib sound better without the of? For short pronouncements, of doesn't flow quite as nicely: https://en.wikipedia.org/wiki/2010_Odyssey_Two. FWIW, same goes for Italian: https://it.wikipedia.org/wiki/2010:_Odissea_due_(romanzo) (tutti questi == all these). (end unsolicited opinion, back to lurking...)
Re: [PATCH] parse-datetime: document the newly accepted format
() Jim Meyering j...@meyering.net
() Tue, 06 Sep 2011 12:40:47 +0200
Suggestions for improvements are most welcome.
[...]
+@example
+1972-09-24T20:02:00,00-0500 # @sc{iso} 8601 extended date and time of
day format
+@end example
This is kind of long (green screen). Better something like:
@example
1972-09-24T20:02:00,00-0500
# @sc{iso} 8601 extended date and time of day format
@end example
Alternatively, you could truncate the comment.
Re: patch-2.6.1.136-31a7 compilation failures on SGI IRIX
() Bruno Haible bruno-nwnvuoht2mvytjvyw6y...@public.gmane.org () Mon, 22 Aug 2011 22:59:05 +0200 The tarball of patch-2.6.1.136-31a7 was unlucky enough to pick up one of the buggy versions. I wonder if there is a way to better the odds of being lucky w/ gnulib.
Re: errno -- errno name ?
() Eric Blake ebl...@redhat.com () Fri, 05 Aug 2011 08:00:06 -0600 Not true. Use of : is portable to all shells that support functions, which is pretty much every shell out there today (including Solaris /bin/sh). Autoconf has already proved this point. OK, i stand corrected. I can let that memory fade now...
Re: errno -- errno name ?
() Bruce Korb bk...@gnu.org
() Fri, 05 Aug 2011 06:19:03 -0700
4 tmpd=`mktemp -d ${TMPDIR:-/tmp}/err-names-XX`
IIRC, constructs like:
${TMPDIR:-/tmp}
can be made more portable:
${TMPDIR-/tmp}
by removing the colon before the dash.
Re: fclose/fflush and GNU RCS
() Thien-Thi Nguyen t...@gnuvola.org () Thu, 09 Jun 2011 13:55:52 +0200 (Please correct me if i'm wrong.) [Mr. T voice] I pity the fool! If so, that means RCS was masking this bug all along, right? To debug, i will need to find out where a call to ‘fclose’ presumes (incorrectly) that the file position should be larger (further along) than it actually is. Right? Who knows? Poking around, i discovered that using ‘rewind’ directly instead of the supposedly equivalent ‘fseeko (STREAM, 0L, SEEK_SET)’ unmanifested the bug: http://git.savannah.gnu.org/cgit/rcs.git/commit/?id=3667dd09 so from GNU RCS pov, things are fine again. (Hydra is happy, too.) However, NB: this change just sidesteps an interop issue rather than grokking in full What Iz; it's possible that latent problems persist.
fclose/fflush and GNU RCS
According to Hydra: http://hydra.nixos.org/build/1114029 gnulib has something to do with the GNU RCS build breaking (actually, failing make check). The particular change is: http://git.savannah.gnu.org/cgit/gnulib.git/diff/?id=3606b9id2=122987 I think this is related to the thread beginning at: http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00269.html (Please correct me if i'm wrong.) If so, that means RCS was masking this bug all along, right? To debug, i will need to find out where a call to ‘fclose’ presumes (incorrectly) that the file position should be larger (further along) than it actually is. Right?
Re: errno -- errno name ?
() Bruno Haible br...@clisp.org () Wed, 8 Jun 2011 11:26:42 +0200 Its list of errno values is pretty extensive, good. Accretion: the coral reef's algorithm. Would you be willing to create a gnulib module from this, for Sam? For Sam and anyone else interested, sure. What needs to be done?
Re: Move sha1 to C?
() Paul Eggert egg...@cs.ucla.edu
() Mon, 23 May 2011 15:10:47 -0700
+sed_extract_condition1='/^ *'$escaped_dep' *$/{
+ s/^.*$/true/p
+}'
+sed_extract_condition2='/^ *'$escaped_dep' *\[.*\] *$/{
+ s/^ *'$escaped_dep' *\[\(.*\)\] *$/\1/p
+}'
IIUC the curly braces are optional if they contain only one command.
Is that not the case everywhere?
Re: breaking dependencies
() Bruno Haible br...@clisp.org () Sat, 19 Feb 2011 02:12:07 +0100 The costs that I can see are two-fold: 1) Additional modules; users have to read some documentation before they can decide whether they need, say, 'strstr' or 'strstr-simple'. As a gnulib user, this cost does not strike me as onerous. I'd rather have fine(r)-grained control than completeness.
Re: [PATCH] doc: update users.txt
() Jim Meyering j...@meyering.net () Thu, 10 Feb 2011 21:35:12 +0100 There. You've just done it: GNU RCS: rcs http://git.savannah.gnu.org/cgit/rcs.git too!
Re: FYI: replacement for MODULES.html.sh
() Bruno Haible br...@clisp.org () Tue, 9 Nov 2010 23:49:24 +0100 If that is considered a big problem, then let's *move* the module description parser to a different programming language (C for example - a language that is fast and that everyone here knows well). But let's not *duplicate* it. Code duplication is always a mistake. Another idea is to add gnulib-tool --dump-database=FORMAT, where FORMAT would be ‘sexp’ for a paren-inclined caller. This way, the internal database format particulars remain a secret. But anyway, here we do not have code duplication. We have algorithm aping and aggregation. Adding ‘--dump-database’ would incorporate the aggregation and eliminate the need for aping. Aggregation is what gives the desired performance. Caller, be it MODULES.html.sh or make-html, should not need to inner loop a quarter-megabyte shell script. THAT is a mistake.
Re: FYI: replacement for MODULES.html.sh
() Bruno Haible br...@clisp.org () Tue, 9 Nov 2010 11:04:12 +0100 [skills of gnulib maintainers] Maybe your point is that you are a skilled Emacs Lisp hacker, and want something to hack on? No, i just wanted to post code for impatient people to use (and hack). I did not take maintenance burden into consideration, although perhaps i should have. In the latest revision (i believe in a libposix thread), there is more consideration, in that lists are mined from the venerable MODULES.html.sh, but the spirit is still non-aggressive sharing for sharing's sake (FWIW, YMMV). It was fun to write, in any case; no need to worry about wasted whiles. Re Emacs Lisp not being a good fit for the skills of gnulib maintainers, i wouldn't know. I assumed that Emacs, older than GNU itself, would be not so difficult a tool to wield (despite its downsides) for this group as you seem to be saying. If anything, i was hoping for critique on the code from fellow programmers (of any and all stripes) so that i could improve my own skills. Put another way, i would be really surprised to hear all the gnulib maintainers chime in to say, sorry, i don't do Emacs Lisp, now and forever. Not only surprised, but saddened, TBH. [three proposals] Thank you for these ideas -- i will keep them in mind for the next time.
Re: libposix stuff
() Bruce Korb bk...@gnu.org () Mon, 08 Nov 2010 15:01:18 -0800 OK, I'll throw together a little script that looks at the dependencies of every POSIX module. It just so happens the latest make-html also computes fanout, albeit without any classification. Since last posting, it has been modified to mine the various lists from MODULES.html.sh, too. Runtime is now ~7 seconds. make-html Description: application/emacs-lisp
[PATCH] [html] Fix copy/paste bug: Use unique name for compiler warnings.
* MODULES.html.sh: For compiler warnings, use name `ansic_ext_compwarn' since `ansic_ext_misc' is already taken. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- ChangeLog |6 ++ MODULES.html.sh |2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 0ef0c27..e59555c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-11-05 Thien-Thi Nguyen t...@gnuvola.org (tiny change) + + [html] Fix copy/paste bug: Use unique name for compiler warnings. + * MODULES.html.sh: For compiler warnings, use name + `ansic_ext_compwarn' since `ansic_ext_misc' is already taken. + 2010-11-04 Eric Blake ebl...@redhat.com isnanl: work around icc bug diff --git a/MODULES.html.sh b/MODULES.html.sh index eb5b642..983953c 100755 --- a/MODULES.html.sh +++ b/MODULES.html.sh @@ -1953,7 +1953,7 @@ func_all_modules () element=Compiler warning management element=`printf %s $element | sed -e $sed_lt -e $sed_gt` - func_section_wrap ansic_ext_misc + func_section_wrap ansic_ext_compwarn func_wrap H3 func_echo $element -- 1.6.3.2
_Exit detection
GNU RCS uses gnulib module ‘stdlib’, which AFAICT does not detect missing ‘_Exit’, e.g., when using dietlibc: https://savannah.gnu.org/bugs/?30372 I am unsure where/how to fix this and would be grateful for any tips. Specifically: - Is this something gnulib can/should handle? - If not, what is the best (gnulib-compatible) way to detect missing ‘_Exit’? - Moving laterally, is it poor style to use ‘_Exit’ (as opposed to plain old ‘_exit’) in the first place? I look forward to learning from your repsonses. thi
Re: _Exit detection
() Paul Eggert egg...@cs.ucla.edu () Mon, 12 Jul 2010 09:40:20 -0700 Perhaps there is some advantage to _Exit on non-free platforms but I wouldn't worry about that unless the topic comes up and you have a good expert on those platforms available. Thanks for the explanation. Were it not for just-minted gnulib module ‘_Exit’, i would probably revert to ‘_exit’. thi
Re: _Exit detection
() Bruno Haible br...@clisp.org () Mon, 12 Jul 2010 18:56:28 +0200 But now, I'm adding the module '_Exit'. So all you have to do is to request this module. Cool. I will try it and report any problems. thi
Re: [PATCH] gnulib-tool: List modules separately, explicit vs dependencies.
() Bruno Haible br...@clisp.org () Sun, 13 Jun 2010 15:57:00 +0200 For me, it's a bit different: I don't think the number of modules has a lot of information. Perhaps it's just my (personal) gnulib-newbie fear... There are some modules, like 'stdint', which provide hardly any code, and 'regex', which are complex and heavy. Everything unknown is heavy with worry. Everything known is lighter (but with other worries :-). But I acknowledge your wish to see specified modules and dependencies to be distinguishable in the output. How can it be done in a lightweight way, without reducing the ability to copypaste the module list? I think indentation is a reasonable way of doing it. Like this: [...] Cool. That's a very nice approach. Thanks. thi
almost smooth
Progress report from the energetic (ha!) curmudgeon
I have
- upgraded my computer from Etch to Lenny;
- installed the requisite support packages, except for libtool (libltdl)
and libunistring, which are installed under prefix /home/ttn/local;
- done a git pull earlier today;
- successfully bootstrapped w/ sh -x autogen.sh;
- successfully configured w/:
../GG/configure -C \
--with-threads \
--prefix /tmp/a/b/z \
BDW_GC_CFLAGS='-I/usr/include' BDW_GC_LIBS='-lgc' \
LIBFFI_CFLAGS='-I/usr/include' LIBFFI_LIBS='-lffi' \
LDFLAGS='-L/home/ttn/local/lib';
- and successfully built w/ make all.
This is much further than previous attempts; i tip my hat to the next
generation! Now comes the hairy part -- make check failed with many
messages of the type:
WARNING: (test-suite test-rnrs-records-procedural): imported module (rnrs
records procedural) overrides core binding `record-constructor'
I saw several PASS and UNRESOLVED tests, and finally it failed with:
FAIL: version.test: version reporting works
Digging further, it looks like configure.ac uses build-aux/git-version-gen
to compute the effective version. In that script, there is the fragment:
81 # First see if there is a tarball-only version file.
82 # then try git describe, then default.
83 if test -f $tarball_version_file
84 then
85 v=`cat $tarball_version_file` || exit 1
86
... [snip]
94
95 if test -n $v
96 then
97 : # use $v
In the case where $tarball_version_file does not exist, var ‘v’ will never
have been set, the (inverse) condition checked on line 95. That's fine,
unless ‘v’ had already inherited a value from the environment, in which case
the test on line 95 evaluates to true and the env value is used (incorrectly).
In short, ‘v’ is possibly used uninitialized. Locally, i have provisionally
applied the following patch and now make check succeeds. Woo hoo!
BTW, gnulib folks: Here is a suitable ChangeLog entry:
2010-06-14 Thien-Thi Nguyen t...@gnuvola.org (tiny change)
git-version-gen: Init shell var to avoid env var influence.
* build-aux/git-version-gen (v): Init shell var to empty.
thi
___
build-aux/git-version-gen |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 9b821e0..5617eb8 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
#!/bin/sh
# Print a version string.
-scriptversion=2010-05-28.15; # UTC
+scriptversion=2010-06-14.19; # UTC
# Copyright (C) 2007-2010 Free Software Foundation, Inc.
#
@@ -78,6 +78,9 @@ tag_sed_script=${2:-s/x/x/}
nl='
'
+# Avoid meddling by environment variable of the same name.
+v=
+
# First see if there is a tarball-only version file.
# then try git describe, then default.
if test -f $tarball_version_file
Re: almost smooth
() Eric Blake ebl...@redhat.com () Mon, 14 Jun 2010 14:37:07 -0600 Since gnulib still maintains ChangeLog in the repository (you _are_ using the git-merge-changelog program, right?), it is appropriate to include ChangeLog edits as part of your git commit. OK, thanks for the reminder (yes, i use git-merge-changelog every so often). thi
Re: [PATCH] gnulib-tool: List modules separately, explicit vs dependencies.
() Bruno Haible br...@clisp.org () Fri, 2 Apr 2010 10:32:18 +0100 I apologize for the delayed response. If you just cut randomly, you will introduce bugs in your package, for sure. There are two reasonable uses of '--avoid': 1) When the documentation of the modules mentions that a module fixes bugs on particular platforms, and you know that these platforms are not used by your users. 2) When you provide fixes for the same bugs in a different way. These seem like reasonable guidelines. I have in the end avoided using ‘--avoid’, but will keep these in mind should the need arise. +# Separating explicit from implicit gives an idea of how bad your +# particular case of creeping gnulibitis has developed. --ttn I don't think it is generally useful to repeat a program's input in its output. The output should contain some level of information that the user is not aware of. Normally people are aware which gnulib modules they have specified. If not, they can look it up in the gnulib-cache.m4 file. I agree, now that i've had a chance to use gnulib more. (Thanks for reviewing the patch, btw.) To me, somewhat interesting is a count of the specified modules (i.e., aggregate information that i am not directly aware of), and really interesting is the full list of support modules (non-specified dependencies). The latter because it gives me an idea of the project's utility of gnulib (roughly, the ratio between specified and supported modules -- higher is better). I feel good increasing the utility; more aware of the code and its inter/intra-relationships. This is especially important for code that i did not originally write (in this case GNU RCS). Listing the support modules instead of simply counting them is a nice way to get ideas, too -- hey, this looks interesting, why don't i use that explicitly. For this reason, I would not like to apply your patch. Fair enough. FWIW, please find below a revised patch. Note that this post's subject and the patch title now differ. +sed -e 's|.*|//d|' $tmp/want $tmp/want.sed +echo '(dependencies)' +echo $modules | sed -f $tmp/want.sed | sed -e 's/^/ /' The autoconf documentation, section Limitations of Usual Tools, mentions that HP-UX sed has a limit of 99 commands. But one can have several module names specified to gnulib-tool. Therefore, the more portable (and more efficient) way to produce the difference set between two sets of module names is through the 'join' program. Thanks for the tip. The revised patch uses join(1). thi From 000c6f480ec6f7acce19f95f13d2c358915f678a Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen t...@gnuvola.org Date: Thu, 10 Jun 2010 15:53:58 +0200 Subject: [PATCH] gnulib-tool: Display specified modules count, list of support modules. * gnulib-tool (func_import): Don't display Module list with included dependencies. Instead, display the number of specified modules and a list of the support modules (non-specified dependencies). Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- ChangeLog |7 +++ gnulib-tool |8 ++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index a2bc2aa..c475317 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-06-10 Thien-Thi Nguyen t...@gnuvola.org + + gnulib-tool: Display specified modules count, list of support modules. + * gnulib-tool (func_import): Don't display Module list with included + dependencies. Instead, display the number of specified modules and + a list of the support modules (non-specified dependencies). + 2010-05-25 Ralf Wildenhues ralf.wildenh...@gmx.de Add missing include in test-pwrite.c. diff --git a/gnulib-tool b/gnulib-tool index 150ac6b..c678262 100755 --- a/gnulib-tool +++ b/gnulib-tool @@ -3591,8 +3591,12 @@ func_import () modules=$specified_modules func_modules_transitive_closure if test $verbose -ge 0; then -echo Module list with included dependencies: -echo $modules | sed -e 's/^/ /' +# Don't display the specified modules; the user already knows that. +# Nonetheless, a count is handy for monitoring creeping gnulibitis. --ttn +echo Number of specified modules: `echo $specified_modules | wc -l` +echo Support modules (non-specified dependencies): +echo $specified_modules | sed 's/$/ |/' $tmp/want +echo $modules | LC_ALL=C join -a 1 - $tmp/want | sed '/|$/d;s/^/ /' fi final_modules=$modules -- 1.6.3.2
[PATCH] gnulib-tool: List modules separately, explicit vs dependencies.
* gnulib-tool (func_import): For Module list with included dependencies, output two module lists: explicit and dependencies. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- Starting to use gnulib for GNU RCS, and playing with gnulib-tool --import strsignal. Fun stuff. I saw the huge list of modules pulled in and wondered where to start cutting (via --avoid). This change to gnulib-tool helps me to do the job more quickly by letting me ignore (for the purposes of experimental cutting) the explicitly specified modules. ChangeLog |6 ++ gnulib-tool |8 +++- 2 files changed, 13 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 82263a7..2a9aefd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-04-01 Thien-Thi Nguyen t...@gnuvola.org + + gnulib-tool: List modules separately, explicit vs dependencies. + * gnulib-tool (func_import): For Module list with included + dependencies, output two module lists: explicit and dependencies. + 2010-03-31 Eric Blake ebl...@redhat.com maint.mk: check for [ as well as test diff --git a/gnulib-tool b/gnulib-tool index 0b07e7a..94e077b 100755 --- a/gnulib-tool +++ b/gnulib-tool @@ -3525,7 +3525,13 @@ func_import () func_modules_transitive_closure if test $verbose -ge 0; then echo Module list with included dependencies: -echo $modules | sed -e 's/^/ /' +# Separating explicit from implicit gives an idea of how bad your +# particular case of creeping gnulibitis has developed. --ttn +echo '(explicitly specified)' +echo $specified_modules | tee $tmp/want | sed -e 's/^/ /' +sed -e 's|.*|//d|' $tmp/want $tmp/want.sed +echo '(dependencies)' +echo $modules | sed -f $tmp/want.sed | sed -e 's/^/ /' fi final_modules=$modules -- 1.6.3.2
putc vs printf
GNU RCS does not presently use gnulib, but it will in the future. With that in mind, i have a question inspired by this comment in the source code: /* Output the first character with `putc', not `printf'. Otherwise, an SVR4 stdio bug buffers output inefficiently. */ I don't know what to make of it and am wondering if, when the transition to gnulib occurs, it's an issue that can be conveniently glossed over. Could someone explain this or point me to more info? thi
[PATCH] [doc] Use three hyphens for emdash.
Very tiny change.
thi
__
From 93ed6c251c133d12bc97be108bb5c237121810ee Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen t...@gnuvola.org
Date: Tue, 16 Feb 2010 14:28:13 +0100
Subject: [PATCH] [doc] Use three hyphens for emdash.
* doc/standards.texi (Change Log Concepts):
Use three hyphens, not two, to effect -- output.
Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org
---
doc/standards.texi |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/standards.texi b/doc/standards.texi
index 7960880..26e30a3 100644
--- a/doc/standards.texi
+++ b/doc/standards.texi
@@ -3,7 +3,7 @@
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-...@set lastupdate February 16, 2010
+...@set lastupdate febbraio 16, 2010
@c %**end of header
@dircategory GNU organization
@@ -3531,7 +3531,7 @@ @node Change Log Concepts
The change log file is normally called @file{ChangeLog} and covers an
entire directory. Each directory can have its own change log, or a
-directory can use the change log of its parent directory--it's up to
+directory can use the change log of its parent directory---it's up to
you.
Another alternative is to record change log information with a version
--
1.6.3.2
[PATCH] [doc] Rethread however, one line to describe change ok idea.
Less jilting this way.
thi
From 995d784ee945b9b6f88d90003c0d4e75984455e3 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen t...@gnuvola.org
Date: Tue, 16 Feb 2010 14:53:21 +0100
Subject: [PATCH] [doc] Rethread however, one line to describe change ok idea.
* doc/standards.texi (Change Log Concepts):
Move the however, one line to describe change ok from its
own paragraph (following another however... sentence, thus
losing the antecedent) into the paragraph where need to
describe full purpose of changes is first discouraged.
Also, expand the prepositional noun phrase to cover a
single change.
Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org
---
doc/standards.texi |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/standards.texi b/doc/standards.texi
index 26e30a3..53b5c63 100644
--- a/doc/standards.texi
+++ b/doc/standards.texi
@@ -3540,7 +3540,10 @@ @node Change Log Concepts
@kbd{C-x v a} (@code{vc-update-change-log}) does the job.
There's no need to describe the full purpose of the changes or how they
-work together. If you think that a change calls for explanation, you're
+work together.
+However, sometimes it is useful to write one line to describe the
+overall purpose of a change or a batch of changes.
+If you think that a change calls for explanation, you're
probably right. Please do explain it---but please put the explanation
in comments in the code, where people will see it whenever they see the
code. For example, ``New function'' is enough for the change log when
@@ -3552,9 +3555,6 @@ @node Change Log Concepts
advised that it is a good idea to include them, for the sake of
copyright records.
-However, sometimes it is useful to write one line to describe the
-overall purpose of a batch of changes.
-
The easiest way to add an entry to @file{ChangeLog} is with the Emacs
command @kbd{M-x add-change-log-entry}. An entry should have an
asterisk, the name of the changed file, and then in parentheses the name
--
1.6.3.2
[PATCH] Add `system-time-locale' to auto-time-stamped doc/*.texi files.
Argh, i forgot to modify ChangeLog in the preceding patches. I will start doing so w/ this one. thi From 332ba5fe0da7fce8ae919a8bfcb5751fc9ad12fc Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen t...@gnuvola.org Date: Tue, 16 Feb 2010 15:01:34 +0100 Subject: [PATCH] Add `system-time-locale' to auto-time-stamped doc/*.texi files. * doc/maintain.texi (system-time-locale): New Emacs local variable. * doc/standards.texi (system-time-locale): Likewise. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- ChangeLog |6 ++ doc/maintain.texi |3 ++- doc/standards.texi |3 ++- 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5d82d10..1d15e4f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-02-16 Thien-Thi Nguyen t...@gnuvola.org + + Add `system-time-locale' to auto-time-stamped doc/*.texi files. + * doc/maintain.texi (system-time-locale): New Emacs local variable. + * doc/standards.texi (system-time-locale): Likewise. + 2010-01-25 Pádraig Brady p...@draigbrady.com syntax-check: detect incorrect boolean macro values in config.h diff --git a/doc/maintain.texi b/doc/maintain.texi index d84faba..befd80e 100644 --- a/doc/maintain.texi +++ b/doc/maintain.texi @@ -5,7 +5,7 @@ @c For double-sided printing, uncomment: @c @setchapternewpage odd @c This date is automagically updated when you save this file: -...@set lastupdate December 12, 2009 +...@set lastupdate February 16, 2010 @c %**end of header @dircategory GNU organization @@ -2067,6 +2067,7 @@ @node Index Local variables: eval: (add-hook 'write-file-hooks 'time-stamp) +system-time-locale: C time-stamp-start: @set lastupdate time-stamp-start: @set lastupdate time-stamp-end: $ diff --git a/doc/standards.texi b/doc/standards.texi index 53b5c63..7379371 100644 --- a/doc/standards.texi +++ b/doc/standards.texi @@ -3,7 +3,7 @@ @setfilename standards.info @settitle GNU Coding Standards @c This date is automagically updated when you save this file: -...@set lastupdate febbraio 16, 2010 +...@set lastupdate February 16, 2010 @c %**end of header @dircategory GNU organization @@ -4220,6 +4220,7 @@ @node Index Local variables: eval: (add-hook 'write-file-hooks 'time-stamp) +system-time-locale: C time-stamp-start: @set lastupdate time-stamp-end: $ time-stamp-format: %:b %:d, %:y -- 1.6.3.2
Re: [PATCH] [doc] Insert space before open-paren in C code fragments.
() Eric Blake e...@byu.net () Tue, 16 Feb 2010 06:00:40 -0700 ChangeLog? Patches to standards.texi should be sent to bug-standa...@gnu.org; if applied only to gnulib, they would be lost at the next upstream synchronization. Ok, thanks for the tip. Somehow i got the impression that gnulib is the authoritative repo for standards.texi and maintain.texi. I will resubmit this (and the flurry of others) there, and w/ ChangeLog. Please disregard them freely. thi
Re: [PATCH] Update doc UPDATED machinery.
() Simon Josefsson [EMAIL PROTECTED] () Thu, 19 Jun 2008 12:51:14 +0200 [low-cost fork of gnulib publishing] You could push your fork to some git host like repo.or.cz, or setup gitweb on your own site, although it doesn't strike me as ideal (what if everyone creates their own gnulib fork on repo.or.cz?). If they use git clone -s -l internally, it's probably No Big Deal. I've done a little experimentation (using git 1.5.3.5) and i think what i seek is partially achievable: normal disk space cost, low bandwidth cost w/ third party cooperation (not guaranteed). On my side, i would publish like so: cd ~/build/GNU/gnulib git prune git gc --prune git clone -l --bare .git $(pubrepo) # initially git push -v --tags $(pubrepo) $(branch) # subsequently Then, $(pubrepo) is staged to my (humble) web host at some point. For j.r.gnulib-hacker, i would request that they do this: cd $(local)/.. git clone -l --reference $(local) \ http://www.gnuvola.org/wip/gnulib.git \ ttn-gnulib where $(local) is the local gnulib repo. This would create a new dir ttn-gnulib/, a sibling of $(local), that shares storage w/ $(local) objects, therefore reducing network load on gnuvola.org for clone/pull. As you can see, if the --reference $(local) is omitted, this devolves into a normal clone operation. There is also a tantalizing blurb about http-alternates in the Documentation/repository-layout.txt, but i haven't investigated. thi
[PATCH] Update doc UPDATED machinery.
Zonking a CVS-ism in gnulib documentation...
BTW, what is the prevailing advice if i want to publish a git repo
containing only diffs between upstream gnulib my branches? The goal is
to make these branches available w/ minimal space/bandwidth cost.
thi
___
Update doc UPDATED machinery.
* doc/Makfile (update-stamp): New target.
(gnulib.info, gnulib.html, gnulib.dvi, gnulib.pdf): Depend on update-stamp.
(mostlyclean): Delete update-stamp.
* doc/gnulib.texi: No longer @set UPDATED directly.
Instead, @include update-stamp.
Signed-off-by: Thien-Thi Nguyen [EMAIL PROTECTED]
---
doc/.gitignore |1 +
doc/Makefile|7 +--
doc/gnulib.texi |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/.gitignore b/doc/.gitignore
index 175321e..b9634ef 100644
--- a/doc/.gitignore
+++ b/doc/.gitignore
@@ -14,3 +14,4 @@ gnulib.info-1
gnulib.info-2
gnulib.info-3
gnulib.html
+update-stamp
diff --git a/doc/Makefile b/doc/Makefile
index a95adfe..fcf988d 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -24,12 +24,15 @@ html: $(doc).html
dvi: $(doc).dvi
pdf: $(doc).pdf
-# Dependencies. Search for @include to find them all.
-gnulib.info gnulib.html gnulib.dvi gnulib.pdf: gnulib.texi gnulib-intro.texi
gnulib-tool.texi $(wildcard headers/*.texi) $(wildcard functions/*.texi)
quote.texi error.texi gcd.texi relocatable-maint.texi regexprops-generic.texi
fdl.texi
+update-stamp: *.texi */*.texi
+ date -u -r $$(ls -t $^ | sed 1q) +@set UPDATED %F %T UTC $@
+
+gnulib.info gnulib.html gnulib.dvi gnulib.pdf: update-stamp
standards.info standards.html standards.dvi: standards.texi make-stds.texi
fdl.texi
mostlyclean:
rm -f *.aux *.cp *.cps *.fn *.ky *.log *.pg *.toc *.tp *.vr *.vrs
+ rm -f update-stamp
clean: mostlyclean
rm -f *.info *.html *.dvi *.ps *.pdf
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index c5f8fd7..6656d9e 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -10,7 +10,7 @@
@end ifclear
@comment %**end of header
[EMAIL PROTECTED] UPDATED $Date: 2007-09-09 13:20:45 $
[EMAIL PROTECTED] update-stamp
@copying
This manual is for GNU Gnulib (updated @value{UPDATED}),
--
1.5.3.5
Re: [PATCH] Update doc UPDATED machinery.
() Simon Josefsson [EMAIL PROTECTED] () Thu, 19 Jun 2008 11:06:04 +0200 BTW, what is the prevailing advice if i want to publish a git repo containing only diffs between upstream gnulib my branches? The goal is to make these branches available w/ minimal space/bandwidth cost. Do you really need to fork gnulib to do this? I don't want to fork anything, unless that's the only way to provide a lightweight gnulib-origin git repo for others to pull from. I would like to do my (ugly, not for polite company) hacking locally and then publish only when things clear up. Gnulib supports project-specific changes using the --local-dir parameter. [...tips...] Thus, if you want to change gnulib for just one particular project, you are better of using the up-stream gnulib and having a local --local-dir directory with your local changes. I don't want to change gnulib for just one particular project. Thanks for those tips, but i don't think they are applicable to what i want to do. Of course, it is better to merge your changes into the real gnulib. If you've noticed a real problem, report that and it would hopefully be fixed. Yes, that is what i want to do. At the moment, to do so means: - identify problem - fix locally on a ttn-specific branch - send email w/ diff - loop: - get feedback - refix - send new email w/ new diff I seek hints on how to modify that to be: - identify problem - fix locally on a ttn-specific branch - push branch to (small footprint) public repo - send email w/ pointer to repo, optionally w/ diff - loop: - get feedback - refix - update public repo - send new email w/ notification of repo update The motivation is to reduce errors and/or misunderstandings due to some MTA (or, more likely, ttn) improperly munging the diff(s). Supposedly git is amenable to this kind of interaction, so i'm asking for help from experienced git users. thi
Re: [PATCH] Update doc UPDATED machinery.
() Simon Josefsson [EMAIL PROTECTED] () Thu, 19 Jun 2008 12:51:14 +0200 You could push your fork to some git host like repo.or.cz, or setup gitweb on your own site, although it doesn't strike me as ideal (what if everyone creates their own gnulib fork on repo.or.cz?). If a lightweight-subset repo is possible, it will be published at: http://www.gnuvola.org/wip/ [write privs] No thanks; i prefer the graduated peer-to-peer model. thi
Re: [PATCH] Update doc UPDATED machinery.
() Bruno Haible [EMAIL PROTECTED] () Thu, 19 Jun 2008 13:52:13 +0200 I couldn't apply it like this, however, because you cannot have rule dependencies with wildcards like this: update-stamp: *.texi */*.texi Ok, will keep in mind for the next time. I applied these two patches. Cool, thanks. thi
suggestion: move Gnulib module: -- blurb to misc notes
Presently, the blurb:
|The notation ``Gnulib module: ---'' means that Gnulib does not provide a
|module providing a substitute for the function. When the list
|``Portability problems not fixed by Gnulib'' is empty, such a module is
|not needed: No portability problems are known. Otherwise, it indicates
|that such a module would be useful but is not available: No one so far
|found this function important enough to contribute a substitute for it.
|If you need this particular function, you may write to
|@code{bug-gnulib at gnu dot org}.
is in @node Function Substitutes, which comes after usage of that notation
in the preceding @node Header File Substitutes. I think it would good to
move it to its own section under Miscellaneous Notes and then @xref to it.
I can provide a patch if there is interest.
thi
[patch] doc/gnulib-too.texi
A tiny change. (Is there a more preferred format for patches?)
thi
__
doc/gnulib-tool.texi |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index 9d9ec56..f5a66e0 100644
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -462,9 +462,10 @@ In projects which commit all source files, whether
generated or not, into
their VCS, the @code{gnulib-tool} generated files should all be committed.
Gnulib also contains files generated by @command{make} (and removed by
[EMAIL PROTECTED] clean}), using information determined by @command{configure}
-They should not be checked into the VCS, but instead added to
[EMAIL PROTECTED] When you have a Gnulib source file of the form
[EMAIL PROTECTED] clean}), using information determined by @command{configure}.
+They should not be registered with the VCS, but instead marked as
+ignorable (for example, by adding them to @file{.cvsignore} if the
+project is under CVS). When you have a Gnulib source file of the form
@file{lib/foo_.h}, the corresponding @file{lib/foo.h} is such a file.
@item
Re: [patch] doc/gnulib-too.texi
() Bruno Haible [EMAIL PROTECTED]
() Thu, 6 Mar 2008 15:01:18 +0100
Thanks, I've applied a slightly different one. (I don't often
read about registering with the VCS. check in is the more
common term. Also, when you say marked as ignorable (for
example, by adding them to @file{.cvsignore} - are there other
ways to mark a file as ignorable?).
It does seem that check in is used a lot. The only other data
point i have in mind is that Emacs, to support many VCSes, uses
the term register. The idea is that check in implies check
out, and the latter is confusing. Probably a little more verbose
but more explicit would be put under control of. Whatever...
As for ignorability, i know that Git has .gitignore, plus a user
ignore file (which i recently learned about). For example:
$ cd
$ echo '*.o' .git-global-ignore
$ git config core.excludesfile ~/.git-global-ignore
This makes Git ignore *.o for all my Git-managed projects.
Perhaps other VCSes sport other methods.
It was OK. For documentation patches, unified diffs (like those
that you sent) are generally preferred over context diff.
So i take it context diff is preferred for code patches?
2008-03-06 Bruno Haible [EMAIL PROTECTED]
Thanks for the quick update.
thi
Re: suggestion: move Gnulib module: -- blurb to misc notes
() Bruno Haible [EMAIL PROTECTED]
() Thu, 6 Mar 2008 15:04:12 +0100
Hmm, I would prefer to copy this paragraph to the beginning of
each of the 4 header file / function substitutes chapters.
Without this paragraph, people did not understand what the
notation means.
Sounds reasonable. Below is a patch. Here is a ChangeLog entry:
Distribute Gnulib module: -- blurb to four reference chapters.
* doc/gnulib.texi (nosuchmodulenote): New macro.
(Header File Substitutes, Functions Substitutes)
(Glibc Header File Substitutes, Glibc Function Substitutes):
Use [EMAIL PROTECTED]'.
thi
_
-*- mode: compilation; default-directory: ~/build/GNU/gnulib/doc/ -*-
Compilation started at Thu Mar 6 15:44:58
git diff ttn-was docfixes -- gnulib.texi
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index 270bcb7..3fe79c7 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -386,7 +386,7 @@ On a machine with recent automake, autoconf, m4 installed and with a
gnulib git or cvs checkout (typically a Linux machine), use
@example
-gnulib-tool --create-megatestdir --with-tests --dir=...
+gnulib-tool --create-megatestdir --with-tests --dir=...
@end example
Note: The created directory uses ca. 512 MB on disk.
@@ -454,6 +454,19 @@ source code, or when the program uses a mix between C and C++ sources
(requiring separate builds of the @code{posixlib} for the C compiler and
for the C++ compiler).
[EMAIL PROTECTED] This is used at the beginning of the following four chapters.
[EMAIL PROTECTED] nosuchmodulenote{thing}
+The notation ``Gnulib module: ---'' means that Gnulib does not provide a
+module providing a substitute for the \thing\. When the list
+``Portability problems not fixed by Gnulib'' is empty, such a module is
+not needed: No portability problems are known.
+
+Otherwise, it indicates that such a module would be useful but is not
+available: No one so far found this \thing\ important enough to
+contribute a substitute for it. If you need this particular \thing\,
+you may write to @code{bug-gnulib at gnu dot org}.
[EMAIL PROTECTED] macro
+
@node Header File Substitutes
@chapter ISO C and POSIX Header File Substitutes
@@ -461,6 +474,8 @@ This chapter describes which header files specified by ISO C or POSIX are
substituted by Gnulib, which portability pitfalls are fixed by Gnulib, and
which (known) portability problems are not worked around by Gnulib.
[EMAIL PROTECTED] header
+
@menu
* aio.h::
* arpa/inet.h::
@@ -641,14 +656,7 @@ ISO C or POSIX are substituted by Gnulib, which portability pitfalls are
fixed by Gnulib, and which (known) portability problems are not worked around
by Gnulib.
-The notation ``Gnulib module: ---'' means that Gnulib does not provide a
-module providing a substitute for the function. When the list
-``Portability problems not fixed by Gnulib'' is empty, such a module is
-not needed: No portability problems are known. Otherwise, it indicates
-that such a module would be useful but is not available: No one so far
-found this function important enough to contribute a substitute for it.
-If you need this particular function, you may write to
[EMAIL PROTECTED]bug-gnulib at gnu dot org}.
[EMAIL PROTECTED] function
@menu
* FD_CLR::
@@ -2898,6 +2906,8 @@ specified by ISO C or POSIX are substituted by Gnulib, which portability
pitfalls are fixed by Gnulib, and which (known) portability problems are
not worked around by Gnulib.
[EMAIL PROTECTED] header
+
@menu
* a.out.h::
* aliases.h::
@@ -2970,14 +2980,7 @@ provided as extensions by at least GNU libc are also supported by Gnulib,
which portability pitfalls are fixed by Gnulib, and which (known)
portability problems are not worked around by Gnulib.
-The notation ``Gnulib module: ---'' means that Gnulib does not provide a
-module providing a substitute for the function. When the list
-``Portability problems not fixed by Gnulib'' is empty, such a module is
-not needed: No portability problems are known. Otherwise, it indicates
-that such a module would be useful but is not available: No one so far
-found this function important enough to contribute a substitute for it.
-If you need this particular function, you may write to
[EMAIL PROTECTED]bug-gnulib at gnu dot org}.
[EMAIL PROTECTED] function
This list of functions is sorted according to the header that declares them.
Compilation finished at Thu Mar 6 15:44:58
Re: suggestion: move Gnulib module: -- blurb to misc notes
() Bruno Haible [EMAIL PROTECTED] () Thu, 6 Mar 2008 18:46:47 +0100 [...] additional paragraph break. Drat, i knew i should have explained that. I added it to avoid the resulting info file displaying the email address at end-of-paragraph split accross two lines, (ugly IMHO). Ah well, a little optical jerking to keep one awake... thi
Re: suggestion: move Gnulib module: -- blurb to misc notes
() Bruno Haible [EMAIL PROTECTED]
() Thu, 6 Mar 2008 19:51:36 +0100
There's a particular texinfo command for this: @w{}.
Cool.
thi
Re: [patch] (but not for gnulib) squash git diff spurious exit code 1
() Jim Meyering [EMAIL PROTECTED] () Fri, 28 Dec 2007 22:41:37 +0100 I've adapted your patch to apply to the trunk. New one below. It looks like you may want to adjust it further, so that git diff-index... with neither --stat option also exits successfully. Do you feel like pursuing it? pursuing it would involve pushing the zero-files-affected check back so that it happens sooner (prior to the supposedly display only handling of --stat), which is more than i can muster at the moment. frankly, i hate pushing an incomplete kludge w/ the inkling of how to DTRT. feels sick and wrong. perhaps it is best if i withdraw the proposal for now, revisiting in a few months if no one beats me to it. in any case, i'll continue living w/ it locally, using: (setq vc-git-diff-switches --stat) thi
[patch] (but not for gnulib) squash git diff spurious exit code 1
first off, apologies to anyone offended by my sending a patch for git to
this mailing list. clearly offtopic. but maybe not completely. please
allow this brief explanation: i remember faintly someone talking about
git diff (and brethren) returning non-zero spuriously even when there
were no differences, and just recently i encountered this anomoly myself.
so i set off to fix things. ugh! single-stepping (and thus having to
peer) through git-1.5.3.5/diff.c almost made me retch, so you might be
able to imagine what relief it was to figure out what kludge was to be
snarled from the kludge-kit, before escaping, nose pinched lest the
heinous cesspool alter me chemically (more than it did already).
simple testing: works fine. so on to the next step, do `diff -u
diff.c.ORIG diff.c' (see below) and hunt for the git mailing list
address. on the way, i stumble upon a big honking camel-cased file
telling me how to avoid MIME so that we can show off how comfortable we
are toiling away in the kludge-kit. that's fine. i can `C-x i' like
the best of them.
however, i got a little miffed reading Generate your patch using git
tools out of your commits and Your patch is not judged by who you
are, which seem just slightly discordant. hey, what if i am a
not-git-diff-using-in-actuality-a-git-diff-fixing kind of person? will
my patch be judged negatively? will i need to endure the approbations
(gentle or othersise) of the git maintainer(s)? why doesn't the code
show the same attention to PROCESS. why isn't the THOUGHT APPLIED?
WHO WAS IT THAT INSPIRED ME TO TRY GIT IN THE FIRST PLACE?!
then i remembered, it was gnulib denizens. ah, justice! so, in the
spirit of sharing around, instead of through, the tree trunk, i post
this here in hopes that it will be useful to git users, and that perhaps
one of them may muster the patience (more than what i have) to fling the
kludge upstream to bake in the flybuzz.
ok, so the explanation was not brief. but it felt good!
thi
_
* diff.c (CHANGE_MIND_LAST_MOMENT): New macro.
(show_stats): Use it immediately prior to output.
(show_shortstats): Likewise. Also, take 2nd arg OPTIONS.
Unique caller updated.
diff -u git-1.5.3.5/diff.c.ORIG git-1.5.3.5/diff.c
--- git-1.5.3.5/diff.c.ORIG 2007-10-31 21:04:37.0 +0100
+++ git-1.5.3.5/diff.c 2007-12-27 21:20:13.0 +0100
@@ -823,6 +823,16 @@
printf(%s, reset);
}
+/* If due to these supposedly output-only (sneer) wranglings
+ we have determined there are actually no changes, backpatch
+ the overall status and avoid any output. Blech. --ttn */
+#define CHANGE_MIND_LAST_MOMENT() do { \
+if (! total_files) { \
+ options-has_changes = 0;\
+ return; \
+} \
+ } while (0) \
+
static void show_stats(struct diffstat_t* data, struct diff_options *options)
{
int i, len, add, del, total, adds = 0, dels = 0;
@@ -957,11 +967,12 @@
free(data-files[i]);
}
free(data-files);
+ CHANGE_MIND_LAST_MOMENT ();
printf(%s %d files changed, %d insertions(+), %d deletions(-)%s\n,
set, total_files, adds, dels, reset);
}
-static void show_shortstats(struct diffstat_t* data)
+static void show_shortstats(struct diffstat_t* data, struct diff_options
*options)
{
int i, adds = 0, dels = 0, total_files = data-nr;
@@ -985,7 +996,7 @@
free(data-files[i]);
}
free(data-files);
-
+ CHANGE_MIND_LAST_MOMENT ();
printf( %d files changed, %d insertions(+), %d deletions(-)\n,
total_files, adds, dels);
}
@@ -3055,7 +3066,7 @@
if (output_format DIFF_FORMAT_DIFFSTAT)
show_stats(diffstat, options);
else if (output_format DIFF_FORMAT_SHORTSTAT)
- show_shortstats(diffstat);
+ show_shortstats(diffstat, options);
separator++;
}
Diff finished. Thu Dec 27 21:22:31 2007
Re: [patch] (but not for gnulib) squash git diff spurious exit code 1
() Ben Pfaff [EMAIL PROTECTED] () Thu, 27 Dec 2007 14:46:26 -0800 As a workaround, you can run git-status before git-diff. This is semi-documented in the documentation for git-status: If any paths have been touched in the working tree (that is, their modification times have changed) but their contents and permissions are identical to those in the index file, the command updates the index file. Running git-status can thus speed up subsequent operations such as git-diff if the working tree contains many paths that have been touched but not modified. thanks for the tip. the test case is extracted from the *Messages* buffer of emacs, so i suppose getting the workaround into emacs is a possibility. but that's going in the wrong direction i fear. thi
Re: [patch] (but not for gnulib) squash git diff spurious exit code 1
below is an updated patch. it skips all output,
instead of just the stats, for this special case.
thi
_
* diff.c (CHANGE_MIND_LAST_MOMENT_MAYBE): New macro.
(show_stats): Use it immediately prior to output.
(show_shortstats): Likewise. Also, take 2nd arg OPTIONS.
(diff_flush): Update calls to `show_stats' and `show_shortstats'.
Also, if we changed our mind, skip all further output.
--- diff.c.ORIG 2007-10-31 21:04:37.0 +0100
+++ diff.c 2007-12-27 23:27:52.0 +0100
@@ -823,6 +823,16 @@
printf(%s, reset);
}
+/* If due to these supposedly output-only (sneer) wranglings
+ we have determined there are actually no changes, backpatch
+ the overall status and avoid any output. Blech. --ttn */
+#define CHANGE_MIND_LAST_MOMENT_MAYBE() do { \
+if (! total_files) { \
+ options-has_changes = 0;\
+ return; \
+} \
+ } while (0) \
+
static void show_stats(struct diffstat_t* data, struct diff_options *options)
{
int i, len, add, del, total, adds = 0, dels = 0;
@@ -957,11 +967,12 @@
free(data-files[i]);
}
free(data-files);
+ CHANGE_MIND_LAST_MOMENT_MAYBE ();
printf(%s %d files changed, %d insertions(+), %d deletions(-)%s\n,
set, total_files, adds, dels, reset);
}
-static void show_shortstats(struct diffstat_t* data)
+static void show_shortstats(struct diffstat_t* data, struct diff_options
*options)
{
int i, adds = 0, dels = 0, total_files = data-nr;
@@ -985,7 +996,7 @@
free(data-files[i]);
}
free(data-files);
-
+ CHANGE_MIND_LAST_MOMENT_MAYBE ();
printf( %d files changed, %d insertions(+), %d deletions(-)\n,
total_files, adds, dels);
}
@@ -3055,7 +3066,10 @@
if (output_format DIFF_FORMAT_DIFFSTAT)
show_stats(diffstat, options);
else if (output_format DIFF_FORMAT_SHORTSTAT)
- show_shortstats(diffstat);
+ show_shortstats(diffstat, options);
+ /* If we changed our minds, avoid further output totally. */
+ if (! options-has_changes)
+ goto free_filepairs;
separator++;
}
@@ -3085,6 +3099,7 @@
if (output_format DIFF_FORMAT_CALLBACK)
options-format_callback(q, options,
options-format_callback_data);
+free_filepairs:
for (i = 0; i q-nr; i++)
diff_free_filepair(q-queue[i]);
free_queue:
doc patch: typos in node CVS Issues
ChangeLog entry:
2007-05-16 Thien-Thi Nguyen [EMAIL PROTECTED] (tiny change)
* doc/gnulib-tool.texi (CVS Issues): Fix typo.
patch:
--- gnulib-tool.texi31 Mar 2007 12:34:55 - 1.14
+++ gnulib-tool.texi16 May 2007 06:50:44 -
@@ -350,7 +350,7 @@
CVS, the @code{gnulib-tool} generated files should all be committed.
Gnulib also contains files generated by @command{make} (and removed by
[EMAIL PROTECTED] clean}, using information determined by @command{configure}
[EMAIL PROTECTED] clean}), using information determined by @command{configure}.
They should not be checked into CVS, but instead added to
@file{.cvsignore}. When you have a Gnulib source file of the form
@file{lib/foo_.h}, the corresponding @file{lib/foo.h} is such a file.
[patch] doc/gnulib.texi typofix
--- gnulib.texi 15 Mar 2007 22:58:36 - 1.33 +++ gnulib.texi 19 Mar 2007 10:42:14 - @@ -202,7 +202,7 @@ handling happens in rare situations, but performing the out of memory error handling after almost all API function invocations pollute your source code and might make it harder to spot more serious problems. -The strategy chosen improve code readability and robustness. +The strategy chosen improves code readability and robustness. @cindex Aborting execution For most applications, aborting the application with an error message
[patch] doc/gnulib.texi typofixes
ChangeLog entry:
* doc/gnulib.texi (Out of memory handling): Fix typos.
diff:
--- gnulib.texi 15 Mar 2007 22:58:36 - 1.33
+++ gnulib.texi 19 Mar 2007 10:46:02 -
@@ -202,16 +202,16 @@
handling happens in rare situations, but performing the out of memory
error handling after almost all API function invocations pollute your
source code and might make it harder to spot more serious problems.
-The strategy chosen improve code readability and robustness.
+The strategy chosen improves code readability and robustness.
@cindex Aborting execution
For most applications, aborting the application with an error message
-when the out of memory situation occur is the best that can be wished
+when the out of memory situation occurs is the best that can be wished
for. This is how the library behaves by default.
@vindex xalloc_fail_func
However, we realize that some applications may not want to have the
-GSS library abort execution in any situation. The GSS library support
+GSS library abort execution in any situation. The GSS library supports
a hook to let the application regain control and perform its own
cleanups when an out of memory situation has occurred. The application
can define a function (having a @code{void} prototype, i.e., no return
[patch] doc/relocatable-maint.texi example sveltening
ChangeLog entry: * doc/relocatable-maint.texi (Supporting Relocation): Refill the script example, eliding one sed invocation. diff attached relocatable-maint.texi.diff Description: Binary data
