Code::Blocks unusable on Mac OS X 10.4

[Auria]

Is that a more stable way?

The wxGTK port seems somewhat more stable, but I guess we'll see how it works for the people that are having problems with the wxMac version first - and whether X11 is acceptable or not...

If so, is there any way a build of 8.02 could be released built in that manner?

Sure, if there is enough demand there could be a version built that bundles GTK+ and wxGTK and doesn't require MacPorts installed. It will require Xcode Tools* and X11.app installed though.

I'm somewhat involved in the mac port of GIMP, and all I can say is, stay as far from X11.app as you can... every week we get something in X11 broken, sometimes they arbitrarly change config files location, it was broken many times on leopard, it contains many broken libs on tiger, ilaunching method was chaned on leopard, it sometimes installs in /usr/X11, sometimes in /usr/X11R6, the updates you can download online install libraries versions older than the ones you previously had, it opens windows out of the screen, it causes memory corruption on many operations and causes crases... In sort, X11.app on mac is total hell  :lol: better fix the native version.

I sould really take a look at it and try to fix some bugs. Now if I could get a faster computer, so that speed is a bit less of an hell

i also agree there should be some mention that the mac version may not be as stable as others (somewat embarrassing snce i recently asked for the mac verson to be listed on the website, however i didn't think it would be marked as stable as others)

[afb]

I'm somewhat involved in the mac port of GIMP, and all I can say is, stay as far from X11.app as you can... every week we get something in X11 broken, sometimes they arbitrarly change config files location, it was broken many times on leopard, it contains many broken libs on tiger, ilaunching method was chaned on leopard, it sometimes installs in /usr/X11, sometimes in /usr/X11R6, the updates you can download online install libraries versions older than the ones you previously had, it opens windows out of the screen, it causes memory corruption on many operations and causes crases... In sort, X11.app on mac is total hell  :lol: better fix the native version.

As mentioned, both are available in MacPorts and wxGTK is slightly "better" (even if the wxgtk port is older than the other - uses 2.8.4 ANSI still). X11.app was rather broken, but is better now with 10.5.2 and the included updates from the Xquartz project. As for the install locations it was /usr/X11R6 on Tiger (XFree86-based), but is /usr/X11 on Leopard (Xorg-based) though there is a compat symlink from the old location so it should still work.

But yes you are right, wxMac is still the primary platform - no question about that...

[afb]

BTW, I will probably continue with the "nightly builds" (usually more like monthly) so any bugfixes made should be available even before the next release is out (next up is 20080310_rev4943). So if you do have some Mac patches for Code::Blocks (or wxWidgets for that matter), do send them in...

http://developer.berlios.de/project/showfiles.php?group_id=5358

[Auria]

As for the install locations it was /usr/X11R6 on Tiger (XFree86-based), but is /usr/X11 on Leopard (Xorg-based) though there is a compat symlink from the old location so it should still work.

Well it should, but in practice we learned that in some cases the symlink is simply not there, no clue why

So if you do have some Mac patches for Code::Blocks (or wxWidgets for that matter), do send them in...
http://developer.berlios.de/project/showfiles.php?group_id=5358

Well I did send a very humble patch there, though it got no answer. (Maybe it's bad, please just tell me so if it's the case  )

[afb]

Well I did send a very humble patch there, though it got no answer. (Maybe it's bad, please just tell me so if it's the case  )

Applied now. (patch #2305, r4945)

[afb]

wxFile::Access is a perfectly legal function to call, unless I am grossly mistaken? So really, from the application's point of view, I can't see how this could crash in a legal environment.

If it crashes on Mac, then I'm really sorry... complain to the wxMac guys, or buy a PC, is all I can say.

Another typical crash is:

Code

Thread 5 Crashed:
0   libwx_macu-2.8.0.dylib         	0x08b649ae wxMBConv::cWC2MB(wchar_t const*) const + 104
1   libwx_macu-2.8.0.dylib         	0x08b393ed wxStat(wchar_t const*, stat*) + 43
2   libwx_macu-2.8.0.dylib         	0x08b39448 wxFileExists(wxString const&) + 26
3   libcodecompletion.so           	0x17a44e5c Parser::FindFileInIncludeDirs(wxString const&, bool) + 220 (parser.cpp:792)
4   libcodecompletion.so           	0x17a451a4 Parser::FindFirstFileInIncludeDirs(wxString const&) + 108 (parser.cpp:773)
5   libcodecompletion.so           	0x17a49be5 Parser::GetFullFileName(wxString const&, wxString const&, bool) + 119 (parser.cpp:821)
6   libcodecompletion.so           	0x17a4bda2 ParserThread::HandleIncludes() + 194 (parserthread.cpp:920)
7   libcodecompletion.so           	0x17a53b7f ParserThread::DoParse() + 8985 (parserthread.cpp:463)
8   libcodecompletion.so           	0x17a552cc ParserThread::Parse() + 76 (parserthread.cpp:333)
9   libcodecompletion.so           	0x17a6c861 ParserThread::Execute() + 17 (parserthread.h:75)
10  libcodeblocks.0.dylib          	0x01a34133 cbThreadPool::cbWorkerThread::Entry() + 183 (thread.h:176)
11  libwx_macu-2.8.0.dylib         	0x08b96678 wxThreadInternal::MacThreadStart(void*) + 142

[MortenMacFly]

...after a short chat with Yiannis I have updated the wxScintilla component in SVN. Mind updating / trying the MAC build again whether this probably increases speed (a lot/slightly/not at all)?! Thanks! :-)

[thomas]

Another typical crash is:

Different API function, same thing.

Conversion from wxString to wchar_t* to UTF-8 char*, and crash. Looking at the awful mess in strconv.[h|cpp], I'm not surprised either... function pointers to #ifdef sections typed through 3 layers of #defines and typedefs, and half a dozen special cases. You can't even figure out which function is actually called in under half an hour...

Either way, since the crash happens during the wx-internal string conversion to "system", there's nothing we can do about it,... except not calling any functions that might possibly open a file, read a directory, or otherwise involve a string which might possibly be passed to the operating system... which kind of makes an IDE absurd.

[afb]

Makes you wonder if it wouldn't be "easier" to use the ANSI version of wxWidgets instead...

[Auria]

Well wx 3 will be Unicode-only so maybe there will be less problems

What would need to be investigated, though, is why C::B is the only app (well that i know of but i know quite a few) that makes this feature crash - dozens of mac wxApps use these features without problems. I'll try looking at it if I have time.

Morten: am building now

[Auria]

...after a short chat with Yiannis I have updated the wxScintilla component in SVN. Mind updating / trying the MAC build again whether this probably increases speed (a lot/slightly/not at all)?! Thanks! :-)

I have built revision 4953. I did not do any benchmark, but unfortunately I did not notice much speed improvements during editing (though, was there something specific I should have checked? not knowing what change to expect it's a bit hard to tell)

I know the CodeLite author added caching code into his wxScintilla, making it significantly faster (on linux too), maybe that's a possible target?