Author Topic: The 11 February 2012 build (7789) is out.  (Read 77678 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
The 11 February 2012 build (7789) is out.
« on: February 12, 2012, 05:16:55 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://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z

The 11 February 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20120211_rev7789_win32.7z
  - Linux :
   none

Resolved Fixed:

  • added batch build files for build and re-build of core and plugins (Windows only atm)
  • BrowseTracker - JumpTracker:record deactivated position rather than activated position
  • adjust SDCC's options
  • do not connect events to dummy editor (used to backup foldstate), avoid moving breakpoints after the end of the file and probably other issues
  • linux: fix build-errors with automake-system, if "make dist" was not used from C::B's root-folder
  • Fixed: bug discussed here: http://forums.codeblocks.org/index.php/topic,15847.0.html
  • applied patch #3226 and extended part list with devices supported by gcc-4.5.3
  • attempt to make KEY_DOWN work in management pane
  • CC: made some of the options persist again
  • CC: added support for __attribute__ statements in structs (classes, typedefs)
  • CC: better handle const and volatile in front of namespaces (classes)
  • CC: major re-factoring to separate hidden classes and global hidden methods (using separate files and/or namespaces)
  • Fixed: Compilation of CodeSnippets with wxWidgets-2.8.12
  • added new cbEditor API to jump to specific line/token (preparation to remove global function from CC)
  • CC: renamed some token variabes to make clear what there are for
  • CC: overworked parsertest massively to parse files serialised but creating ONE TokensTree (not many temporary)
  • CC: major refactoring to allow the use of the CCDEebugInfo dialog in ParserTest project (via menu -> find -> token)
  • CC: optmised ParserTest application to make use of a file queue (enables to parse files serialised and added in between)
  • CC: ParserTest allows to scan priority files first (if needed, handle with care -> can take long!)
  • made About dialog work properly (i.e. not crash) under wx 2.9.x
  • cbProject: fixed possible crash candidate in CloseAllFiles (most likely on shutdown)
  • Fixed: Compilation warnings with -Woverloaded-virtual switch
  • CC: made ParserTest "reload" work again
  • CC: optimised and clarified interface to "SkipToOneOfChars" in parser thread
  • help-plugin: fix annoying occasionally happening crash on shutdown ("double free or corruption" or "corrupted double-linked list"), due to linking against static-libs, that are already linked in through libcodeblocks.so (linux only); style changes
  • CC again: major refactoring concerning lockers
  • CC: extracted more classes so they can be used/tested in ParserTest (automake updated)
  • CC: fixed entering a critical section too often in class browser
  • removed wx 2.4.x compatibility artefacts (C::B does not compile on wx 2.4.x anyways anymore...)
  • wxWidgets 2.9 related changes: add unix-project-file and update-script; small build-fixes; (hopefully) get rid of the annoying crash on close, due to event-handlers
  • cclogger: updated CC macros to enable simply assert mode
  • Prevent crash on exit due to referencing unallocated memory from wxArray::Remove (courtesy of Pecan)
  • CC: fix a build error when CC_ENABLE_LOCKER_ASSERT is defined
  • CC: fixed a hang on CC, reported here: http://forums.codeblocks.org/index.php/topic,15885.msg107044.html#msg107044
  • CC: separated CCTreeControl into own file
  • CC: use Mutex instead of critical section for Parser, as it can be traced to a deadlock! (wxCriticalSection just freezes)
  • CC: separated locker macros, so that individual mutexes can be traced
  • Show an InfoWindow, when the end of the document is reached, while using the Search->Find function;
  • add missing cctrectrl.{cpp,h} to linux projectfile, add cctrectrl.h to windows projectfile
  • speed up closing large project; (hopefully) finally fix a crash on close, that occurs from time to time, see: http://forums.codeblocks.org/index.php/topic,15901.msg107140.html#msg107140 and http://forums.codeblocks.org/index.php/topic,15882.msg107033.html#msg107033
  • CC: pause / resume thread for safety if class browser is updated, so the thread cannot be interrupted anymore
  • CC: send event from class browser thread to parent (class browser) if something relevant changes
  • Valgrind plugin : replace macros
  • CC-plugin: avoid possible infinite wait, if cc-plugin should be disabled, by adding a termination request; avoid possible memory-violation in UpdateLayout, if classbrowser is floating
  • envvars plugin: fixed bug described here: http://forums.codeblocks.org/index.php/topic,15926.msg107296.html#msg107296
  • CC: updated parsertest to be way faster and show progress of tokens added

Regressions/Confirmed/Annoying/Common bugs:



    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 11 February 2012 build (7789) is out.
    « Reply #1 on: February 12, 2012, 05:34:22 pm »
    Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

    Offline neo1691

    • Multiple posting newcomer
    • *
    • Posts: 68
    Re: The 11 February 2012 build (7789) is out.
    « Reply #2 on: February 14, 2012, 07:09:35 pm »
    I changed the presprectives twice and got this!!



    I restarted Code Blocks and it worked fine.. Still thought of reporting

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 11 February 2012 build (7789) is out.
    « Reply #3 on: February 14, 2012, 07:48:45 pm »
    Can you reproduce this problem after you've restarted C::B?
    (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 neo1691

    • Multiple posting newcomer
    • *
    • Posts: 68
    Re: The 11 February 2012 build (7789) is out.
    « Reply #4 on: February 14, 2012, 08:29:20 pm »
    Can you reproduce this problem after you've restarted C::B?

    Thats the wonder. It never happened again as of yet!!

    Offline janissl

    • Multiple posting newcomer
    • *
    • Posts: 10
    Re: The 11 February 2012 build (7789) is out.
    « Reply #5 on: February 15, 2012, 06:25:16 pm »
    I also had such behavior using the previous nightly (7678).
    I guess this was related with my intensive use of the Windows hibernation. I did not close CB for several days and only switched Windows to the hibernation mode and then resumed Windows every day. Once I stopped to use the Windows hibernation with no closing CB completely the problem was not encountered anymore.

    Maybe this may help to find a direction.
    In specialibus generalia quaerimus

    Offline neo1691

    • Multiple posting newcomer
    • *
    • Posts: 68
    Re: The 11 February 2012 build (7789) is out.
    « Reply #6 on: February 15, 2012, 06:26:19 pm »
    I also had such behavior using the previous nightly (7678).
    I guess this was related with my intensive use of the Windows hibernation. I did not close CB for several days and only switched Windows to the hibernation mode and then resumed Windows every day. Once I stopped to use the Windows hibernation with no closing CB completely the problem was not encountered anymore.

    Maybe this may help to find a direction.

    Nope its not that as  i never hibernate my laptop!

    Offline janissl

    • Multiple posting newcomer
    • *
    • Posts: 10
    Re: The 11 February 2012 build (7789) is out.
    « Reply #7 on: February 15, 2012, 10:15:36 pm »
    Nope its not that as  i never hibernate my laptop!

    Then I was wrong. Perhaps, I also switched between perspectives and then got this error but anyway I can not reproduce it anymore.
    In specialibus generalia quaerimus

    Offline ahui886

    • Multiple posting newcomer
    • *
    • Posts: 29
    Re: The 11 February 2012 build (7789) is out.
    « Reply #8 on: February 16, 2012, 12:29:10 pm »
    great,thanks

    Offline xawari

    • Multiple posting newcomer
    • *
    • Posts: 36
    • programming, usability ctrl
      • welcome to reality
    Re: The 11 February 2012 build (7789) is out.
    « Reply #9 on: February 20, 2012, 10:51:08 pm »
    1. Browser tree: I still cannot open files in minibrowser by pressing ENTER.
    2. Editor settings: Why there is "selection" color option only for "C/C++"? (while it should probably be syntax-independent?) UPD: sorry, not only "C/C++" but still kinda irrational.
    3. Editor settings: No "default" or "unknown" type. I just don't understand how to configure base colors for simple text files. (probably these settings, if implemented, should be inherited by all others?)

    svn build rev 7789 (2012/02/11 03:42:39) gcc 4.5.2 Windows/unicode - 32 bit
    Win2003 5.2 R2 build 3790

    As always, thank you for your great work.
    I really hope to join one day.
    ┌──────────────────────────────────────────────────────╖
    in another thousand years we'll be machines or gods█
    ╘══════════════════════════════════════════════════════╝

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 11 February 2012 build (7789) is out.
    « Reply #10 on: February 20, 2012, 11:55:22 pm »
    2. Editor settings: Why there is "selection" color option only for "C/C++"? (while it should probably be syntax-independent?) UPD: sorry, not only "C/C++" but still kinda irrational.
    Look inside the lexer_*.xml files; within lexer_cpp.xml there is:

       [...]
    57.                <Style name="Operator"
    57.                        index="10"
    59.                        fg="255,0,0"/>
    60.                <Style name="Selection"
    61.                        index="-99"
    62.                        bg="192,192,192"/>
    63.                <Style name="Active line"
    64.                        index="-98"
    65.                        bg="255,255,160"/>
       [...]


    Selection color is not accessible in most other languages simply because no one has added that tag.

    Offline teto

    • Almost regular
    • **
    • Posts: 127
    Re: The 11 February 2012 build (7789) is out.
    « Reply #11 on: February 25, 2012, 10:22:16 pm »
    I had to change a project from folder and when opening the project, it obviously couldn't find those files.
    Code
    		<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\C2dShock.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\C2dShock.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CAddTransparencyCB.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CBlurShader.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CBlurShader.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CDepthMapCallback.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CDepthMapCallback.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CFXAA.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CMotionBlur.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CMotionBlur.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CNightVision.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CPostProcessingHandler.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuad.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadCB.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadCB.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadSceneNode.cpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadSceneNode.hpp" />
    <Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadShader.hpp" />
    but I couldn't remove them from the interface, I've been compelled to edit manually the project file.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 11 February 2012 build (7789) is out.
    « Reply #12 on: February 25, 2012, 11:21:20 pm »
    teto: Can you provide the exact steps to reproduce this 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 11 February 2012 build (7789) is out.
    « Reply #13 on: February 26, 2012, 03:35:34 am »
    I've tried to reproduce it without success. I may have been misled by the fact we can select several files in the projet but when we choose "remove from project" (right click) it just removes the file clicked. I will be more careful next time I spot sthg weird

    stefanos_

    • Guest
    Re: The 11 February 2012 build (7789) is out.
    « Reply #14 on: February 27, 2012, 10:39:03 pm »
    Out of curiosity, when will you guys going to release the next release? People come in IRC channel and ask about it; frankly it's been almost two years now.

    Also, I have noticed this release-delay in the past, that lasted 2 years since the official switch of version numbering scheme (8.02) to reach the next stable version (10.05).

    What is the most stable revision that could be assembled in an installer and ship it to download session so people can see some activity from the project?

    Looking forward to hear your reply.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 11 February 2012 build (7789) is out.
    « Reply #15 on: February 27, 2012, 11:05:59 pm »
    SVN HEAD is as stable as it could get :)
    (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 codeur

    • Multiple posting newcomer
    • *
    • Posts: 113
      • Code::Blocks EDU-Portable
    Re: The 11 February 2012 build (7789) is out.
    « Reply #16 on: February 28, 2012, 11:49:47 pm »
    SVN HEAD is as stable as it could get :)

    I trust it is very stable. I am using the current head for a new release of Codeblocks EDU-Portable (in a couple of weeks).

    Offline xawari

    • Multiple posting newcomer
    • *
    • Posts: 36
    • programming, usability ctrl
      • welcome to reality
    Re: The 11 February 2012 build (7789) is out.
    « Reply #17 on: February 29, 2012, 09:44:49 pm »
    Selection color is not accessible in most other languages simply because no one has added that tag.
    There's no such lexer as default/common, it's really a bad idea to add same setting to every language. There may be someone who wants to highlight different text in different colors, of course, but in general there should be a common base. IMHO.
    ┌──────────────────────────────────────────────────────╖
    in another thousand years we'll be machines or gods█
    ╘══════════════════════════════════════════════════════╝

    Offline zetab

    • Multiple posting newcomer
    • *
    • Posts: 18
    Re: The 11 February 2012 build (7789) is out.
    « Reply #18 on: March 09, 2012, 10:24:14 am »
    When using the "Insert -> All method without implementation" to insert the implementation of TestFunction() for this header file:
    TestClass.h
    Code
    #ifndef TESTCLASS_H
    #define TESTCLASS_H
    class TestClass
    {
    public:
    TestClass();
    virtual ~TestClass();

    int* TestFunction();
    };
    #endif // TESTCLASS_H

    I got following code:
    TestClass.cpp
    Code
    #include "TestClass.h"

    TestClass::TestClass(){}
    TestClass::~TestClass(){}

    int TestClass::TestFunction()
    {
    }

    The return type of TestFunction missed the "*".
    I have tried reparsing the project, but the problem is still there.

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5490
    Re: The 11 February 2012 build (7789) is out.
    « Reply #19 on: March 09, 2012, 11:41:10 am »
    many thanks for the feedback, this is indeed a serious error.
    Could you please also register it at our berlios project page as a bug, otherwise it will get lost in the forum ;-)

    Offline Agetian

    • Multiple posting newcomer
    • *
    • Posts: 16
    Re: The 11 February 2012 build (7789) is out.
    « Reply #20 on: March 09, 2012, 12:52:17 pm »
    I can confirm the error submitted by zetab, I can also say that it happens for C functions and not only for C++ classes (C functions that return char* are shown as returning char), and I have found another serious flaw with return types:
    As one types a simple C program like this:

    Code
    #include <stdio.h>
    #include <stdlib.h>

    int main()
    {
        printf(
    }


    Upon typing the opening bracket of the standard function 'printf', which fires the printf declaration hint, the hint will show the function as "__MINGW_NOTHROW printf(const char*, ...)" thus omitting the return type (int) and the other declarations (_CRTIMP, __cdecl). Tested with the latest nightly (from this thread) and MinGW GCC 4.6.1.
    « Last Edit: March 09, 2012, 12:54:00 pm by Agetian »

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9694
    Re: The 11 February 2012 build (7789) is out.
    « Reply #21 on: March 09, 2012, 03:41:46 pm »
    Upon typing the opening bracket of the standard function 'printf', which fires the printf declaration hint, the hint will show the function as "__MINGW_NOTHROW printf(const char*, ...)" thus omitting the return type (int) and the other declarations (_CRTIMP, __cdecl). Tested with the latest nightly (from this thread) and MinGW GCC 4.6.1.
    This is known but not an easy thing to do. I've done some work on it which improves this, but not fully completed yet.
    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

    Offline Agetian

    • Multiple posting newcomer
    • *
    • Posts: 16
    Re: The 11 February 2012 build (7789) is out.
    « Reply #22 on: March 11, 2012, 09:16:41 am »
    Upon typing the opening bracket of the standard function 'printf', which fires the printf declaration hint, the hint will show the function as "__MINGW_NOTHROW printf(const char*, ...)" thus omitting the return type (int) and the other declarations (_CRTIMP, __cdecl). Tested with the latest nightly (from this thread) and MinGW GCC 4.6.1.
    This is known but not an easy thing to do. I've done some work on it which improves this, but not fully completed yet.

    Also, I'm not sure if it's supposed to work (I think it used to work a couple builds ago, but my memory is a bit blurry), but the declaration hint is not shown for function-like macros, e.g. in this stupid little test macro:

    Code
    #define TEST_MACRO(x)  ((x) * (x))

    int main()
    {
        TEST_MACRO(
    }

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #23 on: March 12, 2012, 07:11:16 am »
    When using the "Insert -> All method without implementation" to insert the implementation of TestFunction() for this header file:
    TestClass.h
    Code
    #ifndef TESTCLASS_H
    #define TESTCLASS_H
    class TestClass
    {
    public:
    TestClass();
    virtual ~TestClass();

    int* TestFunction();
    };
    #endif // TESTCLASS_H

    I got following code:
    TestClass.cpp
    Code
    #include "TestClass.h"

    TestClass::TestClass(){}
    TestClass::~TestClass(){}

    int TestClass::TestFunction()
    {
    }

    The return type of TestFunction missed the "*".
    I have tried reparsing the project, but the problem is still there.


    I have find the reason, see the comments in Insert all class methods without implementation malfunction

    I think it can be fixed quickly, but that fix should be reviewed. :)
    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 ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #24 on: March 12, 2012, 07:16:46 am »
    Also, I'm not sure if it's supposed to work (I think it used to work a couple builds ago, but my memory is a bit blurry), but the declaration hint is not shown for function-like macros, e.g. in this stupid little test macro:

    Code
    #define TEST_MACRO(x)  ((x) * (x))

    int main()
    {
        TEST_MACRO(
    }


    It works here, WinXP, c::b trunk.

    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 Agetian

    • Multiple posting newcomer
    • *
    • Posts: 16
    Re: The 11 February 2012 build (7789) is out.
    « Reply #25 on: March 12, 2012, 04:54:46 pm »
    It works here, WinXP, c::b trunk.
    See the screen shot below:


    Hmm, I'm not sure if it's the newer build you might be testing with (so it's already fixed?) or something OS-specific/compiler toolchain-specific; at any rate, I'm testing it with SVN 7789 (from this thread) on Windows Vista 32bit with MinGW GCC 4.6.1 (tdm-gcc). It doesn't work for me under these circumstances. :\

    stefanos_

    • Guest
    Re: The 11 February 2012 build (7789) is out.
    « Reply #26 on: March 20, 2012, 10:23:34 pm »
    Can someone try to close multiple .xrc or .wxs and tell me if his / her system is crashing? I have tried with both svn-7789 and the latest svn-7905 and it crashes like mad.

    Below you may find the generated crash report. It would help a lot your valuable feedback.

    Cheers.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #27 on: March 21, 2012, 02:19:27 am »
    Can someone try to close multiple .xrc or .wxs and tell me if his / her system is crashing?
    Tested under latest trunk and winXP, no crash.
    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 Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 11 February 2012 build (7789) is out.
    « Reply #28 on: March 21, 2012, 06:43:59 am »
    Can someone try to close multiple .xrc or .wxs and tell me if his / her system is crashing? I have tried with both svn-7789 and the latest svn-7905 and it crashes like mad.

    Below you may find the generated crash report. It would help a lot your valuable feedback.

    Cheers.
    did you really clean your sozrce folder before building, especially remove the +.gch's in c::B's include ? They have moved to another place, but if old ones exist, they will probably be used by the compiler, what can lead to weird crashes.

    A fresh svn-checkout is usually the easiest way to avoid such issues.

    stefanos_

    • Guest
    Re: The 11 February 2012 build (7789) is out.
    « Reply #29 on: March 21, 2012, 08:19:29 am »

    jens, I have forgot to mention that it's under Debian wheezy. I have created a script and it runs like this:

    Code
    make clean && \ 
    make distclean && \
    ./bootstrap && \
    ./configure --with-contrib-plugins=all && \
    make && sudo make install

    Up to now it was working just fine, cleaning literally everything that I could see. This issue appeared in svn-7789 and afterwards. Shall I try to uninstall it and run a clean install?

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 11 February 2012 build (7789) is out.
    « Reply #30 on: March 21, 2012, 08:25:42 am »
    Keep in mind that make uninstall is not the most reliable thing in the world. Nor the most easy to use thing in the world!
    So it is advised to do one of two things:
    1. use a prefix specific for codeblocks, like --prefix=/home/yourusers/software/codeblocks, by doing, so you have an easy uninstall procedure (just delete the directory).
    2. make your own packages for your distro, c::b has build in support for debian(-based) and all the rpm based distros (some changes are needed here and there, but they are trivial).

    BTW: Can you explain why are you changing something in configure.in and in Makefile.am (explained here: http://ssofroni1982.users.sourceforge.net/dokuwiki/codeblocks-svn-mint )? Why haven't you provided a patch, so we can integrate your changes? (this link is from the irc.freenode.net channel posted by the user _stefanos_ (I guess this is you)).

    p.s. also it could be a good idea to use a separate build directory, our build system supports it pretty well (I've not tried it, but this is what people say:)).
    (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!]

    stefanos_

    • Guest
    Re: The 11 February 2012 build (7789) is out.
    « Reply #31 on: March 21, 2012, 11:31:46 am »
    Keep in mind that make uninstall is not the most reliable thing in the world. Nor the most easy to use thing in the world!
    So it is advised to do one of two things:
    1. use a prefix specific for codeblocks, like --prefix=/home/yourusers/software/codeblocks, by doing,
    so you have an easy uninstall procedure (just delete the directory).

    2. make your own packages for your distro, c::b has build in support for debian(-based) and all the rpm
    based distros (some changes are needed here and there, but they are trivial).

    BTW: Can you explain why are you changing something in configure.in and in Makefile.am (explained here:
    http://ssofroni1982.users.sourceforge.net/dokuwiki/codeblocks-svn-mint )? Why haven't you provided a patch,
    so we can integrate your changes? (this link is from the irc.freenode.net channel posted by
    the user _stefanos_ (I guess this is you)).

    p.s. also it could be a good idea to use a separate build directory, our build system supports it
    pretty well (I've not tried it, but this is what people say:)).

    Yeah that's my website. Well, I had an issue from the start with many awkward messages about missing macros from
    those two files and searched about it on the web. I have found bits and pieces as plausible fixes and assembled
    them as one whole solution and managed to make it work; frankly I thought it was a minor bug that had to do
    with my system, not with Code::Blocks. I thought it would, could, (should?) have got fixed by now; I didn't know that
    still causes building problems so I could report my solution as an official patch for Code::Blocks.

    As far as concern the build directory, I have tried it once and I found it irritating with all this switch between
    build version and installed version, that is the one I have compiled myself, and the one that comes on Debian
    by default. It was based on this irritation that I decided to compile everything myself, which is more or less
    an old habit I would say; it helps me stay focus on one thing.

    Right now I am at work and cannot really tell what is the cause of my issue. I think tomorrow I will be able to check it,
    because today I have a seminar and I won't get home before 22:00, which I will be way too exhausted.

    In case I find the time to check it, I will surely let you know.

    stefanos_

    • Guest
    Re: The 11 February 2012 build (7789) is out.
    « Reply #32 on: March 22, 2012, 09:32:07 pm »
    did you really clean your sozrce folder before building, especially remove the +.gch's in c::B's include ? They have moved to another place, but if old ones exist, they will probably be used by the compiler, what can lead to weird crashes.

    A fresh svn-checkout is usually the easiest way to avoid such issues.

    As far as I can see with make distclean, it removes .gch files but to be 100% I have added a find command on my script that searches the entire local repository for precompiled header files and delete them. I am anxiously waiting for it to finish and I will let you know after a few minutes.

    Offline Paul_Wortmann

    • Single posting newcomer
    • *
    • Posts: 5
      • PhysHex Games
    Re: The 11 February 2012 build (7789) is out.
    « Reply #33 on: March 31, 2012, 08:16:30 am »
    I think I may have found a small, insignificant bug...
    If I highlight just the class name without the double colon "::" all instances of the class name are highlighted, but if I highlight the class name including the double colon, all instances excluding the destructor are highlighted.
    It appears that a class name followed by two colons and then any other symbol other than a letter or a number has the same effect.



    I am using the 11 February 2012 build (7789) on windows 7.
    It also does the same on my Linux machine with build 7899.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #34 on: March 31, 2012, 09:05:56 am »
    I think I may have found a small, insignificant bug...
    If I highlight just the class name without the double colon "::" all instances of the class name are highlighted, but if I highlight the class name including the double colon, all instances excluding the destructor are highlighted.
    It appears that a class name followed by two colons and then any other symbol other than a letter or a number has the same effect.



    I am using the 11 February 2012 build (7789) on windows 7.
    It also does the same on my Linux machine with build 7899.

    The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

    Thank you.
    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 Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 11 February 2012 build (7789) is out.
    « Reply #35 on: March 31, 2012, 09:10:15 am »
    The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

    That's not correct.
    HighlightOccurrences() is implemented in cbeditor.cpp.
    So please do not report it to scintilla mailinglist.

    I look into it.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #36 on: March 31, 2012, 09:15:04 am »
    The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

    That's not correct.
    HighlightOccurrences() is implemented in cbeditor.cpp.
    So please do not report it to scintilla mailinglist.

    I look into it.

    Oh, You are correct, thanks.
    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 Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 11 February 2012 build (7789) is out.
    « Reply #37 on: March 31, 2012, 09:16:48 am »
    The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

    That's not correct.
    HighlightOccurrences() is implemented in cbeditor.cpp.
    So please do not report it to scintilla mailinglist.

    I look into it.

    Works fine here.
    Can you create a small file, where this occurs and send it me via mail ( my_nickname at codeblocks dot org ) , or attach it here ?

    Offline Paul_Wortmann

    • Single posting newcomer
    • *
    • Posts: 5
      • PhysHex Games
    Re: The 11 February 2012 build (7789) is out.
    « Reply #38 on: March 31, 2012, 02:57:04 pm »
    I included files as requested that exhibit this behavior.  "rs232.cpp"

    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 11 February 2012 build (7789) is out.
    « Reply #39 on: March 31, 2012, 04:20:10 pm »
    I included files as requested that exhibit this behavior.  "rs232.cpp"

    It still works here with my default settings, but after checking "Whole words only" in "Settings -> Editor... -> General settings -> Highlight occurrences", I get the same behaviour as you.
    My guess, is that scintilla treats the double-colon with the following tilde as one word.

    So if you uncheck  "Whole words only", it should work

    Offline Paul_Wortmann

    • Single posting newcomer
    • *
    • Posts: 5
      • PhysHex Games
    Re: The 11 February 2012 build (7789) is out.
    « Reply #40 on: March 31, 2012, 04:37:20 pm »
    I included files as requested that exhibit this behavior.  "rs232.cpp"

    It still works here with my default settings, but after checking "Whole words only" in "Settings -> Editor... -> General settings -> Highlight occurrences", I get the same behaviour as you.
    My guess, is that scintilla treats the double-colon with the following tilde as one word.

    So if you uncheck  "Whole words only", it should work

    I adjusted the setting as you indicated and am now able to highlight the destructor too.
    Thank you very much, Jens.  :)

    Offline VinniPuh

    • Single posting newcomer
    • *
    • Posts: 2
    Re: The 11 February 2012 build (7789) is out.
    « Reply #41 on: April 03, 2012, 10:11:23 am »
    Hi,
    I compiled Code::Blocks (trunk, rev 7916, minGW32) with -Wextra and saw some warnings what is similar to a bug:

    Code
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:348:36: warning: comparison of unsigned expression < 0 is always false
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:381:54: warning: comparison of unsigned expression >= 0 is always true
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenizer.cpp:273:53: warning: comparison of unsigned expression >= 0 is always true
    D:\WORK\cb\trunk\src\plugins\scriptedwizard\wizpage.cpp:482:54: warning: comparison of unsigned expression < 0 is always false
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenstree.cpp:222:41: warning: comparison is always false due to limited range of data type

    Regards,
    VinniPuh.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #42 on: April 03, 2012, 10:58:06 am »
    Hi,
    I compiled Code::Blocks (trunk, rev 7916, minGW32) with -Wextra and saw some warnings what is similar to a bug:

    Code
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:348:36: warning: comparison of unsigned expression < 0 is always false
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:381:54: warning: comparison of unsigned expression >= 0 is always true
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenizer.cpp:273:53: warning: comparison of unsigned expression >= 0 is always true
    D:\WORK\cb\trunk\src\plugins\scriptedwizard\wizpage.cpp:482:54: warning: comparison of unsigned expression < 0 is always false
    D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenstree.cpp:222:41: warning: comparison is always false due to limited range of data type

    Regards,
    VinniPuh.

    Hi, many thanks.
    I will fix them.

    EDIT: Here is the candidate change.

    Code
        /** Return (peek) the previous character */
        wxChar PreviousChar() const
        {
            if ( ((m_TokenIndex - 1) < 0) || (m_BufferLen==0) ) // (m_TokenIndex - 1) >= m_BufferLen can never be true
                return 0;

            return m_Buffer.GetChar(m_TokenIndex - 1);
        };

    Here:

    Code
    (m_TokenIndex - 1) < 0
    The left is unsigned int, so its result is always >=0.

    The only right case is (m_TokenIndex==0), right?

    The next issue:
    Code
    m_TokenIndex - 2 >= 0

    So, it need to change to
    Code
    m_TokenIndex >= 2

    Then
    Code
    ((m_TokenIndex - numBackslash) >= 0)
    should be change to
    Code
    m_TokenIndex >= numBackslash


    Forth issue:
    Code
                           id = (cmb->GetCount() - 1) < 0 ? 0 : (cmb->GetCount() - 1);
    should change to:
    Code
    cmb->GetCount() < 1


    The last issue:
    Code
    size_t TokensTree::FindMatches(const wxString& s, TokenIdxSet& result, bool caseSensitive, bool is_prefix, short int kindMask)
    {
        result.clear();

        std::set<size_t> lists;
        int numitems = m_Tree.FindMatches(s, lists, caseSensitive, is_prefix);
        if (!numitems)
            return 0;

        // now the lists contains indexes to all the matching keywords
        // first loop will find all the keywords
        for (std::set<size_t>::iterator it = lists.begin(); it != lists.end(); ++it)
        {
            TokenIdxSet* curset = &(m_Tree.GetItemAtPos(*it));
            // second loop will get all the items mapped by the same keyword,
            // for example, we have ClassA::foo, ClassB::foo ...
            if (curset)
            {
                for (TokenIdxSet::iterator it2 = curset->begin(); it2 != curset->end(); ++it2)
                {
                    Token* token = at(*it2);
                    if (   token
                        && (   (kindMask == tkUndefined)
                            || (token->m_TokenKind & kindMask) ) )
                        result.insert(*it2);
                }
            }
        }
        return result.size();
    }

    If I remember correct, the function parameter "short int" should be changed to Enum TokenKind type.




    « Last Edit: April 03, 2012, 11:23:29 am 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 MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9694
    Re: The 11 February 2012 build (7789) is out.
    « Reply #43 on: April 03, 2012, 08:33:09 pm »
    Here:
    Code
    (m_TokenIndex - 1) < 0
    The left is unsigned int, so its result is always >=0.

    The only right case is (m_TokenIndex==0), right?
    I would do this differently (to improve readability) and change if clause to check for the opposite:
    Code
        /** Return (peek) the previous character */
        wxChar PreviousChar() const
        {
            if ( (m_TokenIndex > 0) && (m_BufferLen > 0) ) // m_TokenIndex > m_BufferLen can never be true
                return m_Buffer.GetChar(m_TokenIndex - 1);

            return 0;
        };
    The rest seems OK.
    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #44 on: April 04, 2012, 03:11:10 am »
    Ok, committed the fix. Thanks.

    Quote
    Revision: 7917
    Author: ollydbg
    Date: 2012-4-4 9:08:11
    Message:
    - fix log errors when comparing unsigned int with int, see: http://forums.codeblocks.org/index.php/topic,15945.msg109050.html#msg109050 (Thanks VinniPuh)
    -------------------------------
    M : /trunk/src/plugins/codecompletion/parser/tokenizer.cpp

    M : /trunk/src/plugins/codecompletion/parser/tokenizer.h

    M : /trunk/src/plugins/codecompletion/parser/tokenstree.cpp

    M : /trunk/src/plugins/codecompletion/parser/tokenstree.h

    M : /trunk/src/plugins/scriptedwizard/wizpage.cpp

    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 ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 11 February 2012 build (7789) is out.
    « Reply #45 on: April 04, 2012, 08:18:49 am »
    Oh, I found a typo in the log message. The "log" should be "logic", can it be fixed? (svn: change log message does not work).
    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: 9694
    Re: The 11 February 2012 build (7789) is out.
    « Reply #46 on: April 04, 2012, 10:19:12 pm »
    Oh, I found a typo in the log message. The "log" should be "logic", can it be fixed? (svn: change log message does not work).
    As Yiannis didn't find the time to implement this yet, no. :-(
    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ