* lib/renameatu.c (renameat2ish, renameatu) [RENAME_SWAP]:
Use macOS RENAME_SWAP to implement GNU/Linux RENAME_EXCHANGE.
* tests/test-renameatu.c (main): Add a test for RENAME_EXCHANGE.
---
ChangeLog | 7 +++
doc/glibc-functions/renameat2.texi | 2 ++
lib/renameatu.c
Yesterday one of my patches included a tiny bug. In the Emacs source
directory:
$ env GNULIB_TOOL_IMPL=py ./admin/merge-gnulib
Copying file lib/gl_openssl.h
Traceback (most recent call last):
File "/home/collin/.local/src/emacs/../gnulib/pygnulib/main.py", line 1298,
in
main()
File "/
> commit 4bf9c96497946ce6f7b84f6527ed0291657cf728
> Author: Bruno Haible
> Date: Sun Jan 9 15:38:51 2022 +0100
>
> Remove influence of Automake conditionals on conditional dependencies.
>
> So, once that is done things should work properly. Hopefully.
Looks like my prediction was correct.
This patch *should* fix one item in the gnulib-tool.py.TODO file. I am
unsure of a good way to test it at the moment so I am trusting that I
read the original commit correctly. It was a simple addition of a
conditional so I am 99% sure it is correct.
The issue I am having with testing is that the
Collin Funk wrote:
> This patch just modifies the timestamp of 'config.h.in' after
> executing 'autoheader'.
>
> I've used the Pathlib touch function which I will admit looks a bit
> strange [1]. I've tested it and it should update the timestamps
> properly though.
Thanks! Applied.
I see nothing
Hi Collin,
> From
> experimenting, I've confirmed that calling an invalid program will
> throw 'FileNotFoundError'. Other errors should fail loudly so they are
> not ignored.
Yes, that's how exception-related programming should be done. Thanks.
Applied.
Bruno
This patch just modifies the timestamp of 'config.h.in' after
executing 'autoheader'.
I've used the Pathlib touch function which I will admit looks a bit
strange [1]. I've tested it and it should update the timestamps
properly though.
My reasoning for this is that the 'constants.execute' command
Hi Bruno,
On 3/16/24 9:22 AM, Bruno Haible wrote:
> I don't know. Maybe it is related to
> https://stackoverflow.com/questions/16981921/relative-imports-in-python-3 ?
The import stuff always caused me issues in the past when I used
Python. The way we have it now works so I will continue to use it
On 3/15/24 5:27 PM, Bruno Haible wrote:
> * Download and configuration:
> - Eclipse IDE from https://www.eclipse.org/downloads/packages/
> (either the build for Java or for C/C++ should work fine).
I am in the process of setting this up at the moment to experiment. I
figured that I should me
Hi Collin,
> This is somewhat related since it deals with imports, but is there a
> reason why we don't just import things from modules directly?
>
> Right now we have:
>
> from . import constants
> # Define global constants.
> APP = constants.APP
> DIRS = constants.DIRS
Collin Funk wrote:
> it seems like a good time to fix this line
> which has annoyed me more than it should.
Thanks; applied.
Bruno
Hi Bruno,
On 3/16/24 6:22 AM, Bruno Haible wrote:
> I don't see the point of writing bool() where 99.9% of the Python developers
> write False.
> = bool()seen 62 times [1]
> = False seen 358336 times [2]
Yes, I noticed this in a few places and changed it silently because it
is confusi
Hi Bruno,
On 3/16/24 6:14 AM, Bruno Haible wrote:
> Oh, I had not seen that the use of 'classes.' was so inconsistent.
> Haven't made up my mind yet, regarding when 'classes.' should be used or not.
This is somewhat related since it deals with imports, but is there a
reason why we don't just impo
I don't see the point of writing bool() where 99.9% of the Python developers
write False.
= bool()seen 62 times [1]
= False seen 358336 times [2]
[1]
https://codesearch.debian.net/search?q=+%3D+bool%28%29+filetype%3Apython&literal=1
[2]
https://codesearch.debian.net/search?q=+%3D+Fal
Hi Collin,
> Let me know how this looks. I've imported CopyAction to main and use
> that in a similar way to what you wrote.
Nice work. Thanks! Applied.
> I've used the name copymode instead of copyaction to match
> gnulib-tool.sh.
Yes, good. I had forgotten about the distinction between copymo
Hi Bruno,
On 3/16/24 4:46 AM, Bruno Haible wrote:
> Here the Python output is prettier. So, here is a patch to align
> gnulib-tool.sh's output with gnulib-tool.py. It's a leftover from this patch,
> which did not cover the --local-dir options:
I realized that I accidental made the Python output p
Collin Funk wrote:
> On 3/15/24 5:27 PM, Bruno Haible wrote:
> > * Choice: It seems that PyCharm, VSCode, Spyder, Eclipse with PyDev are the
> > most prominent candidates.
>
> I used PyCharm for a course I took in college since the professor
> wanted us to. I remember liking it. It seems that th
Simon Josefsson wrote:
> OATH Toolkit fails with sh+py though... gnulib-cache.m4.
The only remaining difference in gnulib-cache.m4 now is:
$ diff -u oath-toolkit-sh/liboath/gl/m4/gnulib-cache.m4
oath-toolkit-py/liboath/gl/m4/gnulib-cache.m4
--- oath-toolkit-sh/liboath/gl/m4/gnulib-cache.m4 2024
Simon Josefsson wrote:
> Also it seems to "forget" gl_LGPL([2]) in gnulib-cache.m4.
This patch fixes it. It was an omission in my commit on 2022-08-03
"gnulib-tool.py: Follow gnulib-tool changes, part 23."
2024-03-16 Bruno Haible
gnulib-tool.py: Don't lose the gl_LGPL value from gnul
19 matches
Mail list logo
