On 4/25/24 5:14 PM, Bruno Haible wrote:
> Yes, the other heuristic is that when many functions operate on the
> same object, like methods in class do, the pointer to that object
> is often passed first. And, as you noticed, the two heuristics collide...
>
> Here, I would not think of
Hi Bruno,
On 4/25/24 1:18 PM, Bruno Haible wrote:
> Yep, that's the right way to do it. Maybe file_name should come first
> (by the usual heuristic that the argument that shows most variation
> comes first)?
Sure, that is fine with me. I think the other way is based on how I
like to write C.
Hi Collin,
> > Yep, that's the right way to do it. Maybe file_name should come first
> > (by the usual heuristic that the argument that shows most variation
> > comes first)?
>
> Sure, that is fine with me. I think the other way is based on how I
> like to write C. Usually I like to place
Paul Eggert wrote:
> -[AC_CACHE_CHECK([for $CC option to enable large file support],
> +[AC_CACHE_CHECK([for $CPPFLAGS option for large files],
Sorry, but I find the older wording ("option to enable large file support")
more understandable than ("option for large files"). The new wording
Hi Collin,
Object-oriented programming is not easy, and it comes with constant
hesitations and deliberations.
> Less repeated code to maintain.
Yes, this is one of the goals to keep in mind.
The other most relevant questions are:
- Can the purpose of a class be explained in simple terms?
This patch updates the list of target platforms. What has changed since last
year:
- I cannot claim to be testing RHEL any more, since I don't have access
to a copy of it and since the previous clones (CentOS, AlmaLinux etc.)
can no longer sync with RHEL, due to [1].
- FreeBSD's
Paul Eggert wrote:
> Add an extern decl for a “private” extern symbol, to pacify GCC
> 14’s -Wmissing-variable-declarations option.
Thanks. These *_state variables are not worth having an extra .h file
with just a one-line declaration.
Bruno
Since
- IRIX 6.5 is end-of-life for more than 10 years [1],
- I don't have access to an IRIX machine any more,
- the AC_SYS_LARGEFILE macro no longer supports IRIX,
I would suggest to remove mentions of IRIX support from the documentation.
Like we did for OSF/1 in 2019:
doc: Remove
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
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
Bruno Haible writes:
> Since
> - IRIX 6.5 is end-of-life for more than 10 years [1],
> - I don't have access to an IRIX machine any more,
> - the AC_SYS_LARGEFILE macro no longer supports IRIX,
> I would suggest to remove mentions of IRIX support from the
> documentation.
+1
"On
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
Reuben Thomas wrote:
> > Can you please try the attached patch?
>
> Works beautifully, thanks.
OK, I'm committing as shown below.
> Is there a reason not to make a similar macro for compute_curr_prefix?
Yes:
- For compute_curr_prefix, the need has not been demonstrated.
- Even if
On Thu, 25 Apr 2024 at 14:07, Bruno Haible wrote:
> OK, I'm committing as shown below.
>
Great, thanks!
> Is there a reason not to make a similar macro for compute_curr_prefix?
>
> Yes:
> - For compute_curr_prefix, the need has not been demonstrated.
> - Even if ENABLE_RELOCATABLE is 1,
Hi Simon,
> you can ... via
> GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
> needs. ...
> [1]
> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
> [2] https://salsa.debian.org/auth-team/libntlm/-/tree/master/debian
I see
Bruno Haible writes:
> Hi Simon,
>
>> you can ... via
>> GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
>> needs. ...
>> [1]
>> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
>> [2]
This sounds good to me.
As far as IRIX goes, AC_SYS_LARGEFILE still works on 64-bit IRIX. Even
32-bit IRIX should still work if you configure with CC='cc -n32', and
this should be adequate for hobbyists who want to keep IRIX 5.3 going
(some, by reverse engineering it!
You raise several good points. A couple of quick reaction:
On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:
- the gnulib git submodule is huge. Not rarely I get out of memory
errors during 'git clone' in CI/CD jobs.
First I've heard of this problem (other than with
Hi Bruno,
Thank you for the detailed explanations as always.
On 4/25/24 1:48 AM, Bruno Haible wrote:
> Object-oriented programming is not easy, and it comes with constant
> hesitations and deliberations.
:)
My least favorite part of my degree was object-oriented design and
database
* HACKING: Add missing 't' to platforms.
---
ChangeLog | 5 +
HACKING | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 8d1e0e981b..e635e316b8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-04-25 Collin Funk
+
+ HACKING:
On 4/25/24 10:43, Simon Josefsson wrote:
https://gitlab.com/gsasl/inetutils/-/jobs/6706396721
That's an malloc failure on the server side. The savannah admins should
be told about the issue soon after it happens. Routine clones of GNU
projects shouldn't fail like that. (It's never happened
Paul Eggert writes:
> You raise several good points. A couple of quick reaction:
>
> On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:
>
>> - the gnulib git submodule is huge. Not rarely I get out of memory
>>errors during 'git clone' in CI/CD jobs.
>
> First I've heard
On 4/25/24 10:00 AM, Paul Eggert wrote:
> Is there some way to cajole 'git clone' into using less memory, with a
> '--depth 1' or similar options? Cloning shallowly would clone Gnulib a
> lot faster, if you're cloning from a remote repository.
Maybe '--single-branch' would help too. If space is
Paul Eggert wrote:
> This sounds good to me.
Done through the patch below.
2024-04-25 Bruno Haible
doc: Remove documentation of IRIX as supported platform.
* doc/posix-headers/netdb.texi: Don't mention IRIX specific workarounds.
* doc/posix-headers/pthread.texi:
Hi Collin,
> > IMO, the creation of a rewrite_file_name method (singular! you mentioned
> > a couple of days ago that the ability to rewrite a single file name is
> > one of the motivations for this refactoring) in a central place goes in
> > the correct direction. However, moving knowledge about
25 matches
Mail list logo
