:
> > main/.libs/libtexinfoxs_la-build_perl_info.o: in function `convert_error':
> >
> > /cygdrive/d/a/ci-check/ci-check/texinfo-7.1.90-20241006/build/tp/Texinfo/XS/../../../../tp/Texinfo/XS/main/build_perl_info.c:1180:
> > undefined reference to `newSVpv_utf8'
On Sun, Oct 06, 2024 at 07:16:21PM +0100, Gavin Smith wrote:
>
> If it's accepted as part of the Texinfo code base it is the responsibility
> of the Texinfo developers to maintain it, fix reported bugs, keep it
> working with other changes in the code etc., at least if we want to still
> be able t
On Sun, Oct 06, 2024 at 08:08:53AM -0700, Per Bothner wrote:
> On 10/5/24 11:14 PM, Eli Zaretskii wrote:
> > If we are seriously considering rewriting Texinfo in a different
> > language, why should we limit ourselves to C++? Nowadays there are
> > better, safer languages out there.
>
> Which one
uto-image-base -Xlinker --out-implib
> -Xlinker .libs/libtexinfoxs.dll.a
> /usr/lib/gcc/i686-pc-cygwin/11/../../../../i686-pc-cygwin/bin/ld:
> main/.libs/libtexinfoxs_la-build_perl_info.o: in function `convert_error':
>
> /cygdrive/d/a/ci-check/ci-check/texinfo-7.1.90-20241006/
On Sun, Oct 06, 2024 at 07:24:13PM +0200, Patrice Dumas wrote:
> On Sat, Oct 05, 2024 at 06:37:45PM +0100, Gavin Smith wrote:
> >
> > And that is precisely what I DON'T want to happen. I am not willing to
> > work on texi2any any more if parts of it start being written in C++.
>
> While I agree
/ld:
main/.libs/libtexinfoxs_la-build_perl_info.o: in function `convert_error':
/cygdrive/d/a/ci-check/ci-check/texinfo-7.1.90-20241006/build/tp/Texinfo/XS/../../../../tp/Texinfo/XS/main/build_perl_info.c:1180:
undefined reference to `newSVpv_utf8'
/usr/lib/gcc/i686-pc
Hello,
I removed some gettext macros installed by gnulib or gettextize in 2021
when updating gnulib (when I updated the setup of the gnulib po
directories), in this commit (there is a similar one for tp/Texinfo/XS
gnulib):
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a46d1f492047615340
On Sat, Oct 05, 2024 at 06:37:45PM +0100, Gavin Smith wrote:
>
> And that is precisely what I DON'T want to happen. I am not willing to
> work on texi2any any more if parts of it start being written in C++.
While I agree that there is no point in rewritting in C++ the existing C
code, I see no p
> Date: Sun, 6 Oct 2024 08:08:53 -0700
> Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> From: Per Bothner
>
> On 10/5/24 11:14 PM, Eli Zaretskii wrote:
> > If we are seriously considering rewriting Texinfo in a different
> > language, why should we limit ourselves to C++? Nowadays there are
On 10/5/24 11:14 PM, Eli Zaretskii wrote:
If we are seriously considering rewriting Texinfo in a different
language, why should we limit ourselves to C++? Nowadays there are
better, safer languages out there.
Which ones?
If we restrict ourselves to languages with fast execution, modest
run-ti
On Sat, Oct 05, 2024 at 06:00:40PM +0100, Gavin Smith wrote:
> On Sat, Oct 05, 2024 at 02:52:55PM +0200, Patrice Dumas wrote:
> > On Sat, Oct 05, 2024 at 11:00:05AM +0100, Gavin Smith wrote:
> > > I'd also like to know how many more of these commits are coming.
> >
> > I still have some conflict/r
On Sun, Oct 06, 2024 at 03:43:17PM +0200, Patrice Dumas wrote:
> > There are also error messages about locales and collation:
> >
> > $ ../teximakehtml ../../../../doc/texinfo.texi
> > BUG: no Perl collation
> > texi2any: warning: collation locale not found: en_US
>
> The "collation locale not fo
Hello,
I did the timings on elisp, glibc and texinfo manuals and I get about
* 2 between C only and Perl with TEXINFO_XS_CONVERT=1 and
* 4 between Perl with TEXINFO_XS_CONVERT=1 and Perl with XS for
parser only.
> There are also error messages about locales and collation:
>
> $ ../teximakehtm
On Sun, Oct 06, 2024 at 12:09:45PM +0100, Gavin Smith wrote:
> Does it scale with the size of the input? Perhaps a certain part of
> this 0.07 sec is fixed regardless of the size of the input file. Have
> you tried it with a larger manual like glibc or elisp?
For libc, I get:
1.13s with hashmap
On Sun, Oct 06, 2024 at 02:48:25PM +0200, Patrice Dumas wrote:
> On Sun, Oct 06, 2024 at 02:40:42PM +0200, Patrice Dumas wrote:
> >
> > The @iftex sections are expanded, that's why there are all those errors.
> > They probably do not mess that much the timing, but still this should
> > not happen.
On Sun, Oct 06, 2024 at 02:40:42PM +0200, Patrice Dumas wrote:
>
> The @iftex sections are expanded, that's why there are all those errors.
> They probably do not mess that much the timing, but still this should
> not happen. Strangely I have not seen that when comparing texi2any and
> teximakeh
On Sun, Oct 06, 2024 at 12:47:42PM +0100, Gavin Smith wrote:
>
> I've tried it myself although have been unable to run it on anything
> but texinfo.texi for the manuals I tried.
>
> I did not see anything in teximakehtml.c about which converter was used
> so I patched the code in converter_conver
On Sun, Oct 06, 2024 at 12:09:45PM +0100, Gavin Smith wrote:
> On Sun, Oct 06, 2024 at 09:53:22AM +0200, Patrice Dumas wrote:
> > > 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).
On Sun, Oct 06, 2024 at 12:09:47PM +0100, Gavin Smith wrote:
> On Sun, Oct 06, 2024 at 09:53:22AM +0200, Patrice Dumas wrote:
> > > 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).
Patrice Dumas wrote:
> The code that moves index entries after @item was actually confused by
> @subentry. Should be fixed in:
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=5e8fccc9bd1fb775654ebb2e2334682a83cc47c0
>
> Thanks for the report!
>
> @Gavin maybe to be considered for 7.1.
On Sat, Oct 05, 2024 at 11:22:06AM -0600, arn...@skeeve.com wrote:
> Hi.
>
> Apologies for the delay in replying, I've been offline for several
> days.
>
> Thank you for the report. I have fixed all the cases in the manual
> and will push it to Git shortly. The HTML manual will be updated
> when
On Sun, Oct 06, 2024 at 09:53:22AM +0200, Patrice Dumas wrote:
> > 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 f
On Sat, Oct 05, 2024 at 06:45:27PM +0100, Gavin Smith wrote:
> On Sat, Oct 05, 2024 at 11:22:06AM -0600, arn...@skeeve.com wrote:
> > IMHO this is really a makeinfo bug (and indeed, the Info file doesn't
> > change after this update), so I'm cc-ing the texinfo folks.
>
> I am not sure what the bug
You're welcome.
Thérèse Godefroy wrote:
> Hello Arnold, Gavin, all,
>
> Le 05/10/2024 à 20:18, arn...@skeeve.com a écrit :
> > Looking more closely at the gawk.html file for gawk5 5.3.1, from
> > September 22, I don't see these blank lines. It may be that
> > you have an old version?
> >
> >
Hello Arnold, Gavin, all,
Le 05/10/2024 à 20:18, arn...@skeeve.com a écrit :
Looking more closely at the gawk.html file for gawk5 5.3.1, from
September 22, I don't see these blank lines. It may be that
you have an old version?
In any case, I have fixed the doc and pushed it to git.
Arnold
arn
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 d
26 matches
Mail list logo
