New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

binding for etoolbox #478

Closed
kohlhase opened this Issue Apr 19, 2014 · 17 comments

Comments

Projects
None yet
3 participants
@kohlhase
Contributor

kohlhase commented Apr 19, 2014

I find myself using the etoolbox package more and more. It provides nice programming primitives for LaTeX. And at the same time, I like supporting LaTeXML by just RawTeXing parts of the LaTeX packges (at least for roughing things out). Currently, that means that I cannot use etoolbox primitives.

I must confess that I have not tried just inputting etoolbox.sty and letting LaTeXML figure things out, but I think that in the end this will not be efficient.

Therefore, ... a binding would be nice to have.

@kohlhase

This comment has been minimized.

Contributor

kohlhase commented Apr 19, 2014

@dginev this might also be interesting for you to look at.

@dginev

This comment has been minimized.

Collaborator

dginev commented Apr 19, 2014

One interesting bit is the observation that code interpreted through RawTeX is even less efficient than LaTeXML's bindings.

I was brainstorming with Bruce about a radical optimization strategy that would refactor central chunks of bottleneck functionality into pure C and interface it via Perl's XS wrappers.

Interpreting raw TeX directly sounds like a good self-contained target for such a refactoring. Of course that might mean that we turn the entire Gullet and Stomach into C code, and possibly throw in the Token(s) and Definition classes in there for good measure. (Wildly hand-waving here)

If we can optimize the raw interpretation of TeX definitions we may get magnitudes of speedup in the cases of Tikz and XY, where we are dealing with tens or hundreds of thousands expansions per document.

As to the specific etoolbox.sty, it's hopefully just a regular binding-writing exercise.

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Apr 19, 2014

How do you see that RawTeX is less efficient? At least for macros, it should end up pretty much the same.

@kohlhase

This comment has been minimized.

Contributor

kohlhase commented Apr 19, 2014

For the stuff in etoolbox, which is new conditionals, iterators, ... there are perl primitives, and that should be more efficient than loads of \expandafter and \ifx.

@dginev

This comment has been minimized.

Collaborator

dginev commented Apr 19, 2014

Exactly - less efficient in the sense that you need to expand 100 macros to do the TeX equivalent of what would be one or two native Perl commands (e.g. the pseudo random number generation in Tikz)

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Apr 19, 2014

Ah, ok, i misunderstood; certainly handwritten Perl should be more efficient

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Apr 19, 2014

For grins, it would be interesting to know if it can process the file as-is.
But it sounds like it would still be useful to develop a binding for.... (after 0.8)

@dginev

This comment has been minimized.

Collaborator

dginev commented Apr 19, 2014

As an answer:

Testing invocation:

latexmlc --preload=/usr/local/texlive/2013/texmf-dist/tex/latex/etoolbox/etoolbox.sty 'literal:a' --whatsin=fragment

Final report (lots of errors omitted):

1 warning; 19 errors; 1 fatal error; 16 undefined macros[\etb@renew@command, \ifboolexpr,
 \insc@unt, \ifcsstring, \notblank, \etb@provide@command, \ifstrequal, \@argdef, \renewrobustcmd, 
\providerobustcmd, \etb@boolexpr, \ifcsltxprotect, \ifdefstrequal, \ifdefstring, \ifdefltxprotect, \csshow]
 at /home/dreamweaver/perl5/lib/perl5/LaTeXML/Common/Error.pm line 67, <$IN> line 661.

Not quite there yet it seems.

@kohlhase

This comment has been minimized.

Contributor

kohlhase commented Apr 20, 2014

note that etoolbox.sty depends on etex.sty that may be independently interesting for LaTeXML (though it looks quite nastily low-level).

@kohlhase

This comment has been minimized.

Contributor

kohlhase commented Apr 20, 2014

Maybe etoolbox.sty.ltxml would be something for Kim/Lukas over the summer?

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Apr 28, 2014

Indeed; feel free to bring that up with them...or i will. In addition to continuing or finishing the Doc/OOffice stuff. Which reminds me: Since they've got some expertise with XSLT now, it might be nice to knock off a transform to Wiki markdown?

@kohlhase

This comment has been minimized.

Contributor

kohlhase commented Apr 28, 2014

Lukas knows XSLT and Kim has some experience with LaTeXML bindings, so that looks like a good division of labor. You should bring this up with them, I am just advising you.

@dginev dginev added this to the LaTeXML-0.9 milestone Aug 1, 2014

@dginev

This comment has been minimized.

Collaborator

dginev commented May 31, 2015

Btw, I am now of the opinion that before we start writing Perl bindings we should understand the failures with the native TeX interpretation and improve LaTeXML to facilitate a clean load (and use) of etoolbox.sty.

Once that works, we can optimize for performance by rewriting the slowest parts in Perl. I would advertise this as a general approach to new bindings we consider supporting, so that we get ever closer to the magical 1.0 release (where we have indistinguishably close coverage to classic TeX)

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Jun 1, 2015

Good point. In fact, I opened a somewhat related issue #622 more related to coverage than performance.

As far as etoolbox is concerned, since it is mainly 'programming', it might just work. The only way to determine is for somebody to write a somewhat comprehensive test document that exercises all or most of the macros, and then compare pdflatex to latexml with --includestyles. If the comparison is good, we can create a dummy binding that simply loads etoolbox.sty.

Of course, the test above indicates it won't yet go. I don't seem to have etoolbox.sty on my work system, but etex.sty fails due to a random latex-internal counter (\insc@unt).

@dginev

This comment has been minimized.

Collaborator

dginev commented Apr 20, 2018

As far as etoolbox is concerned, since it is mainly 'programming', it might just work.

From today's test I randomly found out, it doesn't currently:

Attempt to pop last locked stack frame at /usr/share/texlive/texmf-dist/tex/latex/etoolbox/etoolbox.sty; 
line 779 col 18 In Core::Stomach[@0x3c490f8] at /usr/share/texlive/texmf-dist/tex/latex/etoolbox/etoolbox.sty;
line 779 col 18 <= Core::Definition::Primitive[End] <= Core::Stomach[@0x3c490f8] <= 
 Core::Gullet[@0x3cabc58] <= Core::Definition::Constructor[\Requir... <=
 Core::Stomach[@0x3c490f8] <= Core::Gullet[@0x3cabc58] <= 
 Core::Definition::Constructor[\usepac... <= Core::Stomach[@0x3c490f8]

source: https://corpora.mathweb.org/corpus/%2Fdata%2Farxiv_1802%2F/raw_tex_to_html/fatal/unexpected/%3Cendgroup%3E

And apparently near 10% of tasks used it, so I'm definitely taking a look at the native interpretation, could lead to all kinds of progress.

@dginev

This comment has been minimized.

Collaborator

dginev commented Apr 20, 2018

Yes, so this goes very deep right away, some more boilerplate is needed from latex.ltx, such as \@argdef
before we can even start testing the etoolbox interpretation. Will get back to it on a fresh head.

Edit: Native interpretation is possible and now successful, but a little binding intervention is needed for full accuracy. I left a comment about the argdef details as a comment in the PR

@dginev

This comment has been minimized.

Collaborator

dginev commented Jul 11, 2018

Solved by merging #978

@dginev dginev closed this Jul 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment