On Sun, Sep 29, 2024 at 04:30:40PM +0200, Patrice Dumas wrote:
> On Sun, Sep 29, 2024 at 05:18:58PM +0300, Eli Zaretskii wrote:
> > Why do I suddenly receive from texinfo-comm...@gnu.org a very long
> > series of commits from June and July? I've received about 400 mails
> > like that already since noon, and it doesn't show any signs of
> > stopping.
>
> That are commits that were written at that time and rebased on master.
> In the beginning we thought that they could be for 7.3, but since we
> have made many more important and user visible changes since in master
> for 7.2, these commits are added to master now. They are also corrected
> as rebasing may lead to incorrect code being in the version control, and
> for that the sooner the better.
>
> These correspond, in general, to changes in C code for better
> performance (less use of memory and processor), tests in special
> situations and refactoring and should not lead to much changes in
> output.
I'd also like to know how many more of these commits are coming.
There were already huge changes made following the 7.1 release (October
2023), with the addition of C code for HTML output and other processing
steps. At the time, these changes had performance problems, which in
my view threatened the future of the project. I spent a lot of time trying
to understand the new structure of the code so that we could fix these
performance problems (which we did).
>From this point on, I have had much less understanding of the code
in texi2any. Correspondingly, my ability and interest to fix issues
in texi2any has gone down. I don't know if there was any alternative,
though.
I thought that having some more of Patrice's private changes on master
might prevent a recurral of this situation with a huge number of changes
being made after a release. But there still seems to be no end in sight.
Even if I spent the time eventually understanding the code with new changes,
it seems likely that there would be more changes following afterwards that
I would again be behind in understanding. (I hope it's also clear that
understanding code (or documentation) that somebody else wrote is much
more difficult and time-consuming than understanding code you wrote
yourself.)
Since the amount of XS code in texi2any has vastly increased since the
7.1 release, it is likely that there are undetected problems. There will
likely be portability problems for different versions of Perl on different
platforms. These would only be shaken out with wider usage and testing,
which would require some degree of stability.
I hope we are not going to have development of major new features before
the next release or much more widespread restructuring of the code.
I guess it doesn't matter as much if code that is new since 7.1 is
changed.
At the moment, I can only keep an eye on commits and ChangeLog entries,
and try to flag anything up that I think that needs further discussion.
Commit a45bddf685edd (dated 2024-10-05, committed 2024-10-05)
"Add C++ code to have an hashmap when Perl is not used"
This adds C++ code to the project!! This is very concerning. We
already have a lot of languages in the Texinfo project: TeX, Perl, C,
even JavaScript. I have no desire to understand or maintain C++ code
in Texinfo as well. It is also a lot for any new contributors in
the future to get up to speed with (as things are, there may never be
any such new contributors). Can we please find some alternative
for whatever this C++ code is used for?
You wrote to me in a private mail on 2024-05-25:
> In the end I used the Perl HV to have a hash map, it works well (it
> probably uses more memory), I propose not to use the C++ hashmap until
> we completely remove Perl.
This change has also been made to TODO:
If others are interested in processing Texinfo files directly,
- however, it could be possible to work on providing a practical API
- for the C codes in the Texinfo project, and maybe bindings for
- other languages than C or Perl.
+ however, it could be possible to work on providing a practical and
+ public API for the C codes in the Texinfo project, especially if the
+ existing APIs can be reused, and maybe bindings for other languages
+ than C or Perl.
I have no interest in developing or supporting a public, stable API for
hooking into texi2any internals. I have probably written emails about
this before. It will tend to "freeze" texi2any implementation details
and make further development more difficult. Users will probably not
be able to achieve exactly the kind of output they want using the API
and will come asking for help. (This already happens with the Perl
customization API.) A C API might also forestall any future rewrite of
texi2any in a different programming language.
The size and scope of Texinfo goes up while my interest, time and ability
to work on Texinfo development goes down.
