Debug Trace

Page: 1 2
ID:1283286
 
Jun 4 2013, 6:28 am (Edited on Jun 4 2013, 6:38 am)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Requesting a Trace feature. Calling Trace(atom) would start keeping a log all of its calls (and the order they're called in). Then, we'd simply need a way of getting or directing this output to a file or as a return value from a function call. I suppose this would have to be limited by a maximum trace count (1000 steps?)

You could build your own Trace, but it would have massive overhead and would require adding code injections to all proc definitions even though a built-in trace could just use the proc definitions it already has to build this for us.
Jun 4 2013, 1:10 pm
I think it would be better as datum.trace(call,params)
so that this could be overwitten and the output can be handled as needed (default action being to do nothing).

Would love to see this feature too.
Jun 4 2013, 1:33 pm
I would absolutely love this.

100% support!
Jun 5 2013, 5:21 pm
This would definitely be useful to my project and a welcome feature, if development time permits the addition.

Supported!
Jun 5 2013, 5:32 pm
+1
Jun 5 2013, 5:39 pm
I think this also goes without mentioning but just in case; the feature would only be available when compiled in DEBUG mode.
Jun 5 2013, 5:45 pm
+1

This would definitely make working on large projects much easier.
Jun 5 2013, 6:06 pm
This would be useful, but I don't think it's an absolutely critical feature. I could see it handy for catching hidden bottlenecks, something I would definitely put to use.
Jul 2 2013, 4:31 am
++
Jul 4 2013, 7:34 am
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.
Jul 4 2013, 8:25 am
In response to MisterPerson
The more reason to unit test our code. Using a testing framework like Deadron.Test will help but testing is still limited due to the reasons that motivated this request.
Jul 5 2013, 3:50 pm
The profiler is a great tool, but to be able to track calls for a specific object is nice. Although let's be honest, this can be done in DM very easily. You can just manually set every proc to output it's name into a text file whenever it's called. Kinda tedious, but just as effective. That would be my solution to the issue.

As far as whether or not I support this, it really doesn't matter to me. If it's implemented, whatever, if not, whatever. I don't really debug anything this way, and even if I wanted to, I could just use my above solution.
Jul 5 2013, 4:05 pm
In response to MisterPerson
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, anyways.
Jul 6 2013, 8:25 am
I wouldn't worry about it too much, GS. If we're not really interested in it, then it doesn't matter to us. Everyone else has their opinion and you've had a chance to express yours. There's no real need to get upset over the request.
Jul 6 2013, 8:30 am
I was actually being polite and understanding... not condescending. I was actually agreeing with you're standpoint that it's not a needed feature and it can already be done just fine with the language. Why are you getting so defensive?
Jul 6 2013, 8:47 am
You just flipped your shit. That's pretty defensive. Or offensive, either or.
Jul 6 2013, 8:56 am
That doesn't change the basic problem, the code has to fail before you can debug it. For a small project this isn't a huge issue. For a large project that's a nightmare. You still have to load the code up, leave debug messages, compile, reload up the program, figure out what went wrong, remove the debug messages, recompile. Ugh. All that takes like 30 minutes. That's not even time spent fixing the actual issue and testing which will take bare minimum 10 minutes, that's just time spent setting up for debugging.

With a stack trace, bugs would probably take half as long to fix, easy, simply because I won't have to load the code up and add and then later comment debug messages. Debug output is NOT the same as a stack trace, especially if the stack trace dumps relevant information like vars, arguments, usr, time spent running the proc, cpu time on the proc, etc. I understand it's a pretty big thing to work on for Lummox and Tom, but I think it's very much worthwhile for larger projects. You know, the kind most likely to have memberships and have large numbers of fans.
Jul 6 2013, 10:22 am
In response to MisterPerson
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.

Instead of dumping your debug information to world and then removing it try putting it into some sort of debugging log and leave it in. It's very helpful for fixing future problems.

With BYOND you have to write your own debugging into your game's framework. That's fine, no biggie.

The point of this thread is it would be nice if there was some more information available from DM code at runtime. You're pretty limited in the kind of debugging you can add. The stack trace dump mentioned in another thread would be an excellent and useful feature. This atom/datum trace would be an excellent and useful feature.

Some other details like memory usage and garbage collection stats would be incredible. I'd love to know how many of what objects exist in memory without having to do it all myself and the collector is just about a black box.
Jul 6 2013, 10:45 am
That would mean literally going through every proc and adding logging to them all. Granted this would mostly mean replacing comments, but it still seems counter-productive to do a bunch of work to make later work easier. And remember, this would be just this one project, other projects are still SOL. Tom and Lummox can do a fraction of that work and get better results that benefits everyone.
Jul 6 2013, 12:01 pm
Well, yes. It would be more convenient if the platform did this sort of thing for you. I agree completely.

Where I disagree is that it's counter productive to spend effort up front to make your life easier in the future. That's the essence of good design.

If you're building something from the ground up you should be putting debugging into it anyway. Going through old code and retrofitting debug handling is a nightmare.
Page: 1 2