Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on June 16, 2013, 08:19:28 pm

Title: The 16 June 2013 build (9158) is out.
Post by: killerbot on June 16, 2013, 08:19:28 pm
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.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_gcc471-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_gcc471-TDM.7z
And the exception handler dll (for better crash reports) : http://prdownload.berlios.de/codeblocks/exchndl_gcc471-TDM.7z

The 16 June 2013 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20130616_rev9158_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 16, 2013, 10:47:35 pm
As there are no linux related changes in svn (except 64 bit project-files, not used by automake bukd-system), I decided not to upload new packages.
Actual packages on my server are (still) svn r9156 :

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 16, 2013, 11:30:18 pm
The CC Test issue remains the same; it does not compile and continues to complain about http://forums.codeblocks.org/index.php/topic,18011.msg123242.html#msg123242 (http://forums.codeblocks.org/index.php/topic,18011.msg123242.html#msg123242).

Is there anything I could do about it? Oh I forgot to mention; the error is reported within Code::Blocks. I haven't tried to compile it with make.

P.S.: Unrelated to bug, related to development: How outdated SDK documentation is in BerliOS? I want to understand how Code::Blocks currently works. Something is causing my IDE to randomly crash under Debian and it's really annoying...too outrageous when you are in the middle of coding!
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 17, 2013, 02:05:02 am
ToApolytoXaos: Try to disable CC for a while and tell us if the crashes are still there...
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ollydbg on June 17, 2013, 08:22:02 am
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:
1, try to build and debug C::B.
2, try to read the source code.
3, ask any questions here.

The most important thing is: C::B core can generate many events (like cbEvent or scintilla event), then the any C::B plugins can receive those event and do any thing they can in the event handler. ;)

Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 17, 2013, 01:16:47 pm
ToApolytoXaos: Try to disable CC for a while and tell us if the crashes are still there...

The problem is much more generic than I thought so...it affects other plugins as well. I have successfully compiled CodeBlocks-unix.cbp, but upon compiling ContribPlugins-unix.workspace as a whole, it would fail. After doing so, I have decided to compile each plugin separately. So far, It has stopped on wxSmith (Unix) and now on wxSmith - Contrib Items (Unix).

I will continue with every plugin and would let you know for sure.

UPDATE: I'm afraid it's almost the entire ContribPlugins-unix.workspace with certain plugins as minor exceptions. Can someone provide feedback if he or she deals the same issue?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: White-Tiger on June 17, 2013, 06:23:42 pm
looks like you'll have to recompile Code::Blocks ToApolytoXaos
Deleting the .gch files should work as well... (src\.objs\include)

At least that's what you'll have to do once the sdk changes. (or your compiler)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 17, 2013, 07:36:01 pm
@White-Tiger: that would not help; my repository is freshly checked out.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: golgepapaz on June 17, 2013, 09:20:27 pm
 I have the same problem . C::B with contrib plugins compile fine with make
but gives compile error when building plugins from C::B itself.(linux mint 15)
in prep.h
Code: [Select]
    const bool linux   = (id == platform_linux);
"linux" is probably defined as a preprocessor token and hence the error.
I also vaguely remember some talk about this but can't remember where it was
now. I am not linux savvy enough to pinpoint the problem but this should be
sorted out.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 18, 2013, 01:17:08 am
Add -ansi to all projects that fail.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 18, 2013, 01:31:02 am
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 18, 2013, 02:22:16 am
What green highlight? Screenshots please!
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 18, 2013, 02:26:36 am
Here you go:

http://pasteboard.co/qFM5yrH.png (http://pasteboard.co/qFM5yrH.png)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 18, 2013, 06:40:06 am
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 ?  ;)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 18, 2013, 12:33:45 pm
Since svn9128 if that helps.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: LETARTARE on June 18, 2013, 05:41:30 pm
I found some possible improvements:
Quote
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

copy the attached file.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 18, 2013, 06:57:08 pm
Please post patches at the project page in berlios.de.

http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 18, 2013, 07:39:05 pm
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 ?

For the build issue (prep.h etc.), I also see it when using the C::B workspace-file on linux.

I will look into it.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: MortenMacFly on June 18, 2013, 08:09:55 pm
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:
svn diff > translation_issues.patch
(Assuming that you have the svn command line tools installed, if not, please do so before and point to the svn executable.)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: MortenMacFly on June 18, 2013, 08:12:21 pm
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...?!
Title: Re: The 16 June 2013 build (9158) is out.
Post by: LETARTARE on June 18, 2013, 08:22:29 pm
@MortenMacFly
thank you.
yes indeed I know, but for extensions, I thought he had the agreement of the author.
The files without target, what to do ?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: MortenMacFly on June 18, 2013, 08:48:28 pm
The files without target, what to do ?
What exactly do you mean by that?

If the file is not existent in SVN, do:
svn add the_file
before the svn diff command.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Alpha on June 18, 2013, 08:50:02 pm
Add -ansi to all projects that fail.
I am not on my computer right now, but attached is an easy commit for someone.

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 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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 18, 2013, 10:11:15 pm
Add -ansi to all projects that fail.
I am not on my computer right now, but attached is an easy commit for someone.
I just committed a similar patch to all linux project-files (wx2.8 and 2.9).
I hope it fixes the build issue not only for me.

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 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.
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.
To reproduce:
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 18, 2013, 10:37:35 pm
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 ?
Yes, 9128 is the first revision where I have found out this issue by accident. I don't remember such issue before.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 18, 2013, 10:38:34 pm
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...?!

On Debian testing with latest updates MortenMacFly.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 18, 2013, 11:56:20 pm
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

Actually, to reproduce it, try to use printf() as you have shown on third point, but instead of typing another double quote, use your right arrow to move your cursor next to right quote, add a comma to add your variable parameter and see the green highlight persisting to continue.

NOTE: You can try the same with std::cout << ("") and as soon as you use right arrow and enter comma next to double quote, it does exactly the same.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 19, 2013, 12:38:33 am
svn r9078 seems to be the first bad revision ("* SDK: major update to core component wxScintilla: Pumped underlying scintilla to v3.3.1").
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 19, 2013, 12:52:19 am
OK, the svn9161 that I have currently compiled produces the same issue.

When you run the updates, can you please tell me which plugin or part of project should I compile within C::B, so I could save a bit of CPU cycles and unnecessary energy?

Another thing is that when I run C::B within terminal without & at its end, I can see how parser works and works pretty fast, actually faster than loading the IDE from "run" command and use it accordingly. Usually with the latter option, most of the times parser would hang and force me to reparse the entire project which is a bit of annoying.

Is there a reason for such behavior?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ollydbg on June 19, 2013, 04:28:45 am
I found some possible improvements:
Thanks for the contribution, as some devs said before, we need patch files.


Quote
1- FILES WITHOUT TARGETS

   'CC Test' : 'src\plugins\codecompletion\'
      - 'cctest\test.h'
I 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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: LETARTARE on June 19, 2013, 09:16:42 am
@mortenmaclfy
Quote
If the file is not existent in SVN, do:
svn add the_file
Files without targets are either an oversight or a desire for the author ?
Should we add them (but what target?) Or remove it?
A developer knows better than me.

@ollydbg
thank you for this last explanation, I discovered.

For other changes I'll try to do several patchs.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: eckard_klotz on June 20, 2013, 03:15:01 pm
Hello Everybody.

Since the last 2 nightlys I recognize a change how namespaces are displayed in the symbol browser.

If I have the following source-example:
Code: [Select]
namespace a {
namespace b {
};
};

using namespace b;

The namespace b will be displayed on toplevel what not happens in this example:
Code: [Select]
namespace a {
namespace b {
};
};


In both examples the namespace b will displayed as child of namespace a also. It seems that using namespace will be analysed like a lonly namespace if it is placed after the closing } of namespace a. This happens not if it is placed after the closing } of namespace b like here:
Code: [Select]
namespace a {
namespace b {

};

using namespace b;

}


Is this the wanted behaviour?

I use the official nightlies on Windows XP SP3 and this behaviour occures since 9156.

BestRegards,
                 Eckard Klotz.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 20, 2013, 04:24:26 pm
First of all, you don't need semicolon at the end of namespace.

I would suggest to avoid doing something like
Code: [Select]
namespace a {
    namespace b {
    }
    using namespace b;
}

because, with this way, if you have declared variables or classes that use the same name to both namespaces, the using directive will hide the outer namespace's names, thus causing nightmares detecting what the hell is going on with your code.

Here's what I have tested myself and works just fine.

Code: [Select]
#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;
}

Please note that I explicitly use using::declaration rather than using-directive for the reasons I have stated above.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 20, 2013, 04:39:14 pm
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, type
Code: [Select]
("") << ("") << (""), 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)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: eckard_klotz on June 20, 2013, 05:30:36 pm
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. 
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 20, 2013, 05:38:15 pm
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, type
Code: [Select]
("") << ("") << (""), 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)
I was not clear enough, that's what I wanted to say:
svn r9078 seems to be is the first bad revision ("* SDK: major update to core component wxScintilla: Pumped underlying scintilla to v3.3.1").

I did a bisecting, so I'm sure it starts with this revision !
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 20, 2013, 06:19:42 pm
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. 

Can you please Eckard provide an example with your issue? I would like to test it on my system.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 20, 2013, 06:27:09 pm
@jens: That makes things much clearer now :) thanks.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: MortenMacFly on June 21, 2013, 06:59:30 am
(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 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...?!
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 21, 2013, 07:02:04 am
(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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 21, 2013, 10:20:34 am
(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.

The issue does not occur on windows.
I will look into it, later.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 21, 2013, 02:59:56 pm
eckard, I have downloaded the source files you have posted here and try to compile them. Obviously I'm doing something wrong ( lol ), but that's not the point.

I have created a new C::B project and imported your code and saw what you said about namespaces and classes. I hope I'm wrong, but seriously something's going on with Symbols' mechanism. 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.

@devs: Which project should I look for Symbols? Is it part of SDK or as a plugin?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: eckard_klotz on June 21, 2013, 03:43:20 pm
Hello ToApolytoXaos.

Quote
Obviously I'm doing something wrong ( lol )

Sory I didn't mention that you have to use some preprocessor defines for the project to compile it. They are described in the readme. But especially for those things I planed to post my C::B project files in the future also. Furthermore you need the current boost-library (1.53) also since I use the spirit parser from it.

Quote
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.

Sory again, I did forget to mention this also. So let confirm me that also. Furthermore you will se that I use the namespace boost in the file prs_tpdef.h. But even I don't define this namespace somewhere else  (this will bedone in the spirit files wich are not part of my project) it is shown in the symbol browser.

Best regards,
                  Eckard.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 21, 2013, 04:34:34 pm
@MortenMacFly: Why "rename symbols" does not always work? It has a very peculiar behavior. "Symbol not found under cursor!" and other times it would let me rename my desired symbols.

It's one of those WTF moments...:D honestly!
Title: Re: The 16 June 2013 build (9158) is out.
Post by: carra on June 27, 2013, 09:57:06 am
I have found a couple of bugs in the toolbar docking system, let's see if you can reproduce this:

BUG 1: reappearing toolbars
---------------------------
- make a fresh install under Windows (removing previous default.conf)
- undock one (or more) toolbars, and close them clicking on their close button
- undock another toolbar, and the ones you closed before reappear again (undocked and apparently in their same position as before being closed)

BUG 2: docking beyond window width
--------------------------------------
- Close all toolbars but code completion, main and compiler
  (use the menu so that they won't reappear)
- Undock main and compiler toolbars, leave code completion at the left
- Redock both toolbars. Even if you try to place them under code completion toolbar, they are always added at its right. With my current window width (non fullscreen), I can't even see the rightmost toolbar.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 27, 2013, 01:00:57 pm
Can't reproduce both problems on Linux.

What happens if you use View -> Toolbars -> Fit toolbars or View -> Toolbars -> Optimize ?
What windows are you using?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: carra on June 27, 2013, 02:14:22 pm
I'm now on Windows XP, I'll try it under Vista later.

Fit Toolbars and Optimize Toolbars seem to work reasonably well. There were a couple of times when a toolbar had a small part of it outside the window width, but I can't find a sure way to reproduce it. I wouldn't worry too much about that though.

None of these options seems to have any effect on undocked toolbars.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 27, 2013, 02:20:25 pm
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:)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: carra on June 27, 2013, 02:22:32 pm
Lol! I meant that after using them the undocked bars bugs kept happening just the same ;)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on June 27, 2013, 02:30:59 pm
Unfortunately someone running windows should try to see if he/she can reproduce it and then debug it.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on June 28, 2013, 07:11:48 am
(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.

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)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: golgepapaz on June 28, 2013, 10:27:55 am
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...
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on June 28, 2013, 08:15:57 pm
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on July 01, 2013, 08:31:04 am
This is getting really interesting...the issue (with bracket-matching highlighting) remains the same on both Debian jessie and windows.

(http://i44.tinypic.com/2mhynuh.png)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on July 02, 2013, 06:46:25 pm
The issue should be fixed in trunk (svn r9171).
The cause was an incorrect use of IndicatorClearRange in void cbStyledTextCtrl::HighlightRightBrace().

IndicatorClearRange takes a position as first and a length as second parameter, but a position was given for both.
If position + length is greater than the documents length the indicators will not be cleared.
This behaviour has changed with the revision of scintilla we use since our svn r9078.
Older scintilla has cleared the indicators anyway.

That's why it happened since this commit.

Can you please test and give feedback.

By the way one of the green indicators is okay and used by the so called SmartTabJump-feature.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on July 02, 2013, 09:33:43 pm
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 */
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on July 04, 2013, 06:21:13 am
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 */


Is the highlight colour the normal colour used for matching parenthesis or the colour we had before (a little more "greener").

What happens if you hit the tab-key in this situation ?

If it jumps to he right, it's the so called SmartTabJumping (http://forums.codeblocks.org/index.php/topic,12406.msg84207.html#msg84207 (http://forums.codeblocks.org/index.php/topic,12406.msg84207.html#msg84207)).

I don't know how it should behave exactly.
I think the "feature" itself and its highlight-colour should be configurable.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: zetab on July 05, 2013, 07:03:57 pm
The combobox on Incremental Search toolbar looks strange, is this normal?

(http://i.imgur.com/EqMZ48E.png) (http://imgur.com/EqMZ48E)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: scarphin on July 05, 2013, 07:27:54 pm
Is there a way to disable compiler checking before loading? CB brings up a list of detected compilers dialog every time before starting. That didn't exist before.

Win7 x64, rev 9158
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on July 05, 2013, 08:36:10 pm
Something is broken. It should do it just once.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: stahta01 on July 05, 2013, 10:26:41 pm
Something is broken. It should do it just once.

That is the way it used to work; I put dummy paths like C:\ in the ones I did NOT have installed.

Tim S.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Alpha on July 05, 2013, 10:47:55 pm
It should only show up on first launch, and once more each time the compiler plugin has a major change.

It is possible Code::Blocks is crashing on exit, so it fails to save its configuration file, which would cause it to believe every launch is the first launch.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: scarphin on July 06, 2013, 12:31:13 am
Shouldn't I be warned about the crash somehow by Windows? Also there is no crash report (whatever its name was) file in cb folder. Can it be related to the changing of advanced compiler settings somehow? One of the latest nightlies asked me to save the new default advanced compiler settings and I believe I said 'no'.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: scarphin on July 09, 2013, 12:15:22 am
I think it's the compiler plugin mulfunctioning. If I disable the compiler plugin cb starts up just fine. When I enable it again it looks for compilers and does that every time I start cb. What may be the problem and the solution?

Will it work if I manually edit the config file cuz that compiler detection thing is driving me nuts?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on July 09, 2013, 12:30:04 am
Can you post the default.conf file?

Also can you try to start cb from command line and to pass parameters like:
codeblocks.exe -v -d  --log-to-file=somefile --debug-log-to-file=somefile

After the crash has happened you can post the files here.

p.s. use paste bin like service.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: scarphin on July 09, 2013, 01:47:29 am
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)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: stahta01 on July 09, 2013, 03:45:45 am
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)


Try without the filenames as in

Code: [Select]
codeblocks.exe -v -d  --log-to-file --debug-log-to-file

Then look for files called codeblocks-debug.log and codeblocks.log

Tim S.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: scarphin on July 09, 2013, 12:08:27 pm
Thnx Tim it worked. It seems the problem was me forgetting to update the 'installation directories' for the 2 tdm compilers I created.
Code: [Select]
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.

After updating the compiler paths to correct directories, cb no longer tries to detect compilers at startup but it still takes much more time to launch than launching with compiler plugin disabled. So my guess is cb still tries to detect compilers but doesn't show the detected compilers screen. 'cb-log' and 'cb-debug.log' here,
http://pastebin.com/0YnjGTAN (http://pastebin.com/0YnjGTAN)
http://pastebin.com/8jpd8Ncr (http://pastebin.com/8jpd8Ncr)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: scarphin on July 13, 2013, 05:46:05 pm
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.

Win7 x64, rev9158
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on July 13, 2013, 07:37:35 pm
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.

Win7 x64, rev9158

Should be fixed in trunk (svn r9206).
Thanks for reporting this !
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ollydbg on July 14, 2013, 06:05:24 am
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.

Win7 x64, rev9158

Should be fixed in trunk (svn r9206).
Thanks for reporting this !
Thanks, Jens, this bug was introduced by me several months ago (when I introduce the "bin" field). :-[
Title: Re: The 16 June 2013 build (9158) is out.
Post by: xawari on July 20, 2013, 08:59:30 pm
Hello guys, I'm back from long absence. Just catched another crash here:
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on July 21, 2013, 01:01:31 am
Hello guys, I'm back from long absence. Just catched another crash here:
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.
This should be fixed in trunk (svn r9214).
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Folco on July 21, 2013, 08:38:39 pm
Hi guys,

I'm on a virtualized Debian 7 x64. I try to build CB, sugin my usual script :
Code: [Select]
#!/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

bootstrap is present, but configure seems to be missing :
Code: [Select]
[email protected]:~$ 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.
Did I miss something ? Thanks in advance. :)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on July 21, 2013, 09:00:44 pm
Quote
[...]
./bootstrap: 70: aclocal: not found
Looks like you are missing the automake package or it is broken.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Folco on July 21, 2013, 09:45:43 pm
What a noob, didn't see that... But... wxwidgets 2.8.12 is needed, Debian provides only 2.8.10 on squeeze ><

Nevertheless, thank you.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: jens on July 21, 2013, 09:55:21 pm
Why do you use squeeze (oldstable) ?

You can use wxWidgets from apt.wxwidgets.org, if you don't want to (or you cannot for whatever reason) update your distro.
See http://wiki.wxpython.org/InstallingOnUbuntuOrDebian (http://wiki.wxpython.org/InstallingOnUbuntuOrDebian) for details. Packages for squeeze are available.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Folco on July 21, 2013, 10:00:14 pm
I use squeeze because I can virtualize it without any problem : https://www.virtualbox.org/wiki/Guest_OSes
I got some troubles with Wheezy, not supporting shared folder, which is a bit embarrassing...
Thanks for your link, I didn't know this page, I'll give a try tomorrow.

Thanks for your responses !
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Folco on July 22, 2013, 07:09:51 pm
Thanks Jens, it perfectly works ! :)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Yemeni Cpluspluser on August 01, 2013, 07:12:15 pm
This is my first software night-build version to download ever,  ::) I hope that I face no more auto-completion bugs.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on August 02, 2013, 08:40:14 am
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.

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.

Cheers.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ollydbg on August 02, 2013, 10:40:25 am
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.

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!
I encountered the hang problem from time to time, but it is hard to reproduce. Do you have steps to reproduce this bug?

Quote
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on August 02, 2013, 12:01:59 pm
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.

I'm afraid there is no such thing; that's why I have mentioned it here. It just shuts down without warning or whatsoever; and the funny thing is that I don't know how to reproduce it so I can check it with GDB :/
Title: Re: The 16 June 2013 build (9158) is out.
Post by: White-Tiger on August 02, 2013, 02:04:58 pm
"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..
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^^
I'm not sure if it's about badly placed locks.. that's just what my first look suggested xD It's also possible that a wxWidgets call freezes... as that's what I see. (called from code completion)

@ToApolytoXaos
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on August 02, 2013, 02:33:59 pm
"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..
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^^
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.

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.

@ToApolytoXaos
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.
I have been doing so for the past 7 years, therefore I think I have it covered ;) Thanks for your suggestions though.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on August 02, 2013, 04:53:50 pm
@ToApolytoXaos
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.
@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.

The so-called dynamic library can be seen in src/ directory and after copied it in devel and ran update.bat, it could re-copied it in output. I don't remember doing such thing in the past...Probably I have forgot such procedure if I have done it only once.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on October 28, 2013, 09:21:08 am
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)
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://i40.tinypic.com/1zx65l.png)

(http://i43.tinypic.com/1zwhd.png)

As you can see, this issue happens when you have forgotten to add an array type for some reason.

Is it an issue or a normal behavior when a variable type is missing?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Alpha on October 28, 2013, 01:40:49 pm
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on October 29, 2013, 07:40:46 pm
By the way, what's this new case with creating new files in a project?

I get a "Mixed Line Endings" popup balloon window; I haven't touched anything in my line endings.

This issue is with svn9423, GNU / Linux Debian testing (32-bit), GCC 4.8.1 fully updated.

P.S.: I have compiled wxMSW-2.8.12 with TDM's GCC 4.8.1 in just 2 hours today (very peculiar I would say...), but I could not finish with C::B compilation and I had to cancel it at 300-minute, 31-second :S

Too many freaking warnings while compiling the project :(
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on October 29, 2013, 07:50:46 pm
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on October 29, 2013, 07:54:34 pm
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?
Title: Re: The 16 June 2013 build (9158) is out.
Post by: oBFusCATed on October 29, 2013, 08:08:01 pm
Project or compiler level...
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Alpha on October 30, 2013, 01:05:44 am
It might be best to add the flags to the global variable cb_release_type.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: stahta01 on October 30, 2013, 03:02:50 am
I added the "-Wno-unused-local-typedefs" to the Compiler Global "other options".

Tim S.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: ToApolytoXaos on October 30, 2013, 07:39:30 am
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!
Title: Re: The 16 June 2013 build (9158) is out.
Post by: White-Tiger on October 30, 2013, 02:37:21 pm
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)
Title: Re: The 16 June 2013 build (9158) is out.
Post by: Alpha on October 30, 2013, 03:15:15 pm
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 ;)
-ansi -Wall -Wextra -Wmissing-include-dirs -Wunreachable-code -Winline -Wundef -Wcast-align -Wredundant-decls -Winit-self -Wshadow -Wnon-virtual-dtor -Wno-long-long -Wno-variadic-macros -Wno-unused-local-typedefs -Werror=return-type
Title: Re: The 16 June 2013 build (9158) is out.
Post by: White-Tiger on October 30, 2013, 03:40:14 pm
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.
Title: Re: The 16 June 2013 build (9158) is out.
Post by: stahta01 on October 30, 2013, 06:01:34 pm
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.

I suggest you do this at the wxWidgets team and see the results.

You do realize the cause of the warning is them or can you NOT read!

Tim S.