Here is a patch fixing another item in gnulib-tool.py.TODO. It is more
complex than the original since the change uncovered a few issues.
When changing GLModule.isTests() to check the Applicability of the
module:
File "/home/collin/.local/src/gnulib/pygnulib/GLModuleSystem.py", line 501,
in ge
On 3/17/24 6:31 PM, Bruno Haible wrote:
> Well, one can also see it the other way around: With single quotes
> everywhere, it's more consistent.
LOL, fair enough.
> Feel free to find more arguments for one or the other. I'm undecided,
> but it would be a major change, so one should think about it
Collin Funk wrote:
> Emacs and vim both agree at least.
>
> def test_emacs(value):
> '''This is a Python comment.
> Here1'''
>
> def test_vim(value):
> '''This is a Python comment.
> Here2'''
Likewise with kate and Eclipse.
> Since we have agreed upon single quotes for actual co
On 3/17/24 5:57 PM, Bruno Haible wrote:
> Yes, we can do that. In the commit today, however, I wanted to close one issue
> without possibly opening another one.
No worries, there is no rush.
> It is also worth testing various editors (gedit, kate, emacs, eclipse,
> PyCharm, etc.): Where do they p
Hi all,
> On Mar 17, 2024, at 5:09 PM, Bruno Haible wrote:
>
> Hi Gordon,
>
>>> It seems to me that many GNU packages (coreutils, emacs, gettext, sed, at
>>> least) include only for the purpose of ACLs.
>>
>> That was why I was trying to make them work, yes. The libacl package
>> requires
Hi Collin,
> Unrelated to the newline change itself, but something I noticed that I
> would like to bring up:
>
> def lines_to_multiline(lines):
> '''lines_to_multiline(List[str]) -> str
>
> Combine the lines to a single string, terminating each line with a newline
> character.'''
>
Hi Bruno,
On 3/17/24 4:49 PM, Bruno Haible wrote:
> It is not good if, each time we deal with a list of lines, we have to give
> extra thought to the case of 0 lines. This is only a recipe for
> inconsistencies.
Yes, this change looks much better. Having 'if len(lines) > 0: ...'
everwhere looks
Collin Funk [2024-03-17 15:03 -0700] wrote:
> +if len(cleansed) > 0:
> +return '\n'.join(cleansed)
> +else:
> +return ''
FWIW '\n'.join([]) is '', so perhaps it isn't necessary to check
len(cleansed).
Thanks,
--
Basil
Hi Gordon,
> > It seems to me that many GNU packages (coreutils, emacs, gettext, sed, at
> > least) include only for the purpose of ACLs.
>
> That was why I was trying to make them work, yes. The libacl package
> requires them and is in turn taken advantage of if present by a great many
> oth
Collin Funk wrote:
> > FWIW '\n'.join([]) is '', so perhaps it isn't necessary to check
> > len(cleansed).
>
> Oops, you are correct. Thanks, that should make the code look nicer. I
> think I originally had '\n'.join(cleansed) + '\n', where the goal was
> to remove the + '\n' but I removed it. Goo
Hi all,
On Mar 17, 2024, at 2:32 PM, Bruno Haible wrote:
>
>> Is this a thing that anyone would want submitted to GNUlib?
>
> It seems to me that many GNU packages (coreutils, emacs, gettext, sed, at
> least) include only for the purpose of ACLs.
That was why I was trying to make them work, y
Hi Collin,
> This patch is just one added function. Can you double check that I
> understood your 'sed' wizardry correctly Bruno?
Yes. You even added support for nested 'if's, which the original doesn't have.
Nice.
> I placed the sed command and a modified version of my Python function in
> two
On 3/17/24 3:21 PM, Basil L. Contovounesios wrote:
> FWIW '\n'.join([]) is '', so perhaps it isn't necessary to check
> len(cleansed).
Oops, you are correct. Thanks, that should make the code look nicer. I
think I originally had '\n'.join(cleansed) + '\n', where the goal was
to remove the + '\n' b
This patch is just one added function. Can you double check that I
understood your 'sed' wizardry correctly Bruno?
I read the GNU sed info page a bit, but I could have missed something.
My normal usage of sed is using 's/pattern/replacement/g' and hoping
that it doesn't break too much. :)
I place
Hi Gordon,
> Some time ago, I got a rudimentary version of a GNU/Linux-compatible
> "sys/xattr.h" module working on my Mac. (For those unfamiliar with the
> trivia involved, Mac OS includes eight of the twelve xattr functions
> natively, but with extra parameters that simultaneously render them
>
Collin Funk wrote:
> This patch removes a few newlines in the diff between gnulib-tool.sh
> and gnulib-tool.py.
Thanks; applied.
Bruno
Hi all,
Some time ago, I got a rudimentary version of a GNU/Linux-compatible
"sys/xattr.h" module working on my Mac. (For those unfamiliar with the
trivia involved, Mac OS includes eight of the twelve xattr functions
natively, but with extra parameters that simultaneously render them
not directly
This patch removes a few newlines in the diff between gnulib-tool.sh
and gnulib-tool.py.
Here is the current diff of Emacs merge-gnulib script with all the
gnulib-tool.py updates. Far better than a month ago. :)
# Add gnulib changes not in Emacs yet.
$ env GNULIB_TOOL_IMPL="sh" ./admin/merge-gnul
Hi Paul,
Not sure if this is best suited for a tar mailing list, but since you
wrote stat-time and are a tar maintainer I figured you could help.
But when following Bruno's advice for downloading Eclipse to work on
gnulib-tool.py I ran into this:
$ tar -xf eclipse-inst-jre-linux64.tar.gz
gtar:
Collin Funk wrote:
> Just adds ensure_writable after copying files.
Thanks! Applied.
Bruno
Bruno Haible writes:
> No, what I mean is just to take a snapshot. For the reasons explained in
> https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00109.html .
Ah, I see. I misunderstood the "frozen-in-time set of gnulib modules",
but that message explains it. Thanks.
Collin
Hi Collin,
> > The gnulib-tool test suite will need this option, in order to use the
> > newest gnulib-tool with a frozen-in-time set of gnulib modules.
>
> By this do you mean if a project has a old gnulib git submodule? I think
> I ran into this with GNU Bison for example. It hasn't had commits
Hi Bruno,
Bruno Haible writes:
> The gnulib-tool test suite will need this option, in order to use the
> newest gnulib-tool with a frozen-in-time set of gnulib modules.
By this do you mean if a project has a old gnulib git submodule? I think
I ran into this with GNU Bison for example. It hasn't
Pretty small patch. Just adds ensure_writable after copying files.
Collin
>From 224c3c910f88d22b825ad93e189ef6102487ad5a Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sun, 17 Mar 2024 10:03:54 -0700
Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 62.
Follow gnulib-tool chan
The gnulib-tool test suite will need this option, in order to use the
newest gnulib-tool with a frozen-in-time set of gnulib modules.
2024-03-17 Bruno Haible
gnulib-tool: Add undocumented option --gnulib-dir.
* gnulib-tool.sh: Accept --gnulib-dir=... option.
* pygnulib
Hi Collin,
All three patches applied. Thanks!
> And then diff'ing the shell and python output before part 60, after part
> 60, and then after this patch:
>
> $ ls -l *.diff
> -rw-r--r--. 1 collin collin 1745735 Mar 16 20:00 0001-pre60.diff
> -rw-r--r--. 1 collin collin 1745735 Mar 16 20:03 0002-
26 matches
Mail list logo
