News for hackers. Stuff that matters.

delta64

Re:BSD kqueue is a mountain of technical debt on Sunday December 29, 2024 @09:43PM (#42545918)
It's slightly odd to say 'wow, epoll can wait on any type of kernel handle, like timerfd and signalfd!' given those *fd interfaces were added just for select/poll/epoll. Strikes me as remarkably ugly design...
Re:So you think you want to write a deterministic hypervisor? on Wednesday March 20, 2024 @04:57PM (#39771931)
I've long thought about these kind of OS designs, and what great features they can enable (such as time travel debugging). But the non-determinism introduced by inter-CPU interactions is a fundamental limitation, hence the need to run everything on a single isolated core.

One day(^TM) I'm really keen to design a multi-core CPU architecture that allows for deterministic message passing between cores in such a way that you could get this kind of software working with true parallelism.

Re:Go 1.21 will (likely) have a static toolchain on Linux on Saturday April 08, 2023 @11:58AM (#35494536)
Why would static linking be incompatible with `dlopen`?
Re:Lies we tell ourselves to keep using Golang on Saturday April 30, 2022 @04:03PM (#31218802)
Sure, but I think '== might be a function call' is a lot less confusing than '== sometimes compares for equal value and sometimes doesn't'
Re:Lies we tell ourselves to keep using Golang on Saturday April 30, 2022 @09:13AM (#31215837)
How is that any different to some opaque method call? By the same logic `a.equals(b)` might be doing something funky under the hood
Re:Lies we tell ourselves to keep using Golang on Saturday April 30, 2022 @09:11AM (#31215810)
The obvious thing is to check if the contents are equal. I don't know what cursed C++ you're looking at if you're finding a ton of string implementations not doing exactly that...
Re:Lies we tell ourselves to keep using Golang on Friday April 29, 2022 @10:44AM (#31205833)
The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people

In languages with operator overloading this just isn't a concern at all because == does the obvious thing

Re:Ray Tracing in pure CMake on Monday January 11, 2021 @11:02AM (#25730708)
Thanks so much! I'll take a look at these when I get a chance
Re:Ray Tracing in pure CMake on Sunday January 10, 2021 @01:35AM (#25711460)
Maybe that'll be my next project. Or instead someone should just write a compiler which outputs a printf format string, perhaps?
Re:Ray Tracing in pure CMake on Sunday January 10, 2021 @01:33AM (#25711439)
It sounds like it should be possible (CMake also has eval), but the lack of OOP isn't so much a problem for what I needed. Packing and unpacking the vectors was more annoying. I can live without OOP, I've written enough C to get used to it haha.
Re:Ray Tracing in pure CMake on Saturday January 09, 2021 @08:44PM (#25707639)
It figures out which rows to render using its own worker index
Re:Ray Tracing in pure CMake on Saturday January 09, 2021 @08:43PM (#25707625)
Thanks! This is extremely impressive, and looks like far more effort haha
Re:Ray Tracing in pure CMake on Saturday January 09, 2021 @08:41PM (#25707596)
> The model being rendered also is hard-coded in the ray tracer.

This is true - but there's no reason why it couldn't be modified to read in a scene description. It's more a proof of concept than anything else.

Re:Ray Tracing in pure CMake on Saturday January 09, 2021 @08:39PM (#25707570)
Speaking as the author of the post, I completely agree! I got burned so many times by random shit that made no sense. Stringly typed languages are the absolute worst.