writebetterc

Java doesn't produce 'garbage data', racing writes will never show intermediary results.

Sorry, I don't see it that way.

Why should we care about the COSMIC Desktop Environment?

Edit: I've now gotten 2 downvotes in 4 minutes. I do not understand what's so controversial about this comment. Why should we care about having a third DE? Does this matter to users at all? I've watched several videos show casing it, and there seems to be no point to it except organizational (Pop OS wants to break free from GNOME).

Intel Arc Pro B60 will come in a 48GB dual-GPU model. So yeah, hardware is gonna be there, and the 24GB model will be $599 from Sparkle. I assume 48GB will be cheaper than a hacked RTX 4090.

Look at this: https://www.maxsun.com/products/intel-arc-pro-b60-dual-48g-t... https://www.sparkle.com.tw/files/20250618145718157.pdf

There are old Arabic maps which have south at the top.

I don't think it counts as visiting, as you never look at the dirtied bitmap during GC, only during allocation. That means, you don't actually know if a dirty bit represents a different object or not (if a 16-byte size class is allowed to have 32-byte objs in it, for example). To know that you'd either have to have strict size classes, or you'd have to have object headers for specifying the start of an object.

I agree that it's easy to add in a visitation pass, where you take the bitmap of live objects after marking and diff it with the currently existing one in order to signal that you might have a leak.

So basically, I think we're like 99% in agreement.

I forgot that this GC is non-moving (I'm not used to that assumption, and it was a bit of a quick comment).

I do find the statement dubious still, do you mind clearing it up for me?

Given a page { void* addr; size_t size; size_t alignment; BitMap used; } where used's size in bits is page.size / page.alignment, surely we only need to visit the used bitmap for marking a memory slot as free?

To add on top of this: This is a tracing GC. It only ever visits the live data, not the dead data. In other words, it would need a lot more special support if it wanted to report the dead objects.

I'm not sure what the goal was here, that's not what I'm saying.

I'll do the opposite: The P vs NP episode is aboslutely horrid. Probably the first and last time that they had any informatics people on the show. One major issue is that the experts didn't explain what we mean by "hard". Melvyn thought, as normal people do, that 'hard problem' means you've gotta be real clever to solve it, not that it takes a lot of steps to solve (and how the number of steps increases as the problem gets larger). When they had the example of purchasing Christmas gifts as a stand-in for maximum bipartite matching, coupled with Melvyn's misconception, the train wreck was a fact.

That's my memory of the event, that was a frustrating lunch walk.

Same, Emacs is improving at a rapid rate thanks to its adoption of LSP and Tree-Sitter. Performance is very good, but the async story needs to become better.

Let's not over correct, of course O-notation has something do with algorithms for the working programmer.

Good job on dispelling the myth of "compiler = fast". I hope SPython will be able to transfer some of its ideas to CPython with time.

That was quite rude of Andrew. If someone doesn't want to review a PR, then they should just ignore it IMHO.

They're talking about dollars

C++ has bitfields built in : https://en.cppreference.com/w/cpp/language/bit_field.html

Fedora 41, KDE Plasma 6.3.5, kernel 6.14.5, Wayland, Mesa Intel Iris Xe Graphics.

I think you answered how you managed to induce latency in Emacs :).

It's surprisingly slow. Switching files in the tab list has a noticeable delay. Typing is higher latency than both Emacs (lsp-mode activated) and my web browser. Also uses approximately 60MiB more than my Emacs. It starts fast though!

I wouldn't complain about this stuff if it wasn't for their tagline being 'it's fast' and they're losing to Emacs Lisp (not a language amenable to being very fast) with a highly optimized C core.

I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?

FWIW, I've heard from people who know this stuff that linking is actually super slow for us :). I also wanted to try out mold, but I couldn't manage to get it to work.

>10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with.

I don't know the exact amounts of time per phase, but you might change a header file and that will of course hurt you a lot more than 1 translation unit.

> Eh, not really. Working with a binary where all variables are optimized out and all operators are inlined is hell.

Yeah, but sometimes that's life. Reading the assembly and what not to figure things out.

>That must absolutely suck to work with.

Well, you know, I also get to work on something approximately as exciting as Chromium.

>How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically

10 minutes.

>If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes.

Typically always compile with debug support. You can debug an optimized build as well. Full recompile takes up to 45 minutes.

The largest reason to use a debugger is the time to recompile. Kinda, I actually like rr a lot and would prefer that to print debugging.

You can't use KeepassXC + Firefox? Might need to downgrade the KeepassXC browser plugin (because of a bug)

> As it happened, my superiors had come to realize the same, so when I asked for a talk, they preempted my plan by announcing this.

What is "this"?

Multi-tenancy on the JVM makes me shudder, though. The general point you're making, thumbs up to that.

Ownership and lifetimes are arguably not about Rust, but about how we construct programs today. Big, interdependent, object graphs are not a good way of constructing programs in Rust or C++.

You don't need to learn how git works internally to be able to use it. You need to know a lot about filesystems in order to use them: Folders, files, symbolic links, copy, cut, paste, how folders can exist on different devices, etc. There's just a tonne of assumed knowledge regarding them, and it's very obvious when you meet someone that doesn't have it (regular people often don't have all it).

Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.

Yes, Rust is better. Implicit numeric conversion is terrible. However, don't use atoi if you're writing C++ :-). The STL has conversion functions that will throw, so separate problem.

It's a bit annoying that there is a standard desugaring of all of this, but there's no actual way of implementing this sugaring yourself. I guess you could have a token macro (or whatever they're called) at the top scope and do it yourself?

Anyway, my conclusion is that in order to learn Rust you can't use any syntactic sugar the language provides, those are 'expert features'. There's no way I'd be able to figure out why this happens. Do rust-analyzer provide a way of desugaring these constructs?

>Benchmarks show its about 25% faster than the raw pointer version. (I don't know why - but I suspect the reason is due to better cache locality.)

Cache locality matters, but so does having less allocator pressure. Use 32-bit unsigned ints as indices, and you get improvements on that as well.

>The original version of my b-tree works just like how you'd implement it in C. Each internal node / leaf is a raw allocations on the heap.

I'd always try to avoid that type of allocation pattern in C++, FWIW :-).