This is an idea to assign a .string to an ent such as a player, which will enlarge via strcat(), and represent from start to finish - all the functions the entity runs from prethink to postthink....for purposes of debugging.
I had been using the .message default string for this during my tests, for example, if we are doing CheckPowerups () , the .message is something like "Checkpowerups()". However when we go to the next call, the string got overwritten bu the new function.
I am very bad with strzone (I forget to unzone) , and I know this would be using a combo of that + strcat , and in Darkplaces we have some ability to check a string for matching text etc. Im also unsure how long a .string is allowed to be in QC, if there is a limit or whatever? I am vaguely aware of what some other similar built ins like trace_on can do, but Im not aware of any that are entity specific...
any comments / ideas / feedback?
New idea for a QC debug tool
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: New idea for a QC debug tool
strzone/strunzone, while really useful, are a pain in the arse to work.
The safest way I found to work if this duo was this:
By default, strings are limited to 8k in Darkplaces (not sure if this values applies to FTE too). You may find this a really small limit for trace functions called from inside a loop, for example.
EDIT: a really nice feature would be a stack trace printing in the same way you find in the Java VM. Something like this, for example:
But I suppose this would also require changes in the progs.dat file format to store more metadata.
The safest way I found to work if this duo was this:
Code: Select all
void (char text) appendToMessage =
{
local string mesg;
if (self.message)
{
mesg = strzone (strcat (self.message, text));
strunzone (self.message);
self.message = mesg;
}
else
{
self.message = strzone (text);
}
};
EDIT: a really nice feature would be a stack trace printing in the same way you find in the Java VM. Something like this, for example:
Code: Select all
Assignment to world entity
at PutClientInServer (client.qc:389)
at foobarFunction1 (foobar.qc:1234)
at foobarFunction2 (foobar.qc:4321)
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: New idea for a QC debug tool
void (char text) appendToMessage =
{
text = strzone(strcat(self.message, text));
if (self.message) strunzone (self.message);
self.message = text;
};
actually, due to a few fte quirks, you could actually write it like this in fte:
void (char text) appendToMessage =
{
strunzone (self.message);
self.message = strzone(self.message, text);
};
but hey... use-after-free is kinda evil even if its (currently) reliable, so I don't really recommend shortening it like that.
on the plus side, combining the strzone and strcat avoids the tempstring memory explosion...
side note: strzone, strcat, strstrofs, substring have no length limit in fte. This doesn't apply to all builtins, so you might need to use substring to chop them up first before using other builtins.
fteqcc generates .lno files. these files contain a statement->line number lookup table for more usable stack traces.
the 'error' builtin will print out a stack trace including these line numbers if they are available.
trace_on can be entity specific in that your QC can explicitly enable it via code as the first part of each function, and can call trace_off before calling code relevent only to other entities.
(FTE will present its line-by-line debugger if you use the trace_on command, as it does with certain other debug events, so long as the debugger cvar is set).
{
text = strzone(strcat(self.message, text));
if (self.message) strunzone (self.message);
self.message = text;
};
actually, due to a few fte quirks, you could actually write it like this in fte:
void (char text) appendToMessage =
{
strunzone (self.message);
self.message = strzone(self.message, text);
};
but hey... use-after-free is kinda evil even if its (currently) reliable, so I don't really recommend shortening it like that.
on the plus side, combining the strzone and strcat avoids the tempstring memory explosion...
side note: strzone, strcat, strstrofs, substring have no length limit in fte. This doesn't apply to all builtins, so you might need to use substring to chop them up first before using other builtins.
fteqcc generates .lno files. these files contain a statement->line number lookup table for more usable stack traces.
the 'error' builtin will print out a stack trace including these line numbers if they are available.
trace_on can be entity specific in that your QC can explicitly enable it via code as the first part of each function, and can call trace_off before calling code relevent only to other entities.
(FTE will present its line-by-line debugger if you use the trace_on command, as it does with certain other debug events, so long as the debugger cvar is set).