Debug Trace

Page: 1 2
Jul 6 2013, 12:21 pm
It's not that I'm against this kind of feature or anything, but it's this spoon feed mentality that I just can't support. It just bothers me when people are always like, "Why can't this just be done for me so I don't have to do it myself?!" I mean, seriously, man up, grow a set, and actually program something. The more you complain about it being tedious to implement is time wasted that you could have already been implementing it with.
Jul 6 2013, 3:41 pm
Being spoon fed is one thing and requesting access to information that is missing/obscured is another.

Kind of funny to hear someone complaining about 'spoon fed' with a framework like BYOND that does much of the work up front.
Jul 6 2013, 7:48 pm
This isn't about spoon feeding at all. Every language has better debugging than DM. It's common to need more diagnostic and statistical type data to troubleshoot code problems. It's not common for a community to resist good ideas, unless you're on the BYOND forums.

You can't currently easily add this in soft code in any sort of reasonably manageable way. That's why the request is here. I've been using DM for over 10 years and its just plain silly that we don't have even a basic stack trace.
Jul 6 2013, 7:58 pm
In response to Solomn Architect
Solomn Architect wrote:
MisterPerson wrote:
The lack of a stack trace is what makes BYOND annoying to work with. Right now if you want to do this, you have to leave world << "DEBUG" messages everywhere and remember to remove them later. The only feature more critical than this is client-side processing.

On this note, I have no idea why people have this issue. Build a function to output the text that checks whether or not a debugging flag is set. You can use either use DM's default DEBUG flag that's set when you set it to debug mode, or make your own.

> proc
>    debug(text)
>       #ifdef DEBUG
>       world << text
>       #endif
>

Seriously, this way you can just leave your debugging messages where they are without worrying about deleting them before launch. You can delete them just to clean up your code a bit, but it won't matter in the end because the DEBUG flag will be off.

In my original post I said it was already possible to add your own soft code version of a debug trace but was inefficient, unreasonably manable, and just plain not good enough.

Jul 10 2013, 3:41 am
Just make iitso a stack ttraceis pprintedoonrruntimesand/or aadda function tthatpprintsiitlike a rruntimebbutddoesntiinteruptccodeeexecutionIf BYOND uusesa sseparatecall stack, which I'd gguessiitdoes,this wwouldentbe ttoohhardttoiimplement
(If this post looks like gibberish, welcome to android, it did ghat randomly, not gonna retype)
Jul 11 2013, 2:17 pm
All I'd really like to be able to do is see a call stack, see some memory usage and garbage collection statistics and have a profiler with more granularity than total/average (just adding longest/shortest call columns would be plenty, nothing fancy).

This thread is a neat idea but I'd much rather see all the hidden details before an easier way to do something that's already possible (albeit inefficient).
Page: 1 2