shmerl

18 ms·

391.
by shmerl 1y ago
That's simply not true, because standard level should operate on the IR level, not on the language. You have to generate some IR from your language, at that level it makes sense to talk about standards. The only exception is probably W
392.
by shmerl 1y ago
And CUDA has zero non CUDA tooling. That's a pointless circular argument which doesn't mean anything. Rust has Rust tooling and it's very good. Being language agnostic is also not the task of the language, but task of IR. The
393.
by shmerl 1y ago
Rust has great tooling and ecosystem. The point here is more of interest of those who want better alternatives to CUDA. AMD would be an obvious beneficiary to back the above, so I'm surprised about some lack of interest from their like
394.
by shmerl 1y ago
After investing a lot of money, bean counters can make things look better on paper if they can say "you see, everyone is using it". Others want to benefit from users actually training their AI. So they'll feed you all kind of
395.
by shmerl 1y ago
Language would matter more for those who actually would want to write some programs in it. So I'd say rust-gpu is something that should get more backing.
396.
by shmerl 1y ago
May be, but who is working on that compiler? And the whole ecosystem is controlled by a nasty company. You don't want to deal with that. Besides, I'd say Rust is a nicer language than CUDA dialects.
397.
by shmerl 1y ago
CUDA is just DOA as a nice language being Nvidia only (not counting efforts like ZLUDA).
398.
by shmerl 1y ago
A better question is why there is no stronger push for a nicer GPU language that's not tied to any particular GPU and serves any purpose of GPU usage (whether it's compute or graphics). I mean efforts like rust-gpu: https:/&
399.
by shmerl 1y ago
neovim community is very active.
400.
by shmerl 1y ago
You can't easily search / grep etc. an IR, unless you use some kind of reverse translator. Readable source files have their benefits in being simple in that sense.
401.
by shmerl 1y ago
DP is perfectly fine for gaming (it's better than HDMI). The only reason HDMI is lingering around is the cartel which profits from patents on it, and manufacturers of TVs which stuff them with HDMI and don't provide DP or USB-C po
402.
by shmerl 1y ago
Local time is irrelevant when you present that time to someone else external. How would they know what your local timezone is? This presentation tells them nothing about it. So it's good for local use, but inadequate for any use that&#
403.
by shmerl 1y ago
Well, worryingly there were reports of AMD X3D CPUs burning out too. I hope it will be sorted out.
404.
by shmerl 1y ago
Surprisingly I don't see ktx tools in Debian. https://github.com/KhronosGroup/KTX-Software
405.
by shmerl 1y ago
I don't understand that argument (and I've heard it several times), see comment below about plugins dependencies. I.e. that argument is OK for isolated cases, not for more complex dependency graph.
406.
by shmerl 1y ago
That's good
407.
by shmerl 1y ago
Well, it might work for individual plugins, but it can't work for when you use plugins as extensions for other plugins. How would plugin A know it has to load B (which is an extension of A) as a prerequisite for [lazy] loading itself?
408.
by shmerl 1y ago
I'm not criticizing it, just describing what I'd consider a level good for switching at least for me. It can be different for others and they might think they need less.
409.
by shmerl 1y ago
I agree if it at least can match lazy.nvim in features, which it so far doesn't. Stuff like pinning plugin versions, notifying about breaking changes and actual lazy loading are very useful.
410.
by shmerl 1y ago
Neat, but it's missing ability to lazy load plugins. I'm using lazy.nvim which is both lazy loader and update manager and it's really great.
411.
by shmerl 1y ago
Well, see here: https://github.com/keepassxreboot/keepassxc/issues/10374 I'm pretty sure a lot of this stuff are arbitrary decisions that sites make when they implement passkey support and you never know
412.
by shmerl 1y ago
> One slightly more concerning issue today is that there is effectively no way to export private keys between authentication password managers Not being able to use the passkey manager at all is a bigger concern. For example Keepassxc
413.
by shmerl 1y ago
May be, but mechanical difficulty adds to less usage too.
414.
by shmerl 1y ago
Suggestion that humans don't use symbols like em dash is based on the possible difficulty to use them. The reason is probably because many never used / heard of the Compose key. It's not hard to do it once you learn about it.
415.
by shmerl 1y ago
What's wrong with em dashes? Use whatever you like. Compose --- should produce — For en dash it's Compose --. produces – Not all fonts show the difference though.
416.
by shmerl 1y ago
Yeah, games I'd guess is the most common case or at least one enough people would care about.
417.
by shmerl 1y ago
I would guess so, but I haven't seen anyone developing that so far.
418.
by shmerl 1y ago
> most of those games would have windows builds? Yeah, that's a reasonable workaround, as long as it doesn't hit that OpenGL problem above (now it mostly affects DX7 era games, since they don't have Vulkan translation pa
419.
by shmerl 1y ago
On the userland side, there is some good progress of using thunking to run 32-bit Windows programs in Wine on Linux without the need for 32-bit libraries (the only edge case remaining is thunking 32-bit OpenGL which is lacking needed extens
420.
by shmerl 1y ago
Trying to guess what that chain is and putting printf's all around that path feels like doing a poor simulation of what debugger can do out of the box and unlike us - precisely. So I'd say it's exactly the opposite. If you on

More ›