ID:1631626
 
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
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
Linux/FreeBSD already have ways to do this but it'd be nice to have it directly. +1
Or for usage with us poor sods on Windows. Would improve things greatly.
Definitely +1 needed
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
please stop posting
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:
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

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 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.
http://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.
Yeah, this would be really helpful.
Yeah this would be super useful
Please do this.
Are you implying that the poor profile, who barely contains any information, is enough to be enough to be the only debugging tool available for byond?
Page: 1 2