On 2023-10-09 06:48, Pádraig Brady wrote:
An incremental patch attached to use xxhash128 (0.8.2)
shows a good improvement (note avx2 being used on this cpu):
xxhash128 is not a cryptographic hash function, so it doesn't attempt to
be random. Of course most people won't care - it's random "eno
On 26/02/2024 06:44, Yann Collet wrote:
* xxhash128 is not a cryptographic hash function, so it doesn't attempt tobe
random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring this property.
It’s even tested with Prac
* xxhash128 is not a cryptographic hash function, so it doesn't attempt to
be random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring this property.
It’s even tested with PractRand, and it could be used as a good ra
On Feb 25 2024, Paul Eggert wrote:
> +/* Dynamically link the crypto library, if it needs linking. */
> +static void
> +link_libcrypto (void)
> +{
> +#if DLOPEN_LIBCRYPTO && HAVE_OPENSSL_MD5
> + void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
That only works if libopenssl-devel
On 26/02/2024 17:11, Andreas Schwab wrote:
On Feb 25 2024, Paul Eggert wrote:
+/* Dynamically link the crypto library, if it needs linking. */
+static void
+link_libcrypto (void)
+{
+#if DLOPEN_LIBCRYPTO && HAVE_OPENSSL_MD5
+ void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
Pádraig Brady wrote:
> >> + void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
> >
> > That only works if libopenssl-devel is installed.
>
> Good spot.
> I'd already pushed a fix for this at:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
Does this work
On 26/02/2024 17:39, Bruno Haible wrote:
Pádraig Brady wrote:
+ void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
That only works if libopenssl-devel is installed.
Good spot.
I'd already pushed a fix for this at:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3
On Feb 26 2024, Pádraig Brady wrote:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
It's still bad as it adds a hidden dependency that is invisible to rpm.
Also, the regexp in the sed command contains unquoted uses of '.' that
are supposed to be matched literally.
--
On 2024-02-26 06:12, Pádraig Brady wrote:
On 26/02/2024 06:44, Yann Collet wrote:
* xxhash128 is not a cryptographic hash function, so it doesn't
attempt tobe random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring
On 26/02/2024 18:06, Andreas Schwab wrote:
On Feb 26 2024, Pádraig Brady wrote:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
It's still bad as it adds a hidden dependency that is invisible to rpm.
Right. In practice though since coreutils also links libcrypto
for
Collin Funk wrote:
> Adding the two attached files to the root directory of gnulib should
> adjust the warnings to the agreed upon coding style (as far as
> pycodestyle and pylint are concerned). It works with Emacs and Eglot
> using pylsp. I assume other editors should work similarly.
>
> Not sur
Hi Collin,
> From what I could understand, it seems that upon seeing that the mode
> is "import", the specified_modules is set with the unsorted list of
> modules [1]. Then that variable is sorted before it is used [2]. Could
> you confirm that I am understanding this correctly?
Yes, I confirm. S
Hi Bruno,
On 2/26/24 12:38 PM, Bruno Haible wrote:
> For pycodestyle, a file named '.pycodestyle' would be OK with me as well,
> if that works. If not, then how about
> - submitting a feature request to the pycodestyle developers, so that
> '.pycodestyle' is accepted in addition to of 'pycod
Hi Collin,
> I think that it would be best to just shove all the Python mess in
> that subdirectory since it is a work-in-progress and is safe to be
> ignored by gnulib users.
I tend to agree. Even after it is finished, it will still be useful
to have all Python sources in one directory: it makes
Hi Bruno,
On 2/26/24 2:54 PM, Bruno Haible wrote:
> I tend to agree. Even after it is finished, it will still be useful
> to have all Python sources in one directory: it makes it easy to do
> a "grep something *.py".
True. I've already run into this a few times. :)
> Done:
>
> 2024-02-26 Bruno
Hi Collin,
> > You can now submit the two configuration files in the pygnulib/ directory.
> > That's the proper place, not the root directory of gnulib.
>
> Done.
Thanks; I applied both patches.
But now we have the desired configurations of pycodestyle and pylint
in two places: in comments and
Hi Bruno,
On 2/26/24 6:38 PM, Bruno Haible wrote:
> But now we have the desired configurations of pycodestyle and pylint
> in two places: in comments and in the config files. With the promise that
> they will get out of sync in the future. To avoid this, let me
> update the comments...
True. I th
These two TODO entries were pretty simple. One of the ChangeLog
entries listed to a test case Bruno wrote that worked for testing both
of them.
[collin@debian gnulib]$ gnulib-tool.py --create-testdir --dir=testdir-all
--single-configure
module parse-datetime2 depends on a module with an incompati
18 matches
Mail list logo
