Hi Bruno,
On 4/8/24 6:28 PM, Bruno Haible wrote:
> What about GLEmiter.py line 468?
Oops, good catch. I must have been focused on not messing with line
460:
emit += "# But here it has a '-gnulib' suffix.\n"
But forgot to come back to it.
You can apply the attached patch or fix it without a
Hi Collin,
> >> Sounds good. What do you think about two patches to normalize the
> >> existing code with the conventions we've agreed upon:
> >>
> >> 1. Convert '+= [item]' to '.append(item)'
> >
>
> Patch 0001.
>
> >> 2. Use single quotes for string literals.
>
> Patch 0002.
Thank
On 4/8/24 3:36 PM, Paul Eggert wrote:
> For what it's worth, the business about the cost of x.append(y) (it's
> O(len(x)), and O(1) amortized) has been a standard part of the cost model
> lecture in my programming languages course for more than two decades, so I
> hope that UCLA graduates, at le
Hi Bruno,
On 4/8/24 2:19 PM, Bruno Haible wrote:
> My experience is that ChatGPT (3.5) provides good answers for things that
> have a lot of mentions on the web. Whereas for things that are rarely
> mentioned, it starts to hallucinate and often provides wrong answers.
> Therefore, for routine ques
On NetBSD 10.0/i386, I see a test failure of ptsname_r. The cause is that
this function, on NetBSD, clobbers the result buffer even when it fails
with error ERANGE.
This patch adds a workaround.
2024-04-08 Bruno Haible
ptsname_r: Work around ptsname_r bug on NetBSD 10.0.
* m4
On 4/8/24 14:19, Bruno Haible wrote:
My experience is that ChatGPT (3.5) provides good answers for things that
have a lot of mentions on the web. Whereas for things that are rarely
mentioned, it starts to hallucinate and often provides wrong answers.
Therefore, for routine questions around Python
Hi Collin,
> > - It explains ChatGPT's failure: Probably there are more explanations
> > regarding += on strings, on the web, than regarding += on lists.
> > So ChatGPT used the "common" explanation, for strings, and then
> > substituted s/string/list/.
>
> Interesting. I know very
On 4/8/24 7:23 AM, Bruno Haible wrote:
> - It explains ChatGPT's failure: Probably there are more explanations
> regarding += on strings, on the web, than regarding += on lists.
> So ChatGPT used the "common" explanation, for strings, and then
> substituted s/string/list/.
Interestin
Hi Bruno,
On 4/8/24 12:30 PM, Bruno Haible wrote:
> Typically, when one changes a function, one should ask oneself
> "should the doc string be updated?"
Yes, I forget this sometimes...
> This is better. But wait: If a return value is a list with unspecified
> sorting order, and doesn't contain d
Hi Collin,
> Patch 0005 changes a list to a set. Previously, it checked if each
> file was a member of the list before appending it. We can just let
> Python do this for us. I've also sorted before returning to make it
> behave like gnulib-tool.sh.
Typically, when one changes a function, one shou
Hi Collin,
> I was having a look at GLModuleSystem.py and noticed some duplicate
> checks that an key is valid. Patch 0003 addresses that.
>
> Patch 0004 adds a missing None return type hint to
> GLModuleTable.getCondition(). This is used to indicate that the module
> is not a conditional depende
Hi Collin,
> Here is two janitorial work patches.
Thanks, applied.
> I remember an extra dict() call causing trouble with GLMakefileTable.
> Removing the extra list() calls from sorted() seemed like a good place
> to start cleaning up.
Well, that extra dict() call made trouble because in that p
Hi Collin,
> I think that I see the issue here. I believe this is a case of the
> "prior knowledge summarization engine" being incorrect. Given this
> statement:
>
> a += [var]
>
> it seems to think that a new copy of 'a' is being created. This is
> incorrect. The given statement is equal to
Some more cleanup.
Patch 0005 changes a list to a set. Previously, it checked if each
file was a member of the list before appending it. We can just let
Python do this for us. I've also sorted before returning to make it
behave like gnulib-tool.sh. In func_modules_to_filelist:
files=`for f in
Hi Collin,
> When running ./configure in findutils I see this warning:
>
> checking for pthread.h... yes
> ...
> ./configure: line 31218: test: =: unary operator expected
> checking for pthread_spin_init... yes
> checking for pthread_t... yes
> checking for pthread_s
15 matches
Mail list logo
