Re: Flood of commits from July?

[Patrice Dumas]

On Sat, Oct 05, 2024 at 06:25:15PM +0100, Gavin Smith wrote:
> > There are three alternatives:
> > * Perl hashmap directly used from C
> > * linear search in C
> > * C++ hashmap used from C
> > 
> > My understanding is that there is no other way than using C++ to have an
> > hash map in C, as was discussed in this thread:
> > https://lists.gnu.org/archive/html/bug-texinfo/2023-10/msg00074.html
> 
> We could also write our own implementation of a hash map or other data
> structure.  It shouldn't be that difficult, we could look up algorithms
> online for how to write a hash map.

That seems more complicated to me than what I did with this little bit
of C++ code.  It could be that the added complexity of the build system
may make a pure C implementation a good trade-off, but I somehow doubt
it in that case.

More to the point, if such a work is done, it should not be for Texinfo
but for an hashmap C library implementation for general use.

> > Note that this code is only used in a pure C implementation, in the
> > default case a Perl hashmap is directly used from C.
> 
> What do you mean by a "pure C implementation"?  Is this a program
> that converts Texinfo only using C, not using any Perl code as well?
> Is this why the Perl hashmap is not available, because it doesn't
> actually have a running instance of a Perl interpreter?

Exactly.  It is in tp/Texinfo/XS/Malefile.am
noinst_PROGRAMS = teximakehtml

It uses only C code to convert Texinfo to HTML.  It is only a
demonstrator, used for development and timing, and it will probably stay
that way for the foreseeable future as
* it produces HTML only
* do not implement the HTML customization API
* we could stop maintaining it

It also lacks command-line options compared to texi2any to set
customization variables, but that would be easy to implement, although I
see little point in doing so (there is one command line option only to
set reproducible output versus mimicking texi2any).

If somebody reimplementas all the converters in C, I think that we
should maintain and ship it, as not having the HTML customization API
would be balanced by the difference in performance.  I do not see
implementing the other converters in C (or any other fast compitled
language such as C++) happening if there are no other developpers
motivated to do it.  I am not motivated to do it myself because in
my opinion
* Info would be a good target, but I hope that someday HTML (or another
  format with more tagging and less formatting) should replace it
* the other formats are not used enough that the gain in performance is
  justified by the time and added complexity to implement to C

> > This is still correct.  But now, there is the demonstrator program fully
> > in C such that, even though we do not distribute that program (and I
> > think that we should not distribute it, it is for development only), we
> > are at that point that Perl is completly removed from that internal
> > program.  To me, the main use of the demonstrator program is to compare
> > the timings with texi2any.  If the linear search is used and not the C++
> > hashmap, this is an 'unfair' treatment of the C program for this
> > purpose.
> 
> How much slower would the linear search actually be?

It is much slower (if I recall well, it was something like 100 times
slower for the texi2any manual).  I juste tested the overall effect and
for the pure C demonstrator for the Texinfo manual, time is about 0.375
s with linear search and 0.305 with the hash map.
 
> > To me, this C++ is not really in Texinfo code, it is more like an
> > external C library that happens to be in C++, but it is well
> > separated.
> 
> It doesn't appear this way to me.  tp/Texinfo/XS/configure.ac checks
> for a C++ compiler with AC_PROG_CXX.  So it is seems that present a
> C++ compiler is required to build Texinfo.

It is not required.  If there is no C++ compiler the linear search is
used in the demonstrator program.

>  There is also a C++ source
> file under tp/Texinfo/XS/convert/call_html_cxx_function.cpp in the same
> subdirectory as other source code files for the program.

Of course there need to be one, but it is the only one and it just
implements the few functions needed to do the job (wrapped as C
functions).

> > If needed, I could try to make it part of contrib/ instead of being in
> > the main code.
> 
> That would be an improvement.

After more thinking, I wonder if it wouldn't be better to require
setting a configure flag to have the teximakehtml demonstrator program
built instead of moving the C++ code to contrib, as it would be much
simpler.

> OK, I misunderstood.  The Perl modules do not have a stable, public
> API (which is what I understand by the term "API") because they are
> just part of the texi2any program, not supposed to be used independently.

Exactly.

Similar with the Perl module, I think that it is now possible to use
the C code independently, as demonstrated by teximakehtml, but we do not 
promise anything on that front.  Accordingly, we do not distribute
teximakehtml and we could stop maintaining it if we want to.  Also,
contrary to the Perl modules which have some documentation, there is no
documentation for the C interface, but if there was we would put the
same disclaimer as we do in the Perl modules documentation.

-- 
Pat