I am assuming the reason the Mac build is how it is is because there are few (if any) Mac programmers contributing to the project. I wish I was more skilled at Mac programming (and had more free time) as I'd rather fix a problem, rather than just complain about it. I only hope that this post calls attention to the state of the Mac build so that other Mac programmers can make this program the work of art it should be.
The Mac OS X build of Code::Blocks is completely unusable.
I am a professional programmer myself, and I if a project I was working on put out a "big" release such as this with bugs as bad as these, my team would not only be fired on the spot, but blacklisted from the industry to make sure they either learned their lesson, or starved on the street regretting their incompetence.
sudo port install codeblocks +x11
Is that a more stable way?
If so, is there any way a build of 8.02 could be released built in that manner?
The crash report is this: (It's long, sorry!)
Thread 1 Crashed:
0 libwx_macu-2.8.0.dylib 0x01586c1c wxMBConv::cWC2MB(wchar_t const*) const + 188
1 libwx_macu-2.8.0.dylib 0x01553354 wxAccess(wchar_t const*, int) + 52
2 libwx_macu-2.8.0.dylib 0x015487a4 wxFile::Access(wchar_t const*, wxFile::OpenMode) + 52
3 libcodeblocks.0.dylib 0x010b3184 FileLoader::operator()() + 36
4 libcodeblocks.0.dylib 0x012bbb08 BackgroundThread::Entry() + 152
OK, at least that gives the point when the thread crashed...This reminds me on a discussion where Thomas insisted that this code cannot fail... Now Thomas: See?! ;-)CodeThread 1 Crashed:
0 libwx_macu-2.8.0.dylib 0x01586c1c wxMBConv::cWC2MB(wchar_t const*) const + 188
1 libwx_macu-2.8.0.dylib 0x01553354 wxAccess(wchar_t const*, int) + 52
2 libwx_macu-2.8.0.dylib 0x015487a4 wxFile::Access(wchar_t const*, wxFile::OpenMode) + 52
3 libcodeblocks.0.dylib 0x010b3184 FileLoader::operator()() + 36
4 libcodeblocks.0.dylib 0x012bbb08 BackgroundThread::Entry() + 152
This reminds me on a discussion where Thomas insisted that this code cannot fail... Now Thomas: See?! ;-)All I do see is that the crash happens inside wxFile::Access(fileName, wxFile::read) on a (entirely unnecessary) character set conversion.
QuoteI am a professional programmer myself, and I if a project I was working on put out a "big" release such as this with bugs as bad as these, my team would not only be fired on the spot, but blacklisted from the industry to make sure they either learned their lesson, or starved on the street regretting their incompetence.
Come on, that's close to trolling. Your project is obviously not developed by volunteers in their free time - no comparison is possible.
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...QuoteIf 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.
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.
So if you do have some Mac patches for Code::Blocks (or wxWidgets for that matter), do send them in...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 :P )
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 :P )
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.
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
Another typical crash is:Different API function, same thing.
...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! :-)