Splitting debugger in two - specific debugger and common GUI

[oBFusCATed]

Because scintilla on windows is not sending the dwell start event if the control or other key is pressed.
I don't know why it doesn't happen on linux, but I see no side effects here. Time will tell.

This is the discussion of Ollydbg with one of the Scintilla devs: http://groups.google.com/group/scintilla-interest/browse_thread/thread/7d109d6e9c6a18f5/700a7871969920da?lnk=gst&q=dwell#700a7871969920da

p.s. there seem to be more problems with the gdb 7.3...

[oBFusCATed]

On Topic: I should probably just read the thread/code, but do you have a cliff notes version of the status of your work on the debugger API, oBFus? (May have some free time to think about the python debugger again in coming months)

dmoore (and others of course):
I've almost finished the switch from raw pointer/references to cb::shared_ptr, only the watches are to be converted (will do it this week, hopefully).
Can you look at the API for some missing bits are things that you don't like?

After I'm finished with the watches I plan to add 'Supported features API', so different plugins can advertise what they support or doesn't support.

[dmoore]

oBFusCATed: That sounds good. I wil try to take a look in the next couple of weeks. Unfortunately, v.busy atm.

[tomjnx]

ParseOutput expects to get debugger output line-wise - however the cbTextInputStream does not really guarantee ReadLine to always return a full line. Not being able to read does not mean we are at the end of a line, it could also be that the sending process hasn't written the remainder of the line or the operating system hasn't caught up getting everything to the receiving process. I haven't seen this problem under linux, but on quite a few windows machines it happens occasionally.

If we can no longer read but haven't seen an EOL, we need to buffer the already read characters, return an empty line, and continue on the next call. The attached patch fixes the problem for me.

[oBFusCATed]

Hm, OK, I'll give it a try, but I'm mostly on windows.

Edit: replace windows with linux...

[MortenMacFly]

Hm, OK, I'll give it a try, but I'm mostly on windows.

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;
}

...is needed instead of this:

Code

if (EatEOL(c))
  return m_line;

...and why in the end instead of this:

Code

return wxString();

...not this is used:

Code

return wxEmptyString;

(...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]

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.

Yes, I know, I've tried to modify this part already, as you know I've failed miserably

Also, I don't understand why this:

Code

if (EatEOL(c)) {
  wxString line;
  line.swap(m_line);
  return line;
}

...

This is the same as:

Code

wxString s=m_line;
m_line.clear();
return s;

But it is faster, it is pretty standard c++ trick

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.

+1

[MortenMacFly]

This is the same as:

Code

wxString s=m_line;
m_line.clear();
return s;

But it is faster, it is pretty standard c++ trick

Ah - I missed that the this is a member variable now that needs to be cleared. OK.

[tomjnx]

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.

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...

[cbexaminr]

svn wxpropgrid_debugger branch R7550 fails to build:
        SqPlus::SQClassDef<wxArrayString>("wxArrayString").
                emptyCtor().
                func(&wxArrayString::Add, "Add").
                func(&wxArrayString::Clear, "Clear").
//                func(&wxArrayString::Index, "Index").
                staticFuncVarArgs(&wxArrayString_Index, "Index", "*").
                func(&wxArrayString::GetCount, "GetCount").
                func(&wxArrayString::Item, "Item");
C:\dev\codeblocks\svn_dbgbranch_on20111101\src\sdk\scripting\bindings\sc_wxtypes.cpp:251: error: no matching function for call to 'SqPlus::SQClassDef<wxArrayString>::func(<unresolved overloaded function type>, const char [5])'

Same problem exists in trunk R7550 retrieved shortly before debugger branch.

Additionally, debugger branch also seems to be missing parenthesis when build attempted with wx 2.9(.2)

sdk\cbplugin.cpp:640-644

Code

    #if wxCHECK_VERSION(2, 9, 0)
    Manager::Get()->GetLogManager()->DebugLog(F(_("Switching layout to \"%s\""), name.wx_str())); <<<==== I added final paren here
    #else
    Manager::Get()->GetLogManager()->DebugLog(F(_("Switching layout to \"%s\""), name.c_str()));
    #endif

[oBFusCATed]

Debugger branch is not ported to wx2.9, sorry.

[oBFusCATed]

The missing brace is fixed in the branch, thanks.

[Pecan]

svn build  rev 7587 (2011-11-12 18:16:49)   gcc 4.3.1 Windows/unicode - 32 bit

At compileroptionsdlg.cpp statement 2293

Code

    // compiler set buttons
    if (!m_pProject)
    {
        en = !data; // global options selected

m_pProject is always 0x0. If I place the following before 2293

Code

    if (!m_pProject) asm("int3"); /*trap*/

the trap never occurs whether there's a project loaded or not.

The old code used to read:

Code

    // compiler set buttons
    if (XRCCTRL(*this, "btnAddCompiler", wxButton)) // only if exist
    {
        en = !data; // global options selected

Something is strange here...
http://dl.dropbox.com/u/46870262/ScreenShot00749.jpg

[oBFusCATed]

Here is the exact commit: http://svn.berlios.de/wsvn/codeblocks/trunk/src/plugins/compilergcc/compileroptionsdlg.cpp?op=diff&rev=6084&peg=7590

It is in trunk and have nothing to do with the branch. I guess Morten could tell you more about it.