Author Topic: symbol browser issue when CB build against wx3.x  (Read 1963 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4903
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
symbol browser issue when CB build against wx3.x
« on: February 28, 2016, 03:07:59 pm »
I build C::B against wx trunk(On windows), I see an interesting issue:

When a new file is opened, the browser tree does not show correctly, see the first image:


Now, you can collapse the root node, see the second image:


And after that, you can expand the root node again, and now you see the correct result(third image):


Please note that the tree in the first image is build from a worker thread, and the tree in the third image is build from the main gui thread(inside the event handler).

It looks like the tree does not work well if it is build from a worker thread. From my point of view, the tree should be only built from the main thread, what's your opinion?

I'm not sure how it works under Linux or Mac.
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: 9949
Re: symbol browser issue when CB build against wx3.x
« Reply #1 on: February 28, 2016, 05:49:15 pm »
Empty tree is the smallest problem.  8)
Calling ui functions from non-ui threads leads to way more severe problems, like random asserts and crashes.

Morten has started work on a patch that will fix this, but I don't know if it is finished.
<debugger plugin maintainer>
(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 yvesdm3000

  • Almost regular
  • **
  • Posts: 223
Re: symbol browser issue when CB build against wx3.x
« Reply #2 on: February 28, 2016, 08:18:06 pm »
I guess this is part of the builtin code-completion plugin ?

Yves
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 9949
Re: symbol browser issue when CB build against wx3.x
« Reply #3 on: February 28, 2016, 11:24:10 pm »
Yes, it is part of the plugin, but it should be moved in the sdk and we should provide a common interface, so multiple cc plugins can provide a list of symbols.
<debugger plugin maintainer>
(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 yvesdm3000

  • Almost regular
  • **
  • Posts: 223
Re: symbol browser issue when CB build against wx3.x
« Reply #4 on: February 29, 2016, 02:53:17 pm »
Anyone working on this move ?
In any case, if we want to support 16-01 I guess the Clang-CC plugin should then just copy the implementation or something ?

Yves
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4903
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: symbol browser issue when CB build against wx3.x
« Reply #5 on: March 13, 2017, 01:12:23 am »
As of Code::Blocks / SVN Repo / Commit [r11027], the symbol browser is disabled by wx3.0+.

Since constructing a wxTree takes a lot of time, so we need to find a way to build it progressively? Any one knows a good method? We need to move the code in the worker thread to the main GUI thread.
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: 9949
Re: symbol browser issue when CB build against wx3.x
« Reply #6 on: March 13, 2017, 02:03:02 am »
Probably the best option is to use wxTreeListCtrl in a virtual mode if possible.
But the code is pretty connected to the CC internals and it is not easy to extract it and make it reusable and with good interface, so other plugins can use it. :(
<debugger plugin maintainer>
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4903
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: symbol browser issue when CB build against wx3.x
« Reply #7 on: March 13, 2017, 02:20:08 am »
Probably the best option is to use wxTreeListCtrl in a virtual mode if possible.
This sounds interesting.
Any document about wxTreeListCtrl working on the virtual mode? I haven't use such control, but if there is a sample project, I may have a try and see what it's look like. Though the wxTreeListCtrl may look different like our current wxTreeCtrl, because it is a list.

Quote
But the code is pretty connected to the CC internals and it is not easy to extract it and make it reusable and with good interface, so other plugins can use it. :(
Yes, it is connected to the CC internals, not easy to extract it. But before that, we may find a way that first try to move the code from worker thread to gui thread.  :)
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4903
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: symbol browser issue when CB build against wx3.x
« Reply #8 on: March 13, 2017, 04:56:36 am »
I asked a question in wxWidgets' forum, see here: Any method to build a big wxTreeCtrl progressively in GUI thread?, let's see whether we can have good suggestions.
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4903
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: symbol browser issue when CB build against wx3.x
« Reply #9 on: March 15, 2017, 03:42:17 am »
Good news, good news, I get some nice answer from wxWidgets' forum, see here
Re: Any method to build a big wxTreeCtrl progressively in GUI thread?

It use a worker thread to dynamically do the dirty work, and construct the child nodes progressively. That is: if you want to add 1000 nodes, you have to send 10 notifications from the worker thread, while in the GUI thread, once received the event, the gui thread will add 100 nodes. It looks like the most time is accessing the TokenTree or search in the TokenTree, so we should still let it in the worker thread, but move the GUI construction in the main GUI thread.
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: 9949
Re: symbol browser issue when CB build against wx3.x
« Reply #10 on: March 16, 2017, 12:46:42 am »
Do you have a tool to do precise profiling (vtune, perf, ms's xperf)?
If you don't have such a tool then you're guessing and you're probably optimizing the wrong thing.

And fixing this is not a simple matter. The whole thing should be extracted and separated, so multiple plugins can use the same class browser.
<debugger plugin maintainer>
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4903
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: symbol browser issue when CB build against wx3.x
« Reply #11 on: March 16, 2017, 12:59:29 am »
Do you have a tool to do precise profiling (vtune, perf, ms's xperf)?
If you don't have such a tool then you're guessing and you're probably optimizing the wrong thing.

I don't have such tool, I think there's no such tool for mingw , I see a lot of timer in current symbol browser code. Is timer useful?
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: 9949
Re: symbol browser issue when CB build against wx3.x
« Reply #12 on: March 16, 2017, 02:35:29 am »
Not much... timers time what is instrumented... sampling profilers time what is being executed...
<debugger plugin maintainer>
(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 yvesdm3000

  • Almost regular
  • **
  • Posts: 223
Re: symbol browser issue when CB build against wx3.x
« Reply #13 on: March 16, 2017, 07:37:40 am »
Not much... timers time what is instrumented... sampling profilers time what is being executed...
If you can fill the tree progressively and that way you can get the tree filled using a huge set of symbols without anything crashing or blocking, what do you need a profiler for at this stage? Determining the amount of elements in the batch but that's just finetuning and might even never be optimal for any combination of cpu's and architectures except the one measured.

Yves
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 9949
Re: symbol browser issue when CB build against wx3.x
« Reply #14 on: March 16, 2017, 08:17:25 am »
Profilers always reveal surprising bottlenecks.  ::)
<debugger plugin maintainer>
(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!]