In the the ./import-tests/test-wget2-1.sh output of gnulib-comp.m4
there is this whitespace diff:
$ diff -u ./test-wget2-1.result/m4/gnulib-comp.m4
tmp115629-result/m4/gnulib-comp.m4
--- ./test-wget2-1.result/m4/gnulib-comp.m4 2024-03-27 03:05:35.527866182
-0700
+++ tmp115629-result/m4/gnuli
On 3/27/24 8:45 PM, Bruno Haible wrote:
> This would be reasonable (*), but is low priority (because the average
> gnulib-tool user will not see any effect from this). I've added it
> to the gnulib-tool.py.TODO file.
>
> (*) Although I'm not sure encoding='utf-8' is the right thing in all
> circum
Collin Funk wrote:
> I can go through all the open() and codec.open() calls and turn them
> into:
>
> with open(file_name, 'r', encoding='utf-8', newline='\n') as file:
> # do something
>
> and
>
> with open(file_name, 'w', encoding='utf-8', newline='\n') as file:
>
On 3/27/24 7:29 PM, Bruno Haible wrote:
> They can recommend it. But what we want here is to recognize Unix
> newlines, not macOS 9 newlines or DOS/Windows newlines. It should
> behave like gnulib-tool.sh, and thus newline='\n' is appropriate here.
Ah, I wasn't paying attention much to the newline
Collin Funk wrote:
> With open() using binary mode with encoding='utf-8' causes a failure:
>
> with open('test.txt', 'wb', encoding='utf-8') as file:
> file.write('abc')
>
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: binary mode doesn't t
On 3/27/24 6:55 PM, Collin Funk wrote:
> [1] https://docs.python.org/3/library/functions.html#open
This link was supposed to be:
https://docs.python.org/3/library/codecs.html#codecs.unregister
Can't type today I guess...
Collin
On 3/27/24 6:24 PM, Bruno Haible wrote:
> Thanks! Applied, with one tweak: Let's continue to use 'rb' and 'wb' as
> file open() modes, not 'r' and 'w'. If gnulib-tool ever gets used on
> Windows, we don't want the trouble caused by Windows CRLF newlines.
> We want all generated files to use Unix LF
I updated the gnulib-tool.py.TODO file again:
The other 'sed' invocation can stay, since it occurs only once per
gnulib-tool.py invocation).
Bruno
On 3/27/24 9:52 AM, Bruno Haible wrote:
> I agree. My main considerations are:
>
> - Can someone with little exposure to Python understand and modify the
> code? When you write 'list' and the developer knows that 'list' means
> what is known as "array" in other programming languages, the
Hi Collin,
> Here is a fixed version, sorry.
Thanks! Applied, with one tweak: Let's continue to use 'rb' and 'wb' as
file open() modes, not 'r' and 'w'. If gnulib-tool ever gets used on
Windows, we don't want the trouble caused by Windows CRLF newlines.
We want all generated files to use Unix LF
On 3/27/24 5:51 PM, Collin Funk wrote:
> Hi Bruno,
>
> Here is the 'sed' inlining I mentioned earlier.
Oops, the I accidently sent the patch with this:
# Determine script to apply to library files that go into $testsbase/.
-sed_transform_testsrelated_lib_file = sed_transform_lib
Hi Bruno,
Here is the 'sed' inlining I mentioned earlier.
While adding the type hints I noticed that some docstrings are missing
or are out of date. Some my fault, some not. :)
I'll work on updating them as I make changes. It is easier to do that
than go out of my way to fix them all at once.
T
Hi Darshit,
> > - Can someone with little exposure to Python understand and modify the
> > code? When you write 'list' and the developer knows that 'list' means
> > what is known as "array" in other programming languages, they can work
> > with the code. Using the abstract interfaces
Hi Bruno,
On 3/27/24 3:11 PM, Bruno Haible wrote:
> I guess the strange syntax comes from
> - a wish to treat all ISO C extensions in a similar way syntactically,
> without extending the parser too much,
And then MSVC tries to do everything differently. :)
#pragma pack() vs. __attribute__ (
On Wed, Mar 27, 2024, at 17:52, Bruno Haible wrote:
> Collin Funk wrote:
>> I have also made a conscious choice not to use more abstract
>> collections like 'Iterable' even though they are recommended [4].
>>
>> The first is because some functions check the type:
>>
>> def setModules(self,
Hi Collin,
> I am a big fan of the GNU C attributes for warnings, nonnull and
> warn_unused_result, for example. I assume most of the syntax
> strangeness is from remaining compliant with ISO C, correct?
I guess the strange syntax comes from
- a wish to treat all ISO C extensions in a similar w
The Oracle Developer Studio 12.6 produces a compilation error when
compiling the Gnulib module 'obstack':
cc -m64 -O -DHAVE_CONFIG_H -I. -I../../gllib -I.. -DGNULIB_STRICT_CHECKING=1
-I/home/haible/prefix64/include -g -c -o obstack.o ../../gllib/obstack.c
"../../gllib/obstack.c", line 119: inte
Hi Bruno,
On 3/27/24 9:34 AM, Bruno Haible wrote:
> It will also help further development: In large pieces of code, it's
> easier to understand the existing code and make modifications if there
> are type annotations with a decent syntax.
> (By "decent syntax" I do *not* mean the K&R C syntax or t
Collin Funk wrote:
> I have also made a conscious choice not to use more abstract
> collections like 'Iterable' even though they are recommended [4].
>
> The first is because some functions check the type:
>
> def setModules(self, modules: list[str] | tuple[str]) -> None:
> '''Set the
Hi Collin,
> Here is the big patch adding type hints. I had a second glance through
> all of the pygnulib/*.py files and believe I got everything.
Looks very good. Applied. Many thanks!
> The typing seems pretty helpful to me already. I am using Emacs eglot
> with pyright which shows many unboun
20 matches
Mail list logo
