Hey, would it be really hard to implement some visual indication on what is the current non-BYOND proc being called?
In all honestly byond doesn't have the best debugging tools, and when it comes down to a dream deamon freeze for any reason, you have to guess the reason.
Just a simple bar of what is the current proc being called would really help on that case, since if DM freezes, then you can see what was going on.
they say an image is more than a 1000 words so http://i.imgur.com/LWWV8tu.png
Thanks.
1
2
| |||||||
Jul 18 2014, 9:57 pm
|
|
+1
|
Linux/FreeBSD already have ways to do this but it'd be nice to have it directly. +1
|
Maybe if the currently-executing proc hadn't changed in a few seconds, but otherwise ohgodno.
It seems like a good idea at first, but the massive processing cost in redrawing that label cannot be understated. Performance would be absolutely demolished if there wasn't a limiter on that. |
you can do this yourself just output it to a log before all the stuff in the proc is called lol.
|
In response to Gokussj99
|
|
For every single proc? There's tens of thousands of them.
|
In response to Gokussj99
|
|
Gokussj99 wrote:
you can do this yourself just output it to a log before all the stuff in the proc is called lol. if you're retarded don't post please |
In response to Aranclanos
|
|
Aranclanos wrote:
please stop posting You don't have to be rude. There is nothing wrong with setting up debug stuff in your code it's your own problem you want redundant features added to BYOND. |
Horribly rude..
Any way, can't we set up a .bat of sorts to add in all the parameters linux uses, or am I just being the fool here. Otherwise.. Switch to the better OS for hosting purposes? Can always make/buy a virtual machine with linux on it to get what you need. |
In response to Aranclanos
|
|
Aranclanos wrote:
Gokussj99 wrote: Don't be rude to a good programmer that is trying to assist you. Giving you suggestions to fix your problems |
Perhaps the better option, although I dunno how straight-forward it would be to implement, is this:
Implement a similar mechanism to the *nix stack-dump functionality, where-by you have a button / option on Dream Daemon when selecting a world, to send a signal to obtain a stack-dump, which is funnelled back to Dream Daemon to show in a big plain old read-only text-area in a new window. This essentially provides the information you need to diagnose a 'freeze', assuming it's a case of busy DM code, as opposed to an actual VM lock-up. |
In response to Stephen001
|
|
Stephen001 wrote:
Perhaps the better option, although I dunno how straight-forward it would be to implement, is thishttp://www.byond.com/members/ Pomf123?command=view_post&post=1579249&first_unread=1 <3 |
Basically, yup, something like that, if it's doable, would work quite well without performance drag, or tying up lots of time in UI dev.
|
1
2