@DavidCarlisle, @MarcelKrüger, @PhelypeOleinik Any idea why github.com/latex3/latex3/runs/4787579747?check_suite_focus=true is exiting as an error? Locally it's fine ...

@JosephWright Checking...

@PhelypeOleinik Thanks

2022-01-12T10:16:54.9605086Z ##[error]Error 422: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"}
Errors:
- Release already exists.

@JosephWright From a quick look, the only suspicious thing I found in the log was this ^^^

no idea what it means though

@PhelypeOleinik Ah, right: I had to move a tag. In the past that used to delete the release too: they must have changed it. Should be fixed shortly :)

@JosephWright it says build failed but I see no failure in any of the items, but seems @PhelypeOleinik spotted thecause

@JosephWright Ah, it didn't want to overwrite a release

@PhelypeOleinik Indeed: if the error said that, it would be useful :)

@JosephWright Yeah, the message is pretty obvious. Finding it is a treasure hunt :)

@JosephWright I found it in the stupidest way: downloaded the log and searched for "error" :P

@JosephWright The online log github shows is basically useless

@PhelypeOleinik I was looking at the last TeX run for \n!, oddly

@PhelypeOleinik Yup, couldn't see anything at all

@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.

@JosephWright If only all systems were as friendly as TeX :)

@UlrikeFischer Yes, there is a change in the regex stuff I think

@UlrikeFischer I guess we need more normalisation in l3build for that

@UlrikeFischer Bruno's commit 4e7ad36c45de640e50542a7ba4f37ba9248f771b

@UlrikeFischer \intarray_new:Nn \g_@@_submatch_case_intarray { 65536 }

@JosephWright There is a option to allow overwriting existing releases, but it's currently disabled. Do you want it to be turned on?

@JosephWright well font numbers are useful, so I'm not sure if it would be good to remove them.

@MarcelKrüger Nah, I'll remember this next time I have a 'drat, re-tag' moment ;)

@UlrikeFischer We can probably pick up the intarray ones: select font cmr10 at 0.00\d\d\dpt or some such

@JosephWright the problem are the pdf tests. Everywhere /F19 is now /F20.

@JosephWright @MarcelKrüger but why do only the pdftex tests fail?

@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

@samcarter @barbarabeeton @UlrikeFischer ooh twitter.com/shouldhaveaduck/status/1481236452776488965

@PauloCereda ohh!

@samcarter dunno why, it has some Audrey Hepburn vibe :)

@PauloCereda :D

Is one of the developers of the babel package available? i do have a question

@Lupino you can ask on the main site. Javier typically sees them.

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.

@UlrikeFischer okay, i will try to break down my problem to the bare minimum and issue a question. May take a while... Thanks.

@Lupino as @UlrikeFischer says but the magyar customisation babel has historically always been "interesting" with more issues than most,

@Lupino also

@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.

@Lupino yes no actual answer posted there unfortunately.

This tweet finally explains why software development in GB is expensive: the devs drink too much tea :) twitter.com/shog9/status/1481013581625782273

@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

@Lupino if you can post a question with a sensible example that doesn't involve downlading some thesis template, it's probably easy to trace.

@DavidCarlisle will do, just need a bit time

@Lupino imho that broke because magyar doesn't like scrlayer-scrpage. But one really need a small example to test.

Although half of what magyar.ldf does, it probably shouldn't be doing....

@UlrikeFischer i dont use koma-related stuff, it's all hand-crafted ;) but the problem seems to be a bit more general.

@Lupino yes, as David says, magyar is rather curious. You could simply disallow your users to use it ...

@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…

@UlrikeFischer néhányunknak szüksége van erre a lehetőségre

but since we want stuff like orthographically correct hyphenation, we can't really live without babel…

btw, if all goes well, i intend to present the automaton at the next DANTE Tagung #spoiler

@Lupino but you can load hyphenation patterns without using magyar.ldf with \babelprovide.

is it (generally) possible to "pass" options to the \documentclass through to \babelprovide?

i need to load babel relatively early because it also triggers fallback fonts for foreign script systems like arabic or chinese

@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?)

@gusbrs on the other hand.... github.com/lvjr/tabularray/issues/167#issuecomment-1002158208

@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...).

@DavidCarlisle thanks, that is an idea I will consider.

@DavidCarlisle I'll try that, thanks!

@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 but from an indexed search tree, if texmfhome is large and the filesystem is slow then....

I hope no one accepts any of my answers for a while

@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! :-)

@UlrikeFischer ^^^

Thank you both!

@gusbrs you have a lot of files in texmfhome?

@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. ;-)

@gusbrs oh so tex is probably wandering over the internal .git directories looking for stuff....

Could I instruct kpathse to skip .git directories?

@DavidCarlisle That's what I'm starting to think, yes.

@gusbrs yes or you could use a local tree that does have ! in the path (forcing use of ls-R files) and arrange that that file does not use them

@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.

@UlrikeFischer Sounds about right

@UlrikeFischer Stumbling and learning...

@JosephWright :)

@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

@Skillmon ooh that's cool! Thanks! <3

@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 me neither, @samcarter showed it to me.

@Skillmon Considering it is "Ministerial", does it mean I can use it in all of my official documents?

@Skillmon Bloody Brazilians!....

@PauloCereda @PhelypeOleinik ^^^ ;-)

@gusbrs seems reasonable. Let's see how well they process my next tax declarations...

@gusbrs No, it means you must

@Skillmon Full tax exemption guaranteed!

@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.

@PhelypeOleinik :-)

@DavidCarlisle Some say my silly walk is pretty silly. But I would never claim it myself! ;-)

@DavidCarlisle :)

@DavidCarlisle I wonder what you mean ....

@DavidCarlisle I think Silly Walks would fit right in

Or, as the saying goes: I cannot confirm nor deny.

@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?

@PhelypeOleinik, @PauloCereda also, you shouldn't use .png for performance reasons...

@PhelypeOleinik basically display the number in base \silly@steps.

@Skillmon That is by design. The Silly Walk has to be performed in its own time. It cannot be rushed

@PhelypeOleinik "we gathered them together for optimization purposes"

@Skillmon Those are @PauloCereda's words

@Skillmon Isn't that what \sillystep does?

@PhelypeOleinik no, \sillystep displays a single figure, \sillynumber would display 14 as \sillystep{1}\sillystep{2}

@Skillmon well, having one image is better than 12 single images, isn't it? :)

@PauloCereda -- Reminds me of Beatrix Potter's "Jemima Puddle Duck", updates a bit.

@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)

@Skillmon Ah, so basically \includegraphics{\silly@picture}

(see duckuments, that's not what I'd do, but what I did)

@PhelypeOleinik no.

@Skillmon ah I see, noted for version 1.3, which defintely never existed. :) @PhelypeOleinik

@Skillmon Sorry

I'm dumb today

Never be this dumb, kids

@PauloCereda Oh, time lords nothing

@PhelypeOleinik no harm done.

@PauloCereda and I never saw it in your GitHub... (which I never opened)

@PhelypeOleinik did you understand it upon rereading or should I try to elaborate?

@PhelypeOleinik woe woe woe youtube.com/…

@PauloCereda LOL

@Skillmon Try shooting a few more words. If that doesn't work, try a heavy chunk of wood :)

@DavidCarlisle I've just found out there is a kind of sage called pineapple sage en.wikipedia.org/wiki/Salvia_elegans

@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).

@Skillmon ooooooohhhh

@Skillmon So (probably, didn't test) \int_to_base:nn then \sillystep on each digit

@PhelypeOleinik exactly (didn't test as well :P)

@Skillmon I'm working on a vectorised version :)

@samcarter question remains: PDF doesn't work in DVI mode (but would otherwise be best).

@Skillmon yes, but it has the advantage that you can zoom in a bit further

@Skillmon ooh a silly base

@PauloCereda Only the English would use 12 as a base for units.

@gusbrs what have the Romans ever done for us?

@gusbrs what have the... oh

@DavidCarlisle Roman numbers?

@JosephWright :)

@JosephWright the acque-duck

@PauloCereda /sigh

@JosephWright also Pizza Romana

@egreg @CarLaTeX ^^

@PauloCereda Yummy

@PauloCereda Good!

@PauloCereda Pizza anatis

@DavidCarlisle ooh

A phrase that a LaTeX lover would never want to hear: "I don't want automatic numbering" (I'm helping a guy)

@DavidCarlisle Since we are talking about Rome: pizza anserem

@CarLaTeX but that would spare @PauloCereda

@DavidCarlisle ooh