Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
MortenMacFly:
--- Quote from: oBFusCATed on October 19, 2011, 12:46:16 pm ---Hm, OK, I'll give it a try, but I'm mostly on windows.
--- End quote ---
Please, be very careful with that one. It changes a very sensitive core component of C::B. Basically all elements using PipedProcess will be affected and change it's behaviour.
Also, I don't understand why this:
--- Code: ---if (EatEOL(c)) {
wxString line;
line.swap(m_line);
return line;
}
--- End code ---
...is needed instead of this:
--- Code: ---if (EatEOL(c))
return m_line;
--- End code ---
...and why in the end instead of this:
--- Code: ---return wxString();
--- End code ---
...not this is used:
--- Code: ---return wxEmptyString;
--- End code ---
(...which would read better...)
Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
oBFusCATed:
--- Quote from: MortenMacFly on October 19, 2011, 02:14:18 pm ---Please, be very careful with that one. It changes a very sensitive core component of C::B. Basically all elements using PipedProcess will be affected and change it's behaviour.
--- End quote ---
Yes, I know, I've tried to modify this part already, as you know I've failed miserably :(
--- Quote from: MortenMacFly on October 19, 2011, 02:14:18 pm ---Also, I don't understand why this:
--- Code: ---if (EatEOL(c)) {
wxString line;
line.swap(m_line);
return line;
}
--- End code ---
...
--- End quote ---
This is the same as:
--- Code: ---wxString s=m_line;
m_line.clear();
return s;
--- End code ---
But it is faster, it is pretty standard c++ trick :)
--- Quote from: MortenMacFly on October 19, 2011, 02:14:18 pm ---Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
--- End quote ---
+1
MortenMacFly:
--- Quote from: oBFusCATed on October 19, 2011, 02:39:33 pm ---This is the same as:
--- Code: ---wxString s=m_line;
m_line.clear();
return s;
--- End code ---
But it is faster, it is pretty standard c++ trick :)
--- End quote ---
Ah - I missed that the this is a member variable now that needs to be cleared. OK.
tomjnx:
--- Quote from: MortenMacFly on October 19, 2011, 02:14:18 pm ---Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
--- End quote ---
Sorry, I don't have an easy testcase. I'd have to send you my computer 8-)
I have one machine where it happens pretty much always (Win XP), two where it happens occasionally (W2K), and quite a few where it never happens.
And it only happens if the debugger writes lots of output, which is seldom enough.
Under Linux, you're not going to see this. Because any debugger output less than 4kBytes (and provided the debugger only calls write for full lines, haven't checked whether gdb does it), is guaranteed by the OS to hit the receiver process atomically.
What are the intended semantics of cbTextInputStream::ReadLine()? What should happen if the writing process only writes part of a line (i.e. characters without terminating newline)? Should ReadLine() block? Should it return that part of the line even if it is not a full line? (and return the rest of the line should the writing process decide to continue the line in a second call to ReadLine(), leaving the caller with no way to determine where the real line ends were)?
cbexaminr:
(peanut gallery chiming in, FWIW)
Can you get the debugger to write lots of output by opening a disassembly window, selecting mixed mode, and stepping through a large module, or possibly back-and-forth between two different large modules, while trying to see if your problem occurs? The stepping can probably be in the normal source window, I think the disassembly window will still be (re-)populated in background.
(A large enough module should also be able to exceed the mentioned 4K size on linux, depending on how much disassembly changed since I was in in it...)
Of course, if you need lots of output withOUT a line-ending present, that probably won't do, as the disassembly will most likely have line-endings fairly often...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version