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_wx287.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 25 June 2008 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20080625_rev5106_win32.7z
- Linux :
none
Resolved Fixed:
- fixed crash with HeaderFixup plugin if no project is active
- Fixed: Couple of layout issues in Header-fixup plugin
- menu entries and keyboard shortcuts for "Find declaration of :'...'" and "Find implementation of :'...'"
- applied patch 2494 which fixes bug 14037 (thanks Jens)
- Help plugin: [BUGFIX] Crash when deleting first entry (patch provided by jens)
- fixed: C::B not asking anymore to save a modified workspace if e.g. another project was added
- menu entry and keyboard shortcut for "Open include file"
- don't parse the targets of another platform for include directories [otherwise you get crap on linux when for example a project containing linux wx target and windows wx target : on linux you get complaints that #WX is unknown and you get the global var dialog very easily 6 times or more presented]
- Added current target to search scope in ThreadSearch plugin
- Fixed: File permission gets messed up after a file save. (Uses a portion of patch by Jens, Thanks!)
- Fixed: AutoVersioning plugin adds version.h more than once for projects with more than 2 targets
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
A source tar-ball (usable on linux and windows) and binaries for debian (32 and 64 bit) are available on my server (http://apt.jenslody.de/).
It shows as svn5105, but it's the same version (there are only some small patches (https://apt.jenslody.de/patchlist.htm)), svn5106 is a change outside trunk.
Ubuntu 7.04 to 8.04 Amd64 tar.gz archive (containing '.deb' installers builds with wx287) can be found here (http://www.esnips.com/web/CodeBlocks).
In Debian Lenny testting, i build CB, but the version info can not show.
In 'Start here' page, it's show: svn build rev 0 (unknown date) gcc 4.3.1 Linux/unicode
Quote from: Loaden on June 26, 2008, 04:04:34 AM
In Debian Lenny testting, i build CB, but the version info can not show.
In 'Start here' page, it's show: svn build rev 0 (unknown date) gcc 4.3.1 Linux/unicode
you need svn to fetch that info
Quote from: JGM on June 26, 2008, 06:22:00 AM
Quote from: Loaden on June 26, 2008, 04:04:34 AM
In Debian Lenny testting, i build CB, but the version info can not show.
In 'Start here' page, it's show: svn build rev 0 (unknown date) gcc 4.3.1 Linux/unicode
you need svn to fetch that info
I get the source from SVN by 'svn checkout svn://svn.berlios.de/codeblocks/trunk ~/Sources/CodeBlocks'
Have some step need me do? thanks!
There appears to be a rather odd bug Ctrl-Delete doesn't delete the current word, it calls the Find Declaration function and, in my case, brings up the Multiple Matches dialog.
Code::Blocks SVN REV5106
Windows XP SP 2
Quote from: Wahooney on June 26, 2008, 11:58:10 AM
There appears to be a rather odd bug Ctrl-Delete doesn't delete the current word, it calls the Find Declaration function and, in my case, brings up the Multiple Matches dialog.
Code::Blocks SVN REV5106
Windows XP SP 2
do you have this issue with the previous nightly ?
EDIT : I tried this on svn 4906 and it does delete something :
a) test123 : if cursor just before the t --> deletes entire word
b) test123 : if cursor just in front of the 1 --> deletes 123
in latest nightly tries to find declaration of test123.
I think I know where it comes from :
find declaration now has a shortcut : "ctrl . "
And on my numeric part of the keyboard the . and Del are on the same key. Whatever the values of the num lock it seems to always see it as a '.' and never as a Del. Same issue applies when I use the unique Delete key (middle of my keyboard together with Home, Insert, End, Page Up/Down).
I have no idea why WXWIDGETS treats them as the same :-(
The last nightly I used was 5093 and Ctrl-Delete worked correctly.
'Search directories' not work on Debian!
When compile, error info:
/media/disk/project/pmoney/src/app.cpp|5|error: calling fdopen: Bad file descriptor|
and is line is ' #include "pch.h" ', and pch.h dir is /include/pch.h
Quote from: jens on June 25, 2008, 11:10:02 PM
A source tar-ball (usable on linux and windows) and binaries for debian (32 and 64 bit) are available on my server (http://apt.jenslody.de/).
It shows as svn5105, but it's the same version (there are only some small patches (https://apt.jenslody.de/patchlist.htm)), svn5106 is a change outside trunk.
How to install old version? e.g. 5093 ?
I want: sudo apt-get install codeblocks={5093}, but it's failure.
thanks!
Now SVN5105 can't work in my Debian OS.
Quote from: Loaden on June 28, 2008, 05:02:24 AM
Quote from: jens on June 25, 2008, 11:10:02 PM
A source tar-ball (usable on linux and windows) and binaries for debian (32 and 64 bit) are available on my server (http://apt.jenslody.de/).
It shows as svn5105, but it's the same version (there are only some small patches (https://apt.jenslody.de/patchlist.htm)), svn5106 is a change outside trunk.
How to install old version? e.g. 5093 ?
I want: sudo apt-get install codeblocks={5093}, but it's failure.
thanks!
Now SVN5105 can't work in my Debian OS.
The easiest way is to use synaptic and force a version (chose the package to install and press Ctrl+E).
If you use command-line you have to use the correct version and no curly-brackets.
For svn5093 from my repo it is:
sudo apt-get install codeblocks=1.0svn5093-1You have to install all C::B-packages that depend on each other in one command-line or you get dependency problems.
You can also download the debs manually from http://apt.jenslody.de/pool (http://apt.jenslody.de/pool).
Quote from: Loaden on June 28, 2008, 04:33:06 AM
'Search directories' not work on Debian!
When compile, error info:
/media/disk/project/pmoney/src/app.cpp|5|error: calling fdopen: Bad file descriptor|
and is line is ' #include "pch.h" ', and pch.h dir is /include/pch.h
thank you! jens.
and this question because g++-4.3.1, if i use g++-4.2, it work fine!
with the CB's 'Start here' can not show version info, because too.
When i close CB, but the PC so slow, so i click 'close button' again, and CB crash!
if click CB's close btn two times, CB will crash.
[attachment deleted by admin]
Quote from: Loaden on June 28, 2008, 04:33:06 AM
'Search directories' not work on Debian!
When compile, error info:
/media/disk/project/pmoney/src/app.cpp|5|error: calling fdopen: Bad file descriptor|
and is line is ' #include "pch.h" ', and pch.h dir is /include/pch.h
It's not related to C::B. Report it GCC-devs.
Quote from: Loaden on June 28, 2008, 03:19:28 PM
When i close CB, but the PC so slow, so i click 'close button' again, and CB crash!
if click CB's close btn two times, CB will crash.
You report a number of crashes which no other users / devs can confirm which is really weird.
Quote from: Biplab on June 28, 2008, 03:24:26 PM
You report a number of crashes which no other users / devs can confirm which is really weird.
Because you computer is fast, but my computer is slow.
When i close CB's 'close btn', CB can not shut. so i close CB's 'Close Button' again, then, CB crash!
Quote from: Loaden on June 29, 2008, 02:34:40 AM
Because you computer is fast, but my computer is slow.
When i close CB's 'close btn', CB can not shut. so i close CB's 'Close Button' again, then, CB crash!
Hmm.. If that is the case then you have to be little patient. If a bug is not reproducible, it's difficult to fix. :)
Quote from: Biplab on June 28, 2008, 03:24:26 PM
Quote from: Loaden on June 28, 2008, 03:19:28 PM
When i close CB, but the PC so slow, so i click 'close button' again, and CB crash!
if click CB's close btn two times, CB will crash.
You report a number of crashes which no other users / devs can confirm which is really weird.
I can reproduce it and I'm working on a fix. Seems as if ProjectManager is accessed after it was already freed.
Edit:
Actually it was an easy one:
Index: src/src/main.cpp
===================================================================
--- src/src/main.cpp (revision 5106)
+++ src/src/main.cpp (working copy)
@@ -2577,6 +2577,9 @@
void MainFrame::OnApplicationClose(wxCloseEvent& event)
{
+ if (m_InitiatedShutdown)
+ return;
+
CodeBlocksEvent evt(cbEVT_APP_START_SHUTDOWN);
Manager::Get()->ProcessEvent(evt);
Manager::Yield();
Thanks to Der Meister!
Found new question: Debian OS, in CB's 'Management'->'Projects', i remove a file form project, add a new file in the same time. but CB auto close, and can't show crash report.
Charset question.
[attachment deleted by admin]
Quote from: Loaden on July 04, 2008, 11:02:05 AM
Charset question.
Maybe with "autochanged" you mean that when you open your file its encoding is wrongly detected.
In that case you can force an encoding, when opening the files, in the
Settings-->Editor-->General Settings-->Default encoding when opening files.
Regards, XayC
Quote from: XayC on July 04, 2008, 09:57:35 PM
Quote from: Loaden on July 04, 2008, 11:02:05 AM
Charset question.
Maybe with "autochanged" you mean that when you open your file its encoding is wrongly detected.
In that case you can force an encoding, when opening the files, in the Settings-->Editor-->General Settings-->Default encoding when opening files.
Regards, XayC
'Settings-->Editor-->General Settings-->Default encoding when opening files'
Hi, XayC, i did it.
and, in winxp sp3, it's no question. only in Debian Lenny.
My Debian locales is en_US_UTF-8
my setting about charset.
[attachment deleted by admin]
In WinXPSp3, when i use cdb to debug, i found: 'step into' not work, but 'next line' is ok.
and when i coding, cb auto close like in Debian: no msg, no crash report, no anything...
As there was no reaction about the patch I posted here as fix for the reported crash I have put it into the tracker on berlios:
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2513&group_id=5358
Quote from: Der Meister on July 08, 2008, 09:11:42 AM
As there was no reaction about the patch I posted here as fix for the reported crash I have put it into the tracker on berlios:
There was a reaction, but not visible... I have applied it since "day one" and had in mind to test it. But it won't get lost as it is in my local copy... don't you worry... ;-)
I don't know if this post belongs to this topic or it should go to plugins section, so excuse me if I'm wrong...
I've found the cause of bug 13447 about wxSmith on 64-bit Linux (http://developer.berlios.de/bugs/?func=detailbug&bug_id=13447&group_id=5358 ) and described how to fix it (redeclare numeric properties of supported components as 'long's). Would some of C::B developers include the full fix in future nightbuild please?..
Quote from: olelukoie on July 09, 2008, 04:47:40 PM
I don't know if this post belongs to this topic or it should go to plugins section, so excuse me if I'm wrong...
I've found the cause of bug 13447 about wxSmith on 64-bit Linux (http://developer.berlios.de/bugs/?func=detailbug&bug_id=13447&group_id=5358 ) and described how to fix it (redeclare numeric properties of supported components as 'long's). Would some of C::B developers include the full fix in future nightbuild please?..
@olelukoie: good work !
I just submitted a patch (http://developer.berlios.de/patch/?func=detailpatch&patch_id=2516&group_id=5358) for this bug.
I will upload patched svn-binaries for debian to my repo this evening.
Quote from: jens on July 09, 2008, 06:02:53 PM
I will upload patched svn-binaries for debian to my repo this evening.
The binaries are on the server (r5115), they also include the Valgrind plugin (http://forums.next.codeblocks.org/index.php/topic,6666.new.html).
when i try to compile svn 5116 my HDD freaks out at Headerfixup when it trys to make the .o file
weird isn't it
only hdd work the cpu is in idle mod
this is causing on linux
I can confirm this. The problem is the file defaults.cpp. Compiling it takes needs more that 1GB of RAM but on machines with less physical RAM (like mine, I have only 512MB here) a huge amount of swap space will be used which slows the computer down or makes it even unusable. After about five minutes I aborted the compiler and decided not to compile this plugin.
i have 2GB ram and 1GB swap :shock:
:lol:
edit
sorry that was offtopic :)
what is causing this
Quote from: PsYhLo on July 10, 2008, 10:03:23 AM
when i try to compile svn 5116 my HDD freaks out at Headerfixup when it trys to make the .o file
weird isn't it
only hdd work the cpu is in idle mod
this is causing on linux
I have 3.3 GB usable Ram and the 64-bit compilation uses about 3.4 GB for "defaults.cpp". Compiling for 32-bit uses much less memory.
This only happens with "./configure make ..." not when compiling with C::B.
And it does not start with r5116.
Quote from: jens on July 10, 2008, 11:33:34 AM
This only happens with "./configure make ..." not when compiling with C::B.
Well, *that* is interesting... But I have no clue why this happens. If you look into the code it's pretty much simple. Why GCC freaks out?! I don't know. Any what's most strange is why this does not happen when compiling with C::B itself because the GCC call should in fact be exactly the same when compiling this file. Well - where to go from here? I won't undo the changes in SVN. Whoever has issues compiling just use C::B for compiling or leave out this plugin. I believe there should be a mystic disable-plugin=headerfixup switch or something... I don't know I am not a make guy (anymore... this cost me too much hairs in the past ;-)). Probably we will remove this plugin from the make system.
It also seems to work with different compiler(s). Probably splitting up the file even more could be another option (but would be stupid to "fix" a compiler bug...?!). Finally the plans for this plugin are that actually these values are read from a file at run-time. But this is a long-term change and may make not even sense...
Quote from: MortenMacFly on July 10, 2008, 09:30:59 PM
I believe there should be a mystic disable-plugin=headerfixup switch or something... I don't know I am not a make guy (anymore... this cost me too much hairs in the past ;-)).
"--with-contrib-plugins=all,-headerfixup" is the way to go.
Quote from: Der Meister on July 10, 2008, 09:43:41 PM
Quote from: MortenMacFly on July 10, 2008, 09:30:59 PM
I believe there should be a mystic disable-plugin=headerfixup switch or something...
"--with-contrib-plugins=all,-headerfixup" is the way to go.
Hehe... see! Thanks! :-)
this is what I showed at : http://forums.next.codeblocks.org/index.php/topic,8756.0.html
Things is if i do a make clean first, it compiles.
I found the cause for the memory-eating:
it's the optimization-flag.
I'm not an automake-guru, so it takes me a while to fin out how to switch it off only for headerfixup-plugin.
But at least it's quite easy.
Here is a patch for "Makefile.am" of headerfixup-plugin.
After applying it you have to run "./bootstrap" to regenerate "Makefile.in" what is used by "./configure".
--- /usr/src/c/codeblocks/codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am 2008-07-09 07:20:42.000000000 +0200
+++ codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am 2008-07-10 23:05:33.000000000 +0200
@@ -2,6 +2,8 @@
-I$(top_srcdir)/src/include \
-I$(top_srcdir)/src/include/wxscintilla/include
+CXXFLAGS = @CXXFLAGS@ -O0
+
libdir = $(pkgdatadir)/plugins
lib_LTLIBRARIES = libheaderfixup.la
This will add a "-O0" (the second one is a zero) to "CXXFLAGS" and overrides the "-O2" set before. The other flags will not be touched.
Quote from: jens on July 10, 2008, 11:33:34 AM
I have 3.3 GB usable Ram and the 64-bit compilation uses about 3.4 GB for "defaults.cpp". Compiling for 32-bit uses much less memory.
I do not have such enormous memory consuming by compiling this file - on my 64-bit system (mandriva linux 2009.0 alpha with GCC 4.3.1 prerelease) it takes about 850 Mb of RAM and ~57 seconds (CPU Intel E6750). And after i've split the function SetDefaultsWxWidgets into two (SetDefaultsWxWidgets26 and SetDefaultsWxWidgets28 plus "wrapper" SetDefaultsWxWidgets that calls them) compiling this file took about the same time but almost twice less memory (~450 Mb).
Quote from: olelukoie on July 11, 2008, 12:19:21 PM
Quote from: jens on July 10, 2008, 11:33:34 AM
I have 3.3 GB usable Ram and the 64-bit compilation uses about 3.4 GB for "defaults.cpp". Compiling for 32-bit uses much less memory.
I do not have such enormous memory consuming by compiling this file - on my 64-bit system (mandriva linux 2009.0 alpha with GCC 4.3.1 prerelease) it takes about 850 Mb of RAM and ~57 seconds (CPU Intel E6750). And after i've split the function SetDefaultsWxWidgets into two (SetDefaultsWxWidgets26 and SetDefaultsWxWidgets28 plus "wrapper" SetDefaultsWxWidgets that calls them) compiling this file took about the same time but almost twice less memory (~450 Mb).
I didn't measure the time, but with no optimization the compilation of "defaults.cpp" needs less then 10 seconds.
With optimization it needs some minutes.
I can't test what happens if I split the SetDefaultWxWidgets-function, my laptop is at home and I am at work :cry: .
My only linux-system here is on my USB-stick and it's 32-bit only.
rather than apply a patch to override the optimization flag, you can just do:
# make CXXFLAGS=-O0
i'm working with a debug build of gcc (4.4) in order to check this issue,
and i hope soon to find the black hole and possibly submit a patch to the gcc trunk.
Quote from: mslomp on July 15, 2008, 01:37:40 AM
rather than apply a patch to override the optimization flag, you can just do:
# make CXXFLAGS=-O0
i'm working with a debug build of gcc (4.4) in order to check this issue,
and i hope soon to find the black hole and possibly submit a patch to the gcc trunk.
Thanks for your reply.
I know I can ovverride CXXFLAGS when I do the make, but that overrides it afaik for the whole build-process and therefore for the complete C::B suite.
The patch to Makefile.am of headefixup-plugin only stops optimization for this one plugin.
i don't know whether is it a bug or feature (and if it was already reported): cb doesn't remember which files were opened in previous session and after restart all files from current projects will be opened.
regards
Andrzej B.
Quote from: blamek on July 15, 2008, 03:24:15 PM
i don't know whether is it a bug or feature (and if it was already reported): cb doesn't remember which files were opened in previous session and after restart all files from current projects will be opened.
regards
Andrzej B.
Can you check your settings in "Settings -> Environment... -> General settings" ?
Which radiobutton is checked under "On applicaton startup" and "On project load" ?
That was exactly what i was looking for. I must have missed that option. Thanks :)
Hi,
i have a lot of toolbar clutter with the actual svn (5130). I have noticed it first in rev. 5126
If I move more than one toolbars into the same row only the first stays visibe after a view switch
or on restart of c::b. The menu says there are opened so I believe the first bar has moved all the other
bars out of the visible scope.
furthermore the settings for custom views (e.g debugging) aren't saved to disk; After a restart of c::b all settings are gone.
I've tried it with fresh settings by deleting default.conf but that make no difference.
Are there any other things I can do?
greetings
denk_mal
Besides the above, the debugger doesn't seem to keep track of the current build target and just dubugs the "Debug" target. That's fine if you're using only "Debug" and "Release", but not when you have more than one actual target, like server vs. client, or test apps for specific features within a larger project.
Quote from: jens on July 10, 2008, 11:24:21 PM
I found the cause for the memory-eating:
it's the optimization-flag.
I'm not an automake-guru, so it takes me a while to fin out how to switch it off only for headerfixup-plugin.
But at least it's quite easy.
Here is a patch for "Makefile.am" of headerfixup-plugin.
After applying it you have to run "./bootstrap" to regenerate "Makefile.in" what is used by "./configure".
--- /usr/src/c/codeblocks/codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am 2008-07-09 07:20:42.000000000 +0200
+++ codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am 2008-07-10 23:05:33.000000000 +0200
@@ -2,6 +2,8 @@
-I$(top_srcdir)/src/include \
-I$(top_srcdir)/src/include/wxscintilla/include
+CXXFLAGS = @CXXFLAGS@ -O0
+
libdir = $(pkgdatadir)/plugins
lib_LTLIBRARIES = libheaderfixup.la
This will add a "-O0" (the second one is a zero) to "CXXFLAGS" and overrides the "-O2" set before. The other flags will not be touched.
svn now contains the hack, but only for 64 bit, right ?
I think a colleague of mine is having the same build issue but on 32 bit (ubuntu). I can only check this in 3 weeks time. But maybe it is best not to 'if' in the configure.in and Makefile.am, that way we can keep the hack very small, and located to 1 file with a minimum of logic ? After all it is just for a plug-in.
Quote from: killerbot on July 20, 2008, 10:21:52 PM
I think a colleague of mine is having the same build issue but on 32 bit (ubuntu). I can only check this in 3 weeks time. But maybe it is best not to 'if' in the configure.in and Makefile.am, that way we can keep the hack very small, and located to 1 file with a minimum of logic ? After all it is just for a plug-in.
I have also applied the correction for ubuntu 32 bits for the two last nightly.
regards, pasgui
http://forums.next.codeblocks.org/index.php/topic,8821.msg64075.html#msg64075 (http://forums.next.codeblocks.org/index.php/topic,8821.msg64075.html#msg64075)
After a short test on my usb-stick (the only 32bit linux with an actual wxWidgets on it), I reverted conditional part of patch.
Takes about half the memory as on 64bit, and needs only 1.5 minutes.
But this is still too much for most build-systems and without optimizations it needs about 4 seconds to compile.