If you insinuate that %q obviates the need for ldump then you are wrong.
There is not even significant overlap in what they do; all that %q does is sufficiently escape Lua strings so the interpreter can read them back. It does not serialize functions nor even tables in any shape or form.
edit: Sorry for being unreasonably harsh after misunderstanding your message.
On my machine it produces an equivalent string, although differently formatted. It seems that ldump preserves all special characters (`"\a\b\f\n\r\t\v\\\"\'"`), although I will need to test in on all supported versions.
Ah, you know what, you're right. It's an equivalent string for me too:
"hi\
"
I didn't know Lua treated \ before newlines like that. That's cool! I made a similar Lua serialization library for myself and was using a chain of `string.match` calls to escape my strings. Now I can make it way simpler. Lol. Thanks
I felt this way for a long time, until a couple years ago. Talking with your mouth uses a completely different part of your brain than talking with your fingers. There's pros and cons to both methods. It's nice to have an ace up your sleeve when your competition is other nerds with great writing skills.
yeah many people don't understand how cheap it is to use the chatgpt API
not to mention all of the other benefits of delegating all the work of setting up the GPUs, public HTTP server, designing the API, security, keeping the model up-to-date with the state of the art, etc
reminds me of the people in the 2000s / early 2010s who would build their own linux boxes back when the platform was super unstable, constantly fighting driver issues etc instead of just getting a mac.
roll-your-own-LLM makes even less sense. at least for those early 2000s linux guys, even if you spent an ungodly amount of time going through the arch wiki or compiling gentoo or whatever, at least those skills are somewhat transferrable to sysadmin/SRE. i dont see how setting up your own instance of ollama has any transferable skills
the only way i could see it making sense is if you're doing super cutting edge stuff that necessitates owning a tinybox, or if you're trying to get a job at openAI or anysphere
Depends on what you value. Many people value keeping general purpose computing free/libre and available to as many as possible. This means using free systems and helping those systems mature.
There are similar superstitions around proprietary software, I hope one day you are able to overcome it before you waste too much of your precious time
Unfortunately the "tabs not working in non-native fullscreen" thing is a dealbreaker for me, so I will be switching back to iTerm 2.
But Ghostty as a whole looks promising. I like zig, zig-objc, MIT license, libghostty, config via text file. I will check back every month or so because I really want to use this. But my hate for macOS native fullscreen outweighs everything else.
IIRC you can even use AppKit to remove the close/minimize/fullscreen buttons, so it would just be a blank bar.
You could go a step further and use private APIs / objc runtime voodoo to set the height of the titlebar to 0. That might outside your design philosophy though.
Also, FYI, clicking the green fullscreen button still uses macOS native fullscreen, so you definitely want to disable that button (which is a public AppKit API) when you have that option enabled
Can someone link me to an article that explains why C is basically frozen at C99 for all practical purposes? Few projects worth talking about leverage features from C11 and newer
C99 is still new! Microsoft tried to kill C by refusing to implement anything that wasn't also in C++. MSVC was 16 years late implementing C99, and implemented only the bare minimum. Their C11 implementation is only 11 years late.
I suspect that decades of C being effectively frozen have caused the userbase to self-select to people who like C exactly the way it is (was), and don't mind supporting ancient junk compilers.
Everyone who lost patience, or wanted a 21st century language, has left for C++/Rust/Zig or something else.
Most of us liking a good language just did not use MSVC. I do not think many people who appreciate C's simplicity and stability would be happy with C++ / Rust. Zig is beautiful, but still limited in many ways and I would not use it outside of fun projects.
I don't even use Windows, but I need to write portable libraries. Unfortunately, MSVC does strongly influence the baseline, and it's not my decision if I want to be interoperable with other projects.
In my experience, Windows devs don't like being told to use a different toolchain. They may have projects tied to Visual Studio, dependencies that are MSVC-only or code written for quirks of MSVC's libc/CRT, or want unique MSVC build features.
I found it hard to convince people that C isn't just C (probably because C89 has been around forever, and many serious projects still target it). I look like an asshole when I demand them to switch to whole another toolchain, instead of me adding a few #ifdefs and macro hacks for some rare nice thing in C.
Honestly, paradoxically it's been easier to tell people to build Rust code instead (it has MSVC-compatible output with almost zero setup needed).
Microsoft basically sabotaged C99 by not implementing any of its features until around 2015 in the Visual Studio C compiler, and then still took until 2019 before they acknowledged their failure and started supporting more recent C versions again (MSVC is still reliably behind Clang and GCC when it comes to their C frontend though).
And back around 2010 MSVC still mattered a lot (which sounds weird from today's pov where most developers appear to have moved to Linux).
But OTH, few projects actually need C11 features (and C11 actually took one thing away from C99: VLAs - nothing of value was lost though).
C23 might be the first version since C99 that's actually worth upgrading to for many C code bases.
C11 gave us one very important thing: a standardized memory model! Just like in C++11, you can finally write cross-platform multithreaded code with standardized atomics, synchronization primitives and threads. Unfortunately, compiler/library support is still lacking...
I digress but my autistic brain couldn't help itself. Provided that it's a recursive lock you could do this instead of adding a new method `foo.BarBaz`
foo.lock {
value = foo.bar() // foo.lock within this method is ignored
if(value.bat()) {
foo.baz() // foo.lock within this method is ignored
}
}
Also, to catch this bug early, you could assert foo is locked in `value.bat` or something. But that may or may not be feasible depending on how the codebase is structured
reply