Having used both, I personally prefer vimlike —nothing major, have just run into fewer issues.

Largely, yes. Arduino code runs on bare metal, and delays simply block execution so they should be accurate with some constant overhead.

Grow your OpenAI bill exponentially with this one easy trick!

In all seriousness — looks nifty! Do you guys have any plans to bring suggestion latency down from what’s show in the demo?

Latency is actually very low as-is, with GPT-4-Turbo!

But other than that, yes, we do have plans - using real-time RAG. I carried out some research with incredibly promising results

https://ai88.substack.com/p/rag-vs-context-window-in-gpt4-ac...

The first place I ever saw that was here:

https://en.uncyclopedia.co/wiki/C%2B%2B

Whole article is worth reading, lots of good laughs in there!

I think the assertion is based on the fact that LLVM is written in C++. Doesn’t directly introduce a C++ dependency to the kernel, but it does introduce it to the toolchain.

But rustc is a cross-compiler, you only need a C compiler for one platform and you get a Rust compiler for all platforms. And it's not like LLVM is doing anything that fundamentally prevents it from being written in Rust (see also the Cranelift backend for Rust, written in Rust). I'm still not quite sure what the concrete concern is. Can you elaborate?

Modern GCC is also primarily written in C++, and has had C++ deps since 2013:

https://github.com/gcc-mirror/gcc/blob/master/gcc/input.cc

if i recall correctly, it was operable so they just removed it

Oh great news!

Well, mostly. I seem to recall that she had a recurrence about a year ago or so (pre-edit, 2019 specifically per her wiki page, I'm getting old). But I've been watching her for a while and she seems to still be active and making good videos, so yeah good news I reckon.

Still in use academically too - we used it in my compilers class last year.

That was the most interesting part of the article for me. I don't understand how it can be faster, given that there's syscall translation going on. Is this more of a commentary on the quality of the `libc` available on Windows? Or on the quality of the GNU Emacs Windows port?

IIUC there is no syscall translation, it's more like there are separate libc implementations and the correct one gets selected at program start based on the OS.

So like in-process WINE?

Yes, this seems fairly accurate. In fact I think Wine supports this mode where you link Wine into a "windows program" at build time to produce a "native" Linux executable. So basically the difference is that you target a POSIX API rather than Win32 and the backend implementation is selected at runtime rather than build time. But both projects have the same idea that they will implement a particular API on multiple platforms.

Could be like the improvements seen when running applications using DXVK. My understanding is that sometimes these translation layers can use newer and more efficient methods than the path that a native implement for the time would use. I'm not a subject matter expert though, and could be completely off base.

Replacing undefined behavior at the program-level with undefined behavior written and tested as part of the standard library, usually vendored and distributed in concert with the compiler, seems like an obvious net-positive to me.

Yes, you did I'm afraid -- this is a tool which is used to check for skimmers, not a preventative measure which is permanently installed. It only blocks the chip slot when an employee is ensuring a skimmer isn't installed on a particular terminal.