Author Topic: Some suggestions for C::B improvements  (Read 12370 times)

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Some suggestions for C::B improvements
« on: November 11, 2015, 12:40:13 am »
Hello!

I'm an experienced C++ programmer, and I use C::B occasionaly. I'm currently working on some C++ tutorials for beginners(http://www.programming4beginners.com/), so I would like to present a few suggestions from that point of view.

1. Out of the box, there are are some problems with the debugger. The problem is in displaying elements of nested containers. 1D vecor is fine, but a 2D vector is not displayed correctly

- On Win7, SVN 10320 + gcc5.1 (TDM), gdb 7.9.1 + Python 2.7 :
It appears that debugger startup script - pretty printer is producing output in a format not recognized correctly by C::B. An older startup script for Python 2.7 from some previous version of TDMgcc is working

- If I remember correctly, the same issue happened with C::B 13.12 on Windows

- On Linux (Linux Mint 17.1), C::B 13.12,  gdb 7.9  seems to be linked to python 3. The pretty printer scrips is, again, using the new format which is not parsed correctly by code::blocks. The workaround is to edit the pretty printer script, and make it return the hint 'array' instead of 'vector', then it works correctly. It would also be good to have an option there to load pretty-printers without relying on .gdbinit, since a beginner is unlikely to have .gdbinit .

But, overall, the fix is to make C::B read this new output of pretty printers correctly

2. Since it's already 2015, it would be great if at least C++11 compiler option is enabled by default.

3. There is a bug that makes the 'watches' window forget the width of columns. It happens when this window is quite small. In that case, the third column gets very wide and the other two get extremely small. Happens on SVN 10320, but if I remember correctly, the same issue is with 13.12 and on Linux.

4. When entering 'debug' perspective it would be good to display call stack, debugger and watches windows by default. In the watches window, local variables are important for beginners.

Also, kudos for making 'run to cursor' start the debugger automatically, that one really makes it easier to work with debuggers.

And now some suggestions that I would like to have, for my own sake:
- the ability to choose background and text color of other windows (the white is killing me)
- the horizontal scrollbar in the editor window is usually unnecessary, and I would like to have an option to remove it. It's just wasting screen space, especially on a laptop.

I hope I didn't forget anything important, but anyways this looks like more than enough for the first post.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #1 on: November 11, 2015, 12:56:31 am »
1. Do you have the watch scripts enabled in the debugger's settings?
3. Try the patch posted here https://sourceforge.net/p/codeblocks/tickets/153/
4. Post a ticket for this on the sf.net page
5. C::B uses the global theme to blend with other apps, change the theme and you'll get darker C::B. We won't work on custom theme support.
 
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #2 on: November 11, 2015, 01:08:04 am »
1. I have just tried removing my 'debugger initialization commands' and unchecking 'disable startup scripts'. As before, this does load the pretty printers, but C::B does not parse the output for 2D vectors correctly (1D vectors are fine)
3. I'll try and get back here with results.
4. Is this really for a ticket? It's more like a change request. But if you say so.
5. I would like the other apps to remain as they are. It's just when I'm programming that I need a darker background. I'm sad to hear that you don't plan to make this possible, I don't need a full theme, just a few colors changed.

But, of course, thank you for the answers!

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #3 on: November 11, 2015, 01:15:55 am »
1. Using the python pretty printers that ship with libstdc++ this is unfixable in the current plugin, sorry.
4. Yes, adding it there minimizes the chance for it getting lost
5. Sorry you'll have to patch cb yourself to get this working...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Some suggestions for C::B improvements
« Reply #4 on: November 11, 2015, 01:54:44 am »
kevinxy
5. Sorry you'll have to patch cb yourself to get this working...
This one was bugging me as well, but I wasn't excited about patching C::B after each update. So my codeblocks.desktop has this line now:
Quote
Exec=env GTK2_RC_FILES=/usr/share/themes/Yukitwo/gtk-2.0/gtkrc GTK_DATA_PREFIX="" codeblocks %F
Yukitwo is my modified Zukitwo with the following colors:
Quote
gtk_color_scheme = "bg_color:#626262\nselected_bg_color:#6699CC\nbase_color:#707070" # Background, base. bg_color was d4d4d4, nselected_bg_color was 6699CC
gtk_color_scheme = "fg_color:#dcdccc\nselected_fg_color:#000000\ntext_color:#dcdccc" # Foreground, text.
gtk_color_scheme = "tooltip_bg_color:#000000\ntooltip_fg_color:#F5F5B5" # Tooltips.
gtk_color_scheme = "link_color:#94caff" # #08c Hyperlinks
gtk_color_scheme = "bg_color_dark:#707070\ntext_color_dark:#FFF" # Dark colors. bg_color_dark was 3f3f3f
Btw. I think following the global theme is a good default, but not giving a user an "override" checkbox to allow for custom color settings could be a showstopper for many newcomers.

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #5 on: November 12, 2015, 06:52:11 pm »
1. I have just tried removing my 'debugger initialization commands' and unchecking 'disable startup scripts'. As before, this does load the pretty printers, but C::B does not parse the output for 2D vectors correctly (1D vectors are fine)
1. Using the python pretty printers that ship with libstdc++ this is unfixable in the current plugin, sorry.

Ok, but I don't quite get your answer because:
a) Why don't you bundle a few versions of pretty printers with code::blocks? Perhaps even more, to detect and enable the pretty printer which matches the python/gdb version.
b) I find it quite confusing that such a simple change is impossible. I might be even tempted to look at the source code. What seems to be the problem, and in what file should I be looking at?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #6 on: November 12, 2015, 08:51:06 pm »
a) Why don't you bundle a few versions of pretty printers with code::blocks? Perhaps even more, to detect and enable the pretty printer which matches the python/gdb version.
The pretty printers bundled with cb are outdated and won't be maintained any more (probably they'll be removed in the future).
The path forward is to use the gdb pretty printers. They are written in python and are provided for more libraries and classes.
Ours has just std::vector, std::string and wxString, if I remember correctly.

If you feel that you can write pretty printers using our api for more classes - go on and try it, but don't come back to complain that
you've wasted your time, because some feature is missing or doesn't work.

We don't bundle gdb pretty printers, because generally we don't bundle sdks, libraries or frameworks. It is a job of the library writer to provide the proper pretty printers. Also there is auto loading features in gdb that can find and use the proper pretty printers.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #7 on: November 12, 2015, 09:29:52 pm »
It seems that you partially misunderstood me. Im using pretty printers from
share\gcc-5.1.0\python\libstdcxx\v6

They don't work with C::B because it seems their output format changed recently. Those are the printers by libstdc library developers.

I would like to take a look in the C::B source code to see whether I can fix it. But I'm asking someone to tell me (to give me a hint) which files should I be looking at.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #8 on: November 12, 2015, 09:48:57 pm »
Do you have the "Enable watch scripts" option disabled?
Also can you enable the full log from the debugger and post a debug session and simple example that demonstrates the problem?

2d std::vectors won't work, same is for most nested std structs.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #9 on: November 12, 2015, 10:26:44 pm »
2d std::vectors won't work, same is for most nested std structs.

Yes, that is what I would like to fix in C::B source. I would like 2D vectors with new libstdc pretty printers to display correctly in C::B.

"Enable watch scripts" option does not make any difference, this bug is still present.

Do I really need to post example code for this issue?

Can you point me to the files in C::B source code which parse the gdb pretty printer output?

Offline raynebc

  • Almost regular
  • **
  • Posts: 217
Re: Some suggestions for C::B improvements
« Reply #10 on: November 12, 2015, 11:42:55 pm »
The watches column width bug has affected me for quite a while, but it doesn't seem to happen to me unless I've had the IDE open for a while.  When it bothers me I just re-open C::B and it seems to work better for a while.  Unfortunately I don't have the expertise to build the IDE with the proposed patch or to directly debug the glitch myself.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Some suggestions for C::B improvements
« Reply #11 on: November 13, 2015, 01:01:49 am »
It seems that you partially misunderstood me. Im using pretty printers from
share\gcc-5.1.0\python\libstdcxx\v6

They don't work with C::B because it seems their output format changed recently. Those are the printers by libstdc library developers.
I use the pretty printer from GCC's trunk svn repo, and I don't see the changed format, can you show the changes?
To demonstrate the problem, you can just copy and paste the debugger log message here(In the debugger panel, you should enable the Full(debug) log option in the debugger's setting).
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #12 on: November 13, 2015, 01:47:31 am »
Can you point me to the files in C::B source code which parse the gdb pretty printer output?
I've tried, but the format is ambiguous.
You can start by adding tests in the debuggergdb_test_parser.cpp file.
From there you can look at the ParseGDBWatchValue function and then make the tests pass.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #13 on: November 13, 2015, 01:52:13 am »
Sure. Here it goes:

vector< vector<double> > vec2D = { {1, 2},{3, 4} ,{5}, {6} };

Debugger name and version: GNU gdb (GDB) 7.9.1
> python print(sys.version)
2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
> print vec2D
$1 = std::vector of length 4, capacity 4 = {std::vector of length 2, capacity 2 = {1, 2}, std::vector of length 2, capacity 2 = {3, 4}, std::vector of length 1, capacity 1 = {5}, std::vector of length 1, capacity 1 = {6}}

This is not displayed correctly in the watches window.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Some suggestions for C::B improvements
« Reply #14 on: November 13, 2015, 02:49:15 am »
Sure. Here it goes:

vector< vector<double> > vec2D = { {1, 2},{3, 4} ,{5}, {6} };

Debugger name and version: GNU gdb (GDB) 7.9.1
> python print(sys.version)
2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
> print vec2D
$1 = std::vector of length 4, capacity 4 = {std::vector of length 2, capacity 2 = {1, 2}, std::vector of length 2, capacity 2 = {3, 4}, std::vector of length 1, capacity 1 = {5}, std::vector of length 1, capacity 1 = {6}}

This is not displayed correctly in the watches window.
OK, I can confirm the same issue. The watch window shows incorrectly.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #15 on: November 15, 2015, 11:07:14 am »
Hello! I need more help.

I kind-of fixed it, but the fix should be regarded more as a proof-of concept.

I disabled a lot of things for which I couldn't figure out what they are for (I guessed: nothing).

It works with structures, vecors, doubly and triply nested.

I don't know how to run your unit tests, I'm on Windows+ TDM gcc 4.81 + wx 2.8.1, CB 13.12 (I used the CB wx2.8.x project file to compile CB with CB).

CB always does some post build-steps to compile CB , and that takes forever and it made debugging awkward.

So, if someone could test it a bit, live and with unit test, that would also be of great help!

The fixed file is here:
http://www.programming4beginners.com/outgoing/parsewatchvalue.cpp

And, btw, the format is ambiguous. Has anyone tried contacting GDB developers?
« Last Edit: November 15, 2015, 11:19:46 am by kevinxy »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #16 on: November 15, 2015, 11:26:46 am »
And, btw, the format is ambiguous. Has anyone tried contacting GDB developers?
This format is not mean for parsing by machines. It is mean for humans. So I doubt they'll do anything.
We're just using the wrong API/protocol. We have to be using the gdb/mi protocol. I've started a plugin, but I have no time at the moment to continue working on it.

About running the tests: you need unittest++ and then find the test project in the debuggergdb folder. Build it and it will run the tests automagically.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #17 on: November 15, 2015, 11:41:12 am »
Applied the patch and these are the failures:
Code
/home/obfuscated/projects/codeblocks/git/src/plugins/debuggergdb/debuggergdb_test_parser.cpp:259: error: Failure in RepeatingChars0: Expected t= {c=0x400d90 'A' <repeats 16 times>, "aa\"a"} but was t= {c=0x400d90 'A' <repeats 16 times>,[1]="aa\"a"}
/home/obfuscated/projects/codeblocks/git/src/plugins/debuggergdb/debuggergdb_test_parser.cpp:266: error: Failure in RepeatingChars1: Expected t= {c=0x400d90 'A' <repeats 16 times>, ' ' <repeats 29 times>, "aabba"} but was t= {c=0x400d90 'A' <repeats 16 times>,[1]=' ' <repeats 29 times>,[2]="aabba"}
/home/obfuscated/projects/codeblocks/git/src/plugins/debuggergdb/debuggergdb_test_parser.cpp:273: error: Failure in RepeatingChars2: Expected t= {c=0x400d90 'A' <repeats 16 times>, ' ' <repeats 29 times>, "aaa",a=5} but was t= {c=0x400d90 'A' <repeats 16 times>,[1]=' ' <repeats 29 times>,[2]="aaa",a=5}
/home/obfuscated/projects/codeblocks/git/src/plugins/debuggergdb/debuggergdb_test_parser.cpp:380: error: Failure in RepeatingChars11: Expected t= {[0]=0x4080d8 "1st",[1]=0x4080dc '.' <repeats 14 times>, "#", '&' <repeats 16 times>,[2]=0x4080fc "3th"} but was t= {[0]=0x4080d8 "1st",[1]=0x4080dc '.' <repeats 14 times>,[2]="#", '&' <repeats 16 times>,[3]=0x4080fc "3th"}
/home/obfuscated/projects/codeblocks/git/src/plugins/debuggergdb/debuggergdb_test_parser.cpp:388: error: Failure in RepeatingChars11_children_count: Expected 3 but was 4
FAILURE: 5 out of 116 tests failed (5 failures).

Next time please post a proper patch. See this for details http://wiki.codeblocks.org/index.php/Creating_a_patch_to_submit_%28Patch_Tracker%29
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #18 on: November 15, 2015, 12:16:18 pm »
I just managed to run it with unittest++, and I got the same errors.

The errors are probably due to me disabling the entire 'repeating chars' segment in the code.

I can enable it back, to see whether it works.

But I'm wondering why is this 'repeating char' feature there at all? It would be easier for me to do debugging if I knew what the code is supposed to be doing.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #19 on: November 15, 2015, 12:36:44 pm »
The tests contain real output produced by gdb.
So this is how the output looks like in the real world.
I've not made this up.

My workflow, when changing code related to parsing is:
1. someone reports a problem
2. I inspect it and find what causes it
3. I add a test case
4. start modifying the code until all tests pass

This workflow guarantees that all supported cases still work after my modification.
Also I don't accept patches without new tests and if there are failing old tests.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #20 on: November 15, 2015, 04:13:20 pm »
Fair enough.

I reenabled 'repeated chars'.

I added 4 or 5 additional unit tests.

Can someone test it just to confirm that I have set up everything correctly?

Also, a live test on some other version of GDB would be great.

Here is the patch.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #21 on: November 15, 2015, 05:17:54 pm »
Ok, passes all tests.

But I'm a bit concerned that you've special cased this just for std::vector.
If I remember correctly the old logic was a bit more generic.
I'll have to test if the parser still works for my custom containers.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #22 on: November 15, 2015, 05:39:27 pm »
Well, why not?

note: the only important change and a 'special case' is the change of delimiters so that the string ", cap" is not cosidered to be a comma anymore.

The rest of the changes are either cosmetic, or removal of some complex cases and questionalbe flow control which seemed to me as completely unnecessary.

In fact, I was quite conservative, if I had more confidence, I would have removed about half the code. But before I do that I need at least to set up my development environment correctly, this ad-hoc setup that I glued together is quite frustrating.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some suggestions for C::B improvements
« Reply #23 on: November 15, 2015, 06:11:34 pm »
Probably, I've not written tests for my custom containers. So if they use something different from ", capacity", they'll brake with the new changes.
But I'll be able to do the tests on Monday.

If you can remove half the code and still make the tests pass then I'm with it.
But every line of code is added because there is need for it, so I highly doubt you'll be able to do it.

BTW: I've attached a bit cleaner version of your code, more cleaning is needed to make it in a good shape for commit.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kevinxy

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Some suggestions for C::B improvements
« Reply #24 on: November 15, 2015, 09:50:13 pm »
Thanks for cleaning it up!

By the way, it will not completely break up if there is no ", capacity" string, it will just add some extra unwanted children. Actually, it will only do that when there is a non item-separating comma not followed by " cap".