P.S.: Unrelated to bug, related to development: How outdated SDK documentation is in BerliOS? I want to understand how Code::Blocks currently works.Here is my suggestion if you would like to learn C::B source code:
ToApolytoXaos: Try to disable CC for a while and tell us if the crashes are still there...
const bool linux = (id == platform_linux);
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.Since which revision do you get this ?
1- FILES WITHOUT TARGETS
'CodeBlocks r9156'
- 'sdk\nullptr.cpp'
- 'wxsmith\debuggersettingspanel.wxs'
'CC Test' : 'src\plugins\codecompletion\'
- 'cctest\test.h'
'wxSmith' : 'src\plugins\contrib\wxSmith\'
- 'wxwidgets\defitems\wxsmediactrl.cpp'
- 'wxwidgets\defitems\wxsmediactrl.h'
'Tools Plus Plugin' : 'src\plugins\contrib\ToolsPlus\'
- 'update.bat'
2- TO AVOID WARNING XGETTEXT :
FILES CONTAINING _("") TO REPLACE _T("") OR wxT("")
'CodeBlocks r9156'
- 'src\scriptingsettingsdlg.cpp' : L128
'wxWidgets - Contrib Items' : 'src\plugins\contrib\wxContribItems\'
- 'wxSpeedButton\wxSpeedButton.h' L73, L89, L90, L107
'wxSmith' : 'src\plugins\contrib\wxSmith\'
- 'wxwidgets\defitems\wxsimagelist.cpp' L206
- 'wxwidgets\properties\wxsimagelisteditordlg.cpp' L1213
'wxSmith - Contrib Items' : 'src\plugins\contrib\wxSmithContribItems\'
- 'wxled\wxsLcdWindow.cpp' L33
- 'wxled\wxsLedNumber.cpp' L34
- 'wxled\wxsLedPanel.cpp' L48
- 'wxspeedbutton\wxsSpeedButton.cpp'L80:
- 'wxtreelist\wxsTreeListCtrl.cpp' L142, L150, L318, L410, L476
'wxSmithAui - wxAUI' :'src\plugins\contrib\wxSmithAui\'
- 'wxAuiManager\wxsAuiManager.cpp' L108, L116
'FileManager Plugin' : 'src\plugins\contrib\FileManager\'
- 'directorymonitor.cpp' L518
'ThreadSearch' : 'src\plugins\contrib\ThreadSearch\'
- 'ThreadSearch.cpp' L656, L660
- 'ThreadSearchLoggerBase.cpp' L52
3- FILES CONTAINING wxT("blabla") TO REPLACE _("blabla")
'src/plugins/compilergcc/compileroptionsdlg.cpp'
L2851, L2875
'src/plugins/contrib/BrowseTracker/ConfigPanel.cpp' (from wxFormBuilder)
L27, 39, 42, 50, 52, 61, 63, 72, 84, 86, 92
'src/plugins/contrib/SpellChecker/ThesaurusDialog.cpp'
L44, 53, 65
'src/plugins/contrib/codesnippets/Search/SearchInPanel.cpp'
L35, 37, 39
'src/plugins/contrib/codesnippets/Search/ThreadSearch.cpp'
L411, 448, 449, 459, 460, 604
'src/plugins/contrib/codesnippets/Search/ThreadSearchConfPanel.cpp'
L44..63, 69, 75, 81, 87, 124, 125, 303,
'src/plugins/contrib/codesnippets/Search/ThreadSearchConfPanel.h'
L47, 52
'src/plugins/contrib/codesnippets/Search/ThreadSearchLoggerList.cpp'
L150, 167, 249, 142, 158
'src/plugins/contrib/codesnippets/Search/ThreadSearchView.cpp'
L73, 76, 77, 80, 295, 296, 837, 838
'src/plugins/contrib/codesnippets/codesnippets.cpp'
L1816
'src/plugins/contrib/codesnippets/codesnippetsapp.cpp'
L431..434, 548..550, 576, 582
'src/plugins/contrib/codesnippets/codesnippetstreectrl.cpp'
L855, 1775...1777, 1868..1870
'src/plugins/contrib/codesnippets/CodeSnippetsWindow.cpp'
L970, 1480..1482, 1515..1540
'src/plugins/contrib/codesnippets/editor/DragScrollCfg_H.cpp'
L26....128
'src/plugins/contrib/codesnippets/SettingsDlg.cpp'
L58
'src/plugins/contrib/codesnippets/SettingsDlgForm.cpp'
L32....121
'src/plugins/contrib/codesnippets/SnippetPropertyform.cpp'
L54....86
'src/plugins/contrib/codesnippets/SnippetPropertyform.h'
L73
'src/plugins/contrib/dragscroll/dragscrollcfg.cpp'
L15....127
'src/plugins/contrib/keybinder/cbkeybinder.cpp'
L351, 518, 563, 624..628, 736
'src/plugins/contrib/keybinder/keybinder.cpp'
L1941....1987, 2002.....2072, 2768..2778
'src/plugins/contrib/keybinder/keybinder.h'
L1342, 1351
Since svn9128 if that helps.Does it mean that 9128 is bad and 9127 is good?
I found some possible improvements:I saw that the attached file is not a patch. Can you try to provide a patch, please? Its very simple! just checkout the sources, then change the lines as needed and then issue the following command in the root folder of your svn-controlled working copy of C::B:
it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
The files without target, what to do ?What exactly do you mean by that?
Add -ansi to all projects that fail.I am not on my computer right now, but attached is an easy commit for someone.
I have occasionally observed this under Linux. It is most likely something to do with smart tab jump, but I have not yet had time to see if I can figure out what.it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
I just committed a similar patch to all linux project-files (wx2.8 and 2.9).Add -ansi to all projects that fail.I am not on my computer right now, but attached is an easy commit for someone.
The green highlight colour occurs immediately if "Brace completion" is on and I type the left parenthesis (round bracket, neither square nor curly bracket). It highlights the right parenthesis and if I type a doublequote, it also highlights the right quote and all characters I type between it and the right parenthesis.I have occasionally observed this under Linux. It is most likely something to do with smart tab jump, but I have not yet had time to see if I can figure out what.it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
Yes, 9128 is the first revision where I have found out this issue by accident. I don't remember such issue before.Since svn9128 if that helps.Does it mean that 9128 is bad and 9127 is good?
Or is 9128 the first revision where you recognized the issue ? If yes which was the last good one (if you still know) ?
Or is 9128 the last good revision you know and a later one is bad ?
it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
To reproduce:
- "Brace completion" checked in the settings.
- In the editor type printf( followed by ".
- You get printf("|") (the pipe-symbol is the caret's place).
- The right quote and the right parenthesis are green highlighted.
- Type another " .
- Now you get printf(""|) .
- All characters you type now are also green highlighted until you type (e.g.) another quote or a right parenthesis
I found some possible improvements:Thanks for the contribution, as some devs said before, we need patch files.
1- FILES WITHOUT TARGETSI think this is by design, E.g. some code snippet cause our Parser hang. To debug this kind of issue, we use a CCTest project, and you just simply copy the code snippet to "test.h", and let the CCTest app to parse it. Now, if "test.h" cause Parser hang issue, then we even can't open CCTest correctly.
'CC Test' : 'src\plugins\codecompletion\'
- 'cctest\test.h'
If the file is not existent in SVN, do:Files without targets are either an oversight or a desire for the author ?
svn add the_file
namespace a {
namespace b {
};
};
using namespace b;
namespace a {
namespace b {
};
};
namespace a {
namespace b {
};
using namespace b;
}
namespace a {
namespace b {
}
using namespace b;
}
#include <iostream>
namespace a
{
int i = 0;
namespace b
{
int i = 0;
}
}
int main()
{
std::cout << "a::i = " << a::i << '\n';
a::i++;
std::cout << "a::i = " << a::i << '\n';
std::cout << "a::b::i = " << a::b::i << '\n';
a::b::i++;
std::cout << "a::b::i = " << a::b::i << '\n';
return 0;
}
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ? ;)
("") << ("") << ("")
I was not clear enough, that's what I wanted to say:I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ? ;)
Update: Issue remains with svn9161. To reproduce it, typeCode, go to the most right bracket pair and use your left arrow to move towards the first pair. See how the right double quotes get highlighted all together.("") << ("") << ("")
(http://i40.tinypic.com/ekjipl.png)
svn r9078seems to beis the first bad revision ("* SDK: major update to core component wxScintilla: Pumped underlying scintilla to v3.3.1").
Hello ToApolytoXaos
Thankyou for your tip.
To be honest I don't uses namespaces for functional reasons but for a better display in the C::B symbol-browser. Unfortunatly all classes wil be displayed on top level even if they are child-classes of other classes. Only nested namespaces where displayed nested in the past. Thus I put around every class a namespace and and put a using-line at the end of the associated header. You are absolutly right, if you say that this is a very confusing behaviour. But is there an other posibility to avoid long lists in the symbol-browser?
I would expect that only parentless classes or classes where the parents are not defined in project-sources would be displayed on toplevel. I would expect child classes under there parents. Alternativly an user specified folder-system (like they have implemented in Dev-C++) would be nice that gives the user the posibility to sort all ellements in the symbol-browser acording to his own wishes. This would be extreemly helpfull in c projects where in C::B all functions of a project are displayed in a long list as well as all variables all preprocessor-definitions all...
Best regards,
Eckard Klotz.
(http://i40.tinypic.com/ekjipl.png)Well sorry to say that, but not for me. Here it works as expected - at least on Windows (see attached image).
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.(http://i40.tinypic.com/ekjipl.png)Well sorry to say that, but not for me. Here it works as expected - at least on Windows.
I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.(http://i40.tinypic.com/ekjipl.png)Well sorry to say that, but not for me. Here it works as expected - at least on Windows.
I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
Obviously I'm doing something wrong ( lol )
It would show a namespace and when I double click it, instead of taking me to the actual namespace, it sends me on the first line of source file.
None of these options seems to have any effect on undocked toolbars.This is good, because the fit/optiomize commands are only for docked toolbars:)
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.(http://i40.tinypic.com/ekjipl.png)Well sorry to say that, but not for me. Here it works as expected - at least on Windows.
I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
The issue does not occur on windows.
I will look into it, later.
Sorry, but I will disappoint you now. I am on Windows at work with svn-9138 and the issue remains the same.
(http://i39.tinypic.com/eo8wp.png)
Ditto . It's pretty annoying...If that is already annoying for you, I hope you will never come in touch with real problems in your life.
Thank you jens. It seems the issue kind of got solved. Another issue exists now.
Take a look at the standard coding I use to produce the issue:
() << () << (). As soon as I start moving from far left to right and reach the first << my first pair of parentheses highlight its right one. As you move along, the same repeat itself.
()| << () << () << ()
-------^ /* this is the blinking cursor supposedly */
Something is broken. It should do it just once.
When I try to run 'codeblocks.exe -v -d --log-to-file=somefile --debug-log-to-file=somefile', I get "Unexpected characters following option 'log-to-file'". I tried many variations in place of 'somefile' and even the files that already exist but no luck. Can you give a simple example with a name for the file pls.
My default.conf is here though, http://pastebin.com/6mBgKUmP (http://pastebin.com/6mBgKUmP)
codeblocks.exe -v -d --log-to-file --debug-log-to-file
Added compiler "TDM GCC Compiler 32-bit"
Added compiler "TDM GCC Compiler 64-bit"
Master path of compiler ID "tdm_gcc_compiler_32-bit" is empty -> triggers auto-detection.
Master path of compiler ID "tdm_gcc_compiler_64-bit" is empty -> triggers auto-detection.
There is something wrong with the 'bin' field of 'global variables'. When I enter some variable there, it doesn't change when the 'current variable' changed. Also it cannot be saved.Should be fixed in trunk (svn r9206).
Win7 x64, rev9158
Thanks, Jens, this bug was introduced by me several months ago (when I introduce the "bin" field). :-[There is something wrong with the 'bin' field of 'global variables'. When I enter some variable there, it doesn't change when the 'current variable' changed. Also it cannot be saved.Should be fixed in trunk (svn r9206).
Win7 x64, rev9158
Thanks for reporting this !
Hello guys, I'm back from long absence. Just catched another crash here:This should be fixed in trunk (svn r9214).
I tried to use file search in C::B to find broken files on a flash drive (they're filled with 1111111111s). I'm not really sure this is a right way to use IDE :) , but still, I have to report it. So: after using parameters provided on attached screenshot, CB hangs (possibly working, full CPU utilization for a few seconds, then 0%). Then abort/retry/ignore dialog pops out. When I try "abort" or "retry", unknown exception rises and CB terminates. My environment and CB version are visible at the screenshot.
#!/bin/bash
cd ~/sourcesCB
svn checkout http://svn.code.sf.net/p/codeblocks/code/trunk .
./bootstrap
./configure --with-contrib-plugins=all
make
sudo make install
folco@debian:~$ buildCB.sh
U src/sdk/wxscintilla/src/scintilla/src/AutoComplete.cxx
U src/src/find_replace.cpp
Fetching external item into 'src/plugins/contrib/FortranProject'
Checked out external at revision 45.
Checked out revision 9215.
Using 'svn --xml info' to get the revision
Found revision: '9215' '2013-07-21 16:23:04'
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
./bootstrap: 70: aclocal: not found
/home/folco/bin/buildCB.sh: line 8: ./configure: No such file or directory
make: *** No targets specified and no makefile found. Stop.
Looks like you are missing the automake package or it is broken.Quote[...]
./bootstrap: 70: aclocal: not found
I have noticed a couple of issues with svn9232 on my Windows XP PC and I would like to ask if anyone else has noticed the same behavior.I encountered the hang problem from time to time, but it is hard to reproduce. Do you have steps to reproduce this bug?
When I attempt to open a recently opened project, the entire IDE freezes and I suspect it has something to do with the parser. It runs on the background as soon as you load the project, am I right? Please do by all means correct me if I'm wrong!
Also, another issue is that when the IDE crashes, it does not produce any report file as it used to, at least on Windows XP.It should be "codeblocks.RPT" in the same folder of codeblocks.exe.
I encountered the hang problem from time to time, but it is hard to reproduce. Do you have steps to reproduce this bug?As you have stated yourself, it hangs from time to time, but I have noticed that it usually hangs when I start Code::Blocks for the first time while attempting to load a recent project.
It should be "codeblocks.RPT" in the same folder of codeblocks.exe.
"from time to time" is relative :P My CB hangs every time when I start it up and try to close one of my opened projects..Speed for sure is totally irrelevant, because the issue *could* be probably the focus from Projects' Workspace while switching to editor. I can see the highlighting line getting disappeared and then the toolbar menus become white as a crashing indicator.
This happens while code completion is parsing stuff.. and that needs a few seconds. When I wait for them, it won't hang.
So with a high speed PC (SSD, fast CPU), it's very unlikely to get CB to hang^^
The only way to fix it seems for me to improve the multi threading stuff.. better locks and more checks for the project existence.. or better... add a reference count to things like projects so that they can be removed from within codeblocks but some plugins may still use them until they remove their reference and it gets deleted^^That could be a solution, but for now I lack the knowledge about threads and I cannot take place, nor can I answer to something like that.
@ToApolytoXaosI have been doing so for the past 7 years, therefore I think I have it covered ;) Thanks for your suggestions though.
when you are self compiling CB and using Windows... make sure you are compiling exchndl.dll as well... or get a copy and put it into CB root.
@ToApolytoXaos@White-Tiger: You have raised an interesting point here mate. I remember exchndl.dll being copied into output from devel folder with execution of update.bat file, but as it seems such thing is not happening anymore.
when you are self compiling CB and using Windows... make sure you are compiling exchndl.dll as well... or get a copy and put it into CB root.
Sorry, but I will disappoint you now. I am on Windows at work with svn-9138 and the issue remains the same.It seems this issue still exists with array brackets this time. If you create an array, but without a type, right bracket remains highlighted for some reason waiting for a matching left bracket arr[] and if you try to create another array next to it barr[], as you move the line it matches the right bracket only.
(http://i39.tinypic.com/eo8wp.png)
Is it an issue or a normal behavior when a variable type is missing?It is *supposed* to be a feature; the highlight represents the location your cursor will jump to if you press tab.
I get a "Mixed Line Endings" popup balloon window; I haven't touched anything in my line endings.The files you've opened have both windows and linux line endings in them. This is just a warning.
Too many freaking warnings while compiling the project :(Search the forum for the proper -fno- blabla option to disable them. Probably you can fine them in the topics for mingw 4.8 or tdm 4.8.
The files you've opened have both windows and linux line endings in them. This is just a warning.OK, but the files have been created under Debian as I have been doing for ages and never had any similar issue. Oh well...
Search the forum for the proper -fno- blabla option to disable them. Probably you can fine them in the topics for mingw 4.8 or tdm 4.8.I have done so with wxMSW compilation procedure and still would get warning messages periodically; with C::B workspace though, where shall I add the specific flag to disable all these warnings?
It might be best to add the flags to the global variable cb_release_type.It seems your way is indeed very convenient next to -g. Thank you both @stahta01 and @Alpha; currently compiling it and I hope it will finish sooner than 300 minutes without my interruption LOL!
my CB build currently has "-w" set :P It just took ages otherwise.... (and as I'm not a CB dev, and not gonna fix ya bugs, I don't care about warnings :P)I think my build has a few more flags than yours ;)
You're on Linux right? Well.. in my Windoze machine it takes 20-40 minutes to compile CB and it's contrib items.
If I had warnings enabled, it would take more then 3 hours because of that warning spam I get... (and the fact that Windoze is slow as hell... especially in terms of console output^^)
As I'm always using the latest GCC, I was probably one of the first ones who have seen all these numerous warnings. It all started with GCC 4.8.. before that, the warnings were few and not really important. (I don't know how much impact they had...)
Anyway.. none the less it would be nice to see you guys not ignoring these warnings and instead fixing them ;) Actually they all have their reasons and it's way easier once you've got rid of them. As then, every warning will be a single one caused by recent changes and is easy to see and fix.