User forums > Using Code::Blocks

see content of a vector in debugging

<< < (12/26) > >>

killerbot:
Question : why would one NOT want to be able to debug STL classes.
I would have it there, and if no one complains (why do I expect a comment from Thomas here ;-)  ) leave it there.

I think it is best to put it in /usr/share/codeblocks and the same for windows.

EDIT : now it is enabled by default right ?

EDIT 2 : /usr/local/share/codeblocks

MortenMacFly:

--- Quote from: killerbot on June 12, 2009, 03:32:45 pm ---Question : why would one NOT want to be able to debug STL classes.

--- End quote ---
The only thing I can imagine is if it really takes too long and "freezes" C::B therefore for large vectors. Otherwise I'd leave it enabled by default, too.

oBFusCATed:
morten: It doesn't freeze the C::B, it's responsive, but the debugging UI is disabled

killerbot: The user should source the stl-views script, so it is disabled by default and watching vectors should be broken by default.

I suppose the plan should be something like:
1. adding an options which is off in the default config
2. giving it a bit of testing/improvements for couple of months
3. switching it on for all user/removing it

oBFusCATed:
I think, I know why the watching of vector with 1000 elements is slow.

The pvector command emits a line for every element in the vector, this means that it emits 1000 + 3 (size, capacity, elem type).
I've added a logging line as follows:

--- Code: ---void GDB_driver::ParseOutput(const wxString& output)
{
    m_pDBG->Log(wxString::Format(_("GDB_driver::ParseOutput output size: %d"), output.length()));


--- End code ---
With this addition, when I add v as a watch, I get too many lines in the debugger pane that look the same:

--- Code: ---GDB_driver::ParseOutput output size: 13
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15

--- End code ---

So, we are parsing the output from the debugger line by line (emiting 1002 pipe events more that we should).
And here is the proof:

In bool PipedProcess::HasInput() we have:

--- Code: ---    if (IsInputAvailable())
    {
        cbTextInputStream sout(*GetInputStream());

        wxString msg;
        msg << sout.ReadLine();

CodeBlocksEvent event(cbEVT_PIPEDPROCESS_STDOUT, m_Id);
        event.SetString(msg);
wxPostEvent(m_Parent, event);
// m_Parent->ProcessEvent(event);

        return true;
    }

--- End code ---

So, the question is can we replace the ReadLine method with ReadBuffer/ReadWholeData one?
What depends on the line by line parsing and what will break if we do the replacement?

p.s. I'm not sure how fast gdb runs the pvector script though

oBFusCATed:
Hello again,

I've done a little experiment (see the patch):

--- Code: ---Index: src/sdk/pipedprocess.cpp
===================================================================
--- src/sdk/pipedprocess.cpp    (revision 5643)
+++ src/sdk/pipedprocess.cpp    (working copy)
@@ -94,8 +94,8 @@
                 if ( !m_input )
                     break;
 
-                if (EatEOL(c))
-                    break;
+//                if (EatEOL(c))
+//                    break;
 
                 line += c;
             }

--- End code ---

Removing the EOL checks makes the ReadLine method to read the whole input data that is available
(the debug output shows that strings of 1000+ character are read).
And the CB is interactive again if the Parse_StlVector looks like this:


--- Code: ---function Parse_StlVector(a_str, start)
{
     // the whole processing not commented to test its speed
     ..... ....

     // put this before the first return, so the function doesn't produce big string result
    return "test-value";
}

--- End code ---

With this setup the CB is quite interactive (less than a second, measured with my internal human clock :) ).

p.s. I've not tested for breakage of the compiler or so... just the debugger

Navigation

[0] Message Index

[#] Next page

[*] Previous page