Author Topic: The 06 August 2013 build (9246) is out.  (Read 143392 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5193
The 06 August 2013 build (9246) is out.
« on: August 08, 2013, 11:43:49 am »
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://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 06 August 2013 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20130806_rev9246_win32.7z
  - Linux :
   none

Resolved Fixed:

  • no list since it has been such a very long time, just enjoy it ......

Regressions/Confirmed/Annoying/Common bugs:



    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 August 2013 build (9246) is out.
    « Reply #1 on: August 08, 2013, 11:56:47 am »
    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 (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo .

    The packages that are currently striked through are not yet available.
    Debian comes this afternoon, RedHat/CentOS 5 might take a little longer as the default compiler there is gcc 4.1, but a header file of mozilla's encoding detection wants at least gcc4.4.
    I hope I can fix this soon (maybe 4.1 is enough or I have to tweak mock to use gcc44 instead of gcc, if possible).

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 150
    Re: The 06 August 2013 build (9246) is out.
    « Reply #2 on: August 09, 2013, 09:47:37 am »
    Hello Everybody.

    Thanks for the new build but unfortunately I still see the effect mentioned in my comments of the last nightly (Re: The 16 June 2013 build (9158) is out.):
    Quote
    Hello Everybody.

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

    If I have the following source-example:

    Code:
    namespace a {
    namespace b {
    };
    };

    using namespace b;

    The namespace b will be displayed on toplevel what not happens in this example:

    Code:
    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:
    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.



    What occurs since the parser seems to handle the using of a namespace like its declaration. Have I overseen something in the currently available configuration?
    Alternatively I proposed in the followed discussion to implement a possibility to show derived classes in sub-levels of the browser-tree or to allow the user to add folders where he can place browser-nodes since my original intention is to reduce the the amount of lines showed on top-level.

    Best Regards,
                             Eckard Klotz.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 August 2013 build (9246) is out.
    « Reply #3 on: August 09, 2013, 06:05:01 pm »
    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 (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo .

    The packages that are currently striked through are not yet available.
    Debian comes this afternoon, RedHat/CentOS 5 might take a little longer as the default compiler there is gcc 4.1, but a header file of mozilla's encoding detection wants at least gcc4.4.
    I hope I can fix this soon (maybe 4.1 is enough or I have to tweak mock to use gcc44 instead of gcc, if possible).
    Finally it's done, sorry for the delay.
    Actual packages on my server are svn r9251 :

    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 (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo .

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5247
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 August 2013 build (9246) is out.
    « Reply #4 on: August 11, 2013, 11:51:18 am »
    Maybe scintilla related bug under Windows:
    The first line number does not show correctly, see the screen shot below:
    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 frithjofh

    • Regular
    • ***
    • Posts: 373
    Re: The 06 August 2013 build (9246) is out.
    « Reply #5 on: August 11, 2013, 05:40:16 pm »
    Hi,

    if I remember correctley, there was a setting somewhere, specifying the width of that grey column...

    regards

    frithjof
    architect with some spare time  -  c::b compiled from last svn  -   openSuSE leap x86_64  -  AMD FX-4100

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5247
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 August 2013 build (9246) is out.
    « Reply #6 on: August 11, 2013, 06:31:59 pm »
    Hi,

    if I remember correctley, there was a setting somewhere, specifying the width of that grey column...

    regards

    frithjof
    That setting was in "left margin" in "Margins and caret" in Editor setting, I have the "Dynamic setting" checked.

    Oh, I noticed that this issue happens when I use the CTRL+MOUSE-Wheel to enlarge the font size, but the "left margin" width was not enlarged accordingly.

    EDIT: I tried NotePad++, the "left margin" width just changed as font size changed, so I believe this is a C::B bug.
    « Last Edit: August 11, 2013, 06:35:13 pm by ollydbg »
    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 oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12122
      • Travis build status
    Re: The 06 August 2013 build (9246) is out.
    « Reply #7 on: August 11, 2013, 09:35:20 pm »
    EDIT: I tried NotePad++, the "left margin" width just changed as font size changed, so I believe this is a C::B bug.
    You have to try the latest Scite, Notepad++ might not have been running the latest scintilla.
    (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: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 August 2013 build (9246) is out.
    « Reply #8 on: August 12, 2013, 01:36:10 am »
    @ollydbg:
    can you test the attached patch ?

    Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
    The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5247
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 August 2013 build (9246) is out.
    « Reply #9 on: August 12, 2013, 03:51:58 am »
    @ollydbg:
    can you test the attached patch ?

    Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
    The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.

    Hi, jens, thanks, I just test this patch, and it fix the problem I reported.

    BTW: when I use CTRL+MOUSE_WHEEL to zoom the fonts, is there any way to "reset" the zoom value to the default value? I can't find a menu item...
    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 jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 August 2013 build (9246) is out.
    « Reply #10 on: August 12, 2013, 05:49:17 am »
    BTW: when I use CTRL+MOUSE_WHEEL to zoom the fonts, is there any way to "reset" the zoom value to the default value? I can't find a menu item...

    "Edit -> Special commands -> Zoom -> Reset", I use "CTRL+0" (CTRL+zero") as shortcut on my system.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 150
    Re: The 06 August 2013 build (9246) is out.
    « Reply #11 on: August 12, 2013, 04:59:07 pm »
    Hello again.

    In the meanwhile I implemented A workaround like this:
    Quote
    #define USING_NAMESPACE using namespace
    };}; USING_NAMESPACE CL_ACTION_GRAMM;
    #undef  USING_NAMESPACE

    The result is that that the symbol-browser shows a reduced list again since the parser is not recognizing the using namespace lines any more.

    But to be honest this is a workaround of a workaround and what happens the parser will start to solve the preprocessor directive ]#define USING_NAMESPACE using namespace
    .

    I think the real solution is that the symbol-browser provides a configuration to hide inherited members from higher tree-levels if they are shown as inherited members. Inherited members can already shown as sub-nodes so the only work is to erase them in the tree-levels above. I know there are also users which prefer flat lists and accept if this list are very long so it should be configurable. But for users like me one advantage of object orientated programming is to design hierarchies and in this case you expect this hibachi in a symbol-browser also.

    Best Regards,

                        Eckard Klotz.

    Offline raynebc

    • Almost regular
    • **
    • Posts: 212
    Re: The 06 August 2013 build (9246) is out.
    « Reply #12 on: August 20, 2013, 05:17:31 am »
    It took me a moment to realize why ALT+F wasn't bringing up the File menu like it always had done:  The F hotkey is overloaded and is now assigned to the Fortran menu as well.  Luckily this can be removed pretty easily by disabling the plugin, but it may be worth seeing if that menu can get another hotkey (I didn't check all plugins, but ALT+A and ALT+N don't seem to be tied to any of the default menus).

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 150
    Re: The 06 August 2013 build (9246) is out.
    « Reply #13 on: August 27, 2013, 01:44:38 pm »
    Hello Everybody.

    I assume that currently no urgent problems have to be discussed here so I hope I'm allowed to discuss an additional symbol-browser point. This discussion may result in a requirement but currently I don't know in which requirement.

    As I wrote before I see a problem in the long lists you get in the symbol-browser. In a object orientated software-project it may be possible to use the language depending hierarchy definitions to move elements from the top-level to deeper levels like class inheritance or nested name-spaces.

    But in more old fashioned software-projects with no object-hierarchies like in C and not Cpp this will not help. The user has to define the hierarchy some how else. My proposal is to give the user to define package-hierarchies inside the symbol-browser which represent a user-define tree whose nodes can be used to carry all symbols like the user wants.

    • The user defines a package-structure that works like a folder-system and where a package may contain sub-packages and sub-sub-packages and sub-sub-sub... . This package-structure will be saved as independent xml-file or as part of the project-file. May be, it will good to have more than one independent package tree to represent different views.
    • The activated package-structure will be displayed in the symbol-browser and can now be used to move symbols in. Once a symbol is moved in a package or its sub-package its id will be saved in the corresponding package xml-node. It may be possible to insert the symbol-id in more than one independent package-tree.
    • The configuration of the symbol-browser allows the user to disable the display of moved symbols outside of their packages. Once the symbol-parser finds a changed symbol its id will be searched in the active package tree to prepare the display there and only there. Thus the user has to open the package to se the symbol and to reach its source but not shown symbols do not disturb the searching.

    My idea is not to replace the current behaviour of the symbol-browser completely but to extend it. some more questions have to be discussed for example how to deal with change symbol-ids It may be useful to have a special tomb-package for symbols not found anymore or a delivery-package for new symbols. It may be good to add comment to every package and perhaps this may be used later to define a doxygen grouping definition. May be that this kind of browsing is to different compared with the currently used Symbol-browser what results in implementing a Package-browser parallel to the symbol-browser.

    And may be you tell me that this already exists and I just was not able to activated it (Jens may remember the "disable the MouseSap-plugin" discussion we had in the last days, very embarrassing). So please help me to fill the vacuum between my ears.

    Best Regards,
                          Eckard.

     

     

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 150
    Re: The 06 August 2013 build (9246) is out.
    « Reply #14 on: August 27, 2013, 03:07:40 pm »
    Hello Everybody.

    Now I have an total other question:

    I know how to create in one project several targets.
    I saw also, that it is possible to use the target-definition for creating an independent project.
    But is it also supported to merge a project into an other for adding its targets (together with all associated configurations)?

    In my example I have on the one side projects which contain application-targets (release and debug) and on the other side projects with test-targets (unit-tests).  The independent test-projects are created by different colleges but once the tests are ready it is useful to have them in the application-project also. Here you are able to define a virtual target to compile and run altogether.

    Currently we redefine all test-targets in the application-project by hand what may create more bugs. Thus a C::B function to copy a target from one project to the other may be very helpful.

    Is there already something available?

    Best regards,
                      Eckard.