panzi

Why also capacity?

What I think would make sense is a change to the C API where the error code is an out parameter and not that ugly thread local errno. But I guess that's not big enough of an issue for people/languages that use libc as system call interface.

Getting Bad Gateway.

Compilers often just build up more and more data structures in memory until the end when they then release everything more or less at once. With an arena you can then just throw away the whole arena at the end, assuming there are no resource handles that need to be closed in drop().

A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation.

A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.

I wonder how fast "Doom in TypeScript" runs in tsrs now. XD

Getting 403 for this.

Hm, does document.write("...") still exist?

Interesting!

We're currently use pgvectorscale. Some questions:

- Will pg_vectorsearch eventually also support vectors bigger than 1968 dimensions? E.g. VoyageAI can create embeddings with 2048 dimensions (but we don't actually need that at the moment, only 1024).

- Why did you choose C this time and not Rust, as you did with pgvectorscale?

- Why did you not just extend pgvectorscale with another index type instead of creating a whole new extensions?

I expected it to also talk about ~username. See e.g.: echo ~root ~pulse ~sddm

What about that makes it sound like AI? I can't detect it. My native language isn't English, though.

8.8 million people? Wikipedia says Denmark only has 6 million people! Historical data too? People from other countries that had any treatment in Denmark?

I think the claim is that GCC supports a few obscure platforms that LLVM doesn't. Don't ask me which, that is just the claim that I heard multiple times. So it's not Rust that limits platforms, but LLVM. And they say the GCC backend efforts of Rust are meant to deal with that.

Sure, I still find it fascinating.

That's more than 4 times the size of Super Mario World, I believe. Always fascinating how little is done with so much these days.

Black Mirror episode 2, IIRC.

For me:

> 503 Service Unavailable

I think the "avoid people" part does a lot of work. For a lack of a better word, AI generated people still look soulless.

Will this mean they yet again throw away their component library for Shopify apps and make everyone migrate AGAIN?

The article says LibreOffice is almost 20 years old. Well, before it was LibreOffice it was OpenOffice in 2000 and before it was OpenOffice it was StarOffice and StarWriter originates in 1985. So you could say it (or the Writer component) is 41 years old.

Even before I read this blog post only the way he behaved on The Standup made me suspicious, raised some red flags.

I'm so disappointed that The Standup was platforming him.

If I'd were 17 I'd choose a different career.

I'm not really against such special symbols, only if they are too much, like in Perl.

~ and @ weren't replaced by anything with ::, though, ~Foo is Box<Foo> and @Foo is Rc<Foo> (or is it Arc<Foo>?). :: to access a member of a module already existed when ~ and @ was in Rust.

Early Rust had ~ and @ references.

What's the public transport of software development? Where can I get good train service here?

Out of the things you mentioned I think the following make totally sense to be included in a language runtime like this:

JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers.

I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.

Just looked it up, that Apple license is indeed approved as open source/free software by the FSF and OSI!

I don't condemn the protocol. I specifically mention the buggy implementation. I say that I use X11 because KDE's Wayland implementation is so buggy.

I want to use KDE. KDE was perfect for me before Wayland. I don't criticize Wayland here, I criticize KDE Wayland. And I'm worried because very soon KDE will delete X11 support.

Yeah, but it works under KDE+X11. Wayland it the thing that changes. I think KDE has it's own Wayland implementation? kwin_wayland is what is broken, probably. Why they broke it when porting it from X11 I don't know. But the effect is the same: Can't use it as of now.

None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland. Why that even has anything to do with Wayland I don't know. I just know that it all works perfectly when I use KDE X11. Maybe other DEs/WMs have better Wayland implementations, I don't know.

Yeah, I still use KDE with X11 because they somehow messed up their window management with Wayland. My problems aren't even about rendering or any those features, but for some reason kwin_wayland's window management is very buggy. I'm still on 6.6 on the distribution that I use, so I don't know if it's fixed in 6.7, but I doubt it since it is here for a long time. Reported it here: https://bugs.kde.org/show_bug.cgi?id=524083