Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx288.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc421.7z
The 19 July 2008 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20080719_rev5142_win32.7z
- Linux :
none
Resolved Fixed:
- Applied: [Patch #2508] Wrong name for .o file after renaming .cpp file
- header_fixup plugin:
- updated C::B defaults (e.g. to include the new logger)
- fixed a few bugs in wx 2.6.4 defaults
- added wx 2.8.8 defaults
- detect existing forward decls
- detect spaces in includes, e.g. #include < wx/wx.h >
- make the log available in a report window for inspection/save
- save the UI settings (including selection of libs)
- use RegEx for detection of includes, forward decls... in files - fixed crash when clicking the close-button twice by applying patch #2513, thanks Der Meister
- applied several patches from Bugtracker (thanks jens and others...)
- handle special charakters in tokenizer (fixes freeze)
- fix some compiler warnings on windows (auto-import)
- fixed issues with wxSmith on 64bit systems
- choose the right target for debugging
- correct placement of file modified dialog
- fixed wrong behaviour of taskbar icon on batch builds
- save missing layout infos - CodeSnippets with ThreadSearch : RightClick root item and choose FullSearch
- wxSmith: Changed method of connecting events directly to item (like itemVariable->Connect( ... ) ) - id's of items are not used now since this caused some problems (like wxEVT_CHAR was not always processed)
- lib_finder: Added support for library dependencies
- allow multiple selection for libraries in compiler options for all operations (move, copy, delete...)
- CodeSnippets 1 3.68 2008/07/13 : Fix standalone module to run as portable exe
- CodeSnippets 1 3.69 2008/07/14 : Jens' fix for broken CheckForModifiedFiles (Thanks)
- wizards:
- add support for Audo-Future derivatives (TC1767/TC1797)
- add wizards with usage of internal flash
- switch to new SFR header files for TriCore
- add support for Audo-Future derivatives - updated bzip libs to most recent version (fixes security flaws)
- added several lexers by applying patch #2517 (thanks danselmi)
- fixed bug #14098, by applying patch #2506 (thanks techtonik)
- Added HexEditor plugin
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
important : switched to wx 2.8.8 !!!
Quote from: killerbot on July 19, 2008, 02:51:43 PM
important : switched to wx 2.8.8 !!!
Note that there is a quite anoying bug with wxSpinCtrl with this wxWidgets version, text is not editable, arrows works.
Dje
I just uploaded binaries for debian (32- and 64bit) to my server (see signature).
A tarball is also available, that should be usable on all platforms
Quote from: dje on July 19, 2008, 07:43:42 PM
Quote from: killerbot on July 19, 2008, 02:51:43 PM
important : switched to wx 2.8.8 !!!
Note that there is a quite anoying bug with wxSpinCtrl with this wxWidgets version, text is not editable, arrows works.
Dje
I can not confirm this.
A quick test on the editor settings for spaces per tab in C::B works. I cann edit with keyboard or with the arrows.
Build with gcc 4.1.2 and wxWidgets 2.8.8 in debian etch chroot.
Quote from: jens on July 19, 2008, 07:59:10 PM
I can not confirm this.
Lucky man !
I had this problem on Win XP pro, last C::B, wxWidgets shared, monolithic, unicode, release with "C::B" gcc 3.4.5
I am not the only one !
http://trac.wxwidgets.org/ticket/9637 (http://trac.wxwidgets.org/ticket/9637)
After a fresh C::B install, I can't edit Tab size in spaces in editor settings but I can change the value with arrows.
C::B 5142, Win XP SP3, provided wxwidgets and mingw dlls
Dje
Quote from: dje on July 19, 2008, 09:12:11 PM
Quote from: jens on July 19, 2008, 07:59:10 PM
I can not confirm this.
Lucky man !
I had this problem on Win XP pro, last C::B, wxWidgets shared, monolithic, unicode, release with "C::B" gcc 3.4.5
I am not the only one !
http://trac.wxwidgets.org/ticket/9637 (http://trac.wxwidgets.org/ticket/9637)
Dje
So it seems to be a bug "only" on windows.
I only use windows at work and for photo printing, and therefore I only use C::B on win for web-developping at the moment.
So I did not run into the bug.
Systematic bug with code snippets:
- View -> Code snippets
- Right click on root (code snippets)
- Click on "Full Search"
- In "Snippets search" window, click on File -> Open
- Select any file (I tried with a workspace and a cpp file)
- Crash
-------------------
Error occured on Saturday, July 19, 2008 at 23:57:04.
C:\DevSofts\CodeBlocks\codeblocks.exe caused an Access Violation at location 6c9ff50b in module C:\DevSofts\CodeBlocks\wxscintilla.dll Reading from location 00000150.
Registers:
eax=00000000 ebx=00b11e98 ecx=0022efe4 edx=0000284f esi=03674dd8 edi=0022f1ec
eip=6c9ff50b esp=0022efd4 ebp=0022efec iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
Call stack:
6C9FF50B C:\DevSofts\CodeBlocks\wxscintilla.dll:6C9FF50B _ZN11wxScintilla7SendMsgEill
6C9FF70B C:\DevSofts\CodeBlocks\wxscintilla.dll:6C9FF70B _ZN11wxScintilla13GetCurrentPosEv
6CA03B4F C:\DevSofts\CodeBlocks\wxscintilla.dll:6CA03B4F _ZN11wxScintilla14GetCurrentLineEv
65E9EE33 C:\DevSofts\CodeBlocks\share\codeblocks\plugins\codecompletion.dll:65E9EE33
65EE3468 C:\DevSofts\CodeBlocks\share\codeblocks\plugins\codecompletion.dll:65EE3468 _ZN8cbPlugin9OnReleaseEb
618101EE C:\DevSofts\CodeBlocks\codeblocks.dll:618101EE _ZN11EditorHooks9CallHooksEP8cbEditorR16wxScintillaEvent
67F49CAF C:\DevSofts\CodeBlocks\share\codeblocks\plugins\codesnippets.dll:67F49CAF
6CCCAC0E C:\DevSofts\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCCAC0EDwarf Error: found dwarf version '16897', this reader only handles version 2 information.Dje
Hi,
I get a nasty build error when compiling defaults.cpp from the headerfixup plugin, but only on x86_64 with gcc <4.3 (opensuse 10.3, 10.2, mandriva 2008 and fedora 8 ). somehow it's using up all the ram and swap. perhaps you know why :)
here it comes (it's from suse 10.3 but all other look the same):
g++ -DHAVE_CONFIG_H -I. -I../../../../src/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FIL
ES -D__WXGTK__ -pthread -I../../../../src/include -I../../../../src/include/wxscintilla/include -Ulinux -Uunix -O2 -ffast-math -fmessage-length=0 -Wall -D_FO
RTIFY_SOURCE=2 -fstack-protector -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT defaults.lo -MD -MP -MF .deps/defaults.Tpo -c defaults.cpp -fPI
C -DPIC -o .libs/defaults.o
In file included from bindings.h:10,
from defaults.cpp:10:
/usr/include/wx-2.8/wx/hashmap.h: In member function 'wxLongToLongHashMap_wxImplementation_HashTable::Node** wxLongToLongHashMap_wxImplementation_HashTable::
GetNodePtr(const long int&) const':
/usr/include/wx-2.8/wx/hashmap.h:714: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from defaults.cpp:10:
bindings.h: In member function 'Bindings::MappingsT_wxImplementation_HashTable::Node** Bindings::MappingsT_wxImplementation_HashTable::GetNodePtr(const wxStr
ing&) const':
bindings.h:53: warning: dereferencing type-punned pointer will break strict-aliasing rules
bindings.h: In member function 'Bindings::GroupsT_wxImplementation_HashTable::Node** Bindings::GroupsT_wxImplementation_HashTable::GetNodePtr(const wxString&
) const':
bindings.h:54: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc1plus invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Call Trace: <ffffffff8015d602>{oom_kill_process+87}
<ffffffff8015da36>{out_of_memory+299} <ffffffff8015f61f>{__alloc_pages+600}
<ffffffff80160f6c>{__do_page_cache_readahead+265} <ffffffff8010622a>{hypercall_page+554}
<ffffffff8010622a>{hypercall_page+554} <ffffffff8015cd2d>{filemap_nopage+336}
<ffffffff8016acbe>{__handle_mm_fault+830} <ffffffff8010622a>{hypercall_page+554}
<ffffffff802e64b5>{do_page_fault+2909} <ffffffff8016e46c>{do_brk+485}
<ffffffff8010a92f>{error_exit+0}
Mem-info:
DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 159 Cold: hi: 62, btch: 15 usd: 44
Free pages: 6368kB (0kB HighMem)
Active:90286 inactive:90313 dirty:0 writeback:0 unstable:0 free:1592 slab:1788 mapped:0 pagetables:1351
DMA free:2932kB min:8kB low:8kB high:12kB active:4152kB inactive:4024kB present:2424kB pages_scanned:13512 all_unreclaimable? yes
lowmem_reserve[]: 0 731 731 731
DMA32 free:3436kB min:3456kB low:4320kB high:5184kB active:356992kB inactive:357228kB present:749420kB pages_scanned:1289562 all_unreclaimable? yes
lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2932kB
DMA32: 1*4kB 11*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3436kB
Swap cache: add 664237, delete 664237, find 31394/68307, race 0+0
Free swap = 0kB
Total swap = 1535992kB
Free swap: 0kB
194048 pages of RAM
4766 reserved pages
11 pages shared
0 pages swap cached
Out of Memory: Kill process 30723 (g++) score 90295 and children.
Out of memory: Killed process 30724 (cc1plus).
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <URL:http://bugs.opensuse.org> for instructions.
make[4]: *** [defaults.lo] Error 1
make[4]: Leaving directory `/usr/src/packages/BUILD/codeblocks-1.0svn5142/src/plugins/contrib/headerfixup'
can someone confirm this? i don't have x86_64 installed and can't make more tests, i only have the opensuse buildservice where i have to wait for free build hosts.
Your compiler ran out of memory while compiling this file. There are already some other posts in the forum around regarding this file. I think the best solution was to disable optimizations for that file.
Quote from: Der Meister on July 20, 2008, 11:58:20 AM
Your compiler ran out of memory while compiling this file. There are already some other posts in the forum around regarding this file. I think the best solution was to disable optimizations for that file.
Here's a link to my post with a patch for "Makefile.am": http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715 (http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715)
Quote from: daniel2000 on July 20, 2008, 11:48:22 AM
can someone confirm this? i don't have x86_64 installed and can't make more tests, i only have the opensuse buildservice where i have to wait for free build hosts.
Confimed ! The solution of jens works fine for me.
Regards, pasgui
Quote from: jens on July 20, 2008, 12:04:42 PM
Quote from: Der Meister on July 20, 2008, 11:58:20 AM
Your compiler ran out of memory while compiling this file. There are already some other posts in the forum around regarding this file. I think the best solution was to disable optimizations for that file.
Here's a link to my post with a patch for "Makefile.am": http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715 (http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715)
Thanks. Just a second ago, I found your post :D (used wrong search strings or overlooked the hit)
will apply the patch and recompile it.
Hi,
I have a small problem with opening files by double clicking...
If C::B is closed and I open a file by double clicking it C::B starts and opens the file, but I get a Windows message that the file could not be found !!! :shock:
This happens with all file types (.h, .cpp, .cbp, ...)...
If C::B is already opened everything works fine...
Well, this problem occured already some times ago and I think the workaround from there would work this time too... ;)
EDIT: NO, the old workaround doesn't work here (disabeling the "Symbols Browser") as I show in this thread: http://forums.next.codeblocks.org/index.php/topic,8845.msg64137.html#msg64137 (http://forums.next.codeblocks.org/index.php/topic,8845.msg64137.html#msg64137) !!!
I'm running XPpro (sp2)...
Quote from: dje on July 20, 2008, 12:09:42 AM
Systematic bug with code snippets:
- View -> Code snippets
- Right click on root (code snippets)
- Click on "Full Search"
- In "Snippets search" window, click on File -> Open
- Select any file (I tried with a workspace and a cpp file)
- Crash
...
Dje
Fixed SVN 5145
*CodeSnippets 1 3.70 2008/07/20
- Fix FullSearch file open crash when CodeCompletion loaded
Quote from: daniel2000 on July 20, 2008, 12:13:34 PM
Quote from: jens on July 20, 2008, 12:04:42 PM
Quote from: Der Meister on July 20, 2008, 11:58:20 AM
Your compiler ran out of memory while compiling this file. There are already some other posts in the forum around regarding this file. I think the best solution was to disable optimizations for that file.
Here's a link to my post with a patch for "Makefile.am": http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715 (http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715)
Thanks. Just a second ago, I found your post :D (used wrong search strings or overlooked the hit)
will apply the patch and recompile it.
I just added a patch to trunk that turns off optimization for headerfixip-plugin
if "build-host" is "x86_64" (r5147).
EDIT:Reverted conditional part: on 32bit systems there are also problems with optimization of "defaults.cpp", not as much memory needed as on 64bit, but way to much for most build-systems.
Sorry for the inconvenience.
Dear All, I would advice to stop using this nightly build. I have discovered a serious regression due to rev 5124. We hope to have it fixed in tomorrows nightly.
I reverted my repo back to r5115, please downgrade to this version if possible, until the cause for the regression is found.
More information about the regression: http://forums.next.codeblocks.org/index.php/topic,8833.msg64081.html (http://forums.next.codeblocks.org/index.php/topic,8833.msg64081.html).
I will be not at home until thursday or friday night, so I will not be able to update the repo earlier.
Quote from: jens on July 20, 2008, 10:18:40 PM
Quote from: daniel2000 on July 20, 2008, 12:13:34 PM
Quote from: jens on July 20, 2008, 12:04:42 PM
Quote from: Der Meister on July 20, 2008, 11:58:20 AM
Your compiler ran out of memory while compiling this file. There are already some other posts in the forum around regarding this file. I think the best solution was to disable optimizations for that file.
Here's a link to my post with a patch for "Makefile.am": http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715 (http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715)
Thanks. Just a second ago, I found your post :D (used wrong search strings or overlooked the hit)
will apply the patch and recompile it.
I just added a patch to trunk that turns off optimization for headerfixip-plugin if "build-host" is "x86_64" (r5147).
EDIT:
Reverted conditional part: on 32bit systems there are also problems with optimization of "defaults.cpp", not as much memory needed as on 64bit, but way to much for most build-systems.
Sorry for the inconvenience.
It looks like I found a much better solution than to manually autobuild-system for one target:
I overworked "defaults.cpp" so that all names and headers are in a StringArray and get applied in a loop.
It was just a little bit of search and replace and put some variables and loops to it.
It might make sense to put the loops in an own function, to avoid to have the same code multiple times.
But it's a little late now and I will have a hard week at work and therefore I had to go to bed now.
So I just attach the 7zipped "defaults.cpp".
@Martin: please have a look at it, if you find the time.
Btw. compile time with optimization is about 1-2 seconds on my system.
[attachment deleted by admin]
Quote from: killerbot on July 20, 2008, 11:47:38 PM
Dear All, I would advice to stop using this nightly build. I have discovered a serious regression due to rev 5124. We hope to have it fixed in tomorrows nightly.
...which one? It works nice here...?!
Edit: Found the other post... ignore this question... I am looking into it.
Quote from: jens on July 21, 2008, 01:46:15 AM
@Martin: please have a look at it, if you find the time.
I had a look at it. The code sucks now (it looks ugly and is not anything I would like to have in my projects) but if the compiler is happy with it, then I am, too. Just commit I have no more complains.
I wonder if we should report this to the GCC gurus. I really would like to know why the slowdown really occurs. I mean: This is very simply code, so why the hell can any optimisation algorithm on that piece of code can freak out like that?!
Quote from: killerbot on July 20, 2008, 11:47:38 PM
Dear All, I would advice to stop using this nightly build. I have discovered a serious regression due to rev 5124. We hope to have it fixed in tomorrows nightly.
Good news! We
have fixed this in R5149.
@killerbot: Probably another nightly as of today...?! ;-)
Ps.: Sorry for this. My fault.
I am in a rush now, so nightly of tomorrow (maybe tomorrow morning ;-) )
Quote from: killerbot on July 21, 2008, 06:30:29 PM
I am in a rush now, so nightly of tomorrow (maybe tomorrow morning ;-) )
So it's probably going to be a "morningly"... :lol:
Just take your time...