Author Topic: The 12 October 2014 build (9958) is out.  (Read 29768 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5234
The 12 October 2014 build (9958) is out.
« on: October 12, 2014, 06:45:36 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.

A link to the unicode windows wxWidget dll for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc481-TDM.7z

The 12 October 2014 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2014/CB_20141012_rev9958_win32.7z
  - Linux :
   none

Resolved Fixed:

  • Browse Tracker 1.2.100 2014/10/9
    Fix incorrect scintilla margin marker usage
    Better resolution of Jump line recording
    Add modifed user contrib tool bar (by sbezgodov)
  • Save notebook layout in project- and workspace-layout files (and load it from there).
  • make the check for externally modified files configurable, useful for slow network shares (default is on)
  • Check non builtin editors for file deletion and read/write-status change.
  • Mark editor tabs of readonly files with an icon
  • Add versioning to project and workspace layout files
  • removed wxWindowUpdateLocker from cbAuiNotebook::LoadPerspective(), because it's broken on windows
  • CC: fix bug when handling "##" operator in macro expansion.
  • CC: fix a bug in Tokenizer::CalcConditionExpression(), when checking whether a token is a macro usage, the length of the token should be larger then 0, not 1.

Regressions/Confirmed/Annoying/Common bugs:



    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5234
    Re: The 12 October 2014 build (9958) is out.
    « Reply #1 on: October 12, 2014, 06:57:42 pm »
    big trouble on linux :

    click somewhere in your editor => move the mouse ==> the entire content gets selected (better don't press another key) ...

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #2 on: October 12, 2014, 07:48:25 pm »
    big trouble on linux :

    click somewhere in your editor => move the mouse ==> the entire content gets selected (better don't press another key) ...
    Did you a real clean build ?
    It does not happen here.

    Offline Pecan

    • Plugin developer
    • Lives here!
    • ****
    • Posts: 2228
    Re: The 12 October 2014 build (9958) is out.
    « Reply #3 on: October 12, 2014, 08:07:25 pm »
    Does -not- happen here either.

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5234
    Re: The 12 October 2014 build (9958) is out.
    « Reply #4 on: October 12, 2014, 09:10:48 pm »
    No , just svn up and make, make install.

    Will try make clean ....

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5234
    Re: The 12 October 2014 build (9958) is out.
    « Reply #5 on: October 12, 2014, 11:01:51 pm »
    make clean did the job.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #6 on: October 13, 2014, 09:55:52 am »
    As usual:
    Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.
    Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc19, fc20, fc21 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (only 64-bit at the moment) can be found in my rpm-repo.
    Fedora and CentOS packaging ar currently uploading, but will be available soon.


    Edit:

    revision is svn r9959 (nonPCH build fix)
    « Last Edit: October 13, 2014, 01:05:19 pm by jens »

    Offline edison

    • Multiple posting newcomer
    • *
    • Posts: 53
    Re: The 12 October 2014 build (9958) is out.
    « Reply #7 on: October 13, 2014, 10:00:00 am »
    There is a yellow pop-up window(BrowseTrack) appear after click close CB, is there any way to prevent it happen?

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #8 on: October 13, 2014, 04:51:32 pm »
    Thanks for the 2 really cool new features:
    -read only icon
    -pane layout saving
    While I have no problem with the readonly icon (works perfectly), the pane layout does not get saved. Is there any extra thing to do before closing cb or anything I could report to help debugging ?
    I have 2 vertical panes of equal size. When I close then reopen codeblocks, only one pane appear covering the whole window (I mean similar to the legacy behavior).
    Here is the (shortened) layout file in question;
    Code: [Select]
    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    <CodeBlocks_layout_file>
    <FileVersion major="1" minor="0" />
    <ActiveTarget name="Release" />
    <File name="src/antenna/model/angles.cc" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="862" topLine="1" />
    </Cursor>
    </File>
    <File name="src/aodv/test/aodv-regression.cc" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="2305" topLine="36" />
    </Cursor>
    </File>
    <File name="src/internet/model/tcp-option-ts.cc" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="1450" topLine="50" />
    </Cursor>
    </File>
    <File name="src/network/utils/ipv4-address.h" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="2824" topLine="44" />
    </Cursor>
    </File>

    <File name="src/internet/model/tcp-option.h" open="0" top="0" tabpos="10" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="1070" topLine="18" />
    </Cursor>
    </File>
    <File name="src/internet/model/tcp-option-mptcp.cc" open="0" top="0" tabpos="13" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="16273" topLine="823" />
    </Cursor>
    </File>
    <File name="src/internet/test/mptcp-options-test.cc" open="0" top="0" tabpos="4" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="11176" topLine="354" />
    </Cursor>
    </File>
    <File name="src/internet/model/tcp-westwood.cc" open="0" top="0" tabpos="19" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="2056" topLine="93" />
    </Cursor>
    </File>
    <File name="src/internet/model/mp-tcp-olia.h" open="0" top="0" tabpos="11" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
    <Cursor>
    <Cursor1 position="631" topLine="21" />
    </Cursor>
    </File>
    <EditorTabsLayout layout="0603b9e0543be510003ca91a00000002=+1;mptcp:src/network/model/socket.cc,2;mptcp:src/internet/model/mp-tcp-typedefs.cc,3;mptcp:src/internet/model/mp-tcp-socket-base.cc,4;mptcp:src/internet/test/mptcp-tcp-test.cc,5;mptcp:src/internet/model/tcp-socket-base.cc,6;mptcp:src/internet/model/mp-tcp-subflow.cc,7;mptcp:src/internet/model/tcp-socket-base.h,8;mptcp:src/internet/model/mp-tcp-socket-base.h,9;mptcp:src/internet/model/mp-tcp-subflow.h|014abe00543be54900c5426400000003=*0;mptcp:src/internet/model/[email protected]|name=dummy;caption=;state=2098174;dir=3;layer=0;row=0;pos=0;prop=100000;bestw=180;besth=180;minw=180;minh=180;maxw=-1;maxh=-1;floatx=-1;floaty=-1;floatw=-1;floath=-1|name=0603b9e0543be510003ca91a00000002;caption=;state=2098172;dir=5;layer=0;row=0;pos=0;prop=100000;bestw=200;besth=200;minw=-1;minh=-1;maxw=-1;maxh=-1;floatx=-1;floaty=-1;floatw=-1;floath=-1|name=014abe00543be54900c5426400000003;caption=;state=2098172;dir=2;layer=0;row=1;pos=0;prop=100000;bestw=839;besth=385;minw=-1;minh=-1;maxw=-1;maxh=-1;floatx=-1;floaty=-1;floatw=-1;floath=-1|dock_size(5,0,0)=20|dock_size(2,0,1)=841|" />
    </CodeBlocks_layout_file>


    EDIT: I use the packages from jens on ubuntu.
    « Last Edit: October 13, 2014, 05:10:18 pm by teto »

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #9 on: October 13, 2014, 05:09:19 pm »
    2 really cool new features in this release:
    -read only icon
    -pane layout saving
    While I have no problem with the readonly icon (works perfectly), the pane layout does not get saved. Is there any extra thing to do before closing cb or anything I could report to help debugging ?
    I have 2 vertical panes of equal size. When I close then reopen codeblocks, only one pane appear covering the whole window (I mean similar to the legacy behavior).
    Here is the (shortened) layout file in question;
    [ .... ]
    Did you try to delete the layout file (before opening the project) or move it away and recreate it, or can you provide the whole project (or a minimal project where this appears) and send it to me via mail ?
    jens at codeblocks dot org

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #10 on: October 13, 2014, 05:34:46 pm »
    In fact if I close a project and reopen it afterwards, it loads with
    the correct/saved pane layout (=the feature works).
    The problem appears when I close codeblocks and reopen it: whatever
    the project I only get one pane.
    I've sent you a test project via mail.

    At first I thought browseTracker was rewriting the layout to save
    points so I disabled all plugins but it didn't change anything.

    EDIT: I tried removing the layout, no change whatsoever

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #11 on: October 13, 2014, 05:38:21 pm »
    One more precision I just found out: if I close the project before closing codeblocks, reopen codeblocks and reopen the project then the feature works. In fact it fails to work only when the project remains open when I close codeblocks. Maybe this is due to my codeblocks config.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #12 on: October 13, 2014, 08:52:45 pm »
    One more precision I just found out: if I close the project before closing codeblocks, reopen codeblocks and reopen the project then the feature works. In fact it fails to work only when the project remains open when I close codeblocks. Maybe this is due to my codeblocks config.
    Just a shot in the dark:
    Did you ever save the default workspace ?
    Or dp you have "Settings -> Environment -> General settings -> On application start-up -> Open default workspace" set ?
    If yes can you set it to "Open blank workspace" and try it again ?


    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12597
      • Travis build status
    Re: The 12 October 2014 build (9958) is out.
    « Reply #13 on: October 13, 2014, 09:03:18 pm »
    What OS are you using?
    Are you able to close codeblocks without a crash?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #14 on: October 14, 2014, 01:39:53 am »
    One more precision I just found out: if I close the project before closing codeblocks, reopen codeblocks and reopen the project then the feature works. In fact it fails to work only when the project remains open when I close codeblocks. Maybe this is due to my codeblocks config.
    Just a shot in the dark:
    Did you ever save the default workspace ?
    Or dp you have "Settings -> Environment -> General settings -> On application start-up -> Open default workspace" set ?
    If yes can you set it to "Open blank workspace" and try it again ?


    If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 12 October 2014 build (9958) is out.
    « Reply #15 on: October 14, 2014, 05:23:07 am »
    click somewhere in your editor => move the mouse ==> the entire content gets selected (better don't press another key) ...
    Hmm... now I am experiencing this, except it only occurs when the mouse hovers on a spot (calls tool tip).  Executed clean, then build from within C::B (Ubuntu).

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #16 on: October 14, 2014, 06:20:52 am »
    I still don't get this on the C::B 9959 from my repo.
    Can you check the dependencies with "ldd" ?
    Do you have older C::B revisions on your system that might interfere ?

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 159
    Re: The 12 October 2014 build (9958) is out.
    « Reply #17 on: October 14, 2014, 08:13:06 am »
    Hello Everybody.

    Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
    http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571( Re: The 16 June 2013 build (9158) is out. « Reply #31 on: June 20, 2013, 03:15:01 pm » please scroll up since the link does not show the first post) . Since we decided to move some parts of the discussion you will find some parts at http://forums.codeblocks.org/index.php/topic,18081.msg125445.html#msg125445 ( Moritz plugin « on: June 21, 2013, 08:20:45 am »)

    The effect is that namespaces nested in other namespaces will be shown parallel to their parent namespaces in the symbol-browser. Furthermore if you click on them in them, just the defining headerfile will be opened but without showing the line where the namspace will beopened. To reproduce this effect please download The files:

    This archives contain a C::B project and the sources for the associated binary. Please open the projects with the last 3 nightlies
    • September the 16th 2014 -> nested namespaces are shown only as child of their parents
    • October the 11th 2014-> nested namespaces are shown as child of their parents as well as independend namspace
    • October the 12th 2041-> nested namespaces are shown as child of their parents as well as independend namspace

    Since their is still no posibility to add virtual folders in the symbol browser like you can do in the project browser I use namespaces to have a more structed view. Without this the symbol browser is not realy helpfull for greater projects. Thus I hope that the effect I described above is only a bug and no feature.

    The environment where I observed this effect is a sony-laptop (VAIO) with Windows 8.1. First tests on WinXP didn't show this effect But I did this check with an other project. Furthermore I try to do the same with Windows 7.

    Best regards,
                       Eckard Klotz.




    « Last Edit: October 14, 2014, 09:19:07 am by eckard_klotz »

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #18 on: October 14, 2014, 09:36:47 am »
    @Obfuscated> I use jens repository on Ubuntu and codeblocks does not crash.

    I indeed use the option " Open default workspace". If I disable this option, then I have to manually reopen the project and then codeblocks correctly restores my layout.

    Quote
    If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..
    I think it is. Cool ! I am eager to try the next nightly.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #19 on: October 14, 2014, 09:52:45 am »
    @Obfuscated> I use jens repository on Ubuntu and codeblocks does not crash.

    I indeed use the option " Open default workspace". If I disable this option, then I have to manually reopen the project and then codeblocks correctly restores my layout.

    Quote
    If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..
    I think it is. Cool ! I am eager to try the next nightly.
    A new build of my debian packages should be available this afternoon.
    I try to build and upload the Fedora/CenTOS packages als, but I can not do this on my server (runs under debian), so I have to upload more than 500 MB and I don't know if I find the time to do so, because I will most likely not have (fast) internet access from tomorrow on for the next ten to ? days (I will be in hospital with my daughter).
    And compiling all packages takes some hours.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 12 October 2014 build (9958) is out.
    « Reply #20 on: October 14, 2014, 10:02:36 am »
    Hello Everybody.

    Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
    http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571( Re: The 16 June 2013 build (9158) is out. Reply #31 on: June 20, 2013, 03:15:01 pm please scroll up since the link does not show the first post) . Since we decided to move some parts of the discussion you will find some parts at http://forums.codeblocks.org/index.php/topic,18081.msg125445.html#msg125445 ( Moritz plugin on: June 21, 2013, 08:20:45 am )

    The effect is that namespaces nested in other namespaces will be shown parallel to their parent namespaces in the symbol-browser. Furthermore if you click on them in them, just the defining headerfile will be opened but without showing the line where the namspace will beopened. To reproduce this effect please download The files:

    This archives contain a C::B project and the sources for the associated binary. Please open the projects with the last 3 nightlies
    • September the 16th 2014 -> nested namespaces are shown only as child of their parents
    • October the 11th 2014-> nested namespaces are shown as child of their parents as well as independend namspace
    • October the 12th 2041-> nested namespaces are shown as child of their parents as well as independend namspace

    Since their is still no posibility to add virtual folders in the symbol browser like you can do in the project browser I use namespaces to have a more structed view. Without this the symbol browser is not realy helpfull for greater projects. Thus I hope that the effect I described above is only a bug and no feature.

    The environment where I observed this effect is a sony-laptop (VAIO) with Windows 8.1. First tests on WinXP didn't show this effect But I did this check with an other project. Furthermore I try to do the same with Windows 7.

    Best regards,
                       Eckard Klotz.





    If I remember correctly, we have some patches from Huki which handle "unnamed namespaces", which may cause this issue, maybe other patches of CC. Any way, I will look into it.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 159
    Re: The 12 October 2014 build (9958) is out.
    « Reply #21 on: October 14, 2014, 02:52:01 pm »
    Hello Ollydbg.

    Thanks for your reply. I hope you are able to reproduce the effect while using my source-archives. In the meanwhile I also tested it on Win XP and Win 7 and I've got the same result as described for Win 8.1.

    Best regards,
                       Eckard.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 12 October 2014 build (9958) is out.
    « Reply #22 on: October 14, 2014, 03:18:54 pm »
    @Obfuscated> I use jens repository on Ubuntu and codeblocks does not crash.

    I indeed use the option " Open default workspace". If I disable this option, then I have to manually reopen the project and then codeblocks correctly restores my layout.

    Quote
    If it is what I think (default workspace), it should be fixed in trunk (svn r9986)..
    I think it is. Cool ! I am eager to try the next nightly.
    svn r9990 for debian and r9989 for Fedora/CentOS are available on my server.

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 12 October 2014 build (9958) is out.
    « Reply #23 on: October 14, 2014, 03:31:12 pm »
    Do you have older C::B revisions on your system that might interfere ?
    Some.. but they all should be isolated.

    I did a "scorched earth" rebuild by manually purging everything that does not come from a fresh checkout.  Seems to be working so far.

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #24 on: October 14, 2014, 03:55:59 pm »
    svn r9990 for debian and r9989 for Fedora/CentOS are available on my server.
    Works perfectly now. Thanks. I hope everything will be fine for you during the coming days.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 12 October 2014 build (9958) is out.
    « Reply #25 on: October 16, 2014, 02:57:09 pm »
    Hello Everybody.

    Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
    http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571( Re: The 16 June 2013 build (9158) is out. Reply #31 on: June 20, 2013, 03:15:01 pm please scroll up since the link does not show the first post) .
    ...
    ...
    I looked at the post: Re: The 16 June 2013 build (9158) is out.
    I have debugged a little, but I think it is the expect behavior.
    If we have this sample code:
    Code: [Select]
    namespace a {
    namespace b {
    };
    };

    using namespace b;
    There are two tokens named "b" in the TokenTree.
    One is the sub namespace under a. (the first b)
    One is in global namespace. (the second b)
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9594
    Re: The 12 October 2014 build (9958) is out.
    « Reply #26 on: October 17, 2014, 07:49:43 am »
    There are two tokens named "b" in the TokenTree.
    One is the sub namespace under a. (the first b)
    One is in global namespace. (the second b)
    Looks OK to me. Maybe the guy is missing to use:
    using namespace a::b?
    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #27 on: October 17, 2014, 01:59:52 pm »
    When replacing a string across files, the final box displays:
    "Replace in files has finished all operations."
    Iirc, codeblocks used to display the number of changes like "string replaced 8 times across 7 files". I wonder if that could be brought back. Sometimes when replacing strings, I forget to untick some boxes (ie, "Match case"), thus replacing more strings than I intended to. The display of the number of replacements used to help me realizing these errors.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 159
    Re: The 12 October 2014 build (9958) is out.
    « Reply #28 on: October 17, 2014, 02:38:01 pm »
    Hello Ollydbg and Morten

    Thanks for your evaluation of my report.

    Quote

    Quote
    There are two tokens named "b" in the TokenTree.
    One is the sub namespace under a. (the first b)
    One is in global namespace. (the second b)
    Looks OK to me. Maybe the guy is missing to use:
    using namespace a::b?

    It seems that you used my simple example from one year ago and did not downloaded the real projects. As far as I remember there was a little problem in this first example but I'm not sure anymore what it was. Thus please check my source projects provided as link also.

    In the case that my simple example was programmed in the same way as in my real projects, it seems taht it is good enough to explain my problem. In the past until the nightly fom September the 16th 2014 b was shown only one times only as  sub namespace under a. And exactly this was for me the reason why I implemented this namespaces. If you have a greater project with many classes and/or many classless functions (as in a c-project), the list shown in the symbol-browser is real huge and less helpfull to find a special source-element.
    Even child-classes are shown in root-list. Until September the last posibility to define for the symbol browser an usedefined tree structure was to use namespaces, since the definition of virtual folders like in the project browser are not available.

    How ever please check my problem by using my source-project and if you than schow me a mistake in my code as the real reason of my problem, than I will change it. But as you can see by my old posts as reaction you changed somewhat in Code::Blocks and the namespaces were shown again as in the older nightlies.

    You may now argue (for what reasons ever), that you don't want to change it any more, since this is exactly the behaviour you want. In this case it would interst me, what you have planned or already implemented to enable an reduction of viewd lists in the symbol browser for great projects. 

    Thanks and best regards,
                                        Eckard.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 12 October 2014 build (9958) is out.
    « Reply #29 on: October 17, 2014, 04:22:57 pm »
    It seems that you used my simple example from one year ago and did not downloaded the real projects.
    Yes, but I'm checking your zip files now.

    Quote
    In the case that my simple example was programmed in the same way as in my real projects, it seems that it is good enough to explain my problem. In the past until the nightly from September the 16th 2014 b was shown only one times only as  sub namespace under a.
    In your "simple example", showing a b under root(global namespace) is correct, right?
    Note that I can open your projects(cbp files), and I'm not sure what is the wrong behavior? Can you give me a screen shot of the symbol browser? Which namespace is not shown correctly? What is the expected symbol browser tree? In my testing system with the latest trunk, I don't see much issue, but sometimes, symbol browser don't show any labels, not sure this is the same issue as you complained.

    BTW: I see that there are many typos in your last post, do you enable the spell check in your web browser? Firefox in my system will display a wavy line beneath spell errors.  :)
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 159
    Re: The 12 October 2014 build (9958) is out.
    « Reply #30 on: October 19, 2014, 11:52:58 am »
    Hello Ollydbg.

    Please excuse my late reply but the Friday afternoon and Saturday are my most busy times in the week.

    First of all please excuse my bad orthography, especial if it is the core-reason, that I was not able to describe my point understandable. I know that Firefox normally offers spell checking since in my company it works and I know that this is a tool I have to use as often as possible. But for some reasons it is not working on my private Win 8 computer even it is activated. Furthermore I'm not able to use the Button Preview of this forum anymore, what I normally use to check how my post looks like. I think I have to look for some plug-in updates and to check the security adjustments. If somebody has tip for me, it will be great.

    As attachment I added the combination of 2 screen shots that contains for one project the symbol browsers of the nightlies from September the 16th and October the 12th. As you can see in the older nightly I have to open the nesting namespace to see the nested namespace ( as I like), while in the newer nightly the nested namespaces are visible on the directly under the root node together with the nesting namespaces also (as I don't like). For me the hiding of nested namespaces is a very important key feature of the old symbol browser since it gave me the only possibility to define a kind of package structure, that was respected by the symbol browser. The idea is, once I look for a special source element, I normally know in what sub-package it is located. Thus I open the namespace path step by step until I reach the one that contains this element. Now the root-list of namespaces is full of namespaces I'm not interested in, if I want to navigate to a special one by opening the tree stepwise. This kind of visibility makes it very difficult to find that top-level namespace I have to open to first, while my navigation.

    Furthermore if I click on a nested namespace shown on the same level as the nesting namespaces, C::B is not showing the location where the namespace is defined. C::B just opens the file and shows its first source lines. This was the case last year also.

    I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling. Unfortunately the possibility to reduce the number of source elements shown in the symbol browser is very limited. For example you have a context command to enable the showing of inherited members but there is no context command to disable the showing of those member elements on the top level of the symbol browser. In the past namespaces gave me the possibility to do so. Using namespaces for convincing the symbol browser to offer me a package-view is not really a good solution but until the nightly of September the 16th it worked. If you define the new behaviour as a feature you disabled this last possibility.  Once there are some additional configuration possibilities to configure the symbol browser to offer as deeper tree-view and to disable the view of flat lists I would delete most of my namespaces. That's why I asked so often if it would be possible to offer a possibility to define virtual folders like in the project browser.

    I already mentioned the limited possibility of reducing the since of top level lists in the symbol browser in the past. But until now nobody reacted. OK, I can understand, that this may mean a bigger change, what may be currently not possible for the C::B developers. You may also ask me why I would not do it by my self. To be honest I already thought about and did some investigations in your sources. But doing it by myself means to stop my own projects. Furthermore it means I have to learn how C::B intently works. I don't think, that you would accept a change to improve one part of C::B, if it influences other parts negatively, since the one who implemented the change was not aware of it. As a newbie in C::B development I would assume, that it would take at least one year to provide a solution that harmonise with the rest of the project and while this time I need frequently support from you also. But perhaps this is a thing we should discuss not in the nightly forum.

    However, I hope that my attached picture is helpful to understand my doubts as well as my description of the goal I try to reach by using namespaces. 

    Best regards,
                       Eckard Klotz.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 12 October 2014 build (9958) is out.
    « Reply #31 on: October 20, 2014, 09:16:17 am »
    Quote
    Furthermore I'm not able to use the Button Preview of this forum anymore, what I normally use to check how my post looks like. I think I have to look for some plug-in updates and to check the security adjustments. If somebody has tip for me, it will be great.
    The preview button is broken, see:Code::Blocks forum 'Preview' not working

    Quote
    As attachment I added the combination of 2 screen shots that contains for one project the symbol browsers of the nightlies from September the 16th and October the 12th. As you can see in the older nightly I have to open the nesting namespace to see the nested namespace ( as I like), while in the newer nightly the nested namespaces are visible on the directly under the root node together with the nesting namespaces also (as I don't like).
    I have debugged a little and I have the same symbol tree results in the two version of nightlies, and see that you have such code:
    MuLanPa\process\h\transform.h
    Code: [Select]
    #ifndef DOXYGEN
    namespace CL_PROCESS {
    namespace CL_TRANSFORM {
    #endif //DOXYGEN
    ...
    ...
    #ifndef DOXYGEN
    #define USING_NAMESPACE using namespace
    };}; USING_NAMESPACE CL_TRANSFORM;
    #endif //DOXYGEN
    #undef  USING_NAMESPACE
    Question:
    Why do you use:
    Code: [Select]
    using namespace CL_TRANSFORM I recommend you should use
    Code: [Select]
    using namespace CL_PROCESS::CL_TRANSFORMSince CL_TRANSFORM is a child of CL_PROCESS.

    Anyway, the CC parser's behaviour is correct in this case as I can see.

    Quote
    Furthermore if I click on a nested namespace shown on the same level as the nesting namespaces, C::B is not showing the location where the namespace is defined. C::B just opens the file and shows its first source lines. This was the case last year also.
    This is the same issue as I said before.
    See here: Re: The 12 October 2014 build (9958) is out.
    When you click on the second "b" (the namespace "b" under global namespace), because the second "b" is created as a dummy token.

    Quote
    I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling.
    ...
    ...
    Please don't use the "misuse" any more, since our parser works correctly now.



    Quote
    ...
    ...
    That's why I asked so often if it would be possible to offer a possibility to define virtual folders like in the project browser.
    Note that symbol browser just build a hierarchy tree from the TokenTree, so if we get the correct parsing result, the symbol browser issue will be fixed, I don't think a "virtual folder" is possible, because the symbol tree are always created dynamically.

    Quote
    I already mentioned the limited possibility of reducing the since of top level lists in the symbol browser in the past. But until now nobody reacted. OK, I can understand, that this may mean a bigger change, what may be currently not possible for the C::B developers. You may also ask me why I would not do it by my self. To be honest I already thought about and did some investigations in your sources. But doing it by myself means to stop my own projects. Furthermore it means I have to learn how C::B intently works. I don't think, that you would accept a change to improve one part of C::B, if it influences other parts negatively, since the one who implemented the change was not aware of it. As a newbie in C::B development I would assume, that it would take at least one year to provide a solution that harmonise with the rest of the project and while this time I need frequently support from you also. But perhaps this is a thing we should discuss not in the nightly forum.
    The source code of C::B is not that hard to understand, so if you have any problems reading the source code, just ask here, I think you can get help from other ones(including me).
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    ToApolytoXaos

    • Guest
    Re: The 12 October 2014 build (9958) is out.
    « Reply #32 on: October 21, 2014, 01:52:34 pm »
    OS:     Debian testing (32-bit) [but it's the same on 64-bit at home PC]
    GCC:   gcc (Debian 4.9.1-16) 4.9.1
    SVN:   10001

    Bug detected in AStyle formatting.

    Copy the following code in your C / C++ project.

    Code: [Select]
    #include <stdio.h>
    #include <stdlib.h>
     
    int valid(void *p) {
      extern char _etext;
      return (p != NULL) && ((char*) p > &_etext);
    }
     
    int global;
     
    int main(void) {
      int local;
     
      printf("pointer to local var valid? %d\n", valid(&local));
      printf("pointer to static var valid? %d\n", valid(&global));
      printf("pointer to function valid? %d\n", valid((void *)main));
     
      int *p = (int *) malloc(sizeof(int));
      printf("pointer to heap valid? %d\n", valid(p));
      printf("pointer to end of allocated heap valid? %d\n", valid(++p));
      free(--p);
      printf("pointer to freed heap valid? %d\n", valid(p));
      printf("null pointer valid? %d\n", valid(NULL));
     
      return 0;
    }

     DO NOT compile it just yet; right-click inside editor and choose "Format use AStyle"

    The code becomes
    Code: [Select]
    #include <stdio.h>
    #include <stdlib.h>

    int valid(void *p)
    {
        extern char _etext;
        return (p != NULL) && ((char*) p > &_etext);
    }

    int global;

    int main(void)
    {
        int local;
    }
        printf("pointer to local var valid? %d\n", valid(&local));
        printf("pointer to static var valid? %d\n", valid(&global));
        printf("pointer to function valid? %d\n", valid((void *)main));

        int *p = (int *) malloc(sizeof(int));
        printf("pointer to heap valid? %d\n", valid(p));
        printf("pointer to end of allocated heap valid? %d\n", valid(++p));
        free(--p);
        printf("pointer to freed heap valid? %d\n", valid(p));
        printf("null pointer valid? %d\n", valid(NULL));

        return 0;
    }

    Can you see the unnecessary } right after int local? Of course it won't compile as it closes main() prematurely, before reaching return 0.

    Now, the mystery lies in the following order; paste the code in editor, compile it, and run it.

    Close the run application and format the code. No curly brace added.


    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 12 October 2014 build (9958) is out.
    « Reply #33 on: October 21, 2014, 05:11:48 pm »
    This will make AStyle play nice again..
    Code: [Select]
    diff --git a/src/plugins/astyle/astyleplugin.cpp b/src/plugins/astyle/astyleplugin.cpp
    index 80c002c..123fa65 100644
    --- a/src/plugins/astyle/astyleplugin.cpp
    +++ b/src/plugins/astyle/astyleplugin.cpp
    @@ -419,6 +419,10 @@ bool AStylePlugin::FormatEditor( cbEditor *ed )
     
     void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rangeStart, int rangeEnd)
     {
    +    stc->SetTargetStart(rangeStart);
    +    stc->SetTargetEnd(rangeEnd);
    +    stc->ReplaceTarget(text);
    +#if 0
         rangeStart = stc->LineFromPosition(rangeStart);
         rangeEnd = stc->LineFromPosition(rangeEnd) + 1;
         const wxString& eolChars = GetEOLStr(stc->GetEOLMode());
    @@ -483,4 +487,5 @@ void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rang
         }
         stc->SetTargetEnd(stc->GetLineEndPosition(rangeEnd - 1));
         stc->ReplaceTarget(buffer);
    +#endif // 0
     }
    ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated.  Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 12 October 2014 build (9958) is out.
    « Reply #34 on: October 21, 2014, 05:43:14 pm »
    ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated.  Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
    On second thought, magic numbers fix everything, right?
    Code: [Select]
    diff --git a/src/plugins/astyle/astyleplugin.cpp b/src/plugins/astyle/astyleplugin.cpp
    index 80c002c..afc645a 100644
    --- a/src/plugins/astyle/astyleplugin.cpp
    +++ b/src/plugins/astyle/astyleplugin.cpp
    @@ -450,7 +450,10 @@ void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rang
                 int i = rangeStart + 1;
                 for (; i < rangeEnd; ++i)
                 {
    -                StrVecItr searchItr = std::find(lnItr + 1, (StrVecItr)textLines.end(), stc->GetLine(i).BeforeLast(eolChars[0]));
    +                wxString edLine = stc->GetLine(i).BeforeLast(eolChars[0]);
    +                if (edLine.Strip(wxString::both).Length() < 7) // magic number
    +                    continue;
    +                StrVecItr searchItr = std::find(lnItr + 1, (StrVecItr)textLines.end(), edLine);
                     if (searchItr != textLines.end())
                     {
                         stc->SetTargetStart(stc->PositionFromLine(rangeStart));

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 6898
      • My Best Post
    Re: The 12 October 2014 build (9958) is out.
    « Reply #35 on: October 21, 2014, 06:19:19 pm »
    ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated.  Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
    On second thought, magic numbers fix everything, right?

    Or, it at least makes most people afraid to make changes to the code.

    I fixed one CB bug with a magic number in it; but, I would NOT likely fix a second one.

    Tim S.
     
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 12 October 2014 build (9958) is out.
    « Reply #36 on: October 21, 2014, 10:47:14 pm »
    Or, it at least makes most people afraid to make changes to the code.
    Yes... I was being a bit sarcastic when I posted :P .  The magic number is what I will be using on my personal C::B build, since I can deal with "mostly working" (and I do like that it shows me more exactly which lines have changed).  However, I plan to be committing the prior fix (unless there are objections) of removing not-so-smart smartness from text insertion, with a comment to come back if ever I (or someone else) has a bright idea of how to make it work.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 159
    Re: The 12 October 2014 build (9958) is out.
    « Reply #37 on: October 22, 2014, 09:13:54 am »
    Hello Ollydbg.

    Thanks for your detailed post and please excuse my late reply.

    First of all, after doing the change you and Morten proposed the shown namespaces in the symbol browser main-level are only the top-level ones. Thus you are right, if you say that the reason of my initial problem was my code even I still wonder why MinGW was still able to compile it. But this may be an other problem between my ears you don't have to care about. While implementing the namespace-using in the way of
    Code: [Select]
    #ifndef DOXYGEN
    namespace A {
    namespace B {
    namespace C {
    #endif //DOXYGEN
    ...
    ...
    #ifndef DOXYGEN
    #define USING_NAMESPACE using namespace
    };};}; USING_NAMESPACE A::B::C;
    #endif //DOXYGEN
    #undef  USING_NAMESPACE
    I recognized that the symbol browser showed an empty and unnamed namespace symbol as child node of A. This occurred not if namespace A contains child namespaces which contain no own child namespaces I face no empty braces. But if the child namespaces of A contain other child namespaces like C by them self than the effect occurred.

    Thus I changed the implementation:
    Code: [Select]
    #ifndef DOXYGEN
    namespace A {
    namespace B {
    namespace C {
    #endif //DOXYGEN
    ...
    ...
    #ifndef DOXYGEN
    #define USING_NAMESPACE using namespace
    }; USING_NAMESPACE C;
    }; USING_NAMESPACE B;
    }; USING_NAMESPACE A;
    #endif //DOXYGEN
    #undef  USING_NAMESPACE
    Now it looks like in the old nightlies. It may be, that I failed again while implementing your solution. Thus from my point of view there is no need for further investigations. But I thought you may be interested in.

    Quote
    I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling.
    ...
    ...
    Quote
    Please don't use the "misuse" any more, since our parser works correctly now.
    No, sorry misuse is still the right word to use here. But I don't write about a wrong display inside the symbol browser. What I mean is that I use hammer where normally a screwdriver should be used. If you take a look to my sources you will see that my namespace structure redefines the structure of the classes. In an object-orientated design you are modeling your structure by derivation of a child-class from a parent-class. But this deviation is not used by the symbol browser to filter out the child to show them only as child-nodes of their parents. Thus I decided to choose namespaces to redefine this derivation structure, since the nesting structure of namespaces is used to show the structure in the symbol browser as I like. But as we learned, this works only if it will be done in the right way. Furthermore maintaining nested namespaces is a tough task and I would nobody recommend to do so without a really good reason.

    However my current issue caused by my self is solved now, so thank you very much for you support.

    Quote
    The source code of C::B is not that hard to understand, so if you have any problems reading the source code, just ask here, I think you can get help from other ones(including me).
     
    I hope that I will find some time in the next days, to note down some details what I'm thinking about if I'm writing about having a package model in the symbol browser (or in an own browser?). And I will post it here. If you agree that the idea may have some potential, I would propose to have further discussions in the development forum. I agree, that the code of the symbol browser itself looks understandable. But there are some other sources which are hard to understand. Some time ago I posted a problem I have with the folding-feature. Furthermore I took a look into the C::B sources but I failed to get an idea how to solve this issue by my self. But I think in the case of my browser solution I already have an idea how to do it and need more somebody who reviews my thoughts to ensure that my solution does not create new issues.

    Best regards,
                          Eckard.





    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #38 on: October 27, 2014, 11:33:53 pm »
    Hi,

    I just need some help using the nightly on linux ubuntu 14.10. I use Jens packages flawlessly with a similar software configuration (Ubuntu 14.10 etc...) on one of my computers but it does not start on this one. I am pretty sure it has to deal with wxWidget (both jens and I use 2.8 I believe but the ubuntu version must differ from Debian's). Apparently it is caused when a software uses a static wxWidget timer in his code cf https://forums.wxwidgets.org/viewtopic.php?p=113193 (from this thread, it looks like a bad idea).
    Here is the output of "codeblocks -v" (I could not find how to display the version number but this should be the latest nightly).
    Code: [Select]
    Initialize EditColourSet .....
    Initialize EditColourSet: done.
    Loading menubar...
    ToolsPlus: loaded
    ProjectsImporter: loaded
    ../src/common/timercmn.cpp(62): assert "Assert failure" failed in Init(): No timer implementation for this platform
    ../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
    ../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
    terminate called after throwing an instance of 'std::bad_alloc'
      what():  std::bad_alloc
    Here is my wxwidget version:
    Code: [Select]
    $ wx-config --list                  
    Default config is base-unicode-release-2.8
    Default config will be used for output
    « Last Edit: October 27, 2014, 11:36:40 pm by teto »

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12597
      • Travis build status
    Re: The 12 October 2014 build (9958) is out.
    « Reply #39 on: October 27, 2014, 11:46:02 pm »
    Hm, can you post a backtrace?
    Also wx-config is the bad tool to ask about your wxgtk, try with apt-get or apt-cache search or something similar that works on your ubuntu.
    The wx-config will list only the dev-file you have for a particular version of wxgtk.

    I guess you have both wx2.8 and 3.0 and cb is using the 3.0.

    ldd /usr/bin/codeblocks will help you see if this is the case.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #40 on: October 28, 2014, 09:44:42 pm »
    Here you go, as you guessed it loads wx*3.so while ldd displays version 2. How should I proceed. I tried modifying LD_LIBRARY_PATH to make wxwidget 2.8 folder appear first without success.

    Quote
    [Thread 0x7fffe589f700 (LWP 10293) exited]
    ProjectsImporter: loaded
    ../src/common/timercmn.cpp(62): assert "Assert failure" failed in Init(): No timer implementation for this platform
    ../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
    ../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
    terminate called after throwing an instance of 'std::bad_alloc'
      what():  std::bad_alloc

    Program received signal SIGABRT, Aborted.
    0x00007ffff2344d27 in __GI_raise ([email protected]=6)
        at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
    56   ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) bt
    #0  0x00007ffff2344d27 in __GI_raise ([email protected]=6)
        at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
    #1  0x00007ffff2346418 in __GI_abort () at abort.c:89
    #2  0x00007ffff2c5105d in __gnu_cxx::__verbose_terminate_handler() ()
       from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #3  0x00007ffff2c4eed6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #4  0x00007ffff2c4ef21 in std::terminate() ()
       from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #5  0x00007ffff2c4f139 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #6  0x00007ffff2c4f6d9 in operator new(unsigned long) ()
       from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #7  0x00007ffff2cb64ff in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_S_create(unsigned long, unsigned long, std::allocator<wchar_t> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #8  0x00007ffff2cb71f9 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_clone(std::allocator<wchar_t> const&, unsigned long) ()
       from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #9  0x00007ffff2cb72b0 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::reserve(unsigned long) ()
       from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #10 0x00007fffc4515de7 in operator+(wchar_t const*, wxString const&) ()
       from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #11 0x00007fffc4520aa1 in wxSystemOptions::GetOption(wxString const&) ()
       from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #12 0x00007fffc45212e8 in wxSystemOptions::GetOptionInt(wxString const&) ()
       from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #13 0x00007fffc4445ad6 in ?? () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #14 0x00007fffc4441600 in wxOnAssert(char const*, int, char const*, char const*, wchar_t const*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #15 0x00007fffc4533d33 in wxTimer::Stop() ()
       from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #16 0x00007fffc4533d6c in wxTimer::~wxTimer() ()
       from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
    #17 0x00007fffd5ea9f1d in wxsCoder::~wxsCoder() ()
       from /usr/local/lib/libwxsmithlib.so.0
    #18 0x00007ffff2348599 in __run_exit_handlers (status=-1,
        listp=0x7ffff26cc6c8 <__exit_funcs>, [email protected]=true)
        at exit.c:82
    #19 0x00007ffff23485e5 in __GI_exit (status=<optimized out>) at exit.c:104
    #20 0x00007ffff232fecc in __libc_start_main (main=0x44fbe0, argc=1,
        argv=0x7fffffffe088, init=<optimized out>, fini=<optimized out>,
        rtld_fini=<optimized out>, stack_end=0x7fffffffe078) at libc-start.c:321
    Quote
    ldd /usr/bin/codeblocks                      master 
       linux-vdso.so.1 =>  (0x00007fffbcbfe000)
       libcodeblocks.so.0 => /usr/lib/libcodeblocks.so.0 (0x00007fe00ca8d000)
       libwx_gtk2u_richtext-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-2.8.so.0 (0x00007fe00c78c000)
       libwx_gtk2u_aui-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-2.8.so.0 (0x00007fe00c521000)
       libwx_gtk2u_xrc-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-2.8.so.0 (0x00007fe00c26e000)
       libwx_gtk2u_qa-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-2.8.so.0 (0x00007fe00c04d000)
       libwx_gtk2u_html-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-2.8.so.0 (0x00007fe00bd91000)
       libwx_gtk2u_adv-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so.0 (0x00007fe00baad000)
       libwx_gtk2u_core-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0 (0x00007fe00b489000)
       libwx_baseu_xml-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-2.8.so.0 (0x00007fe00b27e000)
       libwx_baseu_net-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_net-2.8.so.0 (0x00007fe00b04d000)
       libwx_baseu-2.8.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 (0x00007fe00acfb000)
       libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fe00a6ac000)
       libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007fe00a3f7000)
       libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007fe00a1d2000)
       libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fe009e58000)
       libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007fe009c42000)



    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12597
      • Travis build status
    Re: The 12 October 2014 build (9958) is out.
    « Reply #41 on: October 29, 2014, 12:53:01 am »
    This is rather strange. Can you try to compile a package youself and see if it will exhibit the same problem?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 12 October 2014 build (9958) is out.
    « Reply #42 on: October 29, 2014, 02:26:17 pm »
    I've uninstalled wx3 and it works now. If you really want me to compile myself I can do it but it looks to me like some artifact on my system (ubuntu)/jens packaging (for debian) rather than on codeblocks side so I am not sure it is interesting for the community ?

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12597
      • Travis build status
    Re: The 12 October 2014 build (9958) is out.
    « Reply #43 on: October 29, 2014, 08:26:52 pm »
    Not much, but if it works then all is fine (until you need to install wx3 for something else :) )
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]