ID:2846214
 
Holy cow, is it Friday already?

The new year is in swing and I'm back to working on code. Some of that has been dealing with bug reports that piled up, and inevitably also dealing with the fact that a considerable number of those reports didn't have test cases with them and not finding that out until opening up the report to work on them.

Just before the break, or really just into the beginning of the break on Christmas Eve, I started work on one of my projects for the beta sequence which is the dd.exe command-line Dream Daemon for Windows. That's been coming along really well, and I've even gone so far as to add a limited console for handling some commands like "quit", "reboot", "memory" for a memory report, etc. So that will be in the next release.

Sharp-eyed users will have noticed there was in fact no release this week, though, and really that's because I have too many bug reports to catch up on and also I want to move forward a little more with the map threading (although it won't be in the next release). But a new build will come soon enough, and when it does, it will in fact have the correct copyright date on it for once.

Thanks all of you who supported BYOND in the past year, and I'm grateful for all of your continued support. I'm back at work making it count for you.

Next week: China invades Taiwan, a meteor strike in the Andes will plunge us into a new ice age, and Elon Musk will fake a Mars landing. Also probably some BS forum drama. But seriously, pray for 2023. Pray hard.
That's been coming along really well, and I've even gone so far as to add a limited console for handling some commands like "quit", "reboot", "memory" for a memory report, etc. So that will be in the next release.

Can we get the equivalent command for SIGUSR2 to see recently running procs? The amount of insight this would give us in lockup scenarios would be blessed.
In response to AffectedArc07
AffectedArc07 wrote:
Can we get the equivalent command for SIGUSR2 to see recently running procs? The amount of insight this would give us in lockup scenarios would be blessed.

I'll look into that. I may have to move where the parsing is done, or at least move part of it, but I was probably looking at that anyway if I want to change the backtrace to be able to look for hangs.
I started work on moving the parsing to within the console thread, but I had to pivot off that to work on some map editor stuff. I'll release the new dd.exe as-is, and get to those other changes later. My goal is to get a new release out with new fixes as soon as I can.
I happened to notice you are making your own cross-platform threading thing. Is there a reason not to just use std::thread?
In response to Immibis
STL was never introduced into BYOND.

I tried to use it at one point for the host ban system, but Tom at the time said he was concerned we basically had too many disparate libraries doing too many things, and he was right about that.

There are certainly some things that it could improve, but the cost of overhauling everything to include it is not wonderful.
You're writing C++ code - you already have access to it for free. Built into your compiler. In 1996 it probably sucked and was a separate library you had to install, but now it's standard builtin stuff just like malloc or sprintf.
It's still a library. GCC and MSVC come with copies of that library. Clang does not. I assume Lummox is using MSVC, though.
I think it would be beneficial to use the STL, but in a project built from the start without support for it in mind, it's not necessarily as simple as just including some headers. It is hard to believe that it's easier to make a threading library from scratch than to ensure the classes currently in use are compatible with the STL, though.
In response to Immibis
certainly not like malloc.
In response to Lummox JR
Lummox JR wrote:
STL was never introduced into BYOND.


This is why Tom always told me things like native replacetext() took so long to get, he just never wanted to hand roll his own and always said it'd probably be easier to just implement STL. Thankfully that didn't turn out to be the case, right? ...right?