PhilipRoman

1) You can use interpreted version for rapid development and switch to compiled for release

2) You may like Lua as a language and want to use it for general purpose programming, not necessarily embedding into host program

I will say though that the performance aspect has to be taken with a grain of salt, "native compilation" is not a meaningful improvement if every source line translates to multiple branches or vtable lookups. From my experience plain conversion of Lua to C (assuming you faithfully follow the specification, including coroutines, metatables, etc.) produces equal or slower code with rare exceptions for numerical loops. If it wasn't all AI generated I'd maybe spend time understanding this project.

Maybe that wasn't the best example since you cannot even cast to a function pointer within standard C (but you can in POSIX). If you consider POSIX as portable then writing your own dlopen is pretty simple and you don't even need to be aware of calling conventions, though there are some architecture specific things in the ELF format. But either way it will not integrate well with mechanisms that people expect to work like LD_* environment variables, /etc/ld.so.conf and so on. So I still think it matches the "possible but will not integrate with rest of the system"

Emitting strings is fine, it's the parsing that sucks.

Case in point: echo y | LANG=lv_LV.UTF-8 grep '[a-z]'

I would say there are 3 broad classes of libc functions

1) functions that you cannot implement in portable C - syscalls, signals, ABI specific things like longjmp and setcontext

2) functions that you could implement by yourself in portable C, but they are expected to play nice with the rest of the system - a lot of POSIX user stuff, dns management, dlopen, all the nsswitch mess. Can't think of any standard C examples because of the extreme portability requirements of C. Maybe the locale stuff, although it's usefulness is dubious.

3) functions that are there for convenience and sometimes compiler special-casing, like math, str*, <db.h> stuff that was thankfully removed from glibc

Most of #3 should be ignored. #2 is optional, especially if your software is for end users and not packaged by a distro. Sometimes it's safer to ship your own MDNS implementation for example rather than hope that the distro has sane defaults.

I'm curious why do you need manual intervention after a power cut. Isn't configuring bios enough for this?

another comment on a different HN thread pointed out a similar issue. Now I'm wondering if backdrop-filter can be used correctly at all or should just be avoided entirely

GitHub could make it the default for new repositories created via web UI and devs who don't touch the CLI probably wouldn't even notice

I'm in the process of building one myself. Take what I'm saying with a massive grain of salt, but I believe you basically need three things - objective, tube lens and a camera module.

If I were you, I would probably buy a normal microscope that supports a microscope camera attachment, instead of specifically looking for USB microscope. There is a lot of misleading marketing around USB microscopes, a lot of them are literally just doing digital zooming in (I have a 30€ "1000x" microscope from Amazon which is nice for soldering and such things, but these fake microscopes appear even at higher price ranges). Treat anything >1000x for light-based microscopes as a red flag.

In C, const can also answer B, but only in non-pointer contexts.

The doc won't point it out explicitly and I apologize if my explanation offends anybody, but the intention is basically leftist, state-friendly bitcoin. The authors took a look at the anarchy of real cryptocurrencies and realized they don't actually like anarchy, so instead they want to make something "wholesome" that governments would be willing to go along with (since they can tax it).

They are funded by EU and banks in an attempt to claw back some market share from cryptocurrencies which are slowly getting banned.

The way caches are managed in CI is bonkers (at least in GitLab, but GitHub probably does the same). I guess it's built to conveniently work with the simplest of projects. I had to reimplement the mechanism by hand just to get basic things working, like not downloading the entire cache when only a few entries will be used for each build

and for programs that don't respect this convention ./--file

I'd say Java's virtual threads are also a parallelism construct (at least in the performance sense, not logical guarantees), since they're scheduled on a pool.

Just to nitpick, it's a 8MB-sized mapping, not 8MB of RAM.