The irony of seeing this and wanting to say how crappy the interface is, but the button doesn't work on your browser.

@AlanMunn lol

@AlanMunn yesterday I got a message (per E-Mail) that E-Mail-Forwarding was deactivated on our university. Now, I don't forward my messages, so had no problem with this, but everyone who only reads the forwarded messages will not see this...

@Skillmonlikestopanswers.xyz we have the same rule. Even students are not allowed to have their email forwarded

@AlanMunn I struggled a lot with a similar thing on android - - - then discovered that I had to disable twilight (the app that change the color temperature of the display at night) and another one with right to "write on display" to enable the buttons in pop-ups. Why, I don't know.

@daleif I hope my university will never do that... I have to use only the university mail to send messages to the students if there is any bit of academic info in them, and if they were not able to redirect them, they'll never read them. They don't normally even so (one told me that email is so much an '90 thing...)

@Rmano Actually, for security, I think it is best to not let them forward at all. Students may receive sensitive information by email and we have no control over what ever email system the data is forwarded to. Our change was of course coupled with GDPR.

@daleif well, the reason is not security, but some mail-provides started to block the university's mail-server because of too many requests (thanks to Corona, the amount of sent email jumped a lot, so some providers seemed to think the university was sending spam). The problem is that students have to see their email for the exam registrations and so on. If any student now doesn't see an email, he can reason that it wasn't his fault, but the university cancelled his forwarding.

@daleif yes, probably the same GDPR that forces us to send info using only the university mail. They have to sign a document when activating the forwarding assuming all responsibility for data leaks... ;-)

@daleif and that without proper announcement (announcing via a channel you just deactivated....), making the university responsible for any unread message and not the student.

@UlrikeFischer If the separations stuff looks OK, I'll merge I think: I'd like to get that part out as the DeviceN aspect will be hard and may take a while

@JosephWright I got a bit distracted yesterday by the pdfrestore failure, so only looked at your example, but that worked fine. Shouldn't we first try to decide about the "named" dvips question?

and I should also look again at separations on the dvips route.

@UlrikeFischer Ah, that, yes

@UlrikeFischer OK, I'll think about that

@UlrikeFischer Yes, but that's not critical for fixing the interface for creating Separations

@JosephWright no, the interface looks fine.

@JosephWright key val is nice ;-)

@UlrikeFischer I was thinking that merging is OK now as we have the basic idea down and there is no loss of function: improvements can be added in on master

@JosephWright it is fine with me. Could someone be affected by the changes in l3draw?

@Skillmonlikestopanswers.xyz Luckily we did this a while ago and students are informed. Students relying on forward was already a problem at a student might not have noticed that their external email had reached a quota limit, so the forward would fail. Now they are required to read their university mail.

@DavidCarlisle someone is looking for you tex.stackexchange.com/q/557752/3929

Apparently \epsfig related

@UlrikeFischer Yes in priniciple but it is experiemental

@daleif but that lies in the liability of the student. As it currently is, the university would have to take full responsibility for anything email related (unless they can prove that a student has indeed fetched mail at least once since then)

@yo' 90s are calling?

@Skillmonlikestopanswers.xyz funnily enough, this looks like a screenshot from a recent version, and the wordarts are still the very same :D

@yo' yes, I guess they don't change them anymore.

@Skillmonlikestopanswers.xyz Sending l3kernel update to CTAN: faster keyval for everyone

Inspired by @cis question about old manuals for TikZ, I did a bit of archeology on circuitikz and added all the manuals for the old versions... circuitikz.github.io/circuitikz . Thanks @cis, I reckon that could be useful sometimes!

@JosephWright not as fast as it could be :( But as I already said elsewhere, I understand if you don't want to, but don't understand your arguments on why you don't want to.

This is one for the PDF experts... this screenshot shows the same PDF:

@Skillmonlikestopanswers.xyz I can see both sides: the balance between speed and readability

Could this be an effect of an error on my side?

The code is really simple

\documentclass[border=10pt]{standalone}
\usepackage[siunitx, RPvoltages]{circuitikz}
\begin{document}
\begin{circuitikz}[line width=3pt,european]
    \draw (0,0) to[R]++(2,0)to[R]++(0,2)--++(-2,0)to[R,-.]++(0,-2);
    \draw[red,line width=1pt] circle(2mm);
\end{circuitikz}
\end{document}

@JosephWright still I don't see how \tl_set:Nx \l_tmpa_tl { \exp_not:o \l_tmpa_clist } is any more readable than \cs_set_eq:NN \l_tmpa_tl \l_tmpa_clist, or how \tl_set:Nn \l_tmpa_tl { \q_no_value } is more readable than \cs_set_eq:NN \l_tmpa_tl \q_no_value, when the big point about quarks is, that they are defined as \cs_new:Npn \q_no_value { \q_no_value }. And the argument "don't mix datatypes for the manipulators" for this seems rather odd, given that using \tl_set:Nx on a clist is ok.

@Skillmonlikestopanswers.xyz That one I agree with: leave it with me ;)

@JosephWright I understand the arguments against currying (well, I sort of understand them). But the kernel curries all the time, and with good reason. So I'd think that currying for internal macros is fine. But hey, the kernel also curries for interface macros (think \clist_map_inline:nn). So if currying is ok, then why is currying not ok?

@Skillmonlikestopanswers.xyz That's largely historical: it's convenient until you are \tracingall

@JosephWright the kernel will experience a major slow down if you start to explicitly grab all those curried arguments.

@JosephWright the only things I'd understand are the \cs_set_nopar:Np(n|x) where we already know that the argument is or will expand to a string and it is not directly apparent. I did change some where the structure is something like \cs_set_nopar:Npn \l_tmpa_str { #1 }. #1 is always an expanded string variable, so I figured it wouldn't hurt (and I left a comment in the documentation about that where applicable), but those really can be harder to maintain/understand.

Where this isn't the case is for something like \cs_set_nopar:Npx \l_tmpa_str { \__keys_trim_spaces:n { #1 } }, when the first thing \__keys_trim_spaces:n does is \tl_to_str:n. I don't see any advantage of using \str_set:Nx there, except when the objective is to slow down the code.

@Skillmonlikestopanswers.xyz That's about the idea that as far as possible we should stick to the data types: for example, if you use \cs_set_nopar:Npx you rule out the tests when debugging is active (and which have caught internal errors in the code in the past)

@Skillmonlikestopanswers.xyz It's the old 'relies on implementation' business: what happens if we change how str is implemented?

@JosephWright if you'd do, things like expanding \tl_to_str:n once and relying on it returning a string in one expansion would break as well, which would break half of the kernel code with strings anyways (and certainly l3keys, with \str_set:Nx or without).

@Skillmonlikestopanswers.xyz Possibly, although \tl_to_str:n doesn't necessarily have to have the same implementation as str data types

@JosephWright yes, but the kernel also relies on the str data type to expand in one expansion to the string on several places...

@Skillmonlikestopanswers.xyz I think in part it's about needing to show that performance is critical. For example, the FPU does use every trick available as otherwise it would be too slow. I guess Frank is just not convinced

@Skillmonlikestopanswers.xyz I accept that: it's documented as a special case of tl, and the latter is documented as expanding in one step. But other than in set-up, variables are all handled 'correctly', so at least with \tl_set:Nn or similar (both clist and str are special tl subtypes, so they are a bit tricky there)

@JosephWright performance is always critical. So much software nowadays assumes that it isn't "because we have more powerful machines". The results of this line of thought is bloated software that might run on your PC, but if you want to run two other programs (which are equally bloated) your PC starts to stutter. I have full understanding if someone isn't experienced enough to program efficient code (depending on the language I'm failing in this regard as well) [...]

@JosephWright [...] but programming inefficient though one knows better out of laziness (and using \str_set:Nx instead of \cs_set_nopar:Npx in internal code for something one can determine will always be a valid str is lazy, imo) for software used by many and often, that I don't understand.

@Skillmonlikestopanswers.xyz Following that logic to the extreme, one goes down the route that wipet prefers: sticking to plain and explicitly coding for each case. For example, \tl_set:Nnis less efficient than \cs_set_nopar:Npx (\edef), so in cases where you don't have # tokens one could skip it ...

@Skillmonlikestopanswers.xyz ... or more seriously, the entire conditional set up isn't as fast as TeX primitives, and in many places one could use them without the 'pre-absorbing' approach, as most arguments don't contain unbalanced conditionals. My point being there is a balance here.

@Skillmonlikestopanswers.xyz Like I said, \cs_set_nopar:Npx has no support for debugging (scope checking, requiring variable to be declared, etc.)

@JosephWright if you can guarantee that there will never be a # anyways? Take a look at \str_set:Nx for example. It expands to \exp_args:NNx \str_set:Nn. So far this is fine. Then you call \tl_set:Nx with \tl_to_str:n in its argument. Seriously? What is the advantage here above \cs_set_nopar:Npx #1 { \tl_to_str:n { #2 } } when the scope checking etc. is already dows by \str_set:Nn in debugging mode?

@JosephWright All that is missing would've been to declare \tl_set:Nx as \exp_args:NNx \tl_set:Nn, but that was shortcutted...

@JosephWright Depends. For a user-interface macro? No, put safeguards there. For internal code? Why not use something faster when you can always guarantee it will be fine.

@Skillmonlikestopanswers.xyz There's the whole 'as far as we can, the kernel should stick to the rules' business

@Skillmonlikestopanswers.xyz I'm quite happy to look again at the str stuff: you are right that it could be faster (generally)

@JosephWright then define \tl_set:Nx as \exp_args:NNx \tl_set:Nn #1 { #2 }.

@JosephWright the kernel is already making compromises for speed over the formal approach it is proclaiming (which I'm very happy about)

@JosephWright Most likely the loops in \clist_map_... and \seq_map_... can be made faster as well (except for \seq_map_inline:nn, that one looks very good). I understand the formal approach with \q_recursion_tail, but it is slow to test against it in each iteration.

@JosephWright better use the #1 \q_nil <function> , \q_nil <break> approach, which is also used in \tl_trim_spaces:n (and most of the loops written by myself). Come to think of it, I should take another look at \keyval_parse:NNn (and expkv), maybe I can make it faster in this regard as well (will require some time).

@Skillmonlikestopanswers.xyz I know :)

@Skillmonlikestopanswers.xyz I'm sure ideas would be welcome: the reason for quarks in the first place was to allow fast testing

@Skillmonlikestopanswers.xyz Bruno has done quite a bit of that type of shortcutting I think

@Skillmonlikestopanswers.xyz I guess this is one place performance wins

@Skillmonlikestopanswers.xyz Almost all internal variable use does stick to using the accessors, though

@Skillmonlikestopanswers.xyz I think a post to the team list would be useful to get this all thrased out with input from e.g. Chris and @DavidCarlisle

@JosephWright well, there is a fine balance which one must keep in mind. The test for a quark with tests like \quark_if_recursion_tail_stop:N or similar are slower than testing with TeX's argument grabbing logic, but at the same time the approach taken by \tl_trim_spaces:n and similar is, that they grab the entire argument on each recursion, and grabbing long arguments is again slow. So there is a trade off, and at one point testing against quarks is faster.

and with possibly very long clists, testing against quarks is again the better approach.

But I'm pretty sure that the code for a recursion tail test with \__clist_if_recursion_tail_break:nN could be made faster (I'll take a look this evening, maybe)

@JosephWright sorry, that you took such a rant from me... I'm very grateful of what the team does, though I might sometimes disagree on the nitpicking details, all in all I really appreciate you guys!

@Skillmonlikestopanswers.xyz Like I say, perhaps one for the team list, as people like Bruno can then chip in

@Skillmonlikestopanswers.xyz Partly comes down to have speed-critical stuff is: defining keys less so, setting them more so as they become more widely used

@Rmano Seems like pdf.js does something strange. Does pdfium (Chromium-based browsers) also exhibit this behavior? If all other viewers are showing it correctly, maybe report it in the pdf.js repo.

@JosephWright in that case, just a few things which are used on every entrance (which is e.g., affecting the meta keys, etc.) and don't destroy readability as much will make quite a bit of a change, that is \use:e instead of \use:x, \cs_set_eq:NN \__keys_relative_tl \q__keys_no_value. But a big effect is indeed the usage of \str_set:Nx <foo> { \__keys_trim_spaces:n { #1 } } instead of \cs_set_nopar:Npx on many occasions. And I really don't understand the aversion against currying.

@TeXnician Yep, Chorme shows it correctly. I suppose the repo is github.com/mozilla/pdf.js/issues ...

@Rmano Yes, that's it.

@Skillmonlikestopanswers.xyz On the last point: \tracingall the code and track what the arguments are :)

@JosephWright Your fault for \tracingall :) Just stare at the source code and determine what it does!

@TeXnician Thanks, done --- github.com/mozilla/pdf.js/issues/12185

@Skillmonlikestopanswers.xyz Honestly, raise on the team list: one can argue that for the core material it's worth it, just depends on what you feel the 'core' is (FMi would say l3basics, l3tl, l3expan I suspect)

@Rmano Aha.... I don't remember. But I am glad to hear... :()

@cis I guess @Rmano meant AndréC's question on old TikZ manuals.

(What among others lead to tex.stackexchange.com/q/557049/124577.)

@TeXnician Aha².... Not bad either. :()

@TeXnician Yep. Correct. Mixed @ --- sorry

@JosephWright you mean the currying?

@cis Oops. Wrong attribution, sorry

@Skillmonlikestopanswers.xyz Yup

@JosephWright I mean, not currying in many cases makes much sense (imagine not currying \tl_set:Nx, that might go horribly wrong), but in case of simple argument grabbing without a p type (or any #1#) involved...

Rare photo of @JosephWright as a duckling

> Ice Cream Deserves to Be Eaten From a Mug: lifehacker.com/…

> Frances E. Allen, the First Woman To Win the Turing Award, Dies At 88

@PauloCereda -- Aaarrggh. This is an "automatic" comment. Better: "We have a stop sign here because there have been three fatal crashes at the intersection and the insurance companies are suing the county."

@barbarabeeton oopsie

@PauloCereda yeah :(

@yo' :(

Brewing: twitter.com/BLprintheritage/status/1291685724660674560

@PauloCereda ^^^

@Rmano Reminds me of the useless machine.

drive.google.com/file/d/1lW1XvjSEkahMz0VQvy4vhu8Z5SnfrS3M/…

@cis saw a very interesting useless machine recently with randomized movement patterns.

@Rmano -- I've seen this photo before. Now I want to find out where it's located.

@cis I built one of these some ten years ago with some leftover flooring boards and gears and an electric motor from a broken printer. It was a fun project (and useless, of course :-)

@JosephWright oh, just a last stupid question: How do I raise a question on the team list? I'm not part of the team list, neither do I know an address (except for the one shown on latex-project.org, but that one should only be used for four things, none of which is "discuss implementation details").

@barbarabeeton google image search gives zillions of hits, and I can't find a way to restrict it to google maps images... ;-)

@Rmano -- Too bad. I know a couple of places where this could plausibly be, and it would be fun to go visit.

@barbarabeeton I am not so sure it is real, either... there are a lot of similar images with the last line (the \footnotesize one) different.

@JosephWright should be about 13 to 14 % faster (for the nTF variant, others not benchmarked):

\cs_new:Npn \__tl_if_empty: { \__tl_if_empty:w \q_nil }
\cs_new:Npn \__tl_if_empty:w #1 \q_nil \q_nil
\cs_new:Npn \__tl_if_empty_true_tf:w \q_nil \q_nil \use_ii:nn #1 #2 { #1 }
\cs_new:Npn \__tl_if_empty_true_t:w \q_nil \q_nil \use_none:n #1 { #1 }
\cs_new:Npn \__tl_if_empty_true_f:w \q_nil \q_nil \use_i:n #1 { }
\cs_set:Npn \tl_if_empty:nTF #1
  {
    \exp_after:wN \__tl_if_empty: \tl_to_str:n { #1 }
      \q_nil \__tl_if_empty_true_tf:w \q_nil \q_nil \use_ii:nn
  }
\cs_set:Npn \tl_if_empty:nT #1

@Skillmonlikestopanswers.xyz latex-team@latex-project.org will reach everyone

@JosephWright I'm pretty unsure of what to write in that email :(

@JosephWright :( the \tl_if_empty:nTF above is only faster for non-empty token lists of up to 4 tokens. As soon as I drop the \tl_to_str:n from it and say it only fails for token lists containing the tokens \q__tl_nil and \q__tl_mark directly following each other, I'm always faster (and get more advantage the longer the argument is, actually), but that is reduced stability :(

@JosephWright for me, the current master branch is failing several tests (I suppose the recent color changes are at fault)

@TeXnician github.com/mozilla/pdf.js/issues/12185#issuecomment-670718139 wow, fixed even before the bug report ;-)

@JosephWright forget about it, I had some unstaged changes...

@Rmano Glad that the issue tracker helped :)

@PhelypeOleinik your new version check code just hit me ;-)

@UlrikeFischer That's good, I hope :-)

@UlrikeFischer The one in master?

@PhelypeOleinik well it didn't quite say the truth, my problem wasn't a stray format but that I had just installed from master but not updated the formats yet. But imho it is quite nice that there is a check if both are in sync.

@UlrikeFischer Ah, right. The code in the version-check PR does give that as a possibility:

  The~most~likely~causes~are:
  \\~-~A~recent~format~generation~failed;
  \\~-~A~stray~format~file~in~the~user~tree~which~needs~
       to~be~removed~or~rebuilt;
  \\~-~You~are~running~a~manually~installed~version~of~#2 \\
  \ \ \ which~is~incompatible~with~the~version~in~LaTeX. \\

@PhelypeOleinik you didn't add "or blame Ulrike" ;-)

@UlrikeFischer I just listed the causes. That's a solution :-)