@JosephWright does the new peek/regex code or whatever you were doing there use up an additional intarray? all my pdf tests now fails as the font numbers have changed.
@UlrikeFischer Fonts are done differently when dvips or dvipdfmx are involved, LuaTeX has an independent Lua-based implementation for the arrays, so only pdfTeX in PDF mode will show the font changes
i want to understand why some languages mess with \ps@heading and what i as a cls developer can do to avoid an Illegal parameter number in definition of \@@magyar@now@marks error.
to be clear, i dont look for a fix to this error, i just want to understand what babel is doing.
@Lupino well languages are maintained by various people (and they are of various age). Not everyone is good or up-to-date or show good practice or are actively maintained.
We're trying to change the MastersDoctoralThesis template to use Hungarian, which is magyar in babel.
When running the mwe:
\documentclass[magyar]{MastersDoctoralThesis}
\begin{document}
\tableofcontents
\end{document}
We get weird errors e.g. Illegal parameter number in definition of \@@mag...
@DavidCarlisle i found this thread. In it, it says something alike "is a prolem with the cls" and since i also use/maintain a custom cls, i wonder what i should do to circumvent the problems with babel.
@DavidCarlisle i already narrowed it down to the fact that my cls redefines \ps@headings and that magyar.ldf also does something with the marks. But i wasn't able yet to determine what magyar.ldf intends with this adjustments
@UlrikeFischer it was for me, i'd avoid using babel as a whole… it feels like 50% of my general problems are in one way or another babel-related. Unfortunately, we are building a typessetting automaton, so we don't really have control over what languages authors use…
@Lupino you can easily define specific options on the class to pass on, defining a general "unknown option" handler to just pass on an option to babel if it is valid might be harder
@DavidCarlisle the problem is that i don't know what languages are (ever to be) used. The program that builds the tex file simply writes all lang attributes into the documentclass option string. sure, i can declare an exception for magyar/hungarian, but i would need to do this with every problematic language. i'd rather catch those special cases in a more general way.
Hi All. I have a question which would probably not fit well in the main site, but perhaps this is something known, and somebody could give me a hint about it. In a package of mine I have a good number of settings which are language dependent, so I thought best to keep those in separate "language files" which are read and fed to \keys_set:nn when appropriate. I did so because I thought it would not scale well to keep everything inside the .sty. But the reading of the file is taking a ...
significant toll on performance. Compilation visibly stops when it is reading it. And just doing the same task from within the .sty grants significant reduction of compilation time.
Is this to be expected? Meaning, reading the file is particularly costly somehow? (I'm using \file_get:nnNTF, I don't know if the method may be the culprit here).
@Lupino yes but as I say that's tricky if your class uses traditional string options. If you are using a keyval approach it's easier as \documentclass[lang=whatever]{myclass} you can define lang to just hand over its argument to babel.
accessing the filesystem can be a lot slower than defining macros so yes if you end up loading more files (no one mention tikz or beamer here) you can spend a lot of time just doing that. Especially if the files are not in a directory pre-indexed by kpathse ls-R files @gusbrs
@DavidCarlisle Damn! Didn't know that. I may change the strategy here then. I'm running tests from my $TEXMFHOME, does it count as "directory pre-indexed by kpathse"?
@gusbrs when I were a lad, losing a few dozen csnames for some language definitions just in case they were used would not have been an option, but these days the size of the csname hash table really isn't an issue so teh tradeoffs are different.
@gusbrs no TEXMFHOME is normally searched each time (so that you can add files there without running mktexlsr)
@DavidCarlisle I was taking babel, translator, translations as references here on how to do it. As they say "today I learnt". Thank you very much @DavidCarlisle!
@DavidCarlisle That may be the reason why it is that bad then. Is there a way for me to test this from somewhere pre-indexed to check the difference? (Or, in other words, can I index some path manually?)
@UlrikeFischer Depends on the number of languages used in the document. But only one does matter. I tested doing the same thing from inside the .sty for a single language and got about 25% reduction in compilation time.
@gusbrs add a directory under the default /usr/local/texlive/2021/texmf-dist/tex/latex or wherever. Initially it won't find them at all, then run mktexlsr and it will...
@DavidCarlisle I think it is too late for that approach for the case at hand. And it is a large set of options (hundred plus), so it would probably be complex to keep all of this as csnames. (I'm using property lists...).
@gusbrs that sounds quite odd. Don't forget that babel loads a file for every language too, so it can't be so problematic or we would have heard from it already.
@UlrikeFischer Very light testing, no real benchmarking. But it was the exact same task, I just moved the docstrip gards to keep the "file" inside the .sty, and made that bit be directly fed to \keys_set:nn... But, as mentioned, I decided to investigate because the compilation visibly stops when the file is being read.
@UlrikeFischer And yes, maybe the lack of indexing is the problem here. I'm yet to test the suggestion of @DavidCarlisle.
@DavidCarlisle Reporting back after testing. The problem is indeed the fact that the file is in $TEXMFHOME, and thus not pre-indexed. Letting it come from the installed TeXLive tree just makes the "reading file pause" vanish and compilation time be pretty much the same as moving it to the .sty. That's a relief! :-)
@DavidCarlisle I thought I didn't. But I think I may be to blame for a laziness sin here. I don't have that many "active" files there, some bib files, some personal libraries, some config files. But I symlink my actual git repos of these files directly to my $TEXMFHOME... I may have to stop being lazy. ;-)
@DavidCarlisle I don't think I can change the name of .git, and I don't want to do it with the actual repos (that's what's lazy about it, I don't have to worry about l3build install/uninstall, it is "just there"). But I'll take a look at the docs to see how to exclude the .gits from the search.
@gusbrs if nothing else documented as I say you can set up the directory so it requires an ls-R file and make that in a way that excludes anything you want to exclude
@DavidCarlisle I had never worried about this, so I have yet to learn how it works. I'll do so with your suggestions in mind, of course. Thanks again!
@DavidCarlisle find . | wc -l = 7010. But find . -not -path "*/.git/*" -not -path "*/.auctex/*" -not -path "*/testfiles/*" -not -path "*/build/*" | wc -l = 263, which is still much more than wold need to stay at $TEXMFHOME...
@gusbrs well at the begin I had sources in texmf-trees directly too, but when you start to use dtx-files then you have to install/deinstall. One get used to it.
@PauloCereda, @PhelypeOleinik I have a suggestion for sillypages (lovely, wonderful package by the way!): \sillynumber. It should not cycle through the silly walk, but instead show all "places" of the silly walk.
@gusbrs You could do what e.g. beamer does and have your code in a directory in your Git repo, so you add <repo>/tex rather than <repo> as a TeX tree, then you avoid the .git issue
@JosephWright I have a mixture of stuff down my $TEXMFHOME, some are actual packages with l3build and all. Others are personal "libraries" with nothing of that, but also version controlled and include test files, including compilation aux files etc. So, thinking of it, it is a mess. I had no idea it was taking the toll it is. So I have to put things in order. But this is a good suggestion for packages, thanks!
@Skillmon Oh my! How did I not know of this package?!! :-)
@gusbrs that means you can do what you like, so long as you later apologise for giving the impression that some people may think that you did something, even though technically you'd say you didn't.
@Skillmon Not sure I understand... You mean the number of steps? Or show the whole thing inline as in the documentation just before recommending Pilates?
@PauloCereda but transforming one big image instead of a smaller one from PNG to PDF-internal representation is more expensive, so the optimization could be questioned. Instead I'd pick a multi-page PDF and use that instead of the PNG (you'd not have to crop and rely on sizes that way as well)
@PauloCereda (obvious) drawback: sillypages wouldn't work in DVI mode this way.
@PhelypeOleinik \sillynumber{0} is \sillystep{0}, \sillynumber{1} is \sillystep{1}, and so on. Then \sillynumber{11} is \sillystep{11}, and \sillynumber{12} is \sillystep{1}\sillystep{0}, \sillynumber{13} is \sillystep{1}\sillystep{1}. \sillynumber{144} is \sillystep{1}\sillystep{0}\sillystep{0}. So "we" display the numbers in base 12 (which is \silly@steps).