What do you even do when dream deamon freezes with no error message?
There's nothing to point out where is the error, while it's in your code, it's almost impossible to know from where it comes, your experience on the current project that you're working on and a little bit of luck will only be the variables that make the path to fix the issue.
It's horrible, specially for a project with 300k lines.
Yeah uh, mostly I work on fixing shit that I didn't code on the first place, so it's stupid on this case to tell me that I should program better.
And it doesn't matter the type of debug feature added as long as it tackles down this issue, hell, I suggested this because I thought it would be extremely easy to do, it doesn't really matter how it's it done. | |
The code that crashes DD can be literally anywhere. There's a gameticker that calls a proc on every object every tick. We have at least a hundred different types of objects that process every tick, and as Aran said, 300k lines. Good luck "just concluding" where the error is out of all that. Some of this code is almost ten years old, most of which without any QA at all, and the people that wrote it are long gone.
It's rather obvious how a "last proc called" feature could be useful here. | |
What part of DREAM DEAMON FREEZES you don't understand? How can you check the profile if the bloody program stops answering with no output of why is it like that?
And yes, I'm willing to go to those lengths, I have, I am and I will. There is a reason of why we have the most stable branch. Blaming the user for this is extremly retarded, when DD just doesn't have enough debugging tools. A few months ago dream deamon was crashing because of a byond bug that I found out where was it by just fucking luck, I don't see you looking at the profile there. See: http://www.byond.com/forum/?post=1500172 | |
There really is no reason to get into an argument over this (or any feature request, really). This is a decent suggestion as debugging freezes is one of the more difficult problems in program development. Rather than continuously log, though, I think a signal system as suggested by Pomf/Stephen is the way to go. We'll see what we can do.
| |
We can if we use a separate thread. We already have some multithread logic in there from our early forays into that.
| |
Tom wrote:
There really is no reason to get into an argument over this (or any feature request, really). This is a decent suggestion as debugging freezes is one of the more difficult problems in program development. Rather than continuously log, though, I think a signal system as suggested by Pomf/Stephen is the way to go. We'll see what we can do. Cool. Would be much appreciated. As for logging continuously, being able to get a full log of control passes (with time and giver/receiver) is probably not ideal here, but it could be helpful in other situations (and interesting in general!). | |
bump for please gib ehuehue
| |
no forgeterino pleaserino
| |
Laser50 wrote:
I2edSmok3 wrote:
This forum is for coding, not inter-personal relations.
Some people in this thread have posted out of ignorance, because they don't understand the topic at hand, the realities of game development, and/or basic programming concepts.
And you're more eager to correct Aranclanos's etiquette than their understanding of code and the BYOND engine?
You're even less helpful than he is.
Gokussj99 wrote:
I'm sure this is fine in a project with one or two procs. However, even with 100 this becomes extremely unwieldy, annoying, and time-consuming (not to mention hideous if you're properly conditionally compiling these based on a define). Now consider that even a medium-sized game may have tens of thousands of procs, especially given a language like DM (with a minuscule standard library) and an engine like BYOND's (requiring substantial abstraction inversion, ie reinventing the wheel).
GatewayRa wrote:
No there aren't: until DM and BYOND support multi-threading, only one procedure runs at a time.
I think the same thing about posting that with such certainty when a dozen people who have actually worked on one have posted the exact opposite.
Pending BYOND going open-source, we rely on the BYOND developers (Tom and Lummox) to maintain the language. If you meant "code project", see above with Gokus's statement.