By the way, I still experience the time lags when I open the codeblocks.cbp.(even I disable the real-time options in CC), I suspect there are still something wrong. Sad
FINALLY: In addition I would hereby open a LOGO CONTEST!
QuoteBy the way, I still experience the time lags when I open the codeblocks.cbp.(even I disable the real-time options in CC), I suspect there are still something wrong. Sad
I can confirm this: it's the problem I described here (http://forums.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521 (http://forums.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521)).
I remind you that Nightly Build 5911 doesn't show this behaviour.
I'd still push for a new release. We can list this as a known bug just like CC can't do this / that... We can fix this bug and go for a minor release.Agreed. In fact nobody can reproduce. I know what might cause this issue, but in fact it was a fix for another bug which is more likely to happen. And I have no clue why the current implementation shows such behaviour except that it's platform depended and/or might be caused by e.g. a silly AntiVirus software not allowing to create temporary files. I really doubt this is a bug in Code::Blocks.
- post this logo in this forum: http://forums.codeblocks.org/index.php/board,7.0.html
- setup a logo (probably based on the current one)
- it must have our logo (as seen on http://www.codeblocks.org)
For example: Is this the kind of thing you are looking for? (http://blog.robotarcade.com/wp-content/uploads/2010/02/cblogo_custom1.jpg)Ok - the definition shall be:
A definite choice of standard binary compatibility would encourage a lot more people to make their own plugins and share them as binaries.As with all other releases we will provide a SDK here, too. Plugin-Devs linking against that SDK will automatically be "compatible" with the release. However, if (for good reasons) we change the ABI for the nightlies you cannot use plugins compiled against the nightlies version in the release version, obviously. To overcome, ask the devs to compile/link against the (fixed) release SDK.
A definite choice of standard binary compatibility would encourage a lot more people to make their own plugins and share them as binaries.As with all other releases we will provide a SDK here, too. Plugin-Devs linking against that SDK will automatically be "compatible" with the release. However, if (for good reasons) we change the ABI for the nightlies you cannot use plugins compiled against the nightlies version in the release version, obviously. To overcome, ask the devs to compile/link against the (fixed) release SDK.
A short note concerning the logo contest:
Please post in a new thread in this forum, I'll set them sticky until we start a poll to find out the "winner". Notice that actually ANY contribution is welcome. We will keep all logos and designers in a record.
- it must have our logo (as seen on http://www.codeblocks.org)i am terribly sorry for you to hear that, but your logo sucks .\
Hey Tim,
could you explain why the dll that now is build with the nightlies is not ok ?
The compilers you used in the past was broken or used Dwarf2; I have not tried lately to see if the issue still exists.Usually every MinGW/GCC compiler released ships with its own version of exchndl.dll. So all you need to do is to use the same compiler for compiling wxWidgets and Code::Blocks and then ship the right version of the exchndl.dll. I am aware that we have an old version in the repo which is compatible for MinGW 3.4.5 only. For the release we will should use the right one. But I don't think we really need to compile this ourselves...?! :shock:
Exceptions should not happen very often anyway (hopefully), so I'm almost inclined to say "so what". I'm not even sure we throw anywhere at all, or whether that's heap-allocated.Executing scripts can throw...
The compilers you used in the past was broken or used Dwarf2; I have not tried lately to see if the issue still exists.Usually every MinGW/GCC compiler released ships with its own version of exchndl.dll. So all you need to do is to use the same compiler for compiling wxWidgets and Code::Blocks and then ship the right version of the exchndl.dll. I am aware that we have an old version in the repo which is compatible for MinGW 3.4.5 only. For the release we will should use the right one. But I don't think we really need to compile this ourselves...?! :shock:
When you open two or more projects and there are some variable or function with the same name across different projects, the "Find declaration of " feature will return the wrong location or "not found" message sometime, even after you close the all the other projects. It will become normal when you restart CB with only one project.I guess this is an issue in CodeCompletion, but I have never meet this kind of problem.( because I always use only open one project at once :D).
I have wxWidgets 2.9.0
$> ./configure --with-wxdir=/home/Smitty/dev/sandbox/wxWidgets-2.9.0
Seems to work correctly.
Then
$> make
This is Fedora 12 with all the latest updates.
make[3]: Leaving directory `/home/obfuscated/projects/codeblocks/trunk/src/sdk/resources'
make[3]: Entering directory `/home/obfuscated/projects/codeblocks/trunk/src/sdk'
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -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_FILES -D__WXGTK__ -pthread -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -fPIC -DPIC -fexceptions -MT projectfileoptionsdlg.lo -MD -MP -MF ".deps/projectfileoptionsdlg.Tpo" -c -o projectfileoptionsdlg.lo projectfileoptionsdlg.cpp; \
then mv -f ".deps/projectfileoptionsdlg.Tpo" ".deps/projectfileoptionsdlg.Plo"; else rm -f ".deps/projectfileoptionsdlg.Tpo"; exit 1; fi
libtool: compile: g++ -DHAVE_CONFIG_H -I. -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_FILES -D__WXGTK__ -pthread -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -fPIC -DPIC -fexceptions -MT projectfileoptionsdlg.lo -MD -MP -MF .deps/projectfileoptionsdlg.Tpo -c projectfileoptionsdlg.cpp -fPIC -DPIC -o .libs/projectfileoptionsdlg.o
projectfileoptionsdlg.cpp: In member function ‘void ProjectFileOptionsDlg::FillGeneralProperties()’:
projectfileoptionsdlg.cpp:350: error: invalid use of incomplete type ‘struct wxSizer’
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of ‘struct wxSizer’
projectfileoptionsdlg.cpp:357: error: invalid use of incomplete type ‘struct wxSizer’
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of ‘struct wxSizer’
The C::B trunk doesn't compile without pch...Exactly the same here with the gentoo using live ebuild. It only compiles if pch enabled.
distro: gentoo ~amd64
Steps to reproduce
1. svn update to r6205
2. ./bootstrap
3. ./configure --disable-pch
4. make
projectfileoptionsdlg.cpp: In member function 'void ProjectFileOptionsDlg::FillGeneralProperties()':
projectfileoptionsdlg.cpp:350: error: invalid use of incomplete type 'struct wxSizer'
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of 'struct wxSizer'
projectfileoptionsdlg.cpp:357: error: invalid use of incomplete type 'struct wxSizer'
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of 'struct wxSizer'
make[3]: *** [projectfileoptionsdlg.lo] Error 1
make[3]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999/work/codeblocks-9999/src/sdk'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999/work/codeblocks-9999/src/sdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999/work/codeblocks-9999/src'
make: *** [all-recursive] Error 1
* ERROR: dev-util/codeblocks-9999 failed:
could you update your svn (rev 6216) and try againkillerbot, many thanks for the fix. C::B compiles fine with svn (rev 6216).
Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.See my signature.
Thanks in advance. :)
Dear community,
on behalf of the whole code::Blocks team I would like to inform you hereby that we are in the preparation phase for a new release of Code::Blocks. Most important: WE NEED YOUR HELP!
The road map is as follows:
- the latest nightly (see http://forums.codeblocks.org/index.php/topic,12098.0.html) shall be the base revision
- from that nightly on we are on FEATURE FREEZE that means: don't expect / ask for new features, we won't commit such
- we expect bug reports, posted in an own thread in this forum: http://forums.codeblocks.org/index.php/board,7.0.html
- we will address critical patches with that release in SVN trunk
- if needed another nightly will be announced (you can call it release candidate if you like)
- a release branch will be created
- release will be done.
Here is what you can do:
- use the nightly proposed (or compile from trunk), report bugs!!!
- check the bug tracker of C::B for bugs still active that may be show stoppers
- if you are a developer: try to find patches for the bugs reported
Here is what you shouldn't do:
- ask for new features
- ask for a more detailed schedule
FINALLY: In addition I would hereby open a LOGO / SPLASH SCREEN CONTEST!
The rules are simple:
- setup a logo (probably based on the current one)
- post this logo in this forum: http://forums.codeblocks.org/index.php/board,7.0.html
- it must have our logo (as seen on http://www.codeblocks.org)
- the word "Code::Blocks" shall be part of the logo, including the "::"
- the word "Code::Blocks" should not be splitted
- there must be space for the release number (most likely 10/04)
- there must be space for the revision number
- it must "work" nicely under all platforms (important if you are using alpha / transparency)
- don't overdo it, we still strike for simplicity
- finally: discuss the logos, we will setup an open poll after a while to decide which one we will pick.
GO AHEAD! HELP US TODAY! :P
Edit: Added additional specification for the logo / splash screen contest
Indeed, but the changelog seems to have been refreshed until revision 6203, but not after this one. ^^Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.See my signature.
Thanks in advance. :)
Indeed, but the changelog seems to have been refreshed until revision 6203, but not after this one. ^^Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.See my signature.
Thanks in advance. :)
very curious if bugs such as resizing "build option" is fixed or not yet in this version.
Why still not released?Check the log and don't spam the forums with such nonsense posts. Thank you.
Is the release dead?
I ask the question because someone said the release version in the logo is probably 10.04,but it's almost the end of May,OK?
(http://forums.codeblocks.org/index.php?action=dlattach;topic=12441.0;attach=4597;image)The bottom half of this new logo image is just "blank", I suggest adding some other information. :D
In the face of those blocks can not have some decoration? For example: print some light gray c + + code.
Is the new release already prepared?
codeblocks 10.05
download at here
http://download.berlios.de/codeblocks/
:D