Re: status of C++ support with GNULIB_NAMESPACE
On 11/20/2016 12:23 PM, Bruno Haible wrote: > To see where we are on C++ GNULIB_NAMESPACE support, I ran > $ ./gnulib-tool --create-testdir --with-c++-tests --with-tests > --dir=/tmp/testdir > (takes one hour, be patient) and built it on a glibc system with > $ ./configure CPPFLAGS="-DGNULIB_NAMESPACE= -Wall" CC=g++ > $ make -k Eh, one hour! > > Here are the findings: ... > All these errors are in the category "Not a bug", IMO, because gdb and other > packages can arrange to build the imported gnulib-lib/ directory using a > C compiler rather than a C++ compiler. That's what GDB already does, actually. GDB imports gnulib in a way that makes it a separate static library, configured separately from the programs that use it (gdb and gdbserver). This long email explains gdb's current gnulib import setup: https://sourceware.org/ml/gdb-patches/2012-04/msg00426.html The code is here: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=tree;f=gdb/gnulib;h=754400e0fb14458e4e95a4f9c7c5e18930201d4a;hb=HEAD At some early point of GDB's C++ conversion work, I pondered building gnulib with a C++ compiler, but ended up dismissing it as both impractical, and unnecessary. BTW, do we know which programs use GNULIB_NAMESPACE? I believe the initial support was done for GNU Octave, but I see that quite recently Octave switched away from it, maybe because of the problems with newer GCCs (I believe fixed now). Thanks, Pedro Alves
Re: ChangeLog entries
Pedro Alves wrote: > > I added ChangeLog entries for your two patches from 2016-11-12 > > (that Paul committed). > > Thanks! Should I assume you're all using git-merge-changelog and Yes, we are all using the git-merge-changelog. It handles about 60% of the ChangeLog entry conflicts correctly. (A couple of years ago, it handled 95% of such conflicts correctly. I guess something in the git internals has changed...) > include ChangeLog changes in the diff as well as in the > commit log? Yes, this is how we all do it when we commit a patch. When a contributor sends in a patch, the person who pushes it on behalf of the author takes care of doing the right thing. Many of us also use vc-dwim: It makes it less tedious to create the detailed ChangeLog entry. Bruno
Re: [PATCH] Avoid having GNULIB_NAMESPACE::func always inject references to rpl_func
On 11/21/2016 11:27 PM, Bruno Haible wrote:
> Pedro Alves wrote:
>> How about breaking this line like the rpl method was breaking it, in order
>> to avoid overly-long lines?
>>
>>inline operator type () const
>>{ return reinterpret_cast((rettype2 (*)
>> parameters2)(::func)); }
>>
>> Likewise the other similar cases.
>
> If line breaking it needed, I prefer the GNU style for functions,
That's fine with me. (The single-line {...} style comes from libstdc++.)
> and do it systematically. It takes more vertical space, but it
> make is easier to compare the different variants of _gl_ ## func ## _wrapper.
Agreed, that's what I was thinking when suggesting to give
the other similar cases the same treatment.
Thanks,
Pedro Alves
Re: [PATCH] Avoid having GNULIB_NAMESPACE::func always inject references to rpl_func
Pedro Alves wrote:
> How about breaking this line like the rpl method was breaking it, in order
> to avoid overly-long lines?
>
>inline operator type () const
>{ return reinterpret_cast((rettype2 (*)
> parameters2)(::func)); }
>
> Likewise the other similar cases.
If line breaking it needed, I prefer the GNU style for functions,
and do it systematically. It takes more vertical space, but it
make is easier to compare the different variants of _gl_ ## func ## _wrapper.
--- a/build-aux/snippet/c++defs.h
+++ b/build-aux/snippet/c++defs.h
@@ -133,7 +133,11 @@
static const struct _gl_ ## func ## _wrapper\
{ \
typedef rettype (*type) parameters; \
-inline operator type () const { return ::rpl_func; } \
+ \
+inline operator type () const \
+{ \
+ return ::rpl_func; \
+} \
} func = {};\
} \
_GL_EXTERN_C int _gl_cxxalias_dummy
@@ -154,7 +158,11 @@
static const struct _gl_ ## func ## _wrapper \
{\
typedef rettype (*type) parameters;\
-inline operator type () const { return
reinterpret_cast(::rpl_func); } \
+ \
+inline operator type () const \
+{ \
+ return reinterpret_cast(::rpl_func); \
+} \
} func = {}; \
} \
_GL_EXTERN_C int _gl_cxxalias_dummy
@@ -180,7 +188,11 @@
static const struct _gl_ ## func ## _wrapper\
{ \
typedef rettype (*type) parameters; \
-inline operator type () const { return ::func; } \
+ \
+inline operator type () const \
+{ \
+ return ::func; \
+} \
} func = {};\
} \
_GL_EXTERN_C int _gl_cxxalias_dummy
@@ -201,7 +213,11 @@
static const struct _gl_ ## func ## _wrapper \
{ \
typedef rettype (*type) parameters; \
-inline operator type () const { return reinterpret_cast(::func);
} \
+\
+inline operator type () const \
+{ \
+ return reinterpret_cast(::func);\
+} \
} func = {}; \
} \
_GL_EXTERN_C int _gl_cxxalias_dummy
@@ -228,7 +244,11 @@
static const struct _gl_ ## func ## _wrapper\
{ \
typedef rettype (*type) parameters; \
-inline operator type () const { return
reinterpret_cast((rettype2 (*) parameters2)(::func)); } \
+ \
+inline operator type () const \
+{ \
+ return reinterpret_cast((rettype2 (*) parameters2)(::func)); \
+} \
} func = {};\
} \
_GL_EXTERN_C int _gl_cxxalias_dummy
Pushed with this style change.
Bruno
Re: gettext->gnulib sync conflicts
Hi Daiki (and all), if srclist-update were aware of the serial numbers of the files. 1) Not all synced files have serial numbers. 2) It's not clear to me that the decision about syncing should, in principle, be based on serial numbers (or timestamps). 3) Nevertheless I have no particular objection to the idea (it would solve the immediate question, I guess), but I also don't feel like implementing it. I doubt it's going to be the top of anyone else's priority list either. Therefore I've disabled syncing of all gettext<->gnulib files in gnulib/config/srclist.txt. Feel free to revert/change as you like, at any time ... --best, karl.
fix the license output by --lgpl=3orGPLv2
Hi, The recent patch which added the option 3orGPLv2 didn't modify the license text to reflect the 3orGPLv2 license. This patch attempts to do just that (it's a bit ugly but the result seems ok). regards, Nikos From a052732ba0f8fe7e298d02d60943834117855077 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Mon, 21 Nov 2016 21:15:25 +0100 Subject: [PATCH] gnulib-tool: properly list the LGPL3orGPLv2 license That is, include the text of both the LGPLv3 and GPLv2 in the headers. --- gnulib-tool | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/gnulib-tool b/gnulib-tool index 5145d47..8e735ad 100755 --- a/gnulib-tool +++ b/gnulib-tool @@ -4758,13 +4758,23 @@ s,^\(.[^ ]*\) *, if test -n "$lgpl"; then # Update license. case "$lgpl" in -yes | 3 | 3orGPLv2) +yes | 3) sed_transform_main_lib_file=$sed_transform_main_lib_file' s/GNU General/GNU Lesser General/g s/General Public License/Lesser General Public License/g s/Lesser Lesser General Public License/Lesser General Public License/g ' ;; +3orGPLv2) + sed_transform_main_lib_file=$sed_transform_main_lib_file' +s/GNU General/GNU Lesser General/g +s/General Public License/Lesser General Public License/g +s/Lesser Lesser General Public License/Lesser General Public License/g +s/version [23]\([ ,]\)/version 3\1/g +s/under the terms of/under the terms of either:\n\n*/ +s/any later version./any later version.\n\n or\n\n * the GNU General Public License as published by the Free\n Software Foundation; either version 2 of the License, or\n (at your option) any later version.\n\n or both in parallel, as here./ + ' + ;; 2) sed_transform_main_lib_file=$sed_transform_main_lib_file' s/GNU General/GNU Lesser General/g -- 2.10.1
Re: [PATCH] Avoid having GNULIB_NAMESPACE::func always inject references to rpl_func
On 11/20/2016 12:26 PM, Bruno Haible wrote:
> Hi Pedro,
Hi!
> I added ChangeLog entries for your two patches from 2016-11-12
> (that Paul committed).
Thanks! Should I assume you're all using git-merge-changelog and
include ChangeLog changes in the diff as well as in the
commit log?
> The member function 'rpl ()' is not used, other than in the 'operator type'.
> How about inlining and eliminating it?
That's fine with me.
\
> _GL_EXTERN_C int _gl_cxxalias_dummy
> @@ -234,11 +228,7 @@
>static const struct _gl_ ## func ## _wrapper
> \
>{
> \
> typedef rettype (*type) parameters;
> \
> -
> \
> -inline type rpl () const
> \
> -{ return reinterpret_cast((rettype2 (*) parameters2)(::func));
> }\
> -
> \
> -inline operator type () const { return rpl (); }
> \
> +inline operator type () const { return
> reinterpret_cast((rettype2 (*) parameters2)(::func)); } \
How about breaking this line like the rpl method was breaking it, in order
to avoid overly-long lines?
inline operator type () const
{ return reinterpret_cast((rettype2 (*) parameters2)(::func));
}
Likewise the other similar cases.
Thanks,
Pedro Alves
Re: relicensing libunistring to "dual LGPLv3+ or GPLv2"
On Mon, Nov 21, 2016 at 10:46 AM, Bruno Haible wrote: > I would be willing to put my contributions to these files under LGPLv2+. [...] > === Kevin === > > Would you be willing to do the same for lib/fseterr.c ? Yes, approved.
Re: relicensing libunistring to "dual LGPLv3+ or GPLv2"
Daiki Ueno wrote: > noticed some more dependencies (from the unistdio modules): > > /home/dueno/devel/libunistring/../gnulib/gnulib-tool: *** incompatible > license on modules: > fseterr LGPL > mbcharLGPL > mbiterLGPL > mbsnlen LGPL > wcwidth LGPL Oh, indeed. Somehow I missed these dependencies. The file lib/stdio-impl.h is already under LGPLv2+, per modules fflush, freadahead, freading, freadptr, freadseek, fpurge, fseeko, ftello. The other files were written by: lib/fseterr.h: Bruno lib/fseterr.c: Bruno, Kevin Cernekee lib/mbchar.h: Bruno, Paul (regarding 'inline') lib/mbchar.c: Bruno, Paul (regarding 'inline') lib/mbiter.h: Bruno, Paul lib/mbiter.c: Paul lib/mbsnlen.c: Bruno lib/wcwidth.c: Bruno I would be willing to put my contributions to these files under LGPLv2+. === Paul === Would you be willing to do the same for lib/mbchar.* and lib/mbiter.* ? === Kevin === Would you be willing to do the same for lib/fseterr.c ? Bruno
Re: [PATCH] dfa: addition of new state on demand
On Mon, 17 Oct 2016 22:00:33 +0900
Norihiro Tanaka wrote:
>
> On Mon, 17 Oct 2016 11:45:43 +0900
> Norihiro Tanaka wrote:
>
> > When dfa builds a state, generates all next states. However, I believe
> > most of them are not used.
> >
> > This patch changes as that when dfa builds a state, generates a next
> > state including next input character only.
> >
> > The following test was improved from 2.52s to 0.67s by the patch in my
> > machine.
> >
> > $ seq -f '%g bottles of beer on the wall' 600 >600
> > $ time -p env LC_ALL=C src/grep -vf 600 600
> >
> > $ env LC_ALL=C gcc -v
> > Reading specs from /usr/local/lib/gcc/x86_64-pc-linux-gnu/4.4.7/specs
> > Target: x86_64-pc-linux-gnu
> > Configured with: ./configure --with-as=/usr/local/bin/as
> > --with-ld=/usr/local/bin/ld --with-system-zlib --enable-__cxa_atexit
> > Thread model: posix
> > gcc version 4.4.7 (GCC)
> > $ uname -a
> > Linux rhel6 2.6.32-642.el6.x86_64 #1 SMP Wed Apr 13 00:51:26 EDT 2016
> > x86_64 x86_64 x86_64 GNU/Linux
>
> Hi,
>
> I updated comments in previous patch.
>
> Thanks,
> Norihiro
Can anyone review this change?
From a2144547298fe31a93e6a65b2c4e7e2037c53980 Mon Sep 17 00:00:00 2001
From: Norihiro Tanaka
Date: Mon, 17 Oct 2016 11:27:47 +0900
Subject: [PATCH] dfa: addition of new state on demand
* src/dfa.c (dfastate): Add argument UC. It is current input character.
fill only a group including the character in transition table.
(realloc_trans_if_necessary): Add the dummy state which means that a
transition table is assigned but next state is not assigned.
(build_state): Return next state. All caller updated.
(transit_state_singlebyte): If get the dummy state, fill the transition
tble.
(dfaexec_main): Handle the dummy state.
(free_mbdata, dfafree): Consider the dummy state.
---
lib/dfa.c | 347 +
1 files changed, 142 insertions(+), 205 deletions(-)
diff --git a/lib/dfa.c b/lib/dfa.c
index 744a9f1..793f828 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -477,7 +477,8 @@ struct dfa
/* Fields filled by dfaexec. */
state_num tralloc;/* Number of transition tables that have
- slots so far, not counting trans[-1]. */
+ slots so far, not counting trans[-1] and
+ trans[-2]. */
int trcount; /* Number of transition tables that have
actually been built. */
int min_trcount; /* Minimum of number of transition tables.
@@ -490,7 +491,8 @@ struct dfa
state could possibly accept, its entry in
this table is NULL. This points to one
past the start of the allocated array,
- and trans[-1] is always NULL. */
+ and trans[-1] and trans[-2] are always
+ NULL. */
state_num **fails;/* Transition tables after failing to accept
on a state that potentially could do so. */
int *success; /* Table of acceptance conditions used in
@@ -507,7 +509,8 @@ struct dfa
do not distinguish between their contexts,
as not supported word. */
position_set mb_follows; /* Follow set added by ANYCHAR on demand. */
- state_num **mb_trans; /* Transition tables for states with ANYCHAR. */
+ state_num **mb_trans; /* Transition tables for states with
+ ANYCHAR. */
state_num mb_trcount; /* Number of transition tables for states with
ANYCHAR that have actually been built. */
@@ -2510,19 +2513,12 @@ dfaanalyze (struct dfa *d, bool searchflag)
If after comparing with every group there are characters remaining in C,
create a new group labeled with the characters of C and insert this
position in that group. */
-static void
-dfastate (state_num s, struct dfa *d, state_num trans[])
+static state_num
+dfastate (state_num s, struct dfa *d, unsigned char uc, state_num trans[])
{
- leaf_set grps[NOTCHAR]; /* As many as will ever be needed. */
- charclass labels[NOTCHAR];/* Labels corresponding to the groups. */
- size_t ngrps = 0; /* Number of groups actually used. */
- position pos; /* Current position being considered. */
+ leaf_set group; /* As many as will ever be needed. */
+ charclass labels; /* Labels corresponding to the group. */
charclass matches;/* Set of matching characters. */
- charclass_word matchesf; /* Nonzero if matches is nonempty. */
- charclass intersect; /* Intersection with some label set. */
- charclass_word intersectf; /* Non
Re: gettext->gnulib sync conflicts
Hello, Karl Berry writes: > I can sync against dev, or I can sync against releases, or I can not > sync at all, or I can quit being responsible for this job entirely and > someone else can figure out what to do :). I can't go back and forth > depending on development "periods". [Or gettext could be removed from > gnulib entirely, which I tend to think would tremendously simplify > everything for everyone, but doubt you like the idea.] > > Sigh. > > Daiki needs to decide. > > Daiki? --thanks, karl. I'm not really sure what I need to decide. Is there any room for compromise between the sync-with-releases mechanism and manual check-ins? I thought it would be possible to avoid unwanted overwrites if srclist-update were aware of the serial numbers of the files. Regards, -- Daiki Ueno
