Building with wxWidgets 2.9

[MortenMacFly]

There is already a wx/wxsmith branch why would you need another one?

Because this development is not related to wxSmith, but the conversion to wx29.

[oBFusCATed]

Maybe we need to create a wx29 branch at some stage and work on getting it running. It's important for wxSmith because users (and we) are going to want to use the funky new controls that it brings and to do that we need to build wxSmith with 2.9. I've made a start on getting it to work with the 2.9 version but there's more to do, yet.
Some things in CB's code need to change due to deprecated or missing functions, etc. I'll keep chipping away at that and I'm happy to contribute whatever comes out if it to the greater good. I know Tim's made some progress, too, so we should make sure that the work isn't lost. A new branch would seem to be a good way to do it.

But Cryogen wants to change things in wxSmith -> add controls, so both branches would change wxSmith.
Also the wx2.9 branch should work with 2.8, because wx3.0 won't be released this year for sure and there are people on old linux distros, which won't have it...

[ptDev]

But Cryogen wants to change things in wxSmith -> add controls, so both branches would change wxSmith.
Also the wx2.9 branch should work with 2.8, because wx3.0 won't be released this year for sure and there are people on old linux distros, which won't have it...

But wx2.9 makes too many incompatible changes, starting with the wxString changes. It is meant to allow to transition code to wx3.0. I wouldn't trust it to work well with wx2.8... unless one fills the source code with version macros.

[oBFusCATed]

It is already filled with them...

[oBFusCATed]

Jens:
Is C::B working on your linux when using wx2.9?
I'm trying to see what is going on with wx2.9 and I get a crash in CC

What about making this topic a sticky one, so I don't waste 10 minutes searching for the wx2.9 porting topic (if this is the correct topic of course).

[MortenMacFly]

Is C::B working on your linux when using wx2.9?

Its working fine here on Windows meanwhile, at least the core. However - I have a few patches pending where I am unsure if they are needed for wx29 (for 64bit they are).

I'm trying to see what is going on with wx2.9 and I get a crash in CC

Make sure you compile CC with -DCC_NO_COLLAPSE_ITEM, this solved it for me, at least in 64bit build (with wx29, of course).

[oBFusCATed]

Code

#0 0x7ffff1552629	free() (/lib64/libc.so.6:??)
#1 0x45d44d	wxString::ConvertedBuffer<wchar_t>::~ConvertedBuffer(this=0x7fffffffada8, __in_chrg=<optimized out>) (/usr/include/wx-2.9/wx/string.h:3518)
#2 0x45a7e9	wxString::~wxString(this=0x7fffffffad90, __in_chrg=<optimized out>) (/usr/include/wx-2.9/wx/string.h:1340)
#3 0x7fffd488ab95	ParserCommon::FileType(filename=..., force_refresh=true) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/plugins/codecompletion/parser/parser.cpp:101)
#4 0x7fffd488be2e	ParserBase::ReadOptions(this=0x15c5a70) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/plugins/codecompletion/parser/parser.cpp:203)
#5 0x7fffd488b1e7	ParserBase::ParserBase(this=0x15c5a70) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/plugins/codecompletion/parser/parser.cpp:143)
#6 0x7fffd48b44f4	NativeParser::NativeParser(this=0x15f9ff8) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/plugins/codecompletion/nativeparser.cpp:288)
#7 0x7fffd482cd17	CodeCompletion::CodeCompletion(this=0x15f9f70) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/plugins/codecompletion/codecompletion.cpp:486)
#8 0x7fffd48504bf	PluginRegistrant<CodeCompletion>::CreatePlugin() (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/include/cbplugin.h:613)
#9 0x7ffff2646ac9	PluginManager::LoadPlugin(this=0x11c41b0, pluginName=...) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/sdk/pluginmanager.cpp:1044)
#10 0x7ffff2646479	PluginManager::ScanForPlugins(this=0x11c41b0, path=...) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/sdk/pluginmanager.cpp:985)
#11 0x48bac8	MainFrame::ScanForPlugins(this=0xcab870) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/src/main.cpp:1061)
#12 0x486e2d	MainFrame::MainFrame(this=0xcab870, parent=0x0) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/src/main.cpp:571)
#13 0x47a3b8	CodeBlocksApp::InitFrame(this=0x7799e0) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/src/app.cpp:417)
#14 0x47bc4d	CodeBlocksApp::OnInit(this=0x7799e0) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/src/app.cpp:642)
#15 0x480889	wxAppConsoleBase::CallOnInit(this=0x7799e0) (/usr/include/wx-2.9/wx/app.h:94)
#16 0x7ffff323fb34	wxEntry(int&, wchar_t**) () (/usr/lib64/libwx_baseu-2.9.so.3:??)
#17 0x479d3e	main(argc=6, argv=0x7fffffffdaf8) (/home/obfuscated/projects/codeblocks/dev/trunk_clean/src/src/app.cpp:261)

Here is the crash log, I'm using the -DCC_NO_COLLAPSE_ITEM option. wxGTK 2.9.3.1 on gentoo linux 64bit.

[Jenna]

It seems to work here with gcc 4.6.2, wx 2.9 from their trunk (I'm nit sure about the minor revision) on debian 64-bit.
But it is very, very slow.
Here is a snippet from debug log for simple hello-world project:

Create new parser for project 'test'
Updating class browser...
Class browser updated.
Starting batch parsing for project 'test'...
Project 'test' parsing stage done!
Project 'test' parsing stage done (110 total parsed files, 4482 tokens in 0 minute(s), 16.617 seconds).
Updating class browser...
Class browser updated.

here is the same for debugger-branch 7790 (wx2.:

Create new parser for project 'test'
Updating class browser...
Class browser updated.
Starting batch parsing for project 'test'...
Project 'test' parsing stage done!
Project 'test' parsing stage done (108 total parsed files, 4313 tokens in 0 minute(s), 0.262 seconds).
Updating class browser...
Class browser updated.

[ollydbg]

yesterday, i successful build CB against wx2.9.3 under windows XP, i also notice CC's parser is much much slower than the wx2.8.12.

[MortenMacFly]

yesterday, i successful build CB against wx2.9.3 under windows XP, i also notice CC's parser is much much slower than the wx2.8.12.

Oh dear... I have this feeling that its due to the whole wxString ANSI/Unicode abstraction stuff introduced in wx29... I guess we need to instrument some time measuring to find out...

[ollydbg]

I just test it again right now, the result is:

C::B nightly build against wx2.8.12.

Code

Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125538 tokens in 0 minute(s), 28.516 seconds).

C::B trunk build myself against wx2.9.3

Code

Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125621 tokens in 0 minute(s), 32.652 seconds).

So, it looks like there are not much difference. 

[ollydbg]

yesterday, i successful build CB against wx2.9.3 under windows XP, i also notice CC's parser is much much slower than the wx2.8.12.

Oh dear... I have this feeling that its due to the whole wxString ANSI/Unicode abstraction stuff introduced in wx29... I guess we need to instrument some time measuring to find out...

I have also deep analysis the wxString by reading it's document and code.

As I can see, the wxChar is still defined as wchar_t
wxWidgets: wxWidgets: Strings

wxChar is defined to be

    char when wxUSE_UNICODE==0
    wchar_t when wxUSE_UNICODE==1 (the default).

But the function wxString::GetChar(n) is much different between Linux and Windows.
Because under Windows, the wxString natively use wchar_t, so GetChar(n) will quickly do a fetch by base+address bias.
But under Linux, the wxString use utf8 format, so it will do more work, which means it should do the dynamic decoding from the beginning of the buffer, and count n "code point", then return the nth "code point" value. Luckily, wxString using a cache, which means the address returned by previous call of GetChar(n) was cached, if the next time, the user call GetChar(n+m), wxString is smart enough to begin the calculation/decoding from the address return from GetChar(n).

As a conclusion, if you have a source file in local disk and this file is encode in UTF8 format. Under windows, it should first convert to wchar_t array when the file is loaded and convert to wxString, because wxString use wchar_t natively in wxString. But under linux, we don't need the conversion, because wxString use natively UTF8 buffer. On the other side, when doing search in the wxString (like call GetChar()), it need do the conversion dynamically. So, from my analysis, there should not me much difference from wx2.8 to wx2.9 in Linux.

[Jenna]

I just test it again right now, the result is:

C::B nightly build against wx2.8.12.

Code

Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125538 tokens in 0 minute(s), 28.516 seconds).

C::B trunk build myself against wx2.9.3

Code

Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125621 tokens in 0 minute(s), 32.652 seconds).

So, it looks like there are not much difference. 

With wx2.8.12  from debian (64-bit, used compiler unknown):

Project 'Code::Blocks wx2.8.x - Unix' parsing stage done (1378 total parsed files, 74286 tokens in 0 minute(s), 7.577 seconds).

and with self-compiled wx2.9.4 (wx-trunk, 64-bit, compiled with gcc 4.6):

Project 'Code::Blocks wx2.8.x - Unix' parsing stage done (1851 total parsed files, 75516 tokens in 5 minute(s), 54.683 seconds).

The amount of parsed files is significantly different and the time needed for parsing ... 

[stahta01]

Did you turn off all the debugging options in wxWidgets 2.9?
Because I could see them taking a lot of CPU time to run.

Note: Just making a release build is NOT enough to turn the the checking/debugging code off.
See wxDEBUG_LEVEL or DEBUG_FLAG=0.

Tim S.

[ptDev]

The setting can be edited in setup.h prior to compiling.
Just uncomment this section:

Code

// ----------------------------------------------------------------------------
// debugging settings
// ----------------------------------------------------------------------------

// wxDEBUG_LEVEL will be defined as 1 in wx/debug.h so normally there is no
// need to define it here. You may do it for two reasons: either completely
// disable/compile out the asserts in release version (then do it inside #ifdef
// NDEBUG) or, on the contrary, enable more asserts, including the usually
// disabled ones, in the debug build (then do it inside #ifndef NDEBUG)
//
#ifdef NDEBUG
	#define wxDEBUG_LEVEL 0
#else
	#define wxDEBUG_LEVEL 2
#endif

Also, it would be interesting to know which wxString implementation 2.9.x uses. I've heard that as of 2.9.x, wxString is a wrapper to std::string (or std::wstring) by default. How does each implementation impact the performance?