Author Topic: The 01 September 2015 build (10474) is out.  (Read 29396 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
The 01 September 2015 build (10474) is out.
« on: September 01, 2015, 10:14:44 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_gcc492-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_gcc492-TDM.7z

The 01 September 2015 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2015/CB_20150901_rev10474_win32.7z
  - Linux :
   none

The current SDK version is : 1.26.0

Resolved Fixed:

  • Debian build-system: do not include cached autofoo-stuff in orig.tar-ball to avoid build errors, if the tar-ball was created on a system with different versions.
  • CC: apply jat1's patch(modified) to handle the template alias.
  • Fix bug in debian install file, thanks Tim (stahta01); see http://forums.codeblocks.org/index.php/topic,20507.msg139520.html
  • fix for (out-of-tree) "make dist" with wxWidgets >= 3.x
  • wx3: Re-implement the wxArrayString::Item and wxColour::IsOk in the squirrel bindings (fixes ticket #194)
  • scripting: Expose wxArrayString::SetItem method, so people can modify the contents of a wxArrayString
  • editors: Make 'Close all' and 'Close all except' context menu commands to work a bit better when there are multiple tab controls
  • ui: Better multi monitor support for non windows system (rework the code to use wxDisplay instead of native APIs)
  • support for windows 10
  • updated crash handler DLL
  • DragScroll - Avoid SIGFPE in wx3.0 mouseWheel event
  • KeyBinder - Incorporate wx3.0 negative menu id's. Old key definitions from wx2.x cannot be transfered to wx3.x.
  • added lexer for "Google Protocol Buffer" to setup
  • Installer: make wx version configurable
  • wxContribItems plugin: use delete[] instead of delete for pointer array.
  • SDK: ccmanager: when m_CallTips get updated, also update the iterator
  • wxSmith-plugin: allow wxALIGN_CENTER (2d-centered) in sizeres again, as it is handled differently in wxWidgets, see: http://forums.codeblocks.org/index.php/topic,20338.msg139153.html#msg139153;
  • wxSmith-plugin: do not return wxALIGN_NOT for empty-flags, because xrc-handlers does not recognize it, use wxALIGN_LEFT instead, because it's internally the same.
  • do not use wxALIGN_NOT, because it can not be parsed by xrc-handler of wxWidgets unfortunately.
  • NassiShneiderman-plugin: build fix for boost 1.59
  • remove remaining wxALIGN_NOT's in xrc-file to avoid warnings/asserts
  • CC and CCTest: disable the user defined token replacement, and enable all the macro check on each identifier like token
  • CC and CCTest: handle the skip assignment and ternary operator in ThreadParse::DoParse() function, not Tokenizer::SkipUnwanted() function, this can handle skipping of {} correctly, especially when handling wx's Event handler macros
  • CC: handling the pattern "A B = f();", since we now skip the right hand side of assignment in ParserThread class
  • CC: handling [ ] in Parserthread instead of Tokenizer. Also, avoid the recursive call of SkipUnwanted(), and change it to a while loop
  • CC: add a new function Tokenizer::Lex(), which only do a simple lex without any macro replacement handling, and the top level DoGetToken() function now get simplified. Also, in the most top level function (GetToken() and PeekToken()), the parentheses is read as a whole token. The Tokenizer::ReadParentheses(wxString& str) function are simplified and don't use the raw wxChar pointers, and make the code more readable
  • CC: improve the Tokenizer::CalcConditionExpression(), since DoGetToken() always return a valid expanded token
  • CC: remove the first parameter of Tokenizer::ReadToEOL, since we always don't count brace level
  • CC: remove the parameter of bool Tokenizer::SkipToEOL(bool nestBraces), since all the function pass the false argument. Update all the caller
  • CC: return "==" "=!" "=<" and "=>" as a single token in the Lex() function
  • CC: Tokenizer::MoveToNextChar() function simplify. Remove the parameter of this function, since if we move several chars, the condition of checking new line is not correct
  • CC: since the macro replacement is already done inside the GetToken() function, so no need to check the macro usage
  • CC: skip the [] brace when reading the var list
  • CC: when expanding function like macros, the actual parameter doesn't exists, thus the expansion failed, we need to reset the m_Lex, so that the caller don't get wrong token
  • CC: remove the user token replace rules load and save functions, we don't need them if we fully expand macros
  • CC: massive code remove about user defined macro replacements(include the UI parts). We don't need them any more. part 1
  • CC: use the macro expansion stack, this avoid expanding the used macros. Set the macro expansion stack limit value to 5, since I think 5 is enough
  • CC: fix a bug that in Parserthread, the token after #undef is already expanded
  • CC: clear up the Tokenizer state
  • CC: fix a bug that calculate the preprocessor directive exceeds the EOL
  • CC: fix variable parsing with "=" or "[]" (patch contributed by huki)
  • CC: handle comma char in ParserThread (patch contributed by huki)
  • CC: updated ComputeCallTip to remove macro replacement
  • CC: support macros in local scope (patch contributed by huki)
  • CC: fix the cctest regression on cc_function_ptr.cpp
  • CC: remove the macro replacement UI part in the CC's setting dialog
  • The dialog can't be resized because the wxRESIZE_BORDER option is missing here, see: http://forums.codeblocks.org/index.php/topic,20363.msg139248.html#msg139248
  • NSIS installer: fixed bug reported here: http://forums.codeblocks.org/index.php/topic,20537.0.html

Regressions/Confirmed/Annoying/Common bugs:



    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 01 September 2015 build (10474) is out.
    « Reply #1 on: September 02, 2015, 06:06:10 am »
    Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.
    These packages are build against wxWidgets 3.0 from Debian repos and mght not be as stable than the versions build against wx2.8, but there are no wx2.8 packages available (at least for stable) from official repos.
    Please test and give feedback.

    Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc21, fc22, fc23 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (64-bit) can be found in my rpm-repo.
    I recently switched to copr to build and host my Fedora and CentOS packages.
    Instructions how to use it can be found on my server (easier) or on copr (a little more handwork needed).

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9694
    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 carra

    • Multiple posting newcomer
    • *
    • Posts: 117
    Re: The 01 September 2015 build (10474) is out.
    « Reply #3 on: September 02, 2015, 01:31:32 pm »
    Seems to run fine under windows :)

    I can report news regarding the issues I posted here:
    • As you can see in image 1, the error when using initializers has been corrected
    • I have verified (see image 2) that CC parsers actually ARE recognising all members of my classes right! However, for classes not belonging to the current project, it fails to show any suggestions. In the image, when I typed "V55.", code completion did not show its members...

    Offline shurick

    • Multiple posting newcomer
    • *
    • Posts: 35
    Re: The 01 September 2015 build (10474) is out.
    « Reply #4 on: September 02, 2015, 05:22:11 pm »
    Packages for openSUSE (binaries and sources) for 32-bit and 64-bit.
    Packages for openSUSE http://codeblocks.esy.es  (binaries and sources) for 32-bit and 64-bit.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 01 September 2015 build (10474) is out.
    « Reply #5 on: September 03, 2015, 02:37:45 am »
    Seems to run fine under windows :)

    I can report news regarding the issues I posted here:
    • As you can see in image 1, the error when using initializers has been corrected
    • I have verified (see image 2) that CC parsers actually ARE recognising all members of my classes right!
    Good to hear. :)

    Quote
    However, for classes not belonging to the current project, it fails to show any suggestions. In the image, when I typed "V55.", code completion did not show its members...[/li]
    [/list]
    How can I reproduce your bug, are there any sample code snippet?
    EDIT: if a file is not belong to the active project, then its content is not parsed(if you enable the option as one parser for a project)



    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 carra

    • Multiple posting newcomer
    • *
    • Posts: 117
    Re: The 01 September 2015 build (10474) is out.
    « Reply #6 on: September 03, 2015, 12:20:27 pm »
    Quote
    How can I reproduce your bug, are there any sample code snippet?
    Sure, I have attached here a ZIP file of a very simple project where this happens (see the image). The error seems to come from namespaces: code completion triggers as expected if I simply define the following class and use it in Main.cpp

    Code
    namespace Math
    {
        class Vector2D{ ... };
    }

    However when the class is exported into another namespace, and a source file uses this second namespace, code completion will not trigger.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 01 September 2015 build (10474) is out.
    « Reply #7 on: September 04, 2015, 01:14:25 am »
    Quote
    How can I reproduce your bug, are there any sample code snippet?
    Sure, I have attached here a ZIP file of a very simple project where this happens (see the image). The error seems to come from namespaces: code completion triggers as expected if I simply define the following class and use it in Main.cpp

    Code
    namespace Math
    {
        class Vector2D{ ... };
    }

    However when the class is exported into another namespace, and a source file uses this second namespace, code completion will not trigger.
    OK, I can confirm it, this is a bug in CC, since CC doesn't handle the namespace export command. (CC just skip that statement).
    Please report to the sourceforge ticket with the sample code, so that this bug won't get lost. Thanks.

    About how to fix this bug, I don't have a clean idea, maybe, we need to remember the exported symbol as a child symbol in a namespace token? Maybe, we need a special field of the namespace token.
    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 carra

    • Multiple posting newcomer
    • *
    • Posts: 117
    Re: The 01 September 2015 build (10474) is out.
    « Reply #8 on: September 04, 2015, 07:40:47 am »
    Glad you can reproduce it Olly. I created the ticket, it's number #208.

    About the way to fix it, I have no idea of how CC works. But since the old one had always handled this case correctly, maybe you can see how it was done back then.

    Also, I seem to have messed the formatting badly in the ticket description, and there doesn't seem to be any way to edit it. If you are an admin there, feel free to correct it ;)
    « Last Edit: September 04, 2015, 07:43:07 am by carra »

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 01 September 2015 build (10474) is out.
    « Reply #9 on: September 04, 2015, 09:30:33 am »
    Glad you can reproduce it Olly. I created the ticket, it's number #208.

    About the way to fix it, I have no idea of how CC works. But since the old one had always handled this case correctly, maybe you can see how it was done back then.
    Really? But I think CC has never handle this case before, which revision did you see works OK?

    Quote
    Also, I seem to have messed the formatting badly in the ticket description, and there doesn't seem to be any way to edit it. If you are an admin there, feel free to correct it ;)
    Done. 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 carra

    • Multiple posting newcomer
    • *
    • Posts: 117
    Re: The 01 September 2015 build (10474) is out.
    « Reply #10 on: September 04, 2015, 12:52:54 pm »
    Really? But I think CC has never handle this case before, which revision did you see works OK?
    Wow, you are actually right! :o I have tested it in version 8242, which I used for a long time, and the bug is there too!! My guess is that I wasn't using this pattern in my headers at that time, and that I must have started using it just after switching to some newer version (that's why I believed the new CC to be the culprit).

    Offline Xaviou

    • Regular
    • ***
    • Posts: 402
      • X@v's wxStuff
    Re: The 01 September 2015 build (10474) is out.
    « Reply #11 on: September 04, 2015, 04:28:17 pm »
    Hi to all.

    I probably found a small bug in this release.
    The "Insert" => "All class methods without implementation" functionality of the editor removes the spaces between the parameters names and their types.

    Step to reproduce :
    • Create a new wxWidgets project (frame based) : let's name it wxCBTest
    • Open the frame's cpp file in the editor, and remove one of the events handlers (for example, remove all the implementation of wxCBTestFrame::OnClose) but don't touch the declaration.
    • Press [ Ctrl ] + [ Alt ] + [ S ] to save all the files (or press the "Save all files" toolbar button)
    • Right click in an empty line in the editor (witch should always be open on the frame's cpp file)
    • Select Insert => All class methods without implementation
    • The removed function should be present in the list : select it (and unselect others things if any)
    The declaration of the function is void OnClose(wxCloseEvent& event); (note the space between wxCloseEvent& and event).
    In the cpp file, the inserted method is now void OnClose(wxCloseEvent&event); (the space has been removed).

    I've made some test with the previous nightly (r10376) but the bug wasn't present.

    I also noticed that an old bug is still present : if in a class you have a method witch returns a pointer or a reference (for example wxString& GetAppPath()), the automatically inserted function with the Insert => All class methods without implementation doesn't have the correct type (the * or & sign is removed and the inserted text will be wxString wxCBTestFrame::GetAppPath()).

    Regards
    Xav'.
    The french wxWidgets site : http://www.wxdev.fr
    My wxWidgets's stuff : https://wxstuff.xaviou.fr/

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 01 September 2015 build (10474) is out.
    « Reply #12 on: September 05, 2015, 02:28:01 am »
    Hi to all.

    I probably found a small bug in this release.
    The "Insert" => "All class methods without implementation" functionality of the editor removes the spaces between the parameters names and their types.

    Step to reproduce :
    • Create a new wxWidgets project (frame based) : let's name it wxCBTest
    • Open the frame's cpp file in the editor, and remove one of the events handlers (for example, remove all the implementation of wxCBTestFrame::OnClose) but don't touch the declaration.
    • Press [ Ctrl ] + [ Alt ] + [ S ] to save all the files (or press the "Save all files" toolbar button)
    • Right click in an empty line in the editor (witch should always be open on the frame's cpp file)
    • Select Insert => All class methods without implementation
    • The removed function should be present in the list : select it (and unselect others things if any)
    The declaration of the function is void OnClose(wxCloseEvent& event); (note the space between wxCloseEvent& and event).
    In the cpp file, the inserted method is now void OnClose(wxCloseEvent&event); (the space has been removed).

    I've made some test with the previous nightly (r10376) but the bug wasn't present.
    Hi, thanks for the report, I can confirm this, it is caused by my CC patch serials to enable the macro expansion. I will look into it.

    Quote
    I also noticed that an old bug is still present : if in a class you have a method witch returns a pointer or a reference (for example wxString& GetAppPath()), the automatically inserted function with the Insert => All class methods without implementation doesn't have the correct type (the * or & sign is removed and the inserted text will be wxString wxCBTestFrame::GetAppPath()).

    Regards
    Xav'.
    It is another bug as I can see, I will look into it also.
    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 01 September 2015 build (10474) is out.
    « Reply #13 on: September 05, 2015, 02:35:46 am »
    Hi, thanks for the report, I can confirm this, it is caused by my CC patch serials to enable the macro expansion. I will look into it.
    The issue is caused by reading the parentheses, I just look at the token, I see that:
    Code
    $4 = {m_FullType = L"void", m_BaseType = L"void", m_Name = L"OnAbout", m_Args = L"(wxCommandEvent&event)", m_BaseArgs = L"(wxCommandEvent&)", m_AncestorsString = <g_strEmpty+12> L"", m_FileIdx = 293, m_Line = 31, m_ImplFileIdx = 0, m_ImplLine = 0, m_ImplLineStart = 100, m_ImplLineEnd = 102, m_Scope = tsPrivate, m_TokenKind = tkFunction, m_IsOperator = false, m_IsLocal = true, m_IsTemp = false, m_IsConst = false, m_IsNoExcept = false, m_IsAnonymous = false, m_Index = 68154, m_ParentIndex = 68149, m_Children = std::set with 0 elements, m_Ancestors = std::set with 0 elements, m_DirectAncestors = std::set with 0 elements, m_Descendants = std::set with 0 elements, m_Aliases = wxArray<T>, m_TemplateArgument = <g_strEmpty+12> L"", m_TemplateType = wxArray<T>, m_TemplateMap = std::map with 0 elements, m_TemplateAlias = <g_strEmpty+12> L"", m_UserData = 0x3c54f80, m_TokenTree = 0x1234cc08, m_Ticket = 68489}
    Look at the "m_Args" field.
    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 01 September 2015 build (10474) is out.
    « Reply #14 on: September 05, 2015, 04:47:50 am »
    @Xaviou
    The first issue is fixed in trunk now.

    The second issue is that it looks like the "*“ is lost in the Token. If I have a member function wxString * fff();
    Then, I get such token:
    Code
    $3 = {m_FullType = L"wxString", m_BaseType = L"wxString", m_Name = L"fff", m_Args = L"()"
    , m_BaseArgs = L"()", m_AncestorsString = <g_strEmpty+12> L"", m_FileIdx = 5, m_Line = 43, m_ImplFileIdx = 0, m_ImplLine = 0, m_ImplLineStart = 104, m_ImplLineEnd = 106, m_Scope = tsPrivate, m_TokenKind = tkFunction, m_IsOperator = false, m_IsLocal = true, m_IsTemp = false, m_IsConst = false, m_IsNoExcept = false, m_IsAnonymous = false, m_Index = 20415, m_ParentIndex = 20409
    , m_Children = std::set with 0 elements, m_Ancestors = std::set with 0 elements, m_DirectAncestors = std::set with 0 elements, m_Descendants = std::set with 0 elements, m_Aliases = wxArray<T>, m_TemplateArgument = <g_strEmpty+12> L"", m_TemplateType = wxArray<T>, m_TemplateMap = std::map with 0 elements, m_TemplateAlias = <g_strEmpty+12> L"", m_UserData = 0x0, m_TokenTree = 0x12340458, m_Ticket = 68900}
    This means either the m_FullType or the m_BaseType has no "*" information.
    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.