Collin Funk wrote:
> Lets just use os.path.isabs() and let it deal with
> platform related stuff.
OK.
I assume that if someone uses gnulib-tool with Cygwin, and has a
native Windows Python installation, they will report problems. Then
we can decide what to do. (Probably there are few people who
Collin Funk wrote:
> Good point. I've pushed this patch adding a set() around that one call.
Thanks.
> This comment is interesting:
>
> # We need NO_EXPENSIVE_WARN_CFLAGS, because with gcc 13, the compilation of
> # libxml/parser.c requires 1.9 GB of RAM with -fanalyzer, as opposed to
> #
Bruno Haible writes:
>> The lists there seem small enough that I doubt it matters too much.
>
> Bad excuse :) You haven't seen this module yet:
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gnulib-local/modules/libxml;h=dc6404c59362e5d17885a211a61a4eed99da6642;hb=HEAD#l130
Hi Collin,
> Oops yes. Good point, I must have overlooked that. It appears that it
> will be O(n²). In this loop [1] and the else branch of
> "PyAnySet_Check(other)" [2].
Thanks for checking.
> The lists there seem small enough that I doubt it matters too much.
Bad excuse :) You haven't seen
Hi Bruno,
Bruno Haible writes:
> The variable mentioned_files in pygnulib/GLModuleSystem.py line 599
> was a set and is now a list. Is the expression
> lib_files.difference(mentioned_files)
> therefore being evaluated more slowly (as O(n²) where it was O(n) before)?
> That is, does Python
Hi Collin,
> Indirectly this also fixes two issues. The first is the same issue as
> yesterdays patch. Variables with a trailing comment, e.g.
>
> lib_SOURCES += file.c file.h # comment
>
> are not matched. As far as I can tell none of the module descriptions
> have this comment style but
Collin Funk wrote:
> Thanks, I've applied the attached patch fixing that regular expression.
Thanks. Now it appears to work fine.
Bruno
Bruno Haible writes:
>> > Thanks for this recipe. I think this is worth a unit test, since it
>> > is a special case that is otherwise not tested.
>>
>> Agreed. I can add one later today.
>
> I added it already.
Thanks, I've applied the attached patch fixing that regular expression.
Also,
Hi Collin,
> > Thanks for this recipe. I think this is worth a unit test, since it
> > is a special case that is otherwise not tested.
>
> Agreed. I can add one later today.
I added it already.
Bruno
Hi Bruno,
Bruno Haible writes:
> Thanks for this recipe. I think this is worth a unit test, since it
> is a special case that is otherwise not tested.
Agreed. I can add one later today.
> The regular expression doesn't seem right:
[...]
> The point of using a non-greedy operator is to not
Hi Collin,
> Not sure how this didn't get found sooner, to be honest. Here is an
> example of the bug:
>
> $ git clone https://git.savannah.gnu.org/git/rcs.git
> $ cd rcs
> $ git checkout next
> $ sh -x autogen.sh
Thanks for this recipe. I think this is worth a unit test, since
Hi Collin,
> I've pushed the attached patch. In gnulib-tool.sh the following is
> done:
>
> ../configure || func_exit 1
> $MAKE || func_exit 1
> [...]
>
> So here we can just use sp.run([command, arg], check=True) and exit if
> an exception occurs.
Thanks. I confirm that --test now
Hi Collin,
> > Hmm. Is that refactoring, that you are imagining, intrusive? ...
>
> Depends on the specific warning being addressed. :)
>
> There are more trivial cases like GLMakeFileTable which stores
> information as a dictionary. We have a table of makefile variables:
>
> table:
I forgot to mention: the pattern to provide re-usable GitLab CI/CD
definitions that I'm inspired by is Debian's pipeline project:
https://salsa.debian.org/salsa-ci-team/pipeline/
It is easy to setup a new project to use their reusable pipeline -- just
add the CI/CD configuration file setting
Bruno Haible writes:
> gnulib-tool is used is many CI jobs. Just adding 'python3' to the
> prerequisites of such a job makes it run faster. Here are the execution
> times for a single run, before and after adding 'python3', for those
> CIs that I maintain or co-maintain. In minutes and seconds.
On 5/4/24 8:17 AM, Bruno Haible wrote:
>> For CI, I am thinking it is best to ignore the typing warnings for the
>> time being. Since gnulib-tool.py needs a bit more refactoring for that
>> to be helpful. It was written before typing was a thing. :)
>
> Hmm. Is that refactoring, that you are
Collin Funk wrote:
> For CI, I am thinking it is best to ignore the typing warnings for the
> time being. Since gnulib-tool.py needs a bit more refactoring for that
> to be helpful. It was written before typing was a thing. :)
Hmm. Is that refactoring, that you are imagining, intrusive? If it's
On 5/4/24 3:34 AM, Bruno Haible wrote:
> Yes. We cannot change the past git log, but this is one of the situations
> where changing a ChangeLog entry is adequate. Other such situations are
> obvious typos and forgotten changes.
I've pushed the attached patch adding the date to the ChangeLog
Hi Collin,
> > Can you please add, to the first line of the ChangeLog entry, a note
> > that tells us when the regression was introduced? Such as
> >(regression 2024-xx-xy)
> > or
> >(regr. yesterday)
> ...
> I've never modified a ChangeLog entry before. Is the proper way to
> just modify
On 5/3/24 6:03 PM, Bruno Haible wrote:
>> In main.py a call to mkdtemp() was the use of the 'tempfile' module
>> prefix.
>
> Oh, that would have led to a runtime error, right?
Yes, it would only be seen if it entered the section of code where
modules have an incompatible license. So the program
Hi Collin,
> In main.py a call to mkdtemp() was the use of the 'tempfile' module
> prefix.
Oh, that would have led to a runtime error, right?
Can you please add, to the first line of the ChangeLog entry, a note
that tells us when the regression was introduced? Such as
(regression 2024-xx-xy)
Hi Collin,
> ... It seems like a pain to track
> down every code path that can lead to 'sys.exit()' or 'exit()' with a
> temporary directory still existing.
> ...
> Therefore, we can use tempfile.TemporaryDirectory as a context manager
> and let Python cleanup for us [1]:
>
> def
Collin Funk wrote:
> I noticed that the file names when running 'patch' on test-driver
> weren't quoted. I guess that would cause problems in practice if you
> used spaces in directories
Indeed. Thanks for fixing that!
> Since we assume POSIX shells we can just use shlex.quote() to deal
> with
Collin Funk wrote:
> Since 'module' is pretty much always a GLModule, I have renamed these
> to 'module_name'.
+1
On 5/1/24 1:51 AM, Collin Funk wrote:
> I pushed this patch removing getName() from GLModule, preferring
> it's name variable directly.
This patch fixes a mistake I made in two functions.
They took a 'module' argument which was a str. I must have not looked
at the type hint...
Since 'module' is
Hi Bruno,
On 4/30/24 12:44 AM, Bruno Haible wrote:
> Yes, it's a good sign, and most probably a consequence of the testing
> with various packages [1][2] that we did.
And the test suite that you wrote. Many thanks for working on that for
me.
Also, thanks for testing all the projects who use
Collin Funk wrote:
> Hopefully no other bug reports for gnulib-tool.py since the info-gnu
> announcement other than the one I just patched is a good sign? :)
Yes, it's a good sign, and most probably a consequence of the testing
with various packages [1][2] that we did.
Bruno
[1]
Hi Collin,
> This patch adds type hints to the Python classes.
Looks good. Thanks!
> Same as previously done in GLFileTable that I wrote. The only new
> thing introduced is the syntax for class variables, so this line in a
> class definition:
>
> section_label_pattern = re.compile(...)
>
Hi Bruno,
On 4/27/24 8:48 AM, Bruno Haible wrote:
> Could you please look at this one? I created a megatestdir for some
> portability testing, with gnulib-tool.py (of course), and it failed
> on macOS:
Thanks for the report! I can reproduce it.
I have only had a brief look and it looks like
Hi Bruno,
On 4/26/24 2:20 AM, Bruno Haible wrote:
> However, please hold pushing patches for the next 3 days. I will be
> posting the announcement of the faster gnulib-tool in the next few
> hours; therefore I expect that several GNU package maintainers will
> give it a try for the first time in
Hi Collin,
> Most of the instance variables in GLMegaTestDir are unused. This makes
> sense since GLMegaTestDir pretty much just calls GLTestDir functions
> on a list of modules and then does some extra work afterwards.
>
> I committed this patch removing them.
Looks good. Thanks.
However,
Collin Funk wrote:
> for instance variables I
> rather put them outside __init__. It also serves as a decent place to
> add comments that don't belong in doc strings.
Yes. For instance variables that are used in several methods it would seem
odd to declare them in __init__. To me, __init__ is the
On 4/25/24 1:11 AM, Bruno Haible wrote:
> Interesting syntax. This makes the class easier to understand. You're welcome
> to do the same thing with the other classes (except for GLError.message, which
> is private to a single method).
I agree. I originally wanted to add it to GLModuleTable when I
Collin Funk wrote:
> I've applied the following patch adding a GLFileTable class as
> discussed here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00357.html
Thanks! Looks good.
> +class GLFileTable:
> +'''The GLFileTable class stores file information for the duration of
Hi Bruno,
On 4/23/24 8:37 AM, Bruno Haible wrote:
> I also checked the effect on the warnings in Eclipse: No new warnings,
> and 1 existing "unused import" warning is fixed.
>
> The patch is OK to push.
Done. Thanks!
Collin
Hi Collin,
> > OK, patch welcome. I assume that when Dmitry used this style of assignments,
> > the Python 2.7 / 3.0 imports were not so well developed as they are today.
>
> Here is a patch that removes all the module-specific variables and
> imports the functions directly.
The patch looks
Hi Bruno,
On 4/22/24 7:33 AM, Bruno Haible wrote:
> OK, patch welcome. I assume that when Dmitry used this style of assignments,
> the Python 2.7 / 3.0 imports were not so well developed as they are today.
Here is a patch that removes all the module-specific variables and
imports the functions
Hi Collin,
> I want to make the imports and use of functions from other modules
> consistent. This patch makes all files use absolute imports like
> main.py. So this:
>
>from pygnulib.GLEmiter import GLEmiter
>
> instead of:
>
>from .GLEmiter import GLEmiter
Consistency is not a good
Collin Funk wrote:
> I am still learning about the
> type hinting and type checking stuff. Overall I think it is a good
> decision though. In the past I remember finding large Python code hard
> to follow without them.
Absolutely, yes.
Bruno
Hi Bruno,
On 4/21/24 2:43 PM, Bruno Haible wrote:
> Hmm. It's valid code that will work at runtime. I would understand a
> "warning", if the tool cannot prove that the code is safe. But "error"?
> That's too severe. It's again time for a bug report or two, I would say.
Haha, yes maybe "error" is
Hi Collin,
> > Also, what about the type of filetable? It is described as
> >
> > dict[str, list[str]]
> >
> > but I think it is more
> >
> > dict[str, list[str | tuple[str, str]]]
> >
> > right?
> ...
> Using union types like that is annoying with type checkers though. For
> example,
On 4/21/24 4:07 AM, Bruno Haible wrote:
> Also, what about the type of filetable? It is described as
>
> dict[str, list[str]]
>
> but I think it is more
>
> dict[str, list[str | tuple[str, str]]]
>
> right?
Good catch. I think the one you have written is correct because of the
Hi Bruno,
On 4/21/24 4:37 AM, Bruno Haible wrote:
> The former makes an implicit statement that the function is searching
> for the file. The latter does not; it does not say or hint to as what
> function internally does. Thus it is better to use the latter wording.
Agreed, thanks for the change
Collin Funk wrote:
> This patch prefixes temporary directories created by gnulib-tool.py
> with "glpy". gnulib-tool.sh uses the 'gl' prefix in func_tmpdir, and I
> suppose it is beneficial to differentiate the two.
Thanks, applied.
Bruno
Hi Collin,
> When using --create-testdir with a bad module name:
>
> $ gnulib-tool.py --create-testdir --dir aaa bad-module-name
> gnulib-tool: warning: module bad-module-name doesn't exist
> Traceback (most recent call last):
> File "/home/collin/.local/src/gnulib/.gnulib-tool.py", line 30,
Collin Funk wrote:
> Two type hints are incorrectly marked 'dict[str, str]' instead of
> 'dict[str, tuple[re.Pattern, str] | None]'. I assume I forgot to
> change these when inlining sed expressions to use re.sub().
Thanks, applied.
> Now that I think about it, I should have used a list of
On 4/20/24 4:50 PM, Bruno Haible wrote:
> What I measure (with "GNULIB_TOOL_IMPL=sh time ./test-create-testdir-1.sh")
> is:
> dash 22 sec
> bash 20 sec
dash 31 sec
bash 28 sec
Similar here. Looks like my desktop is just older than I remembered
originally.
> I think that 'dash' is
On Sonntag, 21. April 2024 01:01:01 CEST Collin Funk wrote:
> Hi Bruno,
>
> On 4/20/24 3:50 PM, Bruno Haible wrote:
> > On Linux: On Cygwin 2.9.0:
> >
> > in create-tests: time ./test-all.sh in create-tests: time
> > ./test-all.sh
> > sh: 1225 sec
Hi Bruno,
On 4/20/24 3:50 PM, Bruno Haible wrote:
> On Linux: On Cygwin 2.9.0:
>
> in create-tests: time ./test-all.sh in create-tests: time
> ./test-all.sh
> sh: 1225 secsh: 27406 sec
> py: 155 sec
Simon Josefsson wrote:
> jas@kaka:~/src/oath-toolkit$ time make -f cfg.mk
> ...
> real 0m48,169s
> user 0m49,900s
> sys 0m9,658s
> jas@kaka:~/src/oath-toolkit$ export GNULIB_TOOL_IMPL=py
> jas@kaka:~/src/oath-toolkit$ time make -f cfg.mk
> ...
> real 0m0,704s
> user 0m0,527s
> sys
Hi Collin,
> What do you think of the attached patch?
Looks good, and passes the test suite. => Applied.
> from pygnulib import __author__, __copyright__
>
> to get them from __init__.py.
That seems to work, yes.
Thanks!
Bruno
On 4/19/24 10:07 AM, Bruno Haible wrote:
> Yeah, it seems redundant. You will surely find out whether doing so
> triggers some warnings from pylint, PyCharm, or other tools...
What do you think of the attached patch?
I tried to find out more about these variables but they are only
mentioned
On 4/19/24 2:37 PM, Bruno Haible wrote:
> You're right. Maybe Dmitry wanted to have the full data structure
> available somewhere; but since the 'conditionals' and 'unconditionals'
> tables contain the same info in a different way, it's redundant.
>
> I would leave it in, for possible future
Hi Collin,
> Patch 0001 does the same but uses a set instead of checking for
> membership in a list.
Thanks; applied.
> Also, am I missing something or are the sets/lists at
> self.dependers[str(module)] unused?
You're right. Maybe Dmitry wanted to have the full data structure
available
Hi Collin,
> If I am remembering how __init__.py works correctly,
> we should be able to remove the __copyright__, __author__, and
> __license__ definitions from constants.py and the rest of the files.
Yeah, it seems redundant. You will surely find out whether doing so
triggers some warnings
Collin Funk wrote:
> I submitted a feature request here since I think a configuration
> option would probably be the best fix:
>
> https://github.com/pylint-dev/pylint/issues/9555
Thank you!
> When I say obvious in GLModule we have (comments are added):
>
> # Cache for the getter
On 4/19/24 9:24 AM, Bruno Haible wrote:
> This patch optimizes some subprocess invocations.
>
> I did not change the os.chdir calls around larger blocks of code.
Looks good. I had a look at doing this previously but in GLTestDir for
example, we use 'constants.execute' to deal with the:
Hi Bruno,
On 4/19/24 8:49 AM, Bruno Haible wrote:
> This patch changes the './gnulib-tool.py --version' output to end like this:
>
> Written by Bruno Haible, Paul Eggert, Simon Josefsson, Dmitry Selyutin, and
> Collin Funk.
Thanks. I think I can consider myself famous now. :)
> Also, in
Thanks, Collin. Both patches applied.
Bruno
Hi Bruno,
On 4/18/24 6:05 AM, Bruno Haible wrote:
> The same holds for GCC, glibc, qemu, and many other project: They have
> many open issues because the developers prioritize them. They nevertheless
> depend on their users for reporting issues. Paul Eggert and I regularly
> report issues in GCC,
Hi Collin,
> A single underscore doesn't silence it. I can submit a feature request
> but it isn't really a bug since it is still an attribute outside of
> __init__. IIRC pylint is pretty opinionated and they have many open
> issues so who knows if it will even be addressed.
The same holds for
Hi Bruno,
On 4/17/24 3:18 PM, Bruno Haible wrote:
> In this example, the property 'attribute' is used outside of the class,
> that is, it is public. (In the OO world, the concept of "class" and of
> "private"/"public" are tightly related, because one of the main purposes
> of a class is to hide
Hi Collin,
Both patches applied.
> The reason I dislike defining instance variables outside of __init__
> is that you can run into situations like this, which I find hard to
> follow:
>
> var = GLImport(...) # self.assistant does not exist.
> var.assistant.do_something() #
Hi Bruno,
On 4/17/24 11:02 AM, Bruno Haible wrote:
>> $ pylint *.py | grep W0201
>> GLError.py:119:12: W0201: Attribute 'message' defined outside __init__
>> (attribute-defined-outside-init)
>
> This warning is bogus. In a dynamic language like Python, it is
> perfectly fine to have a property
Hi Collin,
> $ pylint *.py | grep W0201
> GLError.py:119:12: W0201: Attribute 'message' defined outside __init__
> (attribute-defined-outside-init)
This warning is bogus. In a dynamic language like Python, it is
perfectly fine to have a property used only by one method. Only if
it is used by
Hi Collin,
> From the documentation of object.__hash__(self) [1]:
>
> The only required property is that objects which compare equal
> have the same hash value; it is advised to mix together the hash
> values of the components of the object that also play a part in
>
Collin Funk wrote:
> Patch 0001 changes GLModuleTable's unconditionals member from a
> dictionary to a set.
> ...
> PEP 8 makes this recommendation for 'is not' and 'not ... is' for
> similar reasons [1].
Thanks. Both patches applied.
Bruno
Hi Bruno,
On 4/16/24 8:09 AM, Bruno Haible wrote:
> I'm talking about this piece of code:
>
> filetable = []
> for src in filelist:
> dest = self.rewrite_files([src])[-1]
> filetable.append(tuple([dest, src]))
>
> which can be written as
>
>
On 4/16/24 9:06 AM, Collin Funk wrote:
> Patch 0001 changes GLModuleTable's unconditionals member from a
> dictionary to a set.
Forgot attachments, oops.
CollinFrom be8c8ce23d090269f52124630b1b0b4d6034052e Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 16 Apr 2024 08:21:27 -0700
Subject:
Hi Collin,
> But I think the idea of the patch is still
> correct. Since it doesn't make sense to accept a list and then only
> use it with one element lists.
Sure. This code structure comes from the fact that in the shell
implementation, the rewriting of file names is done through a 'sed'
Hi Collin,
> This patch handles the directory creation upfront instead of checking
> for every single file, as you mentioned earlier [1].
Thanks! This looks good. Applied.
Bruno
Hi Bruno,
On 4/15/24 7:58 AM, Bruno Haible wrote:
> Patch 0002 is not applicable because it relies on 0001, which was not good.
Yes, I need to rewrite it. But I think the idea of the patch is still
correct. Since it doesn't make sense to accept a list and then only
use it with one element lists.
Hi Collin,
> Patch 0002 does this. GLTestDir also has this rewrite_files() function
> so I did the same there. Maybe it is worth making that a helper
> function or using a base class in the future.
>
> Also, the set() and list() calls around zip(...) are important since
> zip() returns an
Hi Bruno,
On 4/15/24 4:47 AM, Bruno Haible wrote:
> No. I'm adding 3 unit tests that prove that the patch is wrong,
> one for each of docbase, sourcebase, testsbase. (For auxdir and m4base
> gnulib-tool.{sh,py} does not support changing the value while preserving
> the rest: For auxdir the old
Collin Funk wrote:
> The GLImport class has two functions that are the same,
> GLImport.rewrite_old_files() and GLImport.rewrite_new_files().
No. When I copy these functions into separate text files and use 'diff'
on them:
$ diff -u 1 2
--- 1 2024-04-15 06:34:45.441369330 +0200
+++ 2
On 4/14/24 6:23 PM, Collin Funk wrote:
> Also, I noticed we have:
>
> for src in old_files:
> dest = self.rewrite_files([src])[-1]
> old_table.append(tuple([dest, src]))
>
> This is looping over a list, creating a new list with one item,
> calling
Hi Bruno,
On 4/14/24 3:16 PM, Bruno Haible wrote:
> I verified that on Cygwin, the test suite passes; this is because
> - Cygwin programs produce LF as line terminator,
> - Python's platform.system() returns "CYGWIN_NT-10.0".
>
> Regarding native Windows, I don't think there's a realistic
Collin Funk wrote:
> The 'filelist' passed to
> 'filter_filelist' should be marked 'list[str]' and not 'str'.
Thanks, applied.
Hi Collin,
> You mentioned removing the constants.nlconvert() stuff in
> an earlier email [1]. How about these two patches?
I verified that on Cygwin, the test suite passes; this is because
- Cygwin programs produce LF as line terminator,
- Python's platform.system() returns
Hi Collin,
> There are a few cases of statements like this:
>
> var = None
> try:
> # do something
> var = True
>except:
> var = False
> or:
>
> var = None
> if other_condition:
> var = True
> else:
> var = False
Hi Bruno,
On 4/13/24 4:08 AM, Bruno Haible wrote:
> It seems that codecs.open is frowned upon, nowadays [1],
> and that the Python 3 way of opening a file is a built-in function 'open' [2].
Thanks for this patch. When I started working on gnulib-tool.py I
didn't even know the codecs module
Hi Collin,
> Here is a test program to demonstrate:
>
>
> #!/usr/bin/env python3
>
> def function(arg1, arg2 = dict()):
> arg2[arg1] = 0
> print(arg2)
>
> function('one')
> function('two')
> function('three')
>
>
> When
Collin Funk wrote:
> I see a warning for this section of code because isfile() is called
> with two arguments. It looks like the correct way to write this is to
> joinpath() the two arguments
Yes, I agree. Thanks! Applied.
Bruno
On 4/13/24 10:12 AM, Collin Funk wrote:
> diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py
> index d44ceedcec..098bbc59ac 100644
> --- a/pygnulib/GLImport.py
> +++ b/pygnulib/GLImport.py
> @@ -1230,7 +1230,7 @@ AC_DEFUN([%s_FILE_LIST], [\n''' % macro_prefix
Also, I found out that adding
Hi Collin,
> > +try:
> > +shutil.rmtree(dest)
> > +except FileNotFoundError:
> > +pass
>
> You should be able to use 'shutil.rmtree(dest, ignore_errors=True)'
> here [1]. Unless you have a reason for not doing so that I missed.
It can be useful to get
Hi Bruno,
On 4/13/24 3:17 AM, Bruno Haible wrote:
> +def rmtree(dest: str) -> None:
> +'''Removes the file or directory tree at dest, if it exists.'''
> +# These two implementations are nearly equivalent.
> +# Speed: 'rm -rf' can be a little faster.
> +# Exceptions: shutil.rmtree
Hi Collin,
> This patch fixes the issue for me.
Thanks! I confirm, it's fixed for me too. Applied.
Bruno
Hi Bruno,
On 4/10/24 4:26 AM, Bruno Haible wrote:
> The Python implementation has created a tests/ directory instead of a
> gettext-tools/tests/ directory.
This patch fixes the issue for me. It looks like the GLConfig had it's
destdir set *after* the files were already copied.
CollinFrom
Hi Bruno,
On 4/12/24 3:28 PM, Bruno Haible wrote:
> I am applying these two refactorings. Hope it makes this piece of code
> easier to understand.
Thanks!
It looks like you got all the cache tests passing. Nice work.
Collin
Collin Funk wrote:
> Then only set it to the cache or
> default in GLImport.__init__(). But that section of code is already
> sort of difficult to follow...
I am applying these two refactorings. Hope it makes this piece of code
easier to understand.
>From 27c5b31a42ccd5353ccff09d46dbaa0d105f0f0b
On 4/12/24 5:08 AM, Bruno Haible wrote:
> OK, if you want to rework this part, we need unit tests for it first.
> I have now added unit tests for the gnulib-cache.m4 handling; essentially,
> one test for each possible option.
>
> Before dealing with the 'jugtail' package, it would be good to make
Hi Collin,
> It looks like the reading of gnulib-cache.m4 will need to be reworked.
OK, if you want to rework this part, we need unit tests for it first.
I have now added unit tests for the gnulib-cache.m4 handling; essentially,
one test for each possible option.
Before dealing with the
Hi Collin,
> > Oh, this means that r'[x\$]' contains dollar and backslash, whereas the
> > programmer might have thought that it contains only the dollar? Indeed,
> > it's worth to listen to these warnings!
>
> I don't think it changes the meaning:
>
> import re
> re.match(r'[x$]*',
On 4/11/24 12:25 PM, Bruno Haible wrote:
> Oh, this means that r'[x\$]' contains dollar and backslash, whereas the
> programmer might have thought that it contains only the dollar? Indeed,
> it's worth to listen to these warnings!
I don't think it changes the meaning:
import re
Hi Bruno,
On 4/11/24 12:51 PM, Bruno Haible wrote:
> The func_transitive_closure function in the shell implementation can take
> a lot of time. So I wondered whether in the Python implementation, there
> is room for speedup at this place as well. And indeed, there is.
Nice work. I noticed this
Hi Collin,
> I decided to try PyCharm again since I remember liking it when I used
> it ~1 year ago. It seems that it has pretty good warnings for regular
> expressions.
Both patches applied; thanks.
> Patch 0002 removes some redundant backslashing. I am pretty sure most
> of these were
Collin Funk wrote:
> * Packages successfully tested with gnulib-tool.py
>
> bison
> coreutils
> cppi
> cpio
> diffutils
> findutils
> freedink
> Update AC_PREREQ to 2.64 required.
> gnutls
> grep
> groff
> gzip
> inetutils
> libiconv
> mailutils
> patch
>
On 4/11/24 3:51 AM, Bruno Haible wrote:
> => Applied. Thanks.
Nice! Thanks for writing the ChangeLog entry.
Collin
On 4/10/24 7:23 PM, Bruno Haible wrote:
> $ cat ../glpyFfCgil-sh-err
> .../gnulib-tool.sh: *** missing --doc-base option. --doc-base has been
> introduced on 2006-07-11; if your last invocation of 'gnulib-tool
> --import' is before that date, you need to run 'gnulib-tool --import'
> once, with
Hi Collin,
> Can you test the attached patch for me? It is just an addition of a
> sorted() call, which should hopefully fix it.
The patch works fine. It fixes gnulib-tool.py in the packages
wget
wdiff
freedink
=> Applied. Thanks.
Bruno
1 - 100 of 233 matches
Mail list logo
