On Mon, Apr 1, 2024 at 12:19 AM Paul Eggert wrote:
>
> On 2024-03-31 18:07, NightStrike wrote:
> > I don't quite understand your animosity here.
>
> I don't see any animosity in Bruno's comments. Clearly the system you're
> talking about has a severe performance bug, and the question is whether
>
On 2024-03-31 12:45, Bruno Haible wrote:
I think you must ask this to yourself:
- What caused you to change the unit tests on 2023-09-04?
- How is the musl version that you used on that date configured?
What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
- Did you
On 2024-03-31 18:07, NightStrike wrote:
I don't quite understand your animosity here.
I don't see any animosity in Bruno's comments. Clearly the system you're
talking about has a severe performance bug, and the question is whether
it's worth our limited time to port to buggy systems like
NightStrike wrote:
> I don't quite understand your animosity here. Gnulib is supposed to help
> porting to systems, and I'm highlighting a situation where it doesn't work.
> Why such antagonism vs trying to understand why it doesn't work? Surely a
> configure test that causes the RCU to spin for
On Sun, Mar 31, 2024, 19:02 Bruno Haible wrote:
> NightStrike wrote:
> > In my setup, there is no sandbox.
> > ...
> > Later on, there are data points that show that the algorithm is bad even
> > outside the sandbox, it's just less noticeable. And as mentioned, on
> btrfs,
> > it's crazy.
>
> If
On 3/31/24 5:32 PM, Collin Funk wrote:
> The top part seems like a sorting issue maybe?
This patch fixes this issue.
I was a bit suspicious of this sorted() call previously, but left it
because I had no proof it was incorrect.
diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py
index
Collin Funk wrote:
> > The second is just a simple missing " character.
>
> Here is a patching adding this character.
Thanks; applied.
Bruno
On 3/31/24 5:32 PM, Collin Funk wrote:
> The second is just a simple missing " character.
Here is a patching adding this character.
CollinFrom 30d06b655a9a5172aab059ddab297bef72cd Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sun, 31 Mar 2024 17:41:03 -0700
Subject: [PATCH]
Hi Bruno,
On 3/31/24 4:11 PM, Bruno Haible wrote:
> Cool! Now, it makes sense to
> - look at the two remaining failures in info-tests,
Yes, I was going to start looking at those now. If I remember
correctly they should be simple to fix.
> - try more packages from the users.txt list. Is
Hi Bruno,
On 3/31/24 5:12 AM, Bruno Haible wrote:
> But when I look at your patch now, I see that it can be done in an even
> simpler
> way:
> - From the path and the module name, you compute the directory.
> The only use of that directory is to compute the path again.
> - This directory
Hi Collin,
> Thanks for fixing those. Now all of the create-tests/* and
> import-tests/* are working for me.
Cool! Now, it makes sense to
- look at the two remaining failures in info-tests,
- try more packages from the users.txt list. Is Bison passing meanwhile?
Bruno
Hi Bruno,
Thanks for fixing those. Now all of the create-tests/* and
import-tests/* are working for me.
On 3/31/24 2:52 PM, Bruno Haible wrote:
>> The [gperf] 3.2 release commit didn't have a git tag and isn't on GNU's ftp
>> server. Not sure if you forgot or if this was intended, so I figured
NightStrike wrote:
> In my setup, there is no sandbox.
> ...
> Later on, there are data points that show that the algorithm is bad even
> outside the sandbox, it's just less noticeable. And as mentioned, on btrfs,
> it's crazy.
If an algorithm is fast on ext4 and slow on btrfs: what is the
On Sun, Mar 31, 2024, 18:44 Bruno Haible wrote:
> NightStrike wrote:
> > See https://bugs.gentoo.org/447970 for extra details. While this
> > gentoo report has a workaround posted just a few months ago, it seems
> > that the test itself is faulty, as a failure mode should not be to
> > hang the
NightStrike wrote:
> See https://bugs.gentoo.org/447970 for extra details. While this
> gentoo report has a workaround posted just a few months ago, it seems
> that the test itself is faulty, as a failure mode should not be to
> hang the entire computer.
No. What I understand from the above
See https://bugs.gentoo.org/447970 for extra details. While this
gentoo report has a workaround posted just a few months ago, it seems
that the test itself is faulty, as a failure mode should not be to
hang the entire computer.
When running this configure test on my particular system, a NAS
Hi Collin,
> Here is what I see for the import tests at the moment:
>
> ./test-oath-toolkit-1.out tmp384427-out differ: byte 561, line 24
> --- ./test-oath-toolkit-1.out 2024-03-30 14:11:44.586946254 -0700
> +++ tmp384427-out 2024-03-30 17:14:43.330203522 -0700
> @@ -21,6 +21,7 @@
>
Pádraig Brady wrote:
> > If a string starts with a sequence that requires $'' quoting followed
> > by a \' and then another charactrer requiring $'' quoting, the '$' at
> > the start of the quoted string ends up missing:
> >
> > $ env printf '%q\n' $'\1\'\2'
> > '\001'\'''$'\002'
>
>
On 31/03/2024 02:16, Grisha Levit wrote:
If a string starts with a sequence that requires $'' quoting followed
by a \' and then another charactrer requiring $'' quoting, the '$' at
the start of the quoted string ends up missing:
$ env printf '%q\n' $'\1\'\2'
'\001'\'''$'\002'
Indeed
Adept's Lab wrote:
> >> test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
Thanks for the report. I reproduce it with gnulib testdirs
$ rm -rf ../testdir1; ./gnulib-tool --create-testdir --dir=../testdir1
--single-configure canonicalize-lgpl
$ rm -rf ../testdir2;
On 3/31/24 05:22, Pádraig Brady wrote:
On 31/03/2024 10:02, Adept's Lab wrote:
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
This is on musl 1.1.24 as detailed at:
If a string starts with a sequence that requires $'' quoting followed
by a \' and then another charactrer requiring $'' quoting, the '$' at
the start of the quoted string ends up missing:
$ env printf '%q\n' $'\1\'\2'
'\001'\'''$'\002'
Hi Collin,
> Here is the very simple fix:
>
> diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py
> index c3a7597d02..1fc43bfdff 100644
> --- a/pygnulib/GLImport.py
> +++ b/pygnulib/GLImport.py
> @@ -1241,7 +1241,8 @@ AC_DEFUN([%s_FILE_LIST], [\n''' % macro_prefix
> tmpfile
Hi Collin,
> Not sure why I didn't do this in the first place to be honest...
> Here is two patches. Most of the change is in these lines:
>
> if self.exists(module):
> path, istemp = self.filesystem.lookup(joinpath('modules',
> module))
> -result =
On 31/03/2024 10:02, Adept's Lab wrote:
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
This is on musl 1.1.24 as detailed at:
https://github.com/coreutils/coreutils/issues/83
On 30/03/2024 23:38, Bruno Haible wrote:
Hi Pádraig,
As a matter of interest, where did you get the figure that
94% of users have a $TERM set to xterm.* ?
Personal guesses / estimations :-D.
+def get_terminfo_string(capability: str) -> str:
+'''Returns the value of a string-type
Collin Funk wrote:
> I imagine many of those times the only purpose of 'sort' was to make
> sure that 'join' worked since it requires the field being joined on to
> be sorted right?
Correct, that was one motivation to use 'sort'. The other one was to
remove duplicates, because I did not know of
27 matches
Mail list logo
