I probably already posted this but since I'm working on a paper I'll say again that one of the best paper-writing life hacks I've learned in the last long time is this makefile target that makes latexmk rerun every time you touch a dependency and then pushes the result out to the PDF viewer (which should be configured to re-render when the file changes):
@regehr For me, latexrun is a recent life-changing discovery: the way it presents latex warnings and errors in a nice readable way is unparalleled. It doesn't offer a "background monitor" mode like 'latexmk -pvc' on its own, but one can use inotifywatch for that purpose. https://github.com/aclements/latexrun/
Fun fact: there are at least five distinct choices for type T (not counting typedefs) such that a C compiler targeting a POSIX system cannot optimize out the call to 'aux' in
Apparently #Gentoo's sys-apps/sandbox (which ensures ebuilds don't make a mess outside of their build "sandbox") had a huge performance regression which caused webkit-gtk build times to go from 9 minutes to 1 hour.
After collecting a ton of data, applying patches, reverting patches, etc, I filed https://bugs.gentoo.org/910273 and it seems we have a fix.
Ugh, groff 1.23 removes color from man pages. Using bold and underline text attributes makes more sense in theory, but the monochrome text is much harder for me to read.
@wolfpld@pervognsen Perhaps you have colors configured in the LESS env var? But then I don't see how you'd get proper colors in bat.
groff-1.23 removed 'sgr 0' support, while Arch used to rely on it in groff's man.local to make it output traditional backspace-overstrike instead of ANSI escapes (and then configure 'less' to colorize those).
I think you could try GROFF_NO_SGR=1 or MANROFFOPT=-c to get the previous behavior.
Reminder: a #kernel where uname -r prints something like "5.15.0-71-generic" is a vendor kernel that is likely quite different from #Linux 5.15.71[1].
In case of problems with such a kernel you thus must report them to your vendor.
That's because almost all upstream #LinuxKernel developers don't care about problems in such kernels, as they might happen due to modifications the vendor applied.
[1] it in fact is likely based on a much later Linux 5.15.y release
something I frequently gripe about is how bad SMT solvers are at answering queries about IEEE floating point problems. a recent paper "SMT-Based Translation Validation for Machine Learning Compiler" uses a CEGAR-like approach to refine an initially-coarse FP abstraction, and this seems to work well. anyone know if that sort of technique is available off the shelf anywhere, so we don't have to re-implement?
@Doomed_Daniel@rygorous@steve@regehr@griotspeak As multiple people commented in that thread, people have been running SPEC on x86 with gcc -ffast-math for 20+ years, competing against ICC. And this 2021 LLVM issue only surfaced on arm64, not x86.
In fact, I would go as far as saying that "don't break SPEC" was the single unwritten rule for -ffast-math in GCC until recently. Now there are no rules.
@Doomed_Daniel@rygorous@steve@regehr@griotspeak Outside of standards-conforming mode (without -std=c99 or the like on the command line), GCC defaults to -ffp-contract=fast, which is probably worse than you think. It allows contraction across statements, leading to very spicy and buggy interactions with optimizations after some statements have been duplicated:
have a look at https://gcc.gnu.org/PR106902 if you have the time.
