In expl3, if I use V expansion on a boolean, the result is 0 or 1 which is fine, but I can then not access this value using \bool_if:nTF it seems

So, I should probably not use V expansion, but something like bool_if_q:n?

The answer seems to be yes. At least this way it works

I wonder whether V expansion of booleans shouldn't expand to \c_true_bool or \c_false_bool?

This discussion on character sets is something which may interest some people here (at least, it interested me enough to want to share...) retrocomputing.stackexchange.com/questions/31315/…

@JasperHabicht Yes

Ah, manual says: v type expansion is not supported for bool. I guess there was a long discussion about this

@JasperHabicht There is no \bool_use:N so there is no V-type support

@JosephWright Yes. Makes a lot of sense

@JosephWright @DavidCarlisle blames you for things he doesn't expect when you are not here ;).

@cfr :)

@cfr I'll take a look in a bit - just rebuilding .tlg files ATM

@JosephWright or you could blame him for what he expects?

it is not what I expected either, but that is par for the course so I am probably not worth the trouble of blaming.

@cfr :)

@DavidCarlisle FMi

@cfr, @DavidCarlisle I'll see if Frank remembers why he set it up this way

@JosephWright it looks like it is designed to handle dos text file tests on linux, but I'm not sure why

@DavidCarlisle We could change in l3build without impacting on the 2e repo: the latter uses it's own test2e.tex definition

@DavidCarlisle I wonder if it was to do with @UlrikeFischer's need to use Windows files - but as they are all generated files, I don't see where the issue comes from

@JosephWright you mean about \SHOWFILE? I don't remember any discussion about that. When was the ^^M implemented?

@JosephWright yes my thought was to blame @UlrikeFischer's tests but like you I couldn't see a workflow where this would show up

@cfr as you see from the above, it may be that we can blame Frank or Joseph or Ulrike, but the important thing to take away from your question is: don't blame me.

Why are you \SCREAMING so much these days? ;)

@DavidCarlisle Quite

@UlrikeFischer Frank Mittelbach 6 years ago (September 28th, 2018 10:45 AM)

@UlrikeFischer SHA 3e11288bb8c070ce93893229f92992dbcf91596a

@UlrikeFischer github.com/latex3/l3build/commit/…

@JosephWright can't be me, I joined in october 2018 ;-)

@UlrikeFischer :)

@cfr Could you log an issue about \SHOWFILE with an example of the issue - best to discuss there rather than here or on the team list (not visible to others)

@cfr ?

@cfr (@DavidCarlisle, @UlrikeFischer) I will though also prod Frank directly

@cfr but why are the ^^M a problem for you? I saw them too in some texts (e.g. when I show the created mathml in some tests) but I simply ignore them. From a point of the test the only thing that matters are changes ,

@mickep because unit tests don't like to be ignored.

@Skillmon OHH!

@mickep all the commands defined for unit tests are in all uppercase.

@UlrikeFischer scary and monstrous!

(from the tooltip point of view)

@UlrikeFischer Ȧ̇̇̇̇̇

@UlrikeFischer A̸̡̭̜͈̠̽̓̐̚A̵̢̟̲̾̈́̏̂͑̚A̷̻͆̈́̎̀̓̈́͗̐͛̌̍͂̕̕͝Ả̵̡͇̫̜̗̭̜͇̖̱̗̝͓̘͋̈́̓̏Ǎ̵̡̡̢̼̖̝͕͎̗̟͎̙̽͋͊́̀͗͘͠A̷̡̳͔̯͈͖͙̦͕̪̎͋́̎̂̌̉̈́͐̅͝ͅͅȂ̷̻̾̓͂̿A̵̧̦̘̹̩͇̼̱̞̻͆̿͒͠Á̸̧̺̘̯̙͈̠͙͜ͅȀ̷̛̰̭͙̯͔̗͕͍̟̖͍̑́A̸̤̾͆̑Ạ̴͍͈̱͚̜͉̞̒͛͛̒͋̑͝͝͝

scream cipher with unicode support?

@UlrikeFischer AAH, very well!

@Skillmon Oh, does it compile?

@mickep With LuaLaTeX and Noto Sans ... yes

@JasperHabicht Beautiful!

It is actually Chinese using the above cipher ...

Getting back to xbeamer: hopefully I can sort out 'decoding' the overlay spaces this week

Really want something I can use for my own lecture slides by the summer

@JosephWright with the risk of me not being productive (there or anywhere): keep me posted and ask for help if you need me.

@Skillmon :)

@Skillmon I want something that vaguely works before I check it in: I get the feeling there will be several rounds of refinement (\beamer@masterdecode does various things, and I'm getting the sense they might need to be separated out, at least outside of the 'innards' of reading overlays)

@JosephWright the problem (and advantage) most likely is that I don't know the innards of beamer and only the macroscopic behaviour, so I'd implement something most likely completely different on the architecture side that only behaves similar from the users' perspective

@Skillmon Don't worry - the plan as it stands it more about the user behaviour than the inners, and even then some of the user behaviour (some aspects I think don’t make sense to carry forward for a new class)

For overlays, I will try to get something similar to the current parser, but I am writing from scatch

@JosephWright good, and agreed :)

(remember that I'm part of the xbeamer "team", so I know that the plan is to implement user behaviour, not innards, I'm just one of the guys interested in the project who knows almost nothing of the beamer innards, unlike you and @samcarter)

So for me it comes quite naturally that I don't (re)implement some internal structures because I simply don't know beamer's

@Skillmon :)

@Skillmon best preconditions for a procrastination project

@UlrikeFischer er ... mostly because I didn't expect them. and I didn't realise l3build rewrites a tlg for lua, so not only I had differences I didn't expect at all, but I also have engine differences I didn't expect, including weird characters showing up for xetex and pdftex, but not luatex. and these are showing up in the logged content of .memos, which are identified by checksum, so could not figure out where things diverged. (actually, I still don't know why I now need different tlgs.)

@JosephWright but is it an issue or just user ignorance?

Someone broke CTAN?

@cfr Well if you have a problem using the function, then somewhere we need to change something :)

@PauloCereda AAAA

I thought the on/off switch on the mac mini was a design failure, but it turns out it is an opportunity to add a duck face: chaos.social/@mattgrayyes/114059399751614594

@samcarter :D

@JosephWright yes, but you could change the user.

@cfr :)

@JosephWright does the doc say anywhere that l3build writes an additional .luatex.tlg if there is only .tlg? it talks about additional normalisation for lua, but I interpreted that to mean additional changes to .luatex.log.

@cfr That's not LuaTeX-specific - we need to write a .<engine>.tlg for any case where you do l3build save -e<engine> <test>, as that's how we handle engine variations

@cfr The standard 'extra normalisation' does indeed mean what we do for the .log in a LuaTeX run, to get the standard .tlg files to support as many engines as possible

@JosephWright ?

@cfr I was not sure what you meany by 'public things and hooks'

@JosephWright that isn't what I meant though. if I do l3build check, l3build writes a .luatex.tlg in testdir.

@cfr Oh, in the scratch space - yeah, we do that for each engine

@JosephWright really? do the others get deleted?

@JosephWright you were going to look at it, but for now I just duplicate code from l3build and use @DavidCarlisle's hack to avoid the text files being copied twice by ctan.

@cfr Oh, no,maybe we do only do this for LuaTeX - key is this is just an implementation detail to allow us to use the same .tlg files for LuaTeX and other engines - what's the issue for you?

@cfr Ah, right - I guess I should look at that

@cfr Did you log an issue? I forget the details

@JosephWright it is confusing if you don't expect it. I could not figure out where the additional .tlg came from. I do not like files to appear on my system which I do not expect. If I get changes I almost always run diff on the normalised log and tlg directly, because I get more information that way and in a format I understand better. so then I notice what is in the directory and I try to figure out where this extra file has come from ....

@cfr The whole of the build tree is meant to be scratch stuff - we don't document the whole copy approach, just that it happens, for example

@cfr To enable us to run diff/fc, we need a file to compare against, so for LuaTeX we need a modified copy of the std .tlg - there's no other way to pull this off

@JosephWright yes, but you explicitly tell users to look at diffs if tests fail, so it matters if you are diffing files other than they have reason to expect.

@cfr Er, the assumption is the files being compared are not important (nor are the baths), it's the content

@JosephWright I'm not suggesting you not do it. only that I think it would be helpful to say so when you explain the additional normalisation done for luatex.

@JosephWright but the content of a diff is a function of the files being compared. suppose somebody wants more context, for example, in order to figure out why something changed. the obvious thing to do is to run diff on luatex.log and the tlg. (this is essentially what I do to get a comparison in standard diff format.)

@cfr Er, I guess we work differently: my obvious thing to do is take the .lvt, copy it into my scratch test.tex file, run that, then look manually at the log

@JosephWright I hardly ever do that. for one thing, I already have a copy of the raw log in many cases. but, also, often I don't need that much. I just need a bit more than the .diff has.

@JosephWright please.

@cfr I suspect this partly reflects the fact I treat l3build largely as a black-box - in part as on GitHub we can't get the info directly, and that's usually where problems come up for me :)

@JosephWright I archive the test files and download them. this is much faster than re-running them locally.

@cfr You mean the artefacts, I guess: the test files you already have :)

@JosephWright sorry, yes. the files in build/test.

@cfr :)

my tests are extremely inefficient because I do not know how to write them properly.

@cfr github.com/latex3/l3build/commit/…

@JosephWright thank you!

@JosephWright I guess I'm with @cfr here I always look at the generated logs in build (and rarely use -save as if a test fails and I want to update the tlg I just copy the foo.luatex.log file from build area to testfiles/foo.luatex.tlg