Development news: we can have nice things

Page: 1 2
Aug 16 2021, 6:48 pm
In response to NSBR
Test cases sent in DMs or on the pager tend to get lost, especially if they're not labeled in such a way where I have the ID number as part of the file. (I've taken to numbering such files after I download them now, but it doesn't help that case.)
Aug 17 2021, 1:56 am
Aug 17 2021, 8:42 am
In response to Vallat
It's an old issue as you said from before 513. The thing is I have no idea what's causing it or how to fix it.

I have changed some of the deep internal macro handling code that translates stuff like shift+key into a character, but I forget if that's already in 1461 or if it'll be in the next build—and I don't really have a way to test it.
Aug 18 2021, 4:40 am
Aug 19 2021, 12:27 pm
So, bit of an update: 514 stable is not dropping today. I finally got a good lead on the animate() issue in id:2595289 and although it'll be easier to fix with a major version change, I think it makes more sense to do it now in 514 since it could be a bit before 515 is ready for beta.
Aug 19 2021, 2:50 pm
A built in reference finder for debugging GC failures.

A global proc where we can just put in a datum reference and it can return a list of objects which hold the references, preferably even with which var the reference is held in.

var/datum/my_datum = new()
var/list/refs = find_references(my_datum)
// list would contain either the objects, or their \refs and the var on the object which holds the reference to my_datum


We have alternatives for this in SS13, but it is slow (takes up to 50 seconds with 700,000 instances in the world, running on a RYZEN 5900X).

This would need to support finding raw var references, list entries, and assoc list references.

If this can be added in 515, our ability to pin down GC failures and heavily optimise deletions will dramatically increase.
Aug 19 2021, 9:01 pm
In response to AffectedArc07
AffectedArc07 wrote:
A built in reference finder for debugging GC failures.

A global proc where we can just put in a datum reference and it can return a list of objects which hold the references, preferably even with which var the reference is held in.

> var/datum/my_datum = new()
> var/list/refs = find_references(my_datum)
> // list would contain either the objects, or their \refs and the var on the object which holds the reference to my_datum
>

We have alternatives for this in SS13, but it is slow (takes up to 50 seconds with 700,000 instances in the world, running on a RYZEN 5900X).

This would need to support finding raw var references, list entries, and assoc list references.

If this can be added in 515, our ability to pin down GC failures and heavily optimise deletions will dramatically increase.

This would be awesome
Aug 20 2021, 11:49 am
In response to MrStonedOne
MrStonedOne wrote:
already exists (kinda), but is undocumented

Hacky at best, and overly limited at worst.

You can even get really fancy and make something that takes a list of tasks and returns once they all finished:

> /proc/wait_for_tasks(var/list/tasks)
>     for (var/datum/task/task in tasks)
>       task.waitforfinish()
>

Its handy if you want to do a bunch of blocking things at once, like close all doors in a room and wait until they are all closed.

However, that makes this proc itself synchronous. Proper async model would allow it to remain asynchronous. e.g.

// Actually returns a /task, which can be awaited for the sum
proc/async/async_sum(var/list/tasks)
  . = 0
  for (var/task/t in tasks)
    . += await t  // Alternatively, . += t.Await()


The added boilerplate of hacking undocumented waitfor settings and while(x) sleep() are non-ideal.
Aug 27 2021, 4:10 am
Random thing but simple and would be useful for us.

Make it so we can retrieve the DreamDaemon or DreamSeeker PID via `world.pid` or something else.

This would be useful for metrics monitoring and other server statistics over time.
Aug 27 2021, 9:53 am
In response to AffectedArc07
AffectedArc07 wrote:
Random thing but simple and would be useful for us.

Make it so we can retrieve the DreamDaemon or DreamSeeker PID via `world.pid` or something else.

This would be useful for metrics monitoring and other server statistics over time.

If you haven't already, post a feature request for that. I'm game.
Aug 27 2021, 5:08 pm
In response to Lummox JR
Lummox JR wrote:
AffectedArc07 wrote:
Random thing but simple and would be useful for us.

Make it so we can retrieve the DreamDaemon or DreamSeeker PID via `world.pid` or something else.

This would be useful for metrics monitoring and other server statistics over time.

If you haven't already, post a feature request for that. I'm game.

Feature request filed: https://www.byond.com/forum/post/2711988

Page: 1 2