[gnu.org #1534539] Re: Licensing issues for gendocs_template_min
Whoops, I forgot to include the string "[gnu.org #1531751]" in the Subject of my previous message, so it created new issue (to which this is a reply). I have never written to licens...@fsf.org before, so I didn't realize how it works. I apologize for any inconvenience this may have caused. If you like, I can re-send my reply with the correct subject. Perhaps I never should have involved licens...@fsf.org in the first place; it seems that this is an issue the Gnulib maintainers should be able to solve. Thanks, Asher -- ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Re: Licensing issues for gendocs_template_min
Asher Gordon writes:
> However, gendocs_template_min is licensed under the Creative Commons
> Attribution-NoDerivs 3.0 United States License.
After noticing that the gendocs_template for GNU Tar is licensed under
the GNU All-Permissive license, I figured that perhaps gendocs_template
in Gnulib wasn't always licensed under the CC By-ND. So, using 'git
blame', I discovered commit 9cda876 from 2014. In that commit, the GNU
All-Permissive license text was replaced with a CC By-ND notice (along
with some other changes). Unfortunately, the commit message,
"autoupdate", is rather unhelpful.
Is it possible that licensing gendocs_template{,_min} under the CC By-ND
was a mistake? If so, would it be possible to change it back to the GNU
All-Permissive?
Thanks,
Asher
--
I hate quotations.
-- Ralph Waldo Emerson
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Re: [PATCH] nstrftime: better width support for %N, %z
On 5/20/20 10:51 AM, Kamil Dudka wrote:
If the change is intended, the documentation of `date` should be updated
Thanks for mentioning this. The change was intended, and I installed the
attached patch into the Coreutils documentation.
>From 6d0107a37f3b648aa43bf790625dd25f9f8301e7 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 20 May 2020 17:31:18 -0700
Subject: [PATCH] date: document +%-N change
Suggested by Kamil Dudka in:
https://lists.gnu.org/r/bug-gnulib/2020-05/msg00205.html
* NEWS: Mention the change for coreutils 8.23.
* doc/coreutils.texi (Padding and other flags):
Document it.
---
NEWS | 5 +
doc/coreutils.texi | 10 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/NEWS b/NEWS
index 1f59a156a..8ddd0e22f 100644
--- a/NEWS
+++ b/NEWS
@@ -90,6 +90,11 @@ GNU coreutils NEWS-*- outline -*-
[The old behavior was introduced in sh-utils 2.0.15 ca. 1999, predating
coreutils package.]
+ date now pads nanoseconds on the right, not the left. For example,
+ if the time is currently 1590020079.003388470 seconds after the
+ Epoch, then "date '+%s.%-N'" formerly output "1590020079.3388470",
+ and it now outputs "1590020079.00338847".
+
ls issues an error message on a removed directory, on GNU/Linux systems.
Previously no error and no entries were output, and so indistinguishable
from an empty directory, with default ls options.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 0e1dc48bd..f0684b1c5 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16034,7 +16034,10 @@ a horizontal tab
Unless otherwise specified, @command{date} normally pads numeric fields
with zeros, so that, for
example, numeric months are always output as two digits.
-Seconds since the epoch are not padded, though,
+Most numeric fields are padded on the left.
+However, nanoseconds are padded on the right since they are commonly
+used after decimal points in formats like @samp{%s.%-N}.
+Also, seconds since the epoch are not padded
since there is no natural width for them.
The following optional flags can appear after the @samp{%}:
@@ -16082,9 +16085,10 @@ date +%_d/%_m -d "Feb 1"
You can optionally specify the field width
(after any flag, if present) as a decimal number. If the natural size of the
output of the field has less than the specified number of characters,
-the result is written right adjusted and padded to the given
+the result is normally written right adjusted and padded to the given
size. For example, @samp{%9B} prints the right adjusted month name in
-a field of width 9.
+a field of width 9. Nanoseconds are left adjusted, and are truncated
+or padded to the field width.
An optional modifier can follow the optional flag and width
specification. The modifiers are:
--
2.25.4
Re: Fix memleak in getdelim.m4
Hi Bruno, On 18.05.20 21:44, Bruno Haible wrote: > Hi Tim, > >>> The way to determine the answer is: >>> 1. Create a test dir of all gnulib modules. >>> 2. Configure it with --config-cache. >>> 3. Configure it with --config-cache and your sanitizer options. >>> 4. Compare the generated config.cache and config.status files. >> >> I am short on time and would like to prevent being distracted too much > > Everyone here is probably in the same situation... > >> If you could give me a quick instruction on how to do 1. > > I typically use this command: > > rm -rf ../testdir-all; ./gnulib-tool --create-testdir --dir=../testdir-all > --single-configure > >> I'll happily >> go for steps 2-4. I already have a fresh cloned gnulib locally. > > Thanks! We can then go through the findings one by one. With my getdelim patch applied, this is the summary of sanitizer findings: $ egrep 'SUMM|checking' config.log|grep -B1 SUMM configure:14038: checking for working C stack overflow detection SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change conftest.c:379:30 in -- configure:36833: checking whether memmem works SUMMARY: UndefinedBehaviorSanitizer: invalid-null-argument conftest.c:513:32 in -- configure:55268: checking whether fchownat works with AT_SYMLINK_NOFOLLOW SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change conftest.c:812:50 in configure:55326: checking whether fchownat works with an empty file name SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change conftest.c:817:37 in -- configure:67322: checking whether glob lists broken symlinks SUMMARY: AddressSanitizer: 37 byte(s) leaked in 2 allocation(s). -- configure:94107: checking for working re_compile_pattern SUMMARY: AddressSanitizer: 20072 byte(s) leaked in 116 allocation(s). The lzip'ed tar archive with all 4 files is 137k. Is it ok to send it here or do you better like via PM ? Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Fix memleak in getdelim.m4
Hi Bruno, On 20.05.20 00:46, Bruno Haible wrote: > Hi Tim, > >>> rm -rf ../testdir-all; ./gnulib-tool --create-testdir >>> --dir=../testdir-all --single-configure >> >> This results in: >> >> executing autopoint --force >> autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac >>file requires the infrastructure from gettext-0.20 but >> this version >>is older. Please upgrade to gettext-0.20 or newer. >> autopoint: *** Stop. > > You may try to pass '--avoid=gettext' to overcome this. ./configure --config-cache ends (stops ?) with The BISON_I18N macro is used without being preceded by AM_GNU_GETTEXT. $ ls -la config.cache -rw-r--r-- 1 tim tim 0 Mai 20 20:40 config.cache Is that expected ? And I see this output here as well: gnulib-tool: warning: module euidaccess depends on a module with an incompatible license: group-member > >> As Debian unstable is at gettext 0.19.8.1, I tried to build gettext from >> git master. This results in >> >> make[7]: Entering directory >> '/home/tim/src/gettext/gettext-tools/examples/tmp-hello-pascal' >> make[7]: warning: jobserver unavailable: using -j1. Add '+' to parent >> make rule. >> LOCALEDIR='/usr/local/share/locale' /usr/bin/ppcx64 -o./hello ./hello.pas >> Free Pascal Compiler version 3.0.4+dfsg-23 [2019/11/25] for x86_64 >> Copyright (c) 1993-2017 by Florian Klaempfl and others >> Target OS: Linux for x86-64 >> Compiling ./hello.pas >> hello.pas(9,6) Fatal: Can't find unit gettext used by hello >> Fatal: Compilation aborted >> make[7]: *** [Makefile:798: hello.rsj] Error 1 >> >> >> Is it really needed to fail the whole build just because a *PASCAL* >> example doesn't compile ? > > I may sound a bit old-fashioned when I recommend tarballs over building from > git checkouts. But sometimes it has its advantages. gettext 0.20.2 is not > that old. [1] > > Bruno > > [1] https://ftp.gnu.org/gnu/gettext/gettext-0.20.2.tar.gz I will install that version and try again. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [PATCH] nstrftime: better width support for %N, %z
On Friday, December 6, 2019 11:51:31 PM CEST Paul Eggert wrote: > * lib/nstrftime.c (width_add, width_add1, width_cpy): > New macros, which generalize ‘add’, ‘add1’, ‘cpy’ by adding > a new WIDTH parameter. > (add, add1, cpy): Use these macros. > (width_add): Do not treat digits == 0 as a special case, > do not pad if padding is ‘-’, and do not use a negative width. > (__strftime_internal): Redo formatting of nanoseconds and numeric > timezones to avoid buffer misuse in unusual cases, and so that > widths make more sense. Add support for widths greater than 9 to > the %N format; they are zero filled on the right. > * tests/test-nstrftime.c (posixtm_test): Add a %12N test. This change caused the output of `date +%-N` to change in coreutils-8.32. coreutils-8.31: $ date +%-N -d 0:0:0.012345 12345000 coreutils-8.32: $ date +%-N -d 0:0:0.012345 012345 The change broke scripts relying on the previous date's output: https://github.com/kata-containers/runtime/issues/2692#issuecomment-631404726 If the change is intended, the documentation of `date` should be updated because it still says: ‘%N’ nanoseconds (‘0’...‘9’). This is a GNU extension. ‘-’ (hyphen) Do not pad the field; useful if the output is intended for human consumption. This is a GNU extension. Kamil
Re: copyright in Germany
Hi Marc, > As far as I know (but I am, luckily, not a lawyer either), it is the > common legal opinion that Art. 5.(3) Grundgesetz implies that the > "Nutzungsrechte" are not being implicitly assigned from a professor to > the university ([2]). So the university cannot claim that some of my > works are theirs. Indeed, [2] page 19 is clear. [3] says the same thing. > In any case, I even have a letter from the > university saying basically this. Even better! Then you are free to sign copyright assignment papers with any legal entity, such as the FSF. > Unfortunately, the FSF lawyers don't > accept the German text (I tried to contribute to GCC once) because > they don't have the manpower to verify it; now I have to persuade the > university lawyers to sign the FSF provided text. Why the hassle? Once you know - and you gave a citation from the ministery of education - that the copyright of your works is with you, you don't need confirmation from either the FSF or your university. The copyright assignment only needs _your_ signature, then. Bruno [2] https://www.bmbf.de/upload_filestore/pub/Handreichung_UrhWissG.pdf [3] https://blogs.hrz.tu-freiberg.de/oersax/urheberrecht-des-wissenschaftlichen-personals-an-hochschulen/
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Please see the attached patch file, my first attempt (and first contribution to Gnulib). Am Di., 19. Mai 2020 um 17:51 Uhr schrieb Paul Eggert : > > On 5/19/20 8:35 AM, Marc Nieper-Wißkirchen wrote: > >> It is, however, locale-dependent, and there is no "c_dtoastr" > >> version as there is a "c_strtod". (Could we get such a wrapper?) > > Or a version "c_dtoastr" that uses "c_snprintf" and "c_strtod" internally. > > Yes, that'd be good to have. Could you write that? From f4308c51cc73a8b1397c436f8dd667e15d6d0b9b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc=20Nieper-Wi=C3=9Fkirchen?= Date: Wed, 20 May 2020 13:59:31 +0200 Subject: [PATCH] New module to accurately print (long) doubles in C locale. --- ChangeLog| 18 + MODULES.html.sh | 2 ++ lib/c-dtoastr.c | 3 +++ lib/c-ldtoastr.c | 3 +++ lib/ftoastr.c| 23 +++- lib/ftoastr.h| 6 + modules/c-dtoastr| 27 +++ modules/c-dtoastr-tests | 18 + modules/c-ldtoastr | 27 +++ modules/c-ldtoastr-tests | 18 + tests/test-c-dtoastr.c | 58 tests/test-c-dtoastr.sh | 15 +++ tests/test-c-ldtoastr.c | 58 tests/test-c-ldtoastr.sh | 15 +++ 14 files changed, 285 insertions(+), 6 deletions(-) create mode 100644 lib/c-dtoastr.c create mode 100644 lib/c-ldtoastr.c create mode 100644 modules/c-dtoastr create mode 100644 modules/c-dtoastr-tests create mode 100644 modules/c-ldtoastr create mode 100644 modules/c-ldtoastr-tests create mode 100644 tests/test-c-dtoastr.c create mode 100644 tests/test-c-dtoastr.sh create mode 100644 tests/test-c-ldtoastr.c create mode 100644 tests/test-c-ldtoastr.sh diff --git a/ChangeLog b/ChangeLog index 1c39b92e6..becb40eec 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,21 @@ +2020-05-20 Marc Nieper-Wißkirchen + + c-dtoastr: new module + c-ldtoastr: new module + These modules provide the same functionality as the modules + dtoastr and ldtoastr except for the formatting taking place in the + C locale. + * MODULES.html.sh: Add c-dtoastr and c-ldtoastr. + * lib/c-dtoastr.c, lib/c-ldtoastr.c: New files + * lib/ftoastr.c: Prefix exported functions when the macro C_LOCALE is + defined. Use c_snprintf and c_strtod/c_strtold instead of + snprintf and strtod/strtold whhen the macro C_LOCALE is defined. + * lib/ftoastr.h: Add prototypes for c_dtoastr and c_ldtoastr. + * modules/c-dtoastr, modules/c-dtoastr-tests, modules/c-ldtoastr, + modules/c-ldtoastr-tests: New files. + * tests/test-c-dtoastr.c, tests/test-c-dtoastr.sh, + tests-c-ldtoastr.c tests-c-ldtoastr.sh: New files. + 2020-05-19 Paul Eggert ftoastr: fix ifndef typo diff --git a/MODULES.html.sh b/MODULES.html.sh index 318a15a1d..280bd14da 100755 --- a/MODULES.html.sh +++ b/MODULES.html.sh @@ -2319,6 +2319,8 @@ func_all_modules () func_echo "$element" func_begin_table + func_module c-dtoastr + func_module c-ldtoast func_module dtoastr func_module ftoastr func_module intprops diff --git a/lib/c-dtoastr.c b/lib/c-dtoastr.c new file mode 100644 index 0..b57524fb1 --- /dev/null +++ b/lib/c-dtoastr.c @@ -0,0 +1,3 @@ +#define LENGTH 2 +#define C_LOCALE 1 +#include "ftoastr.c" diff --git a/lib/c-ldtoastr.c b/lib/c-ldtoastr.c new file mode 100644 index 0..5446fc3e7 --- /dev/null +++ b/lib/c-ldtoastr.c @@ -0,0 +1,3 @@ +#define LENGTH 3 +#define C_LOCALE 1 +#include "ftoastr.c" diff --git a/lib/ftoastr.c b/lib/ftoastr.c index 7a7d4113c..47a83152e 100644 --- a/lib/ftoastr.c +++ b/lib/ftoastr.c @@ -33,20 +33,28 @@ #include #include +#ifdef C_LOCALE +# include "c-snprintf.h" +# include "c-strtod.h" +# define PREFIX(name) c_ ## name +#else +# define PREFIX(name) name +#endif + #if LENGTH == 3 # define FLOAT long double # define FLOAT_DIG LDBL_DIG # define FLOAT_MIN LDBL_MIN # define FLOAT_PREC_BOUND _GL_LDBL_PREC_BOUND -# define FTOASTR ldtoastr +# define FTOASTR PREFIX (ldtoastr) # define PROMOTED_FLOAT long double -# define STRTOF strtold +# define STRTOF PREFIX (strtold) #elif LENGTH == 2 # define FLOAT double # define FLOAT_DIG DBL_DIG # define FLOAT_MIN DBL_MIN # define FLOAT_PREC_BOUND _GL_DBL_PREC_BOUND -# define FTOASTR dtoastr +# define FTOASTR PREFIX (dtoastr) # define PROMOTED_FLOAT double #else # define LENGTH 1 @@ -54,7 +62,7 @@ # define FLOAT_DIG FLT_DIG # define FLOAT_MIN FLT_MIN # define FLOAT_PREC_BOUND _GL_FLT_PREC_BOUND -# define FTOASTR ftoastr +# define FTOASTR PREFIX (ftoastr) # define PROMOTED_FLOAT double # if HAVE_STRTOF # define STRTOF strtof @@ -65,13 +73,16 @@ may generate one or two extra digits, but that's better than not working at all. */ #ifndef STRTOF -# define STRTOF strtod +# define STRTOF PREFIX (strtod) #endif /* On hosts where it's not known that snprintf works, use sprintf to implement the subset
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Am Mi., 20. Mai 2020 um 00:37 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > for output, the shortest rounded > > representation that still reads back accurately has to be selected. > > ... > > A simple algorithm is given by Aubrey Jaffer in [1]. > > > > [1] http://people.csail.mit.edu/jaffer/III/EZFPRW This was just one, which I liked because of its simplicity. (And because it is written in my favorite programming language.) [...] > There are several other algorithms for this purpose. There is also the new Ryu algorithm by Ulf Adams, see [2]. Interestingly, he has found some problems in Jaffer's algorithm, see the paper [3]. [...] > Then there's also the algorithm, by Michael Stoll and me (1990), > in GNU clisp and CLN (based on multiprecision arithmetic, not hardware > floats). I didn't know this; I will check this out. The initial version of "c_dtoastr" will, however just work as "dtoastr" does. Marc -- [2] https://github.com/ulfjack/ryu [3] https://dl.acm.org/doi/10.1145/3296979.3192369
Re: copyright in Germany
Am Mi., 20. Mai 2020 um 00:15 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > If the code you write is not related to your job, that is, if you are not > being paid to write it, then the "Nutzungsrechte" belong to you - regardless > whether your employment contract says otherwise. This is guaranteed by > Art. 2.(1) Grundgesetz. (*) > > Often it is clear whether something is related to your job. For example, > if you have a manager that tells you what to develop. (*) > > If your employer is a university [1], things are less clear. In the past, > some universities have been strict and claimed that the works of their > professors and researchers belong to them. This has changed somewhat around > 2000-2005: The slogan "public money - public code" has convinced at least > some universities to allow the code that came out of research projects to > be released under Open Source licenses. In any case, this topic is subject > to negotiation between the professors/researchers and the university. As far as I know (but I am, luckily, not a lawyer either), it is the common legal opinion that Art. 5.(3) Grundgesetz implies that the "Nutzungsrechte" are not being implicitly assigned from a professor to the university ([2]). So the university cannot claim that some of my works are theirs. In any case, I even have a letter from the university saying basically this. Unfortunately, the FSF lawyers don't accept the German text (I tried to contribute to GCC once) because they don't have the manpower to verify it; now I have to persuade the university lawyers to sign the FSF provided text. > [1] > https://www.uni-augsburg.de/de/fakultaet/mntf/math/prof/alg/arbeitsgruppe/nieper-wisskirchen/ Correct. Thanks, Marc -- [2] https://www.bmbf.de/upload_filestore/pub/Handreichung_UrhWissG.pdf
