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_wx2812_gcc452-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z
The 07 Jamuary 2012 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20120107_rev7678_win32.7z
- Linux :
none
Resolved Fixed:
- fixed a few tree selection issues introduced with switch to multiple selections
- fix some more issues related to multiple selection tree-ctrl; fix linux (?) refreshh issue with project-tree
- fixes for automake-system, to be able to build C::B from a build-directory, which is not the top_srcdir (thanks milamber for the hint)
- revert commit 7307 and 7460, to increase loadspeed for large projects and fix the calculating of the common toplevel path, see: http://forums.next.codeblocks.org/index.php/topic,15430.msg103943.html#msg103943 for details
- compiler: allow multiple selection of directories for all operations (copy / delete / move...)
- Added min size setting for the parameters text control in the 'Set programs' arguments' dialog
- remove remaining gtk2-dependencies for codesnippets-plugin
- switch ProjectFile-List to wxHashSet, decreases time needed to load large projects a lot
- rename PrjTree to cbTreeCtrl to comply with other specialisations
- added missing NULL pointer check in projectoptionsdlg
- Force target re-link if any static library it depends on gets updated (i.e. no need to manually add an external dependency for static libraries anymore)
- when checking for changed static library dependencies, look in compiler's linker search paths too
- when checking for changed static library dependencies, include libraries referenced directly (w/out the use of linker's search path)
- changed the way a tab-tooltip is set, so tooltips for newly created files or files "saved as" are shown correctly
- pumped astyle to v2.0.3
- added GNU Fortran and G95 compiler support to Code::Blocks (based on C::B Fortran project of darmar (TODO: Adopt Unix build system, will follow...)
- added WORKSPACE_LOADING_COMPLETE SDK event, based on a patch by daniloz
- change the way infopane tabs get reordered if necessary; speed up perspective changes a lot (especially on linux), see: http://forums.next.codeblocks.org/index.php/topic,15544.msg104557.html#msg104557 for details
- applied patch by xunxun to include gfortran compiler into common functions for scripting (setting up common compiler switches)
- fix broken "Create project from target..."; was broken since commit 7588
- add plugins node (plugins enabled/disabled) to cb_chare_config, order nodes alphabetically
- Patch 3111 JumpTracker no wrap mod
- added MCS51 project wizard and template (applying patch #3226)
- Reimplement GetFile(index) for projects and implement it for targets, to fix broken scripts
- script_plugins: Added Find Broken Files plugin made by Morten;
- broken_files script-plugin: fix to correctly remove all broken files at once
- backport of debugger branch commit to fix an issue with BP handling with CDB
- fix bug described here: http://forums.next.codeblocks.org/index.php/topic,15439.msg105875.html#msg105875 keyboard events are now send to the project-tree (if not a del-key is pressed), opening files with enter works again
- removed CC cache to file (not used since ages, the ode is still in SVN for the record)
- CC: implemented option to setup files to parse by extension (see http://forums.next.codeblocks.org/index.php/topic,15760.msg105934.html)
- CC: better implementation for selecting items from builder thread via event (based on a patch of darmar)
- CC: fixed parser dummy implementation not compiling anymore after latest changes
- updated project file for compilation of C::B using wxWidgets 2.9.x under Windows in separate older (parallel to wx 2.8.x stream)
- updates to fix compilation errors under wx 2.9.x (2.9.3 explicitly) under Windows
- updated SVN ignore patterns - merged (back-ported) wxPropGrid changes form debugger branch into trunk foe wx 2.9.x compatibility
Regressions/Confirmed/Annoying/Common bugs:
[/list]
Thanks a lot for the update, I love the subscribe button..
Greetings
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
Revision is svn7671, the later revisions are unrelated to trunk.
Works like a charm for me... 8)
Hello everyone.
I just wanted to ask, is it easy to have on splash screen the loading modules, so we can see which one is loaded (like Netbeans is doing)?
I am asking this because under Debian wheezy which I am right now, it takes a few seconds to a minute to load the entire IDE and makes me think sometimes that it might have crashed and didn't notice it.
Is it possible?
Cheers
Quote from: stefanos_ on January 14, 2012, 07:08:41 PM
Is it possible?
Possible yes, but it needs to be implemented.
I think I have found a bug with breakpoints; it does not accept mouse clicks to enable / disable breakpoints. Only F5 enables / disables them.
OS: Windows XP SP3 (under VirtualBox)
TDM's GCC: 4.6.1
CodeBlocks Revision: SVN-7671
If this is in the normal nightly, then try a debugger's branch nightly and then report the problem in the appropriate topic.
No fixes are done in trunk for the debugger's code, because the branch build is vastly different and improved.
I just installed the debugger's branch and things are even worse now.
First of all, breakpoints still do not work with mouse and now it even does not exit from debug mode. I was pressing F7 to follow the next line and it was not doing anything at all. I have tried F8 to continue; still nothing. I had to force Code::Blocks to quit to stop debug :(
P.S.: From what i see from Disassembly code, if I stay in line where is "leave" and press F8, it will exit the debug mode successfully. If I press F7 to follow "Next Line" it will hang over there forever. I hope that it helps a bit...
Quote from: stefanos_ on January 15, 2012, 05:01:53 PM
P.S.: From what i see from Disassembly code, if I stay in line where is "leave" and press F8, it will exit the debug mode successfully. If I press F7 to follow "Next Line" it will hang over there forever. I hope that it helps a bit...
This might be related:
http://forums.next.codeblocks.org/index.php/topic,10908.msg106291.html#msg106291
But
please never forget to post a debug log when reporting such!
MortenCanFly: Apologies for not replying earlier; I was rather busy last night.
Something I should have re-stated is that I was using Windows XP under VirtualBox. Right now I am at work and breakpoints work just fine in svn7671. Another thing that should be noticed is that I said I use TDM's GCC 4.6.1 whereas both nightlies are built with TDM's GCC 4.5.2...I am pretty sure that this is the problem.
I am having a problem loading old projects that contain long relative paths:
<Unit filename="..\..\..\Firmware\GNU\Device\Startup\Startup.S" />
Previously with SVN 7452 these loaded correctly, but with more recent nightlys loading of these projects hangs, with CodeBlocks stoping responding and so has to be killed manually. Deleting the above line from the project allows it to be loaded and the file can then be added to the project, compiled and the project saved again. However upon attempting to reload the project CodeBlocks again hangs.
This is on Windows-XP with the Yagarto toolchain.
Any help would be appreciated!
Otherwise, keep up the great work.
Andy
Quote from: AndyJ on January 16, 2012, 12:11:16 PM
I am having a problem loading old projects that contain long relative paths:
<Unit filename="..\..\..\Firmware\GNU\Device\Startup\Startup.S" />
Are you really sure its due to the path (the one you shows is not really long) or maybe because of the file extension? Do other
*.S files in the project work? What is the full path? And have you added
*.S files to CC and/or file (MIME) types?
I am having problems with Code Completion.
Sometimes it shows the code, sometimes it does not.
For eg, if i include a header file it will show all the structures when i type them, then suddenly it will stop working!!
It also happens many time when i switch to default perspective!
Question: I have found something interesting and I would like someone to explain to me this certain behavior.
I am under Windows XP, svn-7713, TDM's GCC 4.6.1 and as soon as I start Code::Blocks, I can see from Task Manager that it takes approximately 50,950K from memory, but as soon as I press the Minimize button it drops immediately to 5,250K ~= 6,200K.
Can someone explain this to me? Enlighten me please...
Cheers
Windows "feature", when something is minimized windows moves it out of memory.
All apps should behave the same.
Quote from: oBFusCATed on January 25, 2012, 03:48:25 PM
Windows "feature", when something is minimized windows moves it out of memory.
All apps should behave the same.
sorry if this seems obvious to everyone but could you explain that a little more for me please; i'm trying to wrap my head around the primary window operations in various o/s's atm :)
Also a quick offtopic: I just noticed that the nightly I installed last night ( my first install of C::B on this pc ) seems to be self-contained in the extracted folder; does this mean that C::B is self-contained and therefore can be used without installing it anywhere like on a usb stick?
Here is some discussion about it: http://channel9.msdn.com/Forums/TechOff/454007-Minimize-Window-Drop-its-Mem-Usage
C::B is not self contained, because by default it saves the settings in your home folder (%APP_DATA%/Codeblocks).
For self contained c::b you need c::b portable. Search the forum for more details.
Sweet, thanks!
hmm... here's a question.. if we extract the nightly build of C::B to a usb stick and then run it at least once on all the computers we are using ( linux box 1,2,3 xp box, win 7 box ect ) then would that also work as well? -or- would the portable verison be best?
I ask because i'd like to not loose any features in favor of portability if that makes sence :)
You will be able to run Code::Blocks anywhere, however, without setting it up with a portable launcher, all settings/customizations will be left behind on whatever machine it is run on.
See FAQ - How do I make Code::Blocks portable? (http://wiki.codeblocks.org/index.php?title=FAQ-Settings#Q:_How_do_I_make_Code::Blocks_portable.3F)
From my experience, running it in a portable mode does not lose any functionality. (I use a slightly modified launcher based on PortableApps.com (http://portableapps.com/node/18671).)
Quote from: tgucm on January 25, 2012, 09:38:08 PM
( linux box 1,2,3 xp box, win 7 box ect )
Note that you will need a different set of executables for Linux and Windows (although portable launchers could share the same set of settings).
Bug found: Open a project, select a file either with mouse or keyboard keys, press enter. Instead of opening the file it minimizes everything to workspace.
Code::Blocks version: svn-7713
Compiler: TDM's GCC 4.6.1
OS: Windows XP Professional SP3 (32-bit)
Quote from: stefanos_ on January 26, 2012, 09:18:22 AM
Bug found: Open a project, select a file either with mouse or keyboard keys, press enter. Instead of opening the file it minimizes everything to workspace.
Works fine here..?!
QuoteBug found: Open a project, select a file either with mouse or keyboard keys, press enter. Instead of opening the file it minimizes everything to workspace.
Are you speaking about the project tree? If yes I must say that I have the same bug on Windows Xp and Windows 7 since rev 7550(I haven't tested the latest nightly yet)
Quote from: renega_666 on January 26, 2012, 01:13:08 PM
(I haven't tested the latest nightly yet)
That is your fault. If you do so, it will work. It was fixed recently.
Please: Before reporting bugs, always try the latest nightly.
Ok I've just tested with the latest nightly(7678) (debugger branch) and the bug is still here...
Btw I now have troubles with the debugger watches but I will report it in the proper forum after some more tests.
QuoteBug found: Open a project, select a file either with mouse or keyboard keys, press enter. Instead of opening the file it minimizes everything to workspace.
I also have this problem on my setup with r7711.
Press again 'ENTER' gives the complete tree.
Just finished compiling the latest revision (7715); the issue remains the same. I go to Management > Project Name > Sources > main.cpp, pressing enter and toggle tree to Workspace. Pressing enter again and unfolds the project up to the main.cpp
Quote from: stefanos_ on January 26, 2012, 03:37:16 PM
Just finished compiling the latest revision (7715)
Are you sure this revision:
http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=7655&peg=7715
...is incorporated? Because this is the actual fix. It works on windows. Maybe this is a platform related issue?
QuoteJust finished compiling the latest revision (7715); the issue remains the same. I go to Management > Project Name > Sources > main.cpp, pressing enter and toggle tree to Workspace. Pressing enter again and unfolds the project up to the main.cpp
and on my pc too ...(r7715)
Quote from: LETARTARE on January 26, 2012, 04:12:10 PM
and on my pc too ...(r7715)
Right, I checked again and (apologies) I had it modified in my version, already addressing this behaviour. I've committed my changes now to SVN, try again with r7717. I was under the impression, Jens' commit addressed this issue, too.
Quote from: MortenMacFly on January 26, 2012, 03:45:27 PM
Quote from: stefanos_ on January 26, 2012, 03:37:16 PM
Just finished compiling the latest revision (7715)
Are you sure this revision:
http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=7655&peg=7715
...is incorporated? Because this is the actual fix. It works on windows. Maybe this is a platform related issue?
It works here on linux without problems.
and for me too (r7717)
thanks
Quote from: MortenMacFly on January 26, 2012, 04:34:59 PM
Quote from: LETARTARE on January 26, 2012, 04:12:10 PM
and on my pc too ...(r7715)
Right, I checked again and (apologies) I had it modified in my version, already addressing this behaviour. I've committed my changes now to SVN, try again with r7717. I was under the impression, Jens' commit addressed this issue, too.
Our posts crossed.
As I wrote it has worked here on debian with the old code (without commit 7717), opening files with and stepping through the tree with the arrow-keys (up, down, left and right)
I compile the newest trunk and test whether it's still working.
Any updates on my problems with the code completion problem?
i posted it a few days before?
Quote from: jens on January 26, 2012, 05:27:03 PM
I compile the newest trunk and test whether it's still working.
That would be wise, because after committing I realised why I didn't do it before: Because of the untested WXGTK part. Feel free to remove that if needed, the Windows part should be correct. I am working with this very long now. Keep in mind it's really not related to your commit, because it emulates an "item activated" event on ENTER. It may be (however), that in wx2.9.x this is supported natively.
Quote from: MortenMacFly on January 26, 2012, 08:18:21 PM
Quote from: jens on January 26, 2012, 05:27:03 PM
I compile the newest trunk and test whether it's still working.
That would be wise, because after committing I realised why I didn't do it before: Because of the untested WXGTK part. Feel free to remove that if needed, the Windows part should be correct. I am working with this very long now. Keep in mind it's really not related to your commit, because it emulates an "item activated" event on ENTER. It may be (however), that in wx2.9.x this is supported natively.
It still works, and a quick check don't show any differences.
Quote from: neo1691 on January 24, 2012, 08:01:47 PM
I am having problems with Code Completion.
Sometimes it shows the code, sometimes it does not.
For eg, if i include a header file it will show all the structures when i type them, then suddenly it will stop working!!
It also happens many time when i switch to default perspective!
We need code snippets and exact steps to produce such bugs (Also OS? Compiler? CB version? ...... Please ask a Good Question). Otherwise, I can do nothing. :)
I also have problems with code completion on MS Windows Vista 32-bit, using Mingw GCC 4.6.1 (tdm-gcc) with the 7th January 2012 C::B SVN nightly (from this thread), under various circumstances - mostly either with custom GCC features or with complex C++ template classes. Here's one test case (with custom GCC extensions) in which it won't work:
typedef struct __attribute__((packed)) _PSTRUCT
{
char a;
char b;
int c;
char d;
} PSTRUCT;
int main()
{
PSTRUCT p;
p.
After typing the last dot after p, code completion box should open up, but it doesn't.
It looks like this particular case is a problem with parsing the GCC __attribute__ tag. Excluding it from the typedef makes the code completion work.
I also had an issue with code completion not popping up for certain complex (I think template-based) class declarations in C++, but sadly I can't reproduce them at the moment, I'll post a test case if and when I'm able to reproduce it again, it happened only once to me and I didn't bother too much cause I considered it to be minor enough.
- Agetian
Quote from: Agetian on January 27, 2012, 08:53:51 AM
Here's one test case (with custom GCC extensions) in which it won't work:
typedef struct __attribute__((packed)) _PSTRUCT
Should be fixed in SVN head. Thanks for providing a test case.
I hate to say it, but...
I pressed ENTER in file browser tree on a file, "How do we open" dialog appeared, I've chosen "open inside cb editor" and... nothing happens. Moreover, pressing ENTER stops working at this moment. Forever. Double-clicking works.
Plus I have to favours to ask...
1. the "current file close" button at the top-right corner like in normal MDI apps - PELASE! :_( I'm so tired that I can't aim at those tiny tabs every time! :'(
2. Is it possible to make the entire output window (the bottom panel) hide when ESC key is pressed in the editor (when no text is selected, no completion or other stuff is active)? (F2 is okay, but still...)
Quote from: xawari on January 27, 2012, 03:14:16 PM
I hate to say it, but...
I pressed ENTER in file browser tree on a file, "How do we open" dialog appeared, I've chosen "open inside cb editor" and... nothing happens. Moreover, pressing ENTER stops working at this moment. Forever. Double-clicking works.
Which version of C::B (this nightly ?), which OS ?
Works fine here on linux.
Quote from: xawari on January 27, 2012, 03:14:16 PM
Plus I have to favours to ask...
1. the "current file close" button at the top-right corner like in normal MDI apps - PELASE! :_( I'm so tired that I can't aim at those tiny tabs every time! :'(
What do you want to say ?
Quote from: xawari on January 27, 2012, 03:14:16 PM
2. Is it possible to make the entire output window (the bottom panel) hide when ESC key is pressed in the editor (when no text is selected, no completion or other stuff is active)? (F2 is okay, but still...)
Does not make sense for me and I think this usage of the ESC key would not be obvious to anyone (except you).
Cannot compile the latest svn (7725) under GNU / Linux Debian wheezy.
In file included from parser/cclogger.cpp:10:0:
parser/cclogger.h:68:23: error: 'auto_ptr' is not a template
parser/cclogger.h:68:23: error: 'auto_ptr' in namespace 'std' does not name a type
parser/cclogger.h:68:5: error: friend declaration does not name a class or function
parser/cclogger.h:69:12: error: 'auto_ptr' in namespace 'std' does not name a type
parser/cclogger.h: In static member function 'static CCLogger* CCLogger::Get()':
parser/cclogger.h:29:14: error: 's_Inst' was not declared in this scope
parser/cclogger.h:31:16: error: 's_Inst' was not declared in this scope
parser/cclogger.cpp: At global scope:
parser/cclogger.cpp:12:1: error: 'auto_ptr' in namespace 'std' does not name a type
make[4]: *** [cclogger.lo] Error 1
make[4]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/plugins/codecompletion'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/plugins/codecompletion'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src'
make: *** [all-recursive] Error 1
Can someone please fix this issue and let me know so I can compile it?
Cheers
Quote from: stefanos_ on January 27, 2012, 05:25:50 PM
In file included from parser/cclogger.cpp:10:0:
parser/cclogger.h:68:23: error: 'auto_ptr' is not a template
Can someone please fix this issue and let me know so I can compile it?
Can you tell me what happens if you put the following line:
#include <memory> // auto_ptr...in between:
#include <wx/string.h>...and:
#include <prep.h> // nullptrin
cclogger.h?
Quote from: MortenMacFly on January 27, 2012, 05:38:21 PM
Quote from: stefanos_ on January 27, 2012, 05:25:50 PM
In file included from parser/cclogger.cpp:10:0:
parser/cclogger.h:68:23: error: 'auto_ptr' is not a template
Can someone please fix this issue and let me know so I can compile it?
Can you tell me what happens if you put the following line:
#include <memory> // auto_ptr
...in between:
#include <wx/string.h>
...and:
#include <prep.h> // nullptr
in cclogger.h?
Hi Morten,
I have already committed a fix for this in rev 7727. Just noticed it during compilation and immediately I committed that fix.
Quote from: Biplab on January 27, 2012, 05:45:54 PM
I have already committed a fix for this in rev 7727. Just noticed it during compilation and immediately I committed that fix.
Well done! :-) Strange it doesn't occur on Windows though.
Thanks guys, both of you.
svn-7727 has been compiled , cheers.
UPDATE:
To test that everything is OK, I opened codeblocks within terminal to get a debug-like behavior and I got this interesting message upon closing it:
*** glibc detected *** codeblocks: corrupted double-linked list: 0x09be10a8 ***
======= Backtrace: =========
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6aa81)[0xb5d95a81]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6aeda)[0xb5d95eda]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c265)[0xb5d97265]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb5d9a39d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x1ff24)[0xb5d4af24]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x18bb7)[0xb5d43bb7]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x18857)[0xb5d43857]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(iconv_close+0x1c)[0xb5d42dbc]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(_ZN14wxMBConv_iconvD1Ev+0x3f)[0xb6abc70f]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(+0x52854)[0xb6a6e854]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(+0xf5820)[0xb6b11820]
/lib/ld-linux.so.2(+0xe4e6)[0xb786f4e6]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x2f4bf)[0xb5d5a4bf]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x2f52f)[0xb5d5a52f]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xee)[0xb5d41e4e]
codeblocks[0x807850d]
======= Memory map: ========
08048000-080e6000 r-xp 00000000 fe:00 754079 /usr/local/bin/codeblocks
080e6000-080ee000 rw-p 0009e000 fe:00 754079 /usr/local/bin/codeblocks
080ee000-080f0000 rw-p 00000000 00:00 0
08792000-09cdd000 rw-p 00000000 00:00 0 [heap]
aaf01000-aaf02000 ---p 00000000 00:00 0
aaf02000-ab702000 rw-p 00000000 00:00 0
ab702000-ab74f000 r--p 00000000 fe:00 11493576 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf
ab74f000-ab789000 r-xp 00000000 fe:00 876719 /usr/lib/i386-linux-gnu/libcroco-0.6.so.3.0.1
ab789000-ab78c000 rw-p 00039000 fe:00 876719 /usr/lib/i386-linux-gnu/libcroco-0.6.so.3.0.1
ab78c000-ab7c3000 r-xp 00000000 fe:00 877338 /usr/lib/i386-linux-gnu/librsvg-2.so.2.34.2
ab7c3000-ab7c4000 rw-p 00037000 fe:00 877338 /usr/lib/i386-linux-gnu/librsvg-2.so.2.34.2
ab7e6000-ab7e7000 ---p 00000000 00:00 0
ab7e7000-abfe7000 rw-p 00000000 00:00 0
abfe7000-abfe8000 ---p 00000000 00:00 0
abfe8000-ac7e8000 rw-p 00000000 00:00 0
ac7e8000-ac7fb000 r-xp 00000000 fe:00 1278452 /usr/local/lib/codeblocks/plugins/libIncrementalSearch.so
ac7fb000-ac7fc000 rw-p 00013000 fe:00 1278452 /usr/local/lib/codeblocks/plugins/libIncrementalSearch.so
ac7fc000-ac869000 r-xp 00000000 fe:00 1278447 /usr/local/lib/codeblocks/plugins/libHexEditor.so
ac869000-ac86d000 rw-p 0006c000 fe:00 1278447 /usr/local/lib/codeblocks/plugins/libHexEditor.so
ac86d000-ac8c5000 r-xp 00000000 fe:00 1278424 /usr/local/lib/codeblocks/plugins/libDoxyBlocks.so
ac8c5000-ac8c7000 rw-p 00058000 fe:00 1278424 /usr/local/lib/codeblocks/plugins/libDoxyBlocks.so
ac8c7000-ac8dc000 r-xp 00000000 fe:00 1278369 /usr/local/lib/codeblocks/plugins/libdefaultmimehandler.so
ac8dc000-ac8de000 rw-p 00014000 fe:00 1278369 /usr/local/lib/codeblocks/plugins/libdefaultmimehandler.so
ac8de000-ac996000 r-xp 00000000 fe:00 1278440 /usr/local/lib/codeblocks/plugins/libheaderfixup.so
ac996000-ac999000 rw-p 000b7000 fe:00 1278440 /usr/local/lib/codeblocks/plugins/libheaderfixup.so
ac999000-ac9a4000 r-xp 00000000 fe:00 1278414 /usr/local/lib/codeblocks/plugins/libCppCheck.so
ac9a4000-ac9a5000 rw-p 0000b000 fe:00 1278414 /usr/local/lib/codeblocks/plugins/libCppCheck.so
ac9a5000-ac9cb000 r-xp 00000000 fe:00 1278382 /usr/local/lib/codeblocks/plugins/libtodo.so
ac9cb000-ac9cd000 rw-p 00026000 fe:00 1278382 /usr/local/lib/codeblocks/plugins/libtodo.so
ac9cd000-aca04000 r-xp 00000000 fe:00 1278455 /usr/local/lib/codeblocks/plugins/libkeybinder.so
aca04000-aca07000 rw-p 00036000 fe:00 1278455 /usr/local/lib/codeblocks/plugins/libkeybinder.so
aca07000-aca78000 r-xp 00000000 fe:00 1278465 /usr/local/lib/codeblocks/plugins/liblib_finder.so
aca78000-aca7c000 rw-p 00070000 fe:00 1278465 /usr/local/lib/codeblocks/plugins/liblib_finder.so
aca7c000-acab7000 r-xp 00000000 fe:00 1278388 /usr/local/lib/codeblocks/plugins/libAutoVersioning.so
acab7000-acab9000 rw-p 0003b000 fe:00 1278388 /usr/local/lib/codeblocks/plugins/libAutoVersioning.so
acab9000-acad3000 r-xp 00000000 fe:00 1278482 /usr/local/lib/codeblocks/plugins/libSymTab.so
acad3000-acad5000 rw-p 00019000 fe:00 1278482 /usr/local/lib/codeblocks/plugins/libSymTab.so
acad5000-acadc000 r-xp 00000000 fe:00 1278400 /usr/local/lib/codeblocks/plugins/libCccc.so
acadc000-acadd000 rw-p 00006000 fe:00 1278400 /usr/local/lib/codeblocks/plugins/libCccc.so
acadd000-acb04000 r-xp 00000000 fe:00 1278394 /usr/local/lib/codeblocks/plugins/libbyogames.so
acb04000-acb07000 rw-p 00027000 fe:00 1278394 /usr/local/lib/codeblocks/plugins/libbyogames.so
acb07000-acb23000 r-xp 00000000 fe:00 1278433 /usr/local/lib/codeblocks/plugins/libenvvars.so
acb23000-acb25000 rw-p 0001b000 fe:00 1278433 /usr/local/lib/codeblocks/plugins/libenvvars.so
acb25000-acbbf000 r-xp 00000000 fe:00 1278366 /usr/local/lib/codeblocks/plugins/libdebugger.so
acbbf000-acbc5000 rw-p 0009a000 fe:00 1278366 /usr/local/lib/codeblocks/plugins/libdebugger.so
acbc5000-acbc6000 rw-p 00000000 00:00 0
acbc6000-acbdb000 r-xp 00000000 fe:00 1278417 /usr/local/lib/codeblocks/plugins/libCscope.so
acbdb000-acbdc000 rw-p 00015000 fe:00 1278417 /usr/local/lib/codeblocks/plugins/libCscope.so
acbdc000-acc05000 r-xp 00000000 fe:00 1278375 /usr/local/lib/codeblocks/plugins/libprojectsimporter.so
acc05000-acc06000 rw-p 00029000 fe:00 1278375 /usr/local/lib/codeblocks/plugins/libprojectsimporter.so
acc06000-acc3d000 r-xp 00000000 fe:00 1278499 /usr/local/lib/codeblocks/plugins/libToolsPlus.so
acc3d000-acc40000 rw-p 00036000 fe:00 1278499 /usr/local/lib/codeblocks/plugins/libToolsPlus.so
acc40000-acc76000 r-xp 00000000 fe:00 1278391 /usr/local/lib/codeblocks/plugins/libBrowseTracker.so
acc76000-acc79000 rw-p 00036000 fe:00 1278391 /usr/local/lib/codeblocks/plugins/libBrowseTracker.so
acc79000-accca000 r-xp 00000000 fe:00 876788 /usr/lib/i386-linux-gnu/libhunspell-1.3.so.0.0.0
accca000-accce000 rw-p 00051000 fe:00 876788 /usr/lib/i386-linux-gnu/libhunspell-1.3.so.0.0.0
accd5000-acce1000 r-xp 00000000 fe:00 1278502 /usr/local/lib/codeblocks/plugins/libValgrind.so
acce1000-acce2000 rw-p 0000c000 fe:00 1278502 /usr/local/lib/codeblocks/plugins/libValgrind.so
acce2000-accef000 r-xp 00000000 fe:00 1278290 /usr/local/lib/codeblocks/plugins/libautosave.so
accef000-accf0000 rw-p 0000c000 fe:00 1278290 /usr/local/lib/codeblocks/plugins/libautosave.so
accf0000-acd4a000 r-xp 00000000 fe:00 1278664 /usr/local/lib/codeblocks/plugins/libSpellChecker.so
acd4a000-acd4f000 rw-p 00059000 fe:00 1278664 /usr/local/lib/codeblocks/plugins/libSpellChecker.so
acd4f000-acd62000 r-xp 00000000 fe:00 1278408 /usr/local/lib/codeblocks/plugins/libcodestat.so
acd62000-acd63000 rw-p 00013000 fe:00 1278408 /usr/local/lib/codeblocks/plugins/libcodestat.so
acd63000-acd75000 r-xp 00000000 fe:00 1278397 /usr/local/lib/codeblocks/plugins/libcb_koders.so
acd75000-acd76000 rw-p 00012000 fe:00 1278397 /usr/local/lib/codeblocks/plugins/libcb_koders.so
acd76000-acdc0000 r-xp 00000000 fe:00 1278505 /usr/local/lib/codeblocks/plugins/libwxSmithAui.so
acdc0000-acdc4000 rw-p 00049000 fe:00 1278505 /usr/local/lib/codeblocks/plugins/libwxSmithAui.so
acdc4000-acdc5000 rw-p 00000000 00:00 0
acdc5000-acdda000 r-xp 00000000 fe:00 1278385 /usr/local/lib/codeblocks/plugins/libabbreviations.so
acdda000-acddb000 rw-p 00014000 fe:00 1278385 /usr/local/lib/codeblocks/plugins/libabbreviations.so
acddb000-acde5000 r-xp 00000000 fe:00 1278468 /usr/local/lib/codeblocks/plugins/libMouseSap.so
acde5000-acde6000 rw-p 00009000 fe:00 1278468 /usr/local/lib/codeblocks/plugins/libMouseSap.so
acde6000-acdf3000 r-xp 00000000 fe:00 1278485 /usr/local/lib/codeblocks/plugins/libRegExTestbed.so
acdf3000-acdf4000 rw-p 0000c000 fe:00 1278485 /usr/local/lib/codeblocks/plugins/libRegExTestbed.so
acdf4000-ace10000 r-xp 00000000 fe:00 1278427 /usr/local/lib/codeblocks/plugins/libdragscroll.so
ace10000-ace12000 rw-p 0001c000 fe:00 1278427 /usr/local/lib/codeblocks/plugins/libdragscroll.so
ace12000-acef9000 r-xp 00000000 fe:00 1278345 /usr/local/lib/codeblocks/plugins/libcodecompletion.so
acef9000-acefe000 rw-p 000e6000 fe:00 1278345 /usr/local/lib/codeblocks/plugins/libcodecompletion.so
acefe000-aceff000 rw-p 00000000 00:00 0
aceff000-acf19000 r-xp 00000000 fe:00 1278475 /usr/local/lib/codeblocks/plugins/libProfiler.so
acf19000-acf1b000 rw-p 00019000 fe:00 1278475 /usr/local/lib/codeblocks/plugins/libProfiler.so
acf1b000-ad108000 r-xp 00000000 fe:00 1278479 /usr/local/lib/codeblocks/plugins/libexporter.so
ad108000-ad123000 rw-p 001ed000 fe:00 1278479 /usr/local/lib/codeblocks/plugins/libexporter.so
ad123000-ad124000 rw-p 00000000 00:00 0
ad124000-ad171000 r-xp 00000000 fe:00 1278372 /usr/local/lib/codeblocks/plugins/libscriptedwizard.so
ad171000-ad176000 rw-p 0004c000 fe:00 1278372 /usr/local/lib/codeblocks/plugins/libscriptedwizard.so
ad176000-ad189000 r-xp 00000000 fe:00 1278430 /usr/local/lib/codeblocks/plugins/libEditorTweaks.so
ad189000-ad18a000 rw-p 00013000 fe:00 1278430 /usr/local/lib/codeblocks/plugins/libEditorTweaks.so
ad18a000-ad1d0000 r-xp 00000000 fe:00 1278648 /usr/local/lib/codeblocks/plugins/libastyle.so
ad1d0000-ad1d2000 rw-p 00045000 fe:00 1278648 /usr/local/lib/codeblocks/plugins/libastyle.so
ad1d2000-ad2db000 r-xp 00000000 fe:00 1278405 /usr/local/lib/codeblocks/plugins/libcodesnippets.so
ad2db000-ad2e4000 rw-p 00109000 fe:00 1278405 /usr/local/lib/codeblocks/plugins/libcodesnippets.so
ad2e4000-ad2e6000 rw-p 00000000 00:00 0
ad2e6000-ad334000 r-xp 00000000 fe:00 1278494 /usr/local/lib/codeblocks/plugins/libThreadSearch.so
ad334000-ad337000 rw-p 0004d000 fe:00 1278494 /usr/local/lib/codeblocks/plugins/libThreadSearch.so
ad337000-ad338000 rw-p 00000000 00:00 0
ad338000-ad33f000 r-xp 00000000 fe:00 746225 /usr/lib/libgamin-1.so.0.1.10
ad33f000-ad340000 rw-p 00006000 fe:00 746225 /usr/lib/libgamin-1.so.0.1.10
ad340000-ad37e000 r-xp 00000000 fe:00 1278437 /usr/local/lib/codeblocks/plugins/libFileManager.so
ad37e000-ad380000 rw-p 0003e000 fe:00 1278437 /usr/local/lib/codeblocks/plugins/libFileManager.so
ad380000-ad381000 rw-p 00000000 00:00 0
ad381000-ad410000 r-xp 00000000 fe:00 1278472 /usr/local/lib/codeblocks/plugins/libNassiShneiderman.so
ad410000-ad416000 rw-p 0008e000 fe:00 1278472 /usr/local/lib/codeblocks/plugins/libNassiShneiderman.so
ad416000-ad455000 r-xp 00000000 fe:00 1286342 /usr/local/lib/wxSmithContribItems/libwxflatnotebook.so.0.0.1
ad455000-ad459000 rw-p 0003e000 fe:00 1286342 /usr/local/lib/wxSmithContribItems/libwxflatnotebook.so.0.0.1
ad459000-ad481000 r-xp 00000000 fe:00 1286328 /usr/local/lib/wxSmithContribItems/libwxchartctrl.so.0.0.1
ad481000-ad484000 rw-p 00027000 fe:00 1286328 /usr/local/lib/wxSmithContribItems/libwxchartctrl.so.0.0.1
ad484000-ad718000 r-xp 00000000 fe:00 754140 /usr/local/lib/libwxsmithlib.so.0.0.1
ad718000-ad72d000 rw-p 00293000 fe:00 754140 /usr/local/lib/libwxsmithlib.so.0.0.1
ad72d000-ad73a000 rw-p 00000000 00:00 0
ad73d000-ad743000 r-xp 00000000 fe:00 1278411 /usr/local/lib/codeblocks/plugins/libcopystrings.so
ad743000-ad744000 rw-p 00005000 fe:00 1278411 /usr/local/lib/codeblocks/plugins/libcopystrings.so
ad744000-ad75b000 r-xp 00000000 fe:00 1278294 /usr/local/lib/codeblocks/plugins/libclasswizard.so
ad75b000-ad75c000 rw-p 00017000 fe:00 1278294 /usr/local/lib/codeblocks/plugins/libclasswizard.so
ad75c000-ad783000 r-xp 00000000 fe:00 1278462 /usr/local/lib/codeblocks/plugins/libwxsmithcontribitems.so
ad783000-ad785000 rw-p 00027000 fe:00 1278462 /usr/local/lib/codeblocks/plugins/libwxsmithcontribitems.so
ad785000-ad786000 rw-p 00000000 00:00 0
ad786000-ad8a5000 r-xp 00000000 fe:00 1278443 /usr/local/lib/codeblocks/plugins/libhelp_plugin.so
ad8a5000-ad8ac000 rw-p 0011f000 fe:00 1278443 /usr/local/lib/codeblocks/plugins/libhelp_plugin.so
ad8ac000-ad8af000 rw-p 00000000 00:00 0
ad8af000-ad9fb000 r-xp 00000000 fe:00 1278348 /usr/local/lib/codeblocks/plugins/libcompiler.so
ad9fb000-ad9ff000 rw-p 0014c000 fe:00 1278348 /usr/local/lib/codeblocks/plugins/libcompiler.so
ad9ff000-ada00000 rw-p 00000000 00:00 0
ada00000-adae2000 rw-p 00000000 00:00 0
adae2000-adb00000 ---p 00000000 00:00 0
adb00000-adb02000 r-xp 00000000 fe:00 1278458 /usr/local/lib/codeblocks/plugins/libwxsmith.so
adb02000-adb03000 rw-p 00001000 fe:00 1278458 /usr/local/lib/codeblocks/plugins/libwxsmith.so
adb03000-adb0d000 r-xp 00000000 fe:00 1286559 /usr/local/lib/wxSmithContribItems/libwxcustombutton.so.0.0.1
adb0d000-adb0e000 rw-p 0000a000 fe:00 1286559 /usr/local/lib/wxSmithContribItems/libwxcustombutton.so.0.0.1
adb0e000-adb17000 r-xp 00000000 fe:00 1278378 /usr/local/lib/codeblocks/plugins/libopenfileslist.so
adb17000-adb18000 rw-p 00009000 fe:00 1278378 /usr/local/lib/codeblocks/plugins/libopenfileslist.so
adb18000-adb2c000 r-xp 00000000 fe:00 1278488 /usr/local/lib/codeblocks/plugins/libReopenEditor.so
adb2c000-adb2e000 rw-p 00013000 fe:00 1278488 /usr/local/lib/codeblocks/plugins/libReopenEditor.so
adb2e000-adb8e000 rw-s 00000000 00:04 17203228 /SYSV00000000 (deleted)
adb8e000-adb94000 r-xp 00000000 fe:00 895181 /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so
adb94000-adb95000 rw-p 00005000 fe:00 895181 /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so
adb95000-adbe7000 r--p 00000000 fe:00 11493578 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
adbe7000-adbe8000 ---p 00000000 00:00 0
adbe8000-ae3e8000 rw-p 00000000 00:00 0
ae3e8000-ae3e9000 ---p 00000000 00:00 0
ae3e9000-aebe9000 rw-p 00000000 00:00 0
aebe9000-aebea000 ---p 00000000 00:00 0
aebea000-af3ea000 rw-p 00000000 00:00 0
af3ea000-af3eb000 ---p 00000000 00:00 0
af3eb000-afbeb000 rw-p 00000000 00:00 0
afbeb000-afc1a000 r-xp 00000000 fe:00 876793 /usr/lib/i386-linux-gnu/libbluray.so.1.1.0
afc1a000-afc1b000 r--p 0002e000 fe:00 876793 /usr/lib/i386-linux-gnu/libbluray.so.1.1.0
afc1b000-afc1c000 rw-p 0002f000 fe:00 876793 /usr/lib/i386-linux-gnu/libbluray.so.1.1.0
afc1c000-afc2a000 r-xp 00000000 fe:00 13543765 /lib/i386-linux-gnu/libudev.so.0.13.0
afc2a000-afc2b000 r--p 0000d000 fe:00 13543765 /lib/i386-linux-gnu/libudev.so.0.13.0
afc2b000-afc2c000 rw-p 0000e000 fe:00 13543765 /lib/i386-linux-gnu/libudev.so.0.13.0
afc2c000-afc74000 r-xp 00000000 fe:00 13543698 /lib/i386-linux-gnu/libdbus-1.so.3.5.8
afc74000-afc75000 r--p 00048000 fe:00 13543698 /lib/i386-linux-gnu/libdbus-1.so.3.5.8Aborted
I hope it's the normal killing process and not something to worry about. I know under Windows it would create an RPT file; now, under GNU / Linux I don't know.
Maybe jens could help or explain this to me, it would help a lot.
Quote from: stefanos_ on January 27, 2012, 07:19:34 PM
Maybe jens could help or explain this to me, it would help a lot.
I know this error, you can ignore it.
Everything is saved, even if it should not occur.
I still try to investigate, what cause it.
It happens during unload of the plugins, but it does not happen always, it does not always happen at the same place, and it does not happen with all builds.
I inserted some debug-output and since then it does not happen at all.
Quote from: jens on January 27, 2012, 08:51:18 PM
Quote from: stefanos_ on January 27, 2012, 07:19:34 PM
Maybe jens could help or explain this to me, it would help a lot.
I know this error, you can ignore it.
BTW: Another error that drives me nuts you can see if you do the following:
- start C::B with
--debug-log and
--verbose- open a "Hello World" project
- close C::B
You'll see:
22:28:27: Can not wait for thread termination (error 6: the handle is invalid.)
22:28:27: Couldn't terminate thread (error 6: the handle is invalid.)
It disappears if you disable the CC plugins (BTW: disabling/enabling CC makes it appear, too). I tried to debug into it but I didn't manage to find the actual cause. I did a lot of debug outputs in the destructors of the threads created by CC that are
not based on
cdThreadedTask - these
seem to be fine. I don't know what to do... but I believe this is also the cause for crash on exit for the 64 bit build of C::b.
Quote from: MortenMacFly on January 27, 2012, 10:34:01 PM
Quote from: jens on January 27, 2012, 08:51:18 PM
Quote from: stefanos_ on January 27, 2012, 07:19:34 PM
Maybe jens could help or explain this to me, it would help a lot.
I know this error, you can ignore it.
BTW: Another error that drives me nuts you can see if you do the following:
- start C::B with --debug-log and --verbose
- open a "Hello World" project
- close C::B
You'll see:
22:28:27: Can not wait for thread termination (error 6: the handle is invalid.)
22:28:27: Couldn't terminate thread (error 6: the handle is invalid.)
It disappears if you disable the CC plugins (BTW: disabling/enabling CC makes it appear, too). I tried to debug into it but I didn't manage to find the actual cause. I did a lot of debug outputs in the destructors of the threads created by CC that are not based on cdThreadedTask - these seem to be fine. I don't know what to do... but I believe this is also the cause for crash on exit for the 64 bit build of C::b.
I do no even to open a "hello world" project, I just start c::b, and close c::b, then I will receive these two errors when c::b exits.
Quote from: ollydbg on January 28, 2012, 05:52:01 AM
I do no even to open a "hello world" project, I just start c::b, and close c::b, then I will receive these two errors when c::b exits.
It looks like the thread: ClassBrowserBuilderThread cause this issue.
I just add the test code:
void ClassBrowser::BuildTree()
{
if (Manager::IsAppShuttingDown() || !m_Parser)
return;
// tree shall only be created in case of a new builder thread
bool create_tree = false;
// create the thread if needed
if (!m_BuilderThread)
{
return; //***************
m_BuilderThread = new ClassBrowserBuilderThread(m_Semaphore, &m_BuilderThread);
m_BuilderThread->Create();
m_BuilderThread->Run();
create_tree = true; // new builder thread - need to create new tree
}
...
You see, I forbid to create an ClassBrowserBuilderThread instance, then I have no error report on c::b exit.
Looks like writing GUI related code in a worker thread cause this issue.
Quote from: ollydbg on January 28, 2012, 07:16:10 AM
Looks like writing GUI related code in a worker thread cause this issue.
Not only this one, but some random crashes, too.
I just debug further, I change the BuildTree function like below:
void ClassBrowserBuilderThread::BuildTree()
{
return;
...
}
Thus, no UI related operation here, but c::b still report 2 errors. That's too strange. It looks like this thread can't safely be destroyed.
Ok, I find the reason, we only need Wait(). (We don't need Delete()), otherwise, we try to delete the thread twice.
// class destructor
ClassBrowser::~ClassBrowser()
{
int pos = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetSashPosition();
Manager::Get()->GetConfigManager(_T("code_completion"))->Write(_T("/splitter_pos"), pos);
SetParser(NULL);
if (m_BuilderThread)
{
m_Semaphore.Post();
//m_BuilderThread->Delete();
m_BuilderThread->Wait();
delete m_BuilderThread;
m_BuilderThread=0;
}
}
It works OK.
Quote from: ollydbg on January 28, 2012, 11:19:14 AM
//m_BuilderThread->Delete();
m_BuilderThread->Wait();
Good catch! This would explain the error indeed and also, why I couldn't catch it - I was looking into the parser stuff, not the classbrowser. I'll try and give feedback (also for the wx2.9.x/64bit builds...).
ollydbg, since you mentioned wx2.9.x, does it compile now this project? Because I remember having issues compiling it both GNU / Linux and Windows. If yes, can you provide more feedback please because I want to try it :D
Quote from: stefanos_ on January 28, 2012, 10:10:31 PM
ollydbg, since you mentioned wx2.9.x, does it compile now this project? Because I remember having issues compiling it both GNU / Linux and Windows. If yes, can you provide more feedback please because I want to try it :D
Me? I have not mentioned wx2.9.x, I guess you ask such question on Morten. :)
Quote from: stefanos_ on January 28, 2012, 10:10:31 PM
does it compile now this project?
Yes, it compiles fine, there is even a C::B project in SVN for you to try.
However, it doesn't run stable atm.
Quote from: jens on January 27, 2012, 08:51:18 PM
Quote from: stefanos_ on January 27, 2012, 07:19:34 PM
Maybe jens could help or explain this to me, it would help a lot.
I know this error, you can ignore it.
Everything is saved, even if it should not occur.
I still try to investigate, what cause it.
It happens during unload of the plugins, but it does not happen always, it does not always happen at the same place, and it does not happen with all builds.
I inserted some debug-output and since then it does not happen at all.
I think I found the issue:
the help-plugin was linked against libcodeblocks.so and agaist the static scripting libs, that are already linked into libcodeblocks.
Should be fixed in svn r7746 .
Quote from: jens on January 27, 2012, 03:52:15 PM
Quote from: xawari on January 27, 2012, 03:14:16 PM
I hate to say it, but...
I pressed ENTER in file browser tree on a file, "How do we open" dialog appeared, I've chosen "open inside cb editor" and... nothing happens. Moreover, pressing ENTER stops working at this moment. Forever. Double-clicking works.
Which version of C::B (this nightly ?), which OS ?
Works fine here on linux.
Does not make sense for me and I think this usage of the ESC key would not be obvious to anyone (except you).
this build, "svn build rev 7671 (2012/01/06 10:23:21) gcc 4.5.2 Windows/unicode - 32 bit" windows 2003 (NT 5.2) 32-bit
I'll clarify all other questions as soon as it'll be possible for me, sorry, in a hurry.
I am posting this problem again as i am facing it for quite some time now!!
Whenever i do ctrl+shift+n to open a new file and type #inc the autocomplete jumps in and provides suggesstions for me.. As soon as i save the file to a .c or a .cpp, the codecompleteion never happens.. :o
and then i create classes with its members variables and functions and then when i type main function, and create objects of that class, then again the code completion will never work..
After some time (if i dont close C::B) and create say file_1.cpp, file_2.cpp, file_n.cpp, and then in file_5.cpp the class of file_2.cpp will be popped up by code completion..
And after working for say half an hour, code completion will start working as usual..!!
What could have gone wrong?? Am i missing any setting?? i am just a student using code::blocks to learn C and C++!!!
1. Sorry for my English;
2. Code::Blocks rocks!;
3. Minor bug report: when I'm using "Rename symbols" on class name - it doesn't rename the constructor.
Quote from: neo1691 on February 02, 2012, 02:51:52 PM
[...]
Whenever i do ctrl+shift+n to open a new file and type #inc the autocomplete jumps in and provides suggesstions for me.. As soon as i save the file to a .c or a .cpp, the codecompleteion never happens.. :o
and then i create classes with its members variables and functions and then when i type main function, and create objects of that class, then again the code completion will never work..
After some time (if i dont close C::B) and create say file_1.cpp, file_2.cpp, file_n.cpp, and then in file_5.cpp the class of file_2.cpp will be popped up by code completion..
[...]
This is not exactly an answer; there are several things I have found that seem to reinitialize CC when it acts strangely.
- Managing all files through a project
- Saving all files
- Clicking "reparse project"
- Watching the application log, and only beginning work after seeing the phrase "parsing stage done"
- And, of course, restarting Code::Blocks
I would also recommend going through all of CC's settings to see if anything is amiss.
Quote from: Alpha on February 04, 2012, 10:20:43 PM
Quote from: neo1691 on February 02, 2012, 02:51:52 PM
[...]
Whenever i do ctrl+shift+n to open a new file and type #inc the autocomplete jumps in and provides suggesstions for me.. As soon as i save the file to a .c or a .cpp, the codecompleteion never happens.. :o
and then i create classes with its members variables and functions and then when i type main function, and create objects of that class, then again the code completion will never work..
After some time (if i dont close C::B) and create say file_1.cpp, file_2.cpp, file_n.cpp, and then in file_5.cpp the class of file_2.cpp will be popped up by code completion..
[...]
This is not exactly an answer; there are several things I have found that seem to reinitialize CC when it acts strangely.
- Managing all files through a project
- Saving all files
- Clicking "reparse project"
- Watching the application log, and only beginning work after seeing the phrase "parsing stage done"
- And, of course, restarting Code::Blocks
I would also recommend going through all of CC's settings to see if anything is amiss.
But most of the times i work with single files like .c or .cpp!! Haven't yet started coding like a pro! :D
Just came to know this...
SCROLL TO THE RIGHT TO SEE THE FAILED DLL's
This happened after i ran C::B for the first time after the installation of the new anti virus
(http://i.minus.com/iWF5LlxEZb0FH.jpg)
That is my laptop is infected by some W32.Xpaj.B.http://www.symantec.com/connect/blogs/w32xpajb-upper-crust-file-infector (http://www.symantec.com/connect/blogs/w32xpajb-upper-crust-file-infector).
Many of the dlls of codeblocks were affected by this virus including the codecompletion plugin.
Now i have waged a war against this virus.. And hopefully if i win, i will get back my system back.. else a complete format is on the cards!! :'(
Quote from: neo1691 on February 05, 2012, 03:39:51 PM
Just came to know this...
So what? Its not our fault. If you don't want a virus, just don't download/run stuff you don't know from the internet or friends... I live very happy with that literally since ages, my last virus was when I was still running MS DOS. ;-)
Quote from: MortenMacFly on February 05, 2012, 04:13:03 PM
Quote from: neo1691 on February 05, 2012, 03:39:51 PM
Just came to know this...
So what? Its not our fault. If you don't want a virus, just don't download/run stuff you don't know from the internet or friends... I live very happy with that literally since ages, my last virus was when I was still running MS DOS. ;-)
I have always taken care regarding that!! Now i will go to my college and ask my sir to sort things out!!
enough off topic..!! Can i ask what is the status of the next stable release?? I really like the minimal prespective!!
@MortenMacFly: I have a kind request from user "_6i" from Code::Blocks' IRC channel to add pasgui's https://launchpad.net/~pasgui/+archive/ppa (https://launchpad.net/~pasgui/+archive/ppa) link. Is it possible please or not?
Quote from: stefanos_ on February 12, 2012, 03:51:57 PM
@MortenMacFly: I have a kind request from user "_6i" from Code::Blocks' IRC channel to add pasgui's https://launchpad.net/~pasgui/+archive/ppa (https://launchpad.net/~pasgui/+archive/ppa) link. Is it possible please or not?
Where do you want to add that link? Its here now...?! I don't understand. ???
Quote from: MortenMacFly on February 12, 2012, 03:54:41 PM
Quote from: stefanos_ on February 12, 2012, 03:51:57 PM
@MortenMacFly: I have a kind request from user "_6i" from Code::Blocks' IRC channel to add pasgui's https://launchpad.net/~pasgui/+archive/ppa (https://launchpad.net/~pasgui/+archive/ppa) link. Is it possible please or not?
Where do you want to add that link? Its here now...?! I don't understand. ???
after patiently listening to all my ranting in the irc channel, _stefanos_ has been so nice and offered to post instead of me so i would not need to register for only one post, but eventually i joined the dark side.. :)
so, i just wanted to ask kindly :) to add pasgui's launchpad ppa repository to the download links
launchpad.net is the quasi-default/-official ubuntu bugtracker and repository "provider", and therefore using launchpad ppa repositories is integrated into ubuntu (creation and management of adequate /etc/apt/sources.list.d/* lists) can be done through a comfortable gui, or one single command (in this case "add-apt-repository ppa:pasgui/ppa", what is explained on the launchpad page)
however it is not exactly easy to find, it makes much easier to get more up-to-date codeblocks packages (without the need to compile anything for those who do not want to alter code, and enjoy the pros of package management systems..), as you probably know, in contrast with the debian packages provided by jens, the pasgui repo works out of the box on ubuntu
and also, using the launchpad link (rather than the lgp203 one) makes it still easier to add and manage the repo
Quote from: MortenMacFly on February 05, 2012, 04:13:03 PM
Quote from: neo1691 on February 05, 2012, 03:39:51 PM
Just came to know this...
So what? Its not our fault. If you don't want a virus, just don't download/run stuff you don't know from the internet or friends... I live very happy with that literally since ages, my last virus was when I was still running MS DOS. ;-)
..and if i'm already registered, maybe i can even contribute a story of mine..
on the anti-virus notification problem:
it might not be a virus at all, but a false-positive---back in the day in the grammar school computer science class, once i could not run a pascal program i have just written from the ide ("missing executable"), and when i exited the editor to investigate, i've seen the notification that norton antivirus just deleted my executable, because it supposedly contained a virus....in fact, it contained some cycles, some addition/division, and printing-to-stdout kinda' stuff...
anti-virus programs DO fail sometimes, but you should still check the origin of those files, and if convinced that they are genuine, report a false positive on the anti-virus developer's site (this is not unusual at all), and they should correct it and maybe the next virus database update will not complain..
...or confirm that the files are indeed infected and you were wrong.. :D
Quote from: _6i on February 12, 2012, 04:43:46 PM
so, i just wanted to ask kindly :) to add pasgui's launchpad ppa repository to the download links
launchpad.net is the quasi-default/-official ubuntu bugtracker and repository "provider", and therefore using launchpad ppa repositories is integrated into ubuntu (creation and management of adequate /etc/apt/sources.list.d/* lists) can be done through a comfortable gui, or one single command (in this case "add-apt-repository ppa:pasgui/ppa", what is explained on the launchpad page)
I changed the appropriate link on our binaries site (http://www.codeblocks.org/downloads/26#linux) and added it to the "Notes for Ubuntu users" on the frontpage of my repo (http://apt.jenslody.de/).
Quote from: jens on February 12, 2012, 07:27:18 PM
I changed the appropriate link on our binaries site (http://www.codeblocks.org/downloads/26#linux)
...which for the sake of being curious... Which one is the link you changed here?
I've just updated my Ubuntu, so I might even try...
Quote from: MortenMacFly on February 12, 2012, 08:32:03 PM
Quote from: jens on February 12, 2012, 07:27:18 PM
I changed the appropriate link on our binaries site (http://www.codeblocks.org/downloads/26#linux)
...which for the sake of being curious... Which one is the link you changed here?
I've just updated my Ubuntu, so I might even try...
Last link in
Important note for Ubuntu users:.
Quote from: jens on February 12, 2012, 07:27:18 PM
I changed the appropriate link on our binaries site (http://www.codeblocks.org/downloads/26#linux) and added it to the "Notes for Ubuntu users" on the frontpage of my repo (http://apt.jenslody.de/).
thank you very much for the quick help, this should solve the "what was that ppa i found last time?.. how/where did i find it?.." kind of dilemmas after the next reinstall and save some time :)
..and hopefully not just for me.. :)
Quote
Force target re-link if any static library it depends on gets updated (i.e. no need to manually add an external dependency for static libraries anymore)
when checking for changed static library dependencies, look in compiler's linker search paths too
when checking for changed static library dependencies, include libraries referenced directly (w/out the use of linker's search path)
How stop this new comportement :
- I modified cpp files from base dynamic lib.
- Build all project
- Codeblocks -> Re-link all solution's projects ( It's useless... it's a dynamic lib not a static lib ) before this Nightly build Codeblocks just check all targets when i rebuild all
I have 30 projects in my solution. I use frequently rebuild all and now i lose more time.
Thanks a lot for your work.
Can you provide an example/test workspace?
What about your platform/gcc versions?
This solution and my solution it's the same hierachy and compilation options. ( see the Attach 7zfile )
I use Mingw ( TDM ).
Example :
I rebuild-All :
my targets are all build.
I modified :
In Lib_Test1 -> Math.cpp
return !aResult ; -> return aResult ;
I build-all in Codeblocks :
-------------- Build: Debug in Lib_Test1 ---------------
[ 50,0%] Compiling: ..\..\..\Test\Math.cpp
[100,0%] Linking dynamic library: ..\..\..\..\Bin\Mingw\Lib_Test1_d_CB.dll
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test1_d_CB.a
Output size is 83,50 KB
-------------- Build: Release in Lib_Test1 ---------------
[ 50,0%] Compiling: ..\..\..\Test\Math.cpp
[100,0%] Linking dynamic library: ..\..\..\..\Bin\Mingw\Lib_Test1_CB.dll
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test1_CB.a
Output size is 80,50 KB
-------------- Build: Debug in Lib_Test2 ---------------
[100,0%] Linking dynamic library: ..\..\..\..\Bin\Mingw\Lib_Test2_d_CB.dll
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test2_d_CB.a
Output size is 49,90 KB
-------------- Build: Release in Lib_Test2 ---------------
[100,0%] Linking dynamic library: ..\..\..\..\Bin\Mingw\Lib_Test2_CB.dll
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test2_CB.a
Output size is 9,50 KB
-------------- Build: Debug in App_Test1 ---------------
[100,0%] Linking console executable: ..\..\..\..\Bin\Mingw\App_Test1_d_CB.exe
Output size is 976,25 KB
-------------- Build: Release in App_Test1 ---------------
[100,0%] Linking console executable: ..\..\..\..\Bin\Mingw\App_Test1_CB.exe
Output size is 461,00 KB
-------------- Build: Debug in App_Test2 ---------------
[100,0%] Linking console executable: ..\..\..\..\Bin\Mingw\App_Test2_d_CB.exe
Output size is 976,84 KB
-------------- Build: Release in App_Test2 ---------------
[100,0%] Linking console executable: ..\..\..\..\Bin\Mingw\App_Test2_CB.exe
Output size is 461,50 KB
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)
Codeblocks re-link all targets.
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test2_CB.a
This is the reason.
You are linking to a static lib.
Have you tried to link directly to the dlls?
Newer TDM/Ming gcc's support this.
You have resolved my problem.
Thanks a lot.
I rename in the linker settings my libraries :
Lib_Test1_d_CB -> Lib_Test1_d_CB.dll
Lib_Test1_CB -> Lib_Test1_CB.dll
etc.
-------------- Build: Debug in Lib_Test1 ---------------
[ 50,0%] Compiling: ..\..\..\Test\Math.cpp
[100,0%] Linking dynamic library: ..\..\..\..\Bin\Mingw\Lib_Test1_d_CB.dll
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test1_d_CB.a
Output size is 83,50 KB
-------------- Build: Release in Lib_Test1 ---------------
[ 50,0%] Compiling: ..\..\..\Test\Math.cpp
[100,0%] Linking dynamic library: ..\..\..\..\Bin\Mingw\Lib_Test1_CB.dll
Creating library file: ..\..\..\..\Bin\Mingw\libLib_Test1_CB.a
Output size is 80,50 KB
-------------- Build: Debug in Lib_Test2 ---------------
Target is up to date.
-------------- Build: Release in Lib_Test2 ---------------
Target is up to date.
-------------- Build: Debug in App_Test1 ---------------
Target is up to date.
-------------- Build: Release in App_Test1 ---------------
Target is up to date.
-------------- Build: Debug in App_Test2 ---------------
Target is up to date.
-------------- Build: Release in App_Test2 ---------------
Quote from: oBFusCATed on March 07, 2012, 12:32:44 PM
You are linking to a static lib.
What makes you say so? This could also be an
import library for the DLL - depending on the settings use to create.
Morten: For me .a or .lib file is a static library. The current auto-relink mechanism in C::B thinks the same.
Gandi: I guess you can revert to the old lib names and uncheck the "Create import library" option in the Project->Properties
oBFusCATed : It's OK and i prefer this last solution.
Quote from: oBFusCATed on March 07, 2012, 12:44:16 PM
Morten: For me .a or .lib file is a static library.
For me, both import library and static library can have .a or .lib. :)