Modern chat systems, whether direct, group, or community, fail to capture the joy of 90s IM systems for me.
The inherently synchronous experience, knowing that the other person was also sitting at their PC on the other end, made it much more like hanging out in person than any modern system.
@thelastpsion cool! I haven't used it much instead of C++ but it is great that it doesn't depend on a complicated compiler like #GCC or #LLVM and still does quite well.
Back to work on packaging @hare for @fedora, let's see how much I can bang out in a few hours. The resulting artifacts are going to be fairly simple, but not particularly packager friendly. That's a day-2 project.
New cross-compile meta packages for #GNU and #LLVM dependencies.
I've created a convenience script, harex, to switch to non-GNU toolsets. Just set HARE_XCOMPILE_TOOLCHAIN to "llvm". User specified env vars will still be respected.
Gosh, I love #Libretto’s so much but they’re basically unobtainium at this point and becoming ever more fragile. https://youtu.be/xfMrqJwuMX8
I like trying to find the balance between minimal and usable in old tech. I have a beautiful Dell X200 which just straddles the line of obsolete and modern as even though it’s an 800MHz PIII it can connect to WiFi and run a browser barely new enough to access the web. #RetroComputing
Have you ever tried to compile an old piece of software that first required compiling an old compiler which itself required an old environment that you can't reproduce? #GCC & #LLVM all work within very narrow bands of time, platforms and environments that shift constantly, meaning that the aparant portability of C/C++ is unusable in practice for any non-current OS. #retrocomputing#cpp
Totally, and the #nanopass framework is a joy to use. While I'm starting to get interested in #LLVM, primarily because the learning resources are immense, I'm not sure why anyone would choose it except for very low-level matters, or targeting something like SPIRV.
> add LLVM CFI and cross-language LLVM CFI (and LLVM KCFI and cross-language LLVM KCFI) to the Rust compiler as part of our work in the Rust Exploit Mitigations Project Group. This is the first cross-language, fine-grained, forward-edge control flow protection implementation for mixed-language binaries that we know of.
I'm playing with #llvm - trying to follow what it's doing in #mesa compiling OpenCL shaders. Now, I've taken the debug IR dump from the AMD driver and written that to a .ll, fed it into llvm's 'llc' program and thrown it --debug (after building my own llvm build). Now just a 36700 line debug file to look at 🙂
scratch86 is a super fast compiler for MIT #Scratch projects--- it's meaningless to so much as try to compare to the standard Scratch interpreter. scratch86 compiles projects directly to #LLVM IR, and the Scratch standard library is handwritten in C.
It's one of these days when upstream fixes a very old bug and you suddenly have to figure out how your ancient workarounds used to work and what to replace them with.
Fortunately, it looks like we just need to replace /usr/lib/llvm/${LLVM_MAJOR}/$(get_libdir)/clang with /usr/lib/clang.
The only problematic part is that the testing of an LLVM bump takes a few hours, and now it's blocked on manual intervention.