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://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc510-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc510-TDM.7z
The 11 April 2016 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2016/CB_20160411_rev10762_win32.7z
- Linux :
none
The current SDK version is : 1.30.0
Resolved Fixed:
- to much to mention, this is the new starting point after the 2016 release.
Regressions/Confirmed/Annoying/Common bugs:
NOTE that we switched toolchains we use to build, so mingw and wx dll need to be redownloaded !
Just a warning with TDM 5.1 version.
No problems with gcc but gfortran 5.1.0 has a big bug >:( : you cannot open a file to read data. It's not specific to TDM version: official MinGW version has also this bug, reported by myself and other users on different forums with a test case! Official versions 5.2 and 5.3 have been corrected 8). Nevertheless last TDM version is still only available in 5.1 version.
So I prefer to keep the previous one 4.9.2 or to use an official 5.3 version while waiting a new TDM version (if John publish it).
gd_on
killerbot: Is the rev number correct? We're at 10824 in trunk/master.
indeed, but then it would mean that our "revision detection" no longer works. This is the revision that CB shows when it launches and and the start here page.
On the start here page, it even claims 2016-02-02, but in the about it says (April 11 2016)
Should be fixed in trunk/master.
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
Forgive me.....
But the latest nightly is 10824 or 10762?
Quote from: MaxGaspa on April 12, 2016, 10:37:46 PM
Forgive me.....
But the latest nightly is 10824 or 10762?
It reports as SVN 10762; but, it is much newer than that; likely it is 10824,
Something I've noticed so far in this nightly that is different from the 11-15-15 nightly is that when I'm editing a watch's keyword field and hit enter, instead of activating the OK button, it passes focus to the Format radio button set, then the "Watch as array" checkbox, then the Start field, then the Count field, and then finally to the OK button after which one more Enter keypress will activate the button. This couldn't have been intentional behavior, could it?
@raynebc: What OS are you using? On linux enter does nothing in this dialog.
Windows 7 x64 pro. I hadn't seen this watch window behavior before, and have verified the expected behavior (Enter activates the OK button) in that previous nightly to make sure.
I'd like to report a bug in this nightly. Using the Hex editor you may observe a shift in the array of data when you are clicking a byte data. The first byte (first) colum can't be selected.
Windows XP SP3
Previous nightly wasn't affected.
I have problem with 10827.
I am using this command in post build options
avr-size $(TARGET_OUTPUT_FILE) > $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).size
Now seems that the execution does not like the redirection >
The failure is
avr-size _build/m2560/project.elf > _build/m2560/project.size
avr-size: '>': No such file
avr-size: '_build/m2560/project.size': No such file
The same command was working in the previous versions.
Actually all commands with > are not working.
OS:debian/amd64
Codeblocks from jenslody repository
SVN r10826 cause such issue.
We have some discussions in our devs' internal subforum, hope it will fixed soon.
Some additional info on Hex Editor bug. I'm observing the same bug using Windows 7 64 bit (Enterprise). Attached a snapshot of the "shift" of the byte once I clicked one of them.
Quote from: killerbot on April 12, 2016, 09:01:36 PM
Quote from: oBFusCATed on April 11, 2016, 11:11:07 PM
Should be fixed in trunk/master.
fix confirmed
Reverted in trunk, because there is no need to fix code, that has worked since 11/2014.
The error was the date in the comment in autorevision.h (if I understand the comment in the commit correctly), and this was an artefact of another commit that broke revisioning with autofoo/linux.
Removing the broken autorevision.h would have been the correct fix for the issue.
Quote from: jens on April 15, 2016, 11:12:44 PM
Removing the broken autorevision.h would have been the correct fix for the issue.
Obviously it is pretty easy to miss it, so the current check is not OK.
But I'm not touching this code any more... too fragile... I shouldn't have bothered in the beginning...
Quote from: oBFusCATed on April 16, 2016, 12:44:04 AM
Quote from: jens on April 15, 2016, 11:12:44 PM
Removing the broken autorevision.h would have been the correct fix for the issue.
Obviously it is pretty easy to miss it, so the current check is not OK.
But I'm not touching this code any more... too fragile... I shouldn't have bothered in the beginning...
It's only not okay, because of the added (in my opinion useless) date to the comment in autorevision.h, that broke revision numbering before.
It has worked without issues (as far as I know) since 2014 for many nightlies on linux and windows, until the date was added to the comment.
And then the auto-fu broke for no apparent reason and thus my statement that the whole autoversion code is too fragile is definitely correct.
Quote from: oBFusCATed on April 16, 2016, 01:18:22 AM
And then the auto-fu broke for no apparent reason and thus my statement that the whole autoversion code is too fragile is definitely correct.
Autofoo itself works fine (configure, build and run), but the autorevisioning stuff does not and the version numnber is "0".
But yes, your are definitely correct, that the autorevision-stuff is quite fragile.
I have general stability problems with the last versions, I dont know if it is related with 10762 exactly.
Sometimes the interface getting frozen or I have failures with exit with no reason, while working on editor.....
I am using CB for many years (from 2006, if I remember) for all my projects and now the instability is worse than ever, every 10-15 minutes the CB fails, it is impossible to work....
I am using Debian/amd64.
Disable the class browser in the settings of the Code completion plugin and the crashes will stop.
Thank you! It is much better now....
I can live without Class browser.
Quote from: oBFusCATed on April 17, 2016, 09:55:17 PM
Disable the class browser in the settings of the Code completion plugin and the crashes will stop.
May, the building of the tree should go to OnIdle handler. The whole task will be divided to several pieces.
Don't know yet. I'm doing others staff at the moment, but eventually I'll get to fixing this issue. :)
Another bug in this nigthly after the Hex editor one. In
Settings->Compiler
make a right click and then "new flag" -> crash!!!
Observed using Windows XP 32 bit SP3, tomorrow I'll be trying to replicate the bug using Windows 7 64 bit.
RPT attached
I reproduced that "new flag" crash on the first try. Windows 7 Pro 64 bit.
Works fine on linux. :(
Quote from: MaxGaspa on April 19, 2016, 09:25:08 PM
Another bug in this nigthly after the Hex editor one. In
Settings->Compiler
make a right click and then "new flag" -> crash!!!
Quote from: raynebc on April 19, 2016, 10:45:10 PM
I reproduced that "new flag" crash on the first try. Windows 7 Pro 64 bit.
Confirmed (also on a Windows 7 pro 64bit machine).
Regards
Xav'
It could have something to do with the version of TDM-GCC (5.1.0) on windows, http://forums.next.codeblocks.org/index.php/topic,20909.0.html.
Is there anybody confirming the Hex Editor bug?
Yes, I can confirm the bug. It happens on linux, too.
Can you test if it works correctly in 16.01?
MaxGaspa: Does the bug disappears if you resize the codeblocks/editor?
Quote from: oBFusCATed on April 22, 2016, 06:39:24 PM
MaxGaspa: Does the bug disappears if you resize the codeblocks/editor?
Yes. it disappears resizing the codeblocks window, and yes it was present in the 16.01 as well.
The HexEditor should be fixed in trunk. Please report back if this is not the case.
Hi, this is me trying to install a nightly the first time. I'm following this tutorial on he wiki: http://wiki.codeblocks.org/index.php/Installing_Code::Blocks_nightly_build_on_Ubuntu
However, at the command "sudo dpkg -i <Name_Of_Daily_Build.deb>", what is supposed to be the name of the daily build? Extremely basic I know, but I'd be extremely grateful for anyone's help.
Quote from: oBFusCATed on April 23, 2016, 06:01:03 PM
The HexEditor should be fixed in trunk. Please report back if this is not the case.
Current trunk doesn't build:
C:\prj\CodeBlocks\src\plugins\contrib\HexEditor\HexEditPanel.cpp: In member function 'void HexEditPanel::OnContentPaint(wxPaintEvent&)':
C:\prj\CodeBlocks\src\plugins\contrib\HexEditor\HexEditPanel.cpp:596:26: error: no matching function for call to 'HexEditPanel::RecalculateCoefs(wxAutoBufferedPaintDC&)'
RecalculateCoefs( dc );
MinGW gcc: 4.8.1
wxWidgets: 2.8.12
Strange. On linux it builds just fine (wx28 and wx30). But I've pushed a fix for this.
Can you tell me if it builds fine on windows now?
noPCH Patch needed when I do a very cut-down build of Code::Blocks (I am trying to remove all the GUI code a little bit at a time.)
Tim S.
Index: src/sdk/cbproject.cpp
===================================================================
--- src/sdk/cbproject.cpp (revision 10850)
+++ src/sdk/cbproject.cpp (working copy)
@@ -9,9 +9,8 @@
#include "sdk_precomp.h"
-#ifndef wxUSE_CHOICEDLG
- #define wxUSE_CHOICEDLG 1
-#endif
+// needed in wxWidgets 2.8.12 to define wxUSE_CHOICEDLG when NOPCH
+#include <wx/defs.h>
#include <wx/choicdlg.h>
#include <wx/filedlg.h>
Index: src/sdk/manager.cpp
===================================================================
--- src/sdk/manager.cpp (revision 10850)
+++ src/sdk/manager.cpp (working copy)
@@ -12,6 +12,7 @@
#ifndef CB_PRECOMP
#include <wx/xrc/xmlres.h>
#include <wx/fs_zip.h>
+ #include <wx/frame.h>
#include <wx/menu.h>
#include "manager.h" // class's header file
Index: src/src/environmentsettingsdlg.cpp
===================================================================
--- src/src/environmentsettingsdlg.cpp (revision 10850)
+++ src/src/environmentsettingsdlg.cpp (working copy)
@@ -15,6 +15,7 @@
#include <wx/radiobut.h>
#include <wx/xrc/xmlres.h>
#include <wx/intl.h>
+ #include <wx/listbox.h>
#include <wx/listctrl.h>
#include <wx/combobox.h>
#include <wx/choice.h>
Quote from: stahta01 on May 06, 2016, 06:17:56 PM
(I am trying to remove all the GUI code a little bit at a time.)
What do you mean by this?
C::B builds fine on linux in no-pch mode with autotools and wx2.8.12.
Quote from: oBFusCATed on May 06, 2016, 07:32:38 PM
Quote from: stahta01 on May 06, 2016, 06:17:56 PM
(I am trying to remove all the GUI code a little bit at a time.)
What do you mean by this?
C::B builds fine on linux in no-pch mode with autotools and wx2.8.12.
I am trying to REMOVE all the GUI code; as in set wxUSE_GUI equal to zero.
Tim S.
From where? This is pretty hard task generally.
Quote from: oBFusCATed on May 06, 2016, 11:49:27 PM
From where? This is pretty hard task generally.
Here's where I did most of the work; I stopped about a month ago; because my Git Repo got messed up.
[I noticed the Git Repo issue when an CB Dev edited a SVN commit message; fixing that I discovered I had messed up a few months back.)
https://github.com/stahta01/codeblocks_console/commits/wxUSE_guard (https://github.com/stahta01/codeblocks_console/commits/wxUSE_guard)
I tried once prior to removing the GUI code all at once and failed; this time I decided to remove just a little bit at a time.
My noPCH fixes was discovered when I disable a header that included the header I added in the patch.
I just now got my Git Repo so once more "git svn info" works.
I do NOT think the CB Team would want my changes that added wxUSE; but, see no downside to doing the noPCH fixes.
I figure once I get CB to work without the GUI part a few people will want the patches that does that.
I am primarily doing this as a learning experience on using Git, C++, CB, and wxWidgets.
I have NOT built this repo for a while; but, it was working a few months back.
https://github.com/stahta01/codeblocks_console/tree/build/reducedGUI (https://github.com/stahta01/codeblocks_console/tree/build/reducedGUI)
Tim S.
These changes are useless (sorry if I'm rude, this is not the intention).
I don't see how C::B will be usable without its toolbars, the choice dialog, the file dialog, the clipboard and the wxpropgrid.
The way to fix this is to just abort the compilation in prep.h or globals.h if one of these wx features is not available.
You're wasting time guarding every use. Probably you'll make C::B compile, but it will broken in many surprising for the users ways.
PLEASE READ MY POSTS!!!
Removing the GUI requires removing the GUI!!!
Tim S.
Ok, keep removing the gui the wrong way. :)
But if you really want to remove the gui, please start from the cbproject class.
This is the most problematic place where the gui is preventing us from compiling a cb_build executable.
Quote from: oBFusCATed on May 05, 2016, 01:02:00 AM
Strange. On linux it builds just fine (wx28 and wx30). But I've pushed a fix for this.
Can you tell me if it builds fine on windows now?
It builds fine again, thanks.
Is it normal that sometimes my SVN is 0? I'm pretty sure other times it's showed the proper version.
I'm using "svn build rev 0 Apr 13 2016, 04:53:52 - wx3.0.2 (Linux, unicode) - 64 bit" in debian jessie, from Jens' repo.
Also I get lots of crashes and weird behaviour from the debugger and watches :-/ I've just disabled the symbols browser following previous advice, I hope it helps.
Something new that has happened to me today just as I started `codeblocks -v`:
Quote10:39:22: Cannot load resources from 'memory:ToolsPlus.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:DoxyBlocks.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:ThreadSearch.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:Cccc.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:Cscope.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:EditorConfig.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:wxSmithAui.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:headerfixup.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:CppCheck.zip#zip:*.xrc'.
10:39:22: Cannot load resources from 'memory:Valgrind.zip#zip:*.xrc'.
Are the debugger crashes reliably reproducible?
The warnings could be safely ignored.
I get the errors constantly with some watches but I couldn't tell you when they happen.
When my variable decl was unitialised it just said "Not available in current context", after initialising:
QuoteParsing GDB output failed for '*decl'!
but other variables work alright...
vayolet: Enable full debugger logging (settings -> debugger -> common) and when the problem happens post the full log.