Code::Blocks

User forums => Announcements => Topic started by: killerbot on November 22, 2015, 09:13:15 pm

Title: Release 15.12, RC1 has arrived
Post by: killerbot on November 22, 2015, 09:13:15 pm
RC1 candidate (i.e. full installer) of new Code::Blocks release for Windows can be found here:
http://sourceforge.net/projects/codeblocks/files/Binaries/15.12-RC1/codeblocks-15.12-setup-RC1.exe

...the same, but bundled with MinGW:
http://sourceforge.net/projects/codeblocks/files/Binaries/15.12-RC1/codeblocks-15.12mingw-setup-RC1.exe


Linux packages are here:
TO BE ADDED

Any feedback is welcome. Please consider that we are in "feature freeze", which means no new features will make it into the next release, but urgent bug-fixes.

Report back in this forum:
http://forums.codeblocks.org/index.php/board,7.0.html
...precisely here:
http://forums.codeblocks.org/index.php/topic,20730.0.html
Title: Re: Release 15.12, RC1 has arrived
Post by: Folco on November 24, 2015, 06:19:21 am
Not tested yet, but good job !
Title: Re: Release 15.12, RC1 has arrived
Post by: ffs on November 29, 2015, 03:03:17 pm
Hello.

I have problem with code completion with this release.

When I type this code:
Code: [Select]
#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
   
    v.
   
    return 0;
}

and after v. I should get code completion.
BUT when I type using namespace std;
and just vector<int> v; then when I type v. everything works good.

Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?
Title: Re: Release 15.12, RC1 has arrived
Post by: jens on December 08, 2015, 05:54:01 am
From what I see at the SourceForge Website is 15-12 RC1 is downloadable for Windows 8, 7, Vista only.
Does anyone know if it will work with Windows 10 64 bit?
The nightlies did, so there is no cause to believe the rc1 does not.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 08, 2015, 01:28:53 pm
From what I see at the SourceForge Website is 15-12 RC1 is downloadable for Windows 8, 7, Vista only.
What makes you say so? I don't see such limitation...?!
Title: Re: Release 15.12, RC1 has arrived
Post by: NearTox on December 08, 2015, 04:05:59 pm
Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?

It's a problem with CC(Code Completion), specifically with the macros replacement (Replacement tokens), that was erased or are missed (after of the nightly build 10320)
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 09, 2015, 03:33:25 pm
Hello.

I have problem with code completion with this release.

When I type this code:
Code: [Select]
#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
   
    v.
   
    return 0;
}

and after v. I should get code completion.
BUT when I type using namespace std;
and just vector<int> v; then when I type v. everything works good.

Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?
Fine here, see the screen shot:
(http://imagizer.imageshack.us/v2/836x376q90/910/ZqGkt0.png)
I use the wx3.0.2 and c::b trunk under windows(rev10609)
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 09, 2015, 08:39:19 pm
I use the wx3.0.2 and c::b trunk under windows(rev10609)
I use wx 2.8.12 and GCC 5.1.0 and it does not work at all. I think it does not work for others, too this way...

And it is our fault because if I revert back to r10437 it works for me on the same setup...
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 01:10:11 am
@morten:
I think I may found some reason.
I do have some tiny CC patches against the trunk, but I think that doesn't cause the "fix". The reason is that when I test my own build, I see it use an quite old gcc 4.7 compiler, so our parser can parse the headers from this gcc.

When I test the nightly build rev10574 or my own build c::b with the mingw build 5.2 from mingw-w64 site, and the "v." dose not show any code suggestion, so it looks like our parser fails to parse the newer gcc's header.

I will look into it.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 01:26:11 am
I see I found the reason, it is a bug in parsing the code: (both gcc 4.7 and 5.2 have such code)
Code: [Select]
namespace std _GLIBCXX_VISIBILITY(default)
{
...
}
especially expanding the _GLIBCXX_VISIBILITY(default) macro usage.

Under testing of GCC 4.7 or GCC 5.2, I can find the the definition of _GLIBCXX_VISIBILITY, they both point to:
Code: [Select]
# define _GLIBCXX_VISIBILITY(V) _GLIBCXX_PSEUDO_VISIBILITY(V)
While, under GCC 5.2, I can't find the definition of _GLIBCXX_PSEUDO_VISIBILITY, while under 4.7, I can. That's the point.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 01:44:01 am
To simplify the issue, you can simply create a simple cpp file, which does not include any other files:

Code: [Select]
# define _GLIBCXX_VISIBILITY(V) _GLIBCXX_PSEUDO_VISIBILITY(V)
namespace std _GLIBCXX_VISIBILITY(default)
{
    class vector
    {
        size_t size();
    }
}

Then, you can type "std::"
If the std namespace is parse correctly, then you should show "std::vector", but actually it is not.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 01:50:15 am
Code: [Select]
void ParserThread::HandleNamespace()
{
    wxString ns = m_Tokenizer.GetToken();
    int line = m_Tokenizer.GetLineNumber();

    if (ns == ParserConsts::opbrace)
    {
        // parse inside anonymous namespace
        Token*     lastParent = m_LastParent;
        TokenScope lastScope  = m_LastScope;

        DoParse();

        m_LastParent = lastParent;
        m_LastScope   = lastScope;
    }
    else
    {
        // for namespace aliases to be parsed, we need to tell the tokenizer
        // not to skip the usually unwanted tokens. One of those tokens is the
        // "assignment" (=).
        // we just have to remember to revert this setting below, or else problems will follow
        m_Tokenizer.SetState(tsNormal);

        wxString next = m_Tokenizer.PeekToken(); // named namespace
        if (next==ParserConsts::opbrace)
        {
            m_Tokenizer.SetState(tsNormal);

            // use the existing copy (if any)
            Token* newToken = TokenExists(ns, m_LastParent, tkNamespace);
            if (!newToken)
                newToken = DoAddToken(tkNamespace, ns, line);
            if (!newToken)
            {
                TRACE(_T("HandleNamespace() : Unable to create/add new token: ") + ns);
                return;
            }

            m_Tokenizer.GetToken(); // eat {
            int lineStart = m_Tokenizer.GetLineNumber();

            Token*     lastParent = m_LastParent; // save status, will restore after DoParse()
            TokenScope lastScope  = m_LastScope;

            m_LastParent = newToken;
            // default scope is: public for namespaces (actually no, but emulate it)
            m_LastScope   = tsPublic;

            DoParse();

            m_LastParent = lastParent;
            m_LastScope   = lastScope;

            // update implementation file and lines of namespace.
            // this doesn't make much sense because namespaces are all over the place,
            // but do it anyway so that buffer-based parsing returns the correct values.
            newToken->m_ImplFileIdx   = m_FileIdx;
            newToken->m_ImplLine      = line;
            newToken->m_ImplLineStart = lineStart;
            newToken->m_ImplLineEnd   = m_Tokenizer.GetLineNumber();
        }
        else if (next==ParserConsts::equals)
        {
            // namespace alias; example from cxxabi.h:
            //
            // namespace __cxxabiv1
            // {
            // ...
            // }
            // namespace abi = __cxxabiv1; <-- we 're in this case now

            m_Tokenizer.GetToken(); // eat '='
            m_Tokenizer.SetState(tsNormal);

            Token* lastParent = m_LastParent;
            Token* aliasToken = NULL;

            while (IS_ALIVE)
            {
                wxString aliasStr = m_Tokenizer.GetToken();

                // use the existing copy (if any)
                aliasToken = TokenExists(aliasStr, m_LastParent, tkNamespace);
                if (!aliasToken)
                    aliasToken = DoAddToken(tkNamespace, aliasStr, line);
                if (!aliasToken)
                    return;

                if (m_Tokenizer.PeekToken() == ParserConsts::dcolon)
                {
                    m_Tokenizer.GetToken();
                    m_LastParent = aliasToken;
                }
                else
                    break;
            }

            aliasToken->m_Aliases.Add(ns);
            m_LastParent = lastParent;
        }
        else
        {
            m_Tokenizer.SetState(tsNormal);
            // probably some kind of error in code ?
            SkipToOneOfChars(ParserConsts::semicolonopbrace);
        }
    }
}
For the above code, I see that it finally run the SkipToOneOfChars(ParserConsts::semicolonopbrace);
So that the "{" is skipped, thus the "vector" token is put in the global namespace.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 01:58:24 am
In the above example, the three token will be skipped from the function SkipToOneOfChars(ParserConsts::semicolonopbrace);
Code: [Select]
1, _GLIBCXX_PSEUDO_VISIBILITY
2, (default)
3, {
I think the fix should be:
If we skip from the "{", we should handle it like the code before:
Code: [Select]
   wxString next = m_Tokenizer.PeekToken(); // named namespace
        if (next==ParserConsts::opbrace)
        {
            m_Tokenizer.SetState(tsNormal);

            // use the existing copy (if any)
            Token* newToken = TokenExists(ns, m_LastParent, tkNamespace);
            if (!newToken)
                newToken = DoAddToken(tkNamespace, ns, line);
            if (!newToken)
            {
                TRACE(_T("HandleNamespace() : Unable to create/add new token: ") + ns);
                return;
            }

            m_Tokenizer.GetToken(); // eat {
            int lineStart = m_Tokenizer.GetLineNumber();

            Token*     lastParent = m_LastParent; // save status, will restore after DoParse()
            TokenScope lastScope  = m_LastScope;

            m_LastParent = newToken;
            // default scope is: public for namespaces (actually no, but emulate it)
            m_LastScope   = tsPublic;

            DoParse();
            ...
            ...

The function DoParse() will carefully parse the body inside the "{ .... }", and put the "class vector" as a child of std namespace.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 02:27:52 am
This is the patch to fix such issue:
Code: [Select]
src/plugins/codecompletion/parser/parserthread.cpp | 166 ++++++++++++---------
 1 file changed, 97 insertions(+), 69 deletions(-)

diff --git a/src/plugins/codecompletion/parser/parserthread.cpp b/src/plugins/codecompletion/parser/parserthread.cpp
index a22cb61..bd9a31f 100644
--- a/src/plugins/codecompletion/parser/parserthread.cpp
+++ b/src/plugins/codecompletion/parser/parserthread.cpp
@@ -1762,95 +1762,123 @@ void ParserThread::HandleNamespace()
     }
     else
     {
-        // for namespace aliases to be parsed, we need to tell the tokenizer
-        // not to skip the usually unwanted tokens. One of those tokens is the
-        // "assignment" (=).
-        // we just have to remember to revert this setting below, or else problems will follow
-        m_Tokenizer.SetState(tsNormal);
 
-        wxString next = m_Tokenizer.PeekToken(); // named namespace
-        if (next==ParserConsts::opbrace)
+        while (true)
         {
+            // for namespace aliases to be parsed, we need to tell the tokenizer
+            // not to skip the usually unwanted tokens. One of those tokens is the
+            // "assignment" (=).
+            // we just have to remember to revert this setting below, or else problems will follow
             m_Tokenizer.SetState(tsNormal);
 
-            // use the existing copy (if any)
-            Token* newToken = TokenExists(ns, m_LastParent, tkNamespace);
-            if (!newToken)
-                newToken = DoAddToken(tkNamespace, ns, line);
-            if (!newToken)
+            wxString next = m_Tokenizer.PeekToken(); // named namespace
+            if (next==ParserConsts::opbrace)
             {
-                TRACE(_T("HandleNamespace() : Unable to create/add new token: ") + ns);
-                return;
-            }
+                m_Tokenizer.SetState(tsNormal);
 
-            m_Tokenizer.GetToken(); // eat {
-            int lineStart = m_Tokenizer.GetLineNumber();
+                // use the existing copy (if any)
+                Token* newToken = TokenExists(ns, m_LastParent, tkNamespace);
+                if (!newToken)
+                    newToken = DoAddToken(tkNamespace, ns, line);
+                if (!newToken)
+                {
+                    TRACE(_T("HandleNamespace() : Unable to create/add new token: ") + ns);
+                    return;
+                }
 
-            Token*     lastParent = m_LastParent; // save status, will restore after DoParse()
-            TokenScope lastScope  = m_LastScope;
+                m_Tokenizer.GetToken(); // eat {
+                int lineStart = m_Tokenizer.GetLineNumber();
 
-            m_LastParent = newToken;
-            // default scope is: public for namespaces (actually no, but emulate it)
-            m_LastScope   = tsPublic;
+                Token*     lastParent = m_LastParent; // save status, will restore after DoParse()
+                TokenScope lastScope  = m_LastScope;
 
-            DoParse();
+                m_LastParent = newToken;
+                // default scope is: public for namespaces (actually no, but emulate it)
+                m_LastScope   = tsPublic;
 
-            m_LastParent = lastParent;
-            m_LastScope   = lastScope;
-
-            // update implementation file and lines of namespace.
-            // this doesn't make much sense because namespaces are all over the place,
-            // but do it anyway so that buffer-based parsing returns the correct values.
-            newToken->m_ImplFileIdx   = m_FileIdx;
-            newToken->m_ImplLine      = line;
-            newToken->m_ImplLineStart = lineStart;
-            newToken->m_ImplLineEnd   = m_Tokenizer.GetLineNumber();
-        }
-        else if (next==ParserConsts::equals)
-        {
-            // namespace alias; example from cxxabi.h:
-            //
-            // namespace __cxxabiv1
-            // {
-            // ...
-            // }
-            // namespace abi = __cxxabiv1; <-- we 're in this case now
-
-            m_Tokenizer.GetToken(); // eat '='
-            m_Tokenizer.SetState(tsNormal);
+                DoParse();
 
-            Token* lastParent = m_LastParent;
-            Token* aliasToken = NULL;
+                m_LastParent = lastParent;
+                m_LastScope   = lastScope;
 
-            while (IS_ALIVE)
+                // update implementation file and lines of namespace.
+                // this doesn't make much sense because namespaces are all over the place,
+                // but do it anyway so that buffer-based parsing returns the correct values.
+                newToken->m_ImplFileIdx   = m_FileIdx;
+                newToken->m_ImplLine      = line;
+                newToken->m_ImplLineStart = lineStart;
+                newToken->m_ImplLineEnd   = m_Tokenizer.GetLineNumber();
+
+                // the namespace body is correctly parsed
+                break;
+            }
+            else if (next==ParserConsts::equals)
             {
-                wxString aliasStr = m_Tokenizer.GetToken();
+                // namespace alias; example from cxxabi.h:
+                //
+                // namespace __cxxabiv1
+                // {
+                // ...
+                // }
+                // namespace abi = __cxxabiv1; <-- we 're in this case now
 
-                // use the existing copy (if any)
-                aliasToken = TokenExists(aliasStr, m_LastParent, tkNamespace);
-                if (!aliasToken)
-                    aliasToken = DoAddToken(tkNamespace, aliasStr, line);
-                if (!aliasToken)
-                    return;
+                m_Tokenizer.GetToken(); // eat '='
+                m_Tokenizer.SetState(tsNormal);
 
-                if (m_Tokenizer.PeekToken() == ParserConsts::dcolon)
+                Token* lastParent = m_LastParent;
+                Token* aliasToken = NULL;
+
+                while (IS_ALIVE)
                 {
-                    m_Tokenizer.GetToken();
-                    m_LastParent = aliasToken;
+                    wxString aliasStr = m_Tokenizer.GetToken();
+
+                    // use the existing copy (if any)
+                    aliasToken = TokenExists(aliasStr, m_LastParent, tkNamespace);
+                    if (!aliasToken)
+                        aliasToken = DoAddToken(tkNamespace, aliasStr, line);
+                    if (!aliasToken)
+                        return;
+
+                    if (m_Tokenizer.PeekToken() == ParserConsts::dcolon)
+                    {
+                        m_Tokenizer.GetToken();
+                        m_LastParent = aliasToken;
+                    }
+                    else
+                        break;
                 }
+
+                aliasToken->m_Aliases.Add(ns);
+                m_LastParent = lastParent;
+
+                // the namespace alias statement is correctly parsed
+                break;
+            }
+            else
+            {
+                m_Tokenizer.SetState(tsNormal);
+                // probably some kind of error in code ?
+                SkipToOneOfChars(ParserConsts::semicolonopbrace);
+
+                // in case of the code:
+                //
+                //    # define _GLIBCXX_VISIBILITY(V) _GLIBCXX_PSEUDO_VISIBILITY(V)
+                //    namespace std _GLIBCXX_VISIBILITY(default)
+                //    {
+                //        class vector
+                //        {
+                //            size_t size();
+                //        }
+                //    }
+                // we still want to parse the body of the namespace, but skip the tokens before "{"
+                m_Tokenizer.UngetToken();
+                wxString peek = m_Tokenizer.PeekToken();
+                if(peek == ParserConsts::opbrace)
+                    continue;
                 else
                     break;
             }
-
-            aliasToken->m_Aliases.Add(ns);
-            m_LastParent = lastParent;
-        }
-        else
-        {
-            m_Tokenizer.SetState(tsNormal);
-            // probably some kind of error in code ?
-            SkipToOneOfChars(ParserConsts::semicolonopbrace);
-        }
+        } // while(true)
     }
 }
 

Please test and give feedback. The method I use is: I just check which token is skipped by the SkipToOneOfChars(), if it is the "{", then I need to still parse it as the beginning of the namespace body.

The issue I see that, when I hit the dot, I see the suggestion window pop up, and disappeared quickly, so no suggestion after the dot. I'm not sure the reason. But if I continue enter the member function, like "push_", I get the correct result, see the image shot below:
(http://imagizer.imageshack.us/v2/828x365q90/908/datUo8.png)

The patch is in GIT style, so you need the patch utility to apply it in your local copy.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 10, 2015, 09:21:02 am
This is the patch to fix such issue:
That looks very good - its working for me again now.

Great work! I'll some some more testing on larger projects but so far I see no negative side-effects. If you commit, please also add the source snippet to the test cases.

BTW: The patch applied as-it-is just fine.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 10, 2015, 03:51:32 pm
This is the patch to fix such issue:
That looks very good - its working for me again now.

Great work! I'll some some more testing on larger projects but so far I see no negative side-effects. If you commit, please also add the source snippet to the test cases.

BTW: The patch applied as-it-is just fine.
Grad to see that the patch works OK from your side.
I have committed the fix, as I think we will make a final release in this month. Also a test case is added.
Title: Re: Release 15.12, RC1 has arrived
Post by: nanyu on December 11, 2015, 06:12:08 pm
1) add "-std=c++11" option
2) everything ok with:

#include <vector>

int main()
{
          std::vector<int> a1 = {1,2};
          a1.    //<--- cc do everything ok..
}

3) but..
#include <vector>

int main()
{
          std::vector<int> a1  {1,2};
          a1.    //<--- cc did not work.
}
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 11, 2015, 09:06:14 pm
nanyu: What build are you testing with?
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 11, 2015, 09:19:01 pm
nanyu: What build are you testing with?
It really does not work. Its a rather new feature of C++ we didn't account for in the parser yet.
But I don't think many people actually use it to initialise a vector. It would be rather bad style and hardly "portable".

So for now I would say please file a bug report so it gets not forgotten, but we'll take care after the upcoming release.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 11, 2015, 09:36:33 pm
Uf, I thought this is the same case as the one ollydbg has just fixed.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 11, 2015, 10:44:11 pm
Uf, I thought this is the same case as the one ollydbg has just fixed.
No, its related to the assignment of the vector with values w/o the equal sign. So that is a different story. It should be doable, but I'm afraid we might break other things, thats why I would postpone it.

The actual bug you were referring to is already fixed.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 11, 2015, 10:52:20 pm
I suppose the new Debian version from jenslody is RC1? svn build rev 10611.
It worked a lot better than last nightly build so far, but got one crash when I was clicking to open a second project via the "File" - "Recent projects".

Last console output:

Switching layout to "GDB/CDB debugger:Default"

(codeblocks:2591): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'width >= -1' failed
Switching layout to "Code::Blocks default"

Crashlog is appended.
System is Debian Jessie 64 bit.
I could not reproduce the bug so far :-(
Title: Re: Release 15.12, RC1 has arrived
Post by: jens on December 11, 2015, 10:59:59 pm
I suppose the new Debian version from jenslody is RC1? svn build rev 10611.
It worked a lot better than last nightly build so far, but got one crash when I was clicking to open a second project via the "File" - "Recent projects".

Last console output:

Switching layout to "GDB/CDB debugger:Default"

(codeblocks:2591): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'width >= -1' failed
Switching layout to "Code::Blocks default"

Crashlog is appended.
System is Debian Jessie 64 bit.
I could not reproduce the bug so far :-(
The main problem with my Debian packages is, that they are linked against wx3.0.
This is still not fully supported.
But Debian does no longer provide wx2.8 in the official repos and therefore, there is no alternative.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 11, 2015, 11:13:28 pm
I see, thanks for the info!
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 12, 2015, 12:27:11 am
Can you try to reproduce it again and then report what are the minimal steps needed to reproduce it.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 12, 2015, 05:29:36 pm
@oBFusCATed: Unfortunately I couldn't reproduce it at all so far. Just something that happened after a few hours working with it a single time.
Title: Re: Release 15.12, RC1 has arrived
Post by: alin on December 16, 2015, 04:23:49 pm
packages for opensuse Tumbleweed if anyone is intersted
http://download.opensuse.org/repositories/home:/ealin:/varia/openSUSE_Tumbleweed/
check for codeblocks-unstable

I may be able to produce packages for other opensuse recent versions... just ping me.

Alin
Title: Re: Release 15.12, RC1 has arrived
Post by: ssawgift on December 17, 2015, 08:06:56 am
Though I do not use CB seriously, but I do use it to do experiments in my C/C++ learning. Tried 3 projects (console and WIN32 SDI GUI), all work fine.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 17, 2015, 11:34:19 am
@jens: Is it still worth reporting wx3.0 crashes? Last evening I spend another few hours with your build - and unfortunately I got so many crashes that it's getting hard to code with it. Especially when doing global global search&replace with many files. I sometimes got several crashes within minutes when refactoring code. Never easy reproducible, but always happening after a working with it a while. And generally getting some asserts first like the one above.

I'd like to help with reports - can also start from console and enable additional output etc if that is possible. But given the amount of crashes I had, I suppose you probably still get them yourself enough anyway. So not sure if it's worth reporting each one currently?
Title: Re: Release 15.12, RC1 has arrived
Post by: jens on December 17, 2015, 03:59:56 pm
@jens: Is it still worth reporting wx3.0 crashes? Last evening I spend another few hours with your build - and unfortunately I got so many crashes that it's getting hard to code with it. Especially when doing global global search&replace with many files. I sometimes got several crashes within minutes when refactoring code. Never easy reproducible, but always happening after a working with it a while. And generally getting some asserts first like the one above.

I'd like to help with reports - can also start from console and enable additional output etc if that is possible. But given the amount of crashes I had, I suppose you probably still get them yourself enough anyway. So not sure if it's worth reporting each one currently?
I do not work on Debian, and use C::B with wx3 in maost cases with disabled Codecompletion-plugin.
But I get also random crashes and I get also random crashes with C::B and wx2.8 on linux 64Bit compiled with gcc 5.3 .
But unfortunately I did not have the time to reproduce it.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 17, 2015, 09:15:12 pm
If you're getting asserts please report them, I'm trying to fix as many as I can.
Also if you get crashes it would be good if they are reported, so we can try to do something about them.
I'm running a wx3.0 build of C::B at home in order to test it more, but I don't have much time to code at home at the moment so I'm not testing it much:(
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 18, 2015, 12:12:52 am
Assert (without crash) after doing very long nothing with c::b, followed by Find in files over workspace files and then double-clicking one of the results):

ASSERT INFO:
../include/wx/dynarray.h(838): assert "uiIndex < m_nCount" failed in Item().

BACKTRACE:
[1] wxGenericTreeCtrl::CalculateLevel(wxGenericTreeItem*, wxDC&, int, int&)
[2] wxGenericTreeCtrl::CalculatePositions()
[3] wxGenericTreeCtrl::DoDirtyProcessing()
[4] wxGenericTreeCtrl::OnInternalIdle()
[5] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[6] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[7] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[8] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[9] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[10] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[11] wxFrame::SendIdleEvents(wxIdleEvent&)
[12] wxAppBase::ProcessIdle()
[13] wxApp::DoIdle()
[14] g_main_context_dispatch
[15] g_main_loop_run
[16] gtk_main
[17] wxGUIEventLoop::DoRun()
[18] wxEventLoopBase::Run()
[19] wxAppConsoleBase::MainLoop()
[20] CodeBlocksApp::OnRun() /tmp/buildd/codeblocks-13.12svn10621/src/src/app.cpp:852
[21] wxEntry(int&, wchar_t**)
[22] main /tmp/buildd/codeblocks-13.12svn10621/src/src/app.cpp:322
[23] __libc_start_main

Build: Dec 10 2015, 22:09:58 - wx3.0.2 (Linux, unicode) - 64 bit
On Debian stable.

edit: Got the same assert with same callstack later on when switching betwen files by clicking a tab. So it's maybe related to bringing some file to the front in the editor. Also not just getting it once but maybe 5 times in a row.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 18, 2015, 08:26:26 am
Do you have the option to sync the editor and the project tree enabled?

Also can you share your project or checkout the codeblocks' source code and try to reproduce it with some of the projects or workspaces in it?

edit: Also have you added or removed some files to the workspace projects between the find in files and double clicking results?
Title: Re: Release 15.12, RC1 has arrived
Post by: ssawgift on December 18, 2015, 12:54:24 pm
I use CB inside a Windows XP virtual machine. I see that it does not have XP styles (specifically the buttons don't have visual effects).
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 18, 2015, 07:58:47 pm
Do you have the option to sync the editor and the project tree enabled?
Hm, help me - I'm not finding that option so far.

Also can you share your project or checkout the codeblocks' source code and try to reproduce it with some of the projects or workspaces in it?
The project I've been working on is this one: https://bitbucket.org/mzeilfelder/trunk_hc1
But I fear it's not that easy to set-up, I don't really expect you to do that :-)
I had also the Irrlicht engine project open the same time (the one in libs/irrlicht/source/Irrlicht in the h-craft project).
If I can figure out any way to reproduce this in a less random way I'll inform you. But so far the only common factor I found is that it's happening when a new file should be displayed in the editor (not even sure yet if it's also happening when the file was already open in the background).

edit: Also have you added or removed some files to the workspace projects between the find in files and double clicking results?
No, I didn't do that. 
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 18, 2015, 08:08:00 pm
Hm, help me - I'm not finding that option so far.
You'll know if you have this option enabled if when you switch between file the same file gets selected in the project tree.
The option is in Settings -> Editor -> General -> Other editor settings -> Synchronise editor with Project manager.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 18, 2015, 08:33:12 pm
Nice option. Didn't have it enabled, but definitely will enable it in future :-)
But I did have the "open file list" from the open files list plugin open. And that did synchronize already.
Title: Re: Release 15.12, RC1 has arrived
Post by: ssawgift on December 19, 2015, 07:36:54 am
I'm on the opposite.

Code completion works for me in your case. However, if do 'using namespace std' and 'vector<int> v', I won't get autocompletion.

BTW, I use CB RC1 on Windows XP.

Hello.

I have problem with code completion with this release.

When I type this code:
Code: [Select]
#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
   
    v.
   
    return 0;
}

and after v. I should get code completion.
BUT when I type using namespace std;
and just vector<int> v; then when I type v. everything works good.

Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 19, 2015, 09:51:57 am
Don't know if it's related to my asserts. But when I start codeblocks from console I get the following message right on start (before opening any projects):
(codeblocks:2292): Gtk-CRITICAL **: IA__gtk_tree_model_iter_nth_child: assertion 'n >= 0' failed

edit: I could reproduce the assert now once the same way as before. I opened codeblocks with 2 project and a few open files in the editor and the Open files list visible. Then worked for a few hours on other stuff just keeping it in background. Switched back to c::b did a global search for something - and got the assert again. The synchronize settings was again disabled.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 19, 2015, 01:22:16 pm
OK, it's not about time spend in background. It happens when the "Search results" box contains a result which needs no scrollbars. And then I make a new search which needs scrollbars - but just barely (like the result has 1-2 line more than what would fit in the window without scrollbars).  Doing that I could reproduce the assert now a few times. Searching again when the scrollbars are already there with same search won't give the assert again even when I try different sizes for the "Search results" window. Only when I clear it in between (using a new search which is found less often).

edit: Thinking about it some more - it could also have been affected by the file-order opened on clicking search-results. So the other part would just have been random. Because when I tested resizing the "Search results" dialog I also resized the editor window which was above.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 19, 2015, 02:41:41 pm
I'm on the opposite.

Code completion works for me in your case. However, if do 'using namespace std' and 'vector<int> v', I won't get autocompletion.

BTW, I use CB RC1 on Windows XP.

Hello.

I have problem with code completion with this release.

When I type this code:
Code: [Select]
#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
   
    v.
   
    return 0;
}

and after v. I should get code completion.
BUT when I type using namespace std;
and just vector<int> v; then when I type v. everything works good.

Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?
@ssawgift, both the two cases works fine here for the latest svn10625. Which compiler do you use?
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 20, 2015, 01:33:56 am
Another crash, unfortunately no crash-dialog this time. It happened when I started the debugger (gdb 7.7.1).
On console the last messages had been:

Switching layout to "GDB/CDB debugger:Default"
../src/gtk/colour.cpp(241): assert "IsOk()" failed in GetColor(): invalid colour
Trace/breakpoint trap

Also another problem twice today where the debugger froze - and caused C::B to freeze as well (no more screen updates). When killed the debugger manually (with killall gdb) then C::B continued to work again.

edit: Got another crash when starting the debugger. This time last messages had been:
Switching layout to "GDB/CDB debugger:Default"
../src/common/object.cpp(352): assert "m_count > 0" failed in DecRef(): invalid ref data count
*** Error in `codeblocks': malloc(): smallbin double linked list corrupted: 0x00000000023bbaf0 ***
Aborted
Title: Re: Release 15.12, RC1 has arrived
Post by: ssawgift on December 20, 2015, 07:52:59 am
I'm on the opposite.

Code completion works for me in your case. However, if do 'using namespace std' and 'vector<int> v', I won't get autocompletion.

BTW, I use CB RC1 on Windows XP.

Hello.

I have problem with code completion with this release.

When I type this code:
Code: [Select]
#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
   
    v.
   
    return 0;
}

and after v. I should get code completion.
BUT when I type using namespace std;
and just vector<int> v; then when I type v. everything works good.

Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?
@ssawgift, both the two cases works fine here for the latest svn10625. Which compiler do you use?

I use gcc 4.9.3 built by MinGW-W64 project.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/i686-w64-mingw32/4.9.3/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.9.3/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-min
gw32 --prefix=/mingw32 --with-sysroot=/c/mingw493/i686-493-win32-dwarf-rt_v4-rev1/mingw32 --with-gxx-include-dir=/mingw3
2/i686-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,objc,
obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable
-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-
exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-lib
stdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symver
s --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/ming
w493/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw493/prerequisites/i686-w64-mingw32-static --with-mpc=/c/m
ingw493/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw493/prerequisites/i686-w64-mingw32-static --with-cloog=
/c/mingw493/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-win32-dwarf-rev1, B
uilt by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw493/i686-
493-win32-dwarf-rt_v4-rev1/mingw32/opt/include -I/c/mingw493/prerequisites/i686-zlib-static/include -I/c/mingw493/prereq
uisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw493/i686-493-win32-dwarf-rt_v4-rev1/mingw32/opt/i
nclude -I/c/mingw493/prerequisites/i686-zlib-static/include -I/c/mingw493/prerequisites/i686-w64-mingw32-static/include'
 CPPFLAGS= LDFLAGS='-pipe -L/c/mingw493/i686-493-win32-dwarf-rt_v4-rev1/mingw32/opt/lib -L/c/mingw493/prerequisites/i686
-zlib-static/lib -L/c/mingw493/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware'
Thread model: win32
gcc version 4.9.3 (i686-win32-dwarf-rev1, Built by MinGW-W64 project)


I want to add that I tried code completion using one of my test project which is a bit more complex than the test code in the post I replied to.

However, I do not have problems with typedefs:

typedef vector<int> vi;

Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 20, 2015, 09:48:02 am
@ssawgift, both the two cases works fine here for the latest svn10625. Which compiler do you use?
I use gcc 4.9.3 built by MinGW-W64 project.
...
I just tested this compiler, and it works fine here on my system with the latest svn rev10626.
EDIT: I'm on my local c::b build against wx3.0.2
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 20, 2015, 03:50:56 pm
Next crash - I had just started C::B a few seconds before and was modifying a comment in a header. No crash-dialog, just those messages on the console where I started codeblocks:

ClassBrowser::OnThreadEvent(): Updating class browser...
codeblocks: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
../src/common/debugrpt.cpp(453): assert "IsOk()" failed in AddContext(): use IsOk() first
Title: Re: Release 15.12, RC1 has arrived
Post by: ssawgift on December 20, 2015, 04:22:08 pm
@ssawgift, both the two cases works fine here for the latest svn10625. Which compiler do you use?
I use gcc 4.9.3 built by MinGW-W64 project.
...
I just tested this compiler, and it works fine here on my system with the latest svn rev10626.
EDIT: I'm on my local c::b build against wx3.0.2

I found out why. It's caused by parsing delay. the 'using namespace std' scenario always takes much much more time than the other two cases.

For std::vector<int> and typedef cases, code completion is available almost instantly; but for the 'using namespace std' case, it usually takes more than 10 second in my case (a Windows XP virtual machine using VirtualBox).
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 20, 2015, 04:31:23 pm
@CuteAlien:
Posting these is not very useful. Can you start codeblocks under gdb and post full backtraces when something crashes. You'll have to install the debug info package for these to be meaningful.

I'm having some crashes when using cb built with wx3, too, so hopefully I'll be able to get a meaningful backtrace.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 20, 2015, 09:36:45 pm
Yeah, I feared that it's not enough information. My hope is only that some assert might seem familiar and for example gives you an idea about further asserts to add which get us closer.
I can try the gdb setup I guess. Thought I get the feeling the crashes are not exactly related to the actions I do when it crashes. Far too random and all over the place - and never reproducible. So likely even a callstack won't give the answer. But maybe more hints.
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 20, 2015, 09:53:20 pm
OK, here's a crash with gdb callstack (was typing code in the editor):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f36f1f3c700 (LWP 11483)]
0x00007f36fec36428 in IsOk (this=0x4455f88) at ../include/wx/gdiobj.h:49
49      ../include/wx/gdiobj.h: No such file or directory.
(gdb) bt
#0  0x00007f36fec36428 in IsOk (this=0x4455f88) at ../include/wx/gdiobj.h:49
#1  wxWindowBase::GetBackgroundColour (this=this@entry=0x4455eb0) at ../src/common/wincmn.cpp:1588
#2  0x00007f36feb08270 in wxDCImpl::InheritAttributes (this=0x7f36d0205eb0, win=0x4455eb0)
    at ../src/common/dcbase.cpp:1031
#3  0x00007f36feb07f74 in wxNativeDCFactory::CreateClientDC (this=<optimized out>, owner=0x7f36f1f3b790,
    window=0x4455eb0) at ../src/common/dcbase.cpp:143
#4  0x00007f36feb0a090 in wxClientDC::wxClientDC (this=0x7f36f1f3b790, win=0x4455eb0)
    at ../src/common/dcbase.cpp:210
#5  0x00007f36fecbd907 in wxGenericTreeCtrl::CalculatePositions (this=this@entry=0x4455eb0)
    at ../src/generic/treectlg.cpp:3983
#6  0x00007f36fecbef40 in wxGenericTreeCtrl::DoDirtyProcessing (this=0x4455eb0)
    at ../src/generic/treectlg.cpp:4145
#7  0x00007f36cb3b2fc8 in ClassBrowserBuilderThread::BuildTree (this=this@entry=0x445d4d0)
    at classbrowserbuilderthread.cpp:566
#8  0x00007f36cb3b369a in ClassBrowserBuilderThread::Entry (this=0x445d4d0)
    at classbrowserbuilderthread.cpp:220
#9  0x00007f36fe0163a2 in wxThread::CallEntry (this=this@entry=0x445d4d0) at ../include/wx/thrimpl.cpp:356
#10 0x00007f36fe016c83 in wxThreadInternal::PthreadStart (thread=0x445d4d0) at ../src/unix/threadpsx.cpp:867
#11 0x00007f36fb78c0a4 in start_thread (arg=0x7f36f1f3c700) at pthread_create.c:309
#12 0x00007f36faa9b04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 21, 2015, 01:58:48 am
Oh, can you try to disable the symbol browser in the code completion settings?
This one is known to cause problems, because it calls gui functions in non-main-thread.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 21, 2015, 08:03:38 am
Oh, can you try to disable the symbol browser in the code completion settings?
This one is known to cause problems, because it calls gui functions in non-main-thread.
I think:running the gui function in non-main-thread is not a good idea. But building the tree really take a lot of time. :)
Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 22, 2015, 12:44:07 am
Thank you! Whole evening without any crashes. Looks good so far :-)
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 22, 2015, 09:09:06 am
Thank you! Whole evening without any crashes. Looks good so far :-)
No crashes because of what? Disabling the symbol browser or something else?
Title: Re: Release 15.12, RC1 has arrived
Post by: Kalite on December 22, 2015, 09:18:34 am
I try to download codeblocks 15.12 release and Avast is reporting there is a Virus inside.

Is it a false positive or not?

Title: Re: Release 15.12, RC1 has arrived
Post by: CuteAlien on December 22, 2015, 11:34:40 am
Thank you! Whole evening without any crashes. Looks good so far :-)
No crashes because of what? Disabling the symbol browser or something else?

Yes, I disabled the symbol browser. Note that I had several crashes/asserts per hour the days before. Often several within minutes. So not having a single crash (or even assert) in coding for 2-3 hours last evening means it's a pretty good chance this was the main reason. I'll try to test it some more next days to see if any other asserts/crashes show up (well, because of X-Mas it'll probably be 1-2 weeks until I get to it).
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 22, 2015, 01:21:55 pm
I try to download codeblocks 15.12 release and Avast is reporting there is a Virus inside.
What exactly did you download? Its not visible in the screenshot.

Is it a false positive or not?
99.99999% likely a false positive. If unsure, please use services like virtustotal.com to see for yourself.
Title: Re: Release 15.12, RC1 has arrived
Post by: Kalite on December 22, 2015, 03:45:12 pm
I try to download codeblocks 15.12 release and Avast is reporting there is a Virus inside.
What exactly did you download? Its not visible in the screenshot.

I download codeblocks 15.12 RC1 from sourceforge. Using the link bellow.
http://sourceforge.net/projects/codeblocks/files/Binaries/15.12-RC1/codeblocks-15.12-setup-RC1.exe/download

It download this link: http://skylink.dl.sourceforge.net/project/codeblocks/Binaries/15.12-RC1/codeblocks-15.12-setup-RC1.exe

Sorry, but I don't known this site (virustotal.com) and it's seems be a false positive (only 4 antivirus detect a Malware in it).
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 22, 2015, 05:18:13 pm
Sorry, but I don't known this site (virustotal.com) and it's seems be a false positive (only 4 antivirus detect a Malware in it).
Yes - that's typical for false-positive. The only way a virus can make it into the installer is if SourceForge gets hacked. But this would be recognized pretty fast I guess... 8)
Title: Re: Release 15.12, RC1 has arrived
Post by: OmegaDoom on December 26, 2015, 01:36:18 pm
Hello. I've installed CB 15.12 RC1 on Win 7 but when I start it then nothing happens. The process "codeblocks" exists in TM but I don't see anything.

PS. Oh, it's working, it just starts very slowly.
Title: Logs window : Conflict between tabs re-ordering and frames docking
Post by: earlgrey on December 27, 2015, 10:12:25 pm
When trying to re-order the tabs in the Logs window, I end up with this (http://www.mediafire.com/view/7ly32xje9mqm3cb/manager-window-tabs-conflict.png).

Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 27, 2015, 11:04:46 pm
Yes, this is a feature. You can easily order them in a single tab control.
Title: Re: Release 15.12, RC1 has arrived
Post by: earlgrey on December 28, 2015, 07:33:16 am
Yes, this is a feature. You can easily order them in a single tab control.

I can easily reorder the tabs in Manager frame.
In the Logs frame, I have to split the frame and reassemble it.

Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 28, 2015, 10:18:15 am
What do you mean by "split the frame"?
Title: Re: Release 15.12, RC1 has arrived
Post by: earlgrey on December 28, 2015, 10:50:12 am
What do you mean by "split the frame"?

I would like going from this (http://www.mediafire.com/view/eb9f5l41y86ab2j/tabs-01.png) to this (http://www.mediafire.com/view/ap9lgzriadc4p07/tabs-03.png) without this step (http://www.mediafire.com/view/9oj78632dgmatxs/tabs-02.png)

( Currently I toggle the tabs off, and then toggle them on in the order which I want them to appear )
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 28, 2015, 11:08:38 am
This works just fine in my version. Just drag the tab horizontally to the left or right.
If you're doing it correctly no highlight should be visible.
It works the same as for editors.
Title: Re: Release 15.12, RC1 has arrived
Post by: earlgrey on December 28, 2015, 11:17:14 am
It works the same as for editors.
No highlight seen while moving one editor tab, but ended up with this (http://www.mediafire.com/view/8mz38flw5vzat42/tabs-04.png) : editor window splitted.
Anyway, I shall check that with a proper install.
Thanks for your attention.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 28, 2015, 02:20:04 pm
I've made a video that demonstrates how this works.
It is a little blurry, but I have no time to fix it.

https://vimeo.com/150166889 (https://vimeo.com/150166889)
Title: Re: Release 15.12, RC1 has arrived
Post by: earlgrey on December 30, 2015, 10:58:06 am
It works OK with a std 10631/wx-2.8.12 install ( bootstrap, configure --prefix=/usr, make install )
It is buggy with my customs10631/wx-2.8.12 installs
Pb is on my side, sorry
Title: Re: Release 15.12, RC1 has arrived
Post by: G-Shadow on January 05, 2016, 06:39:27 pm
The RC installer still shows "13.12" version on the splash screen :)
Title: Re: Release 15.12, RC1 has arrived
Post by: ouch on January 05, 2016, 11:47:37 pm
Aside from the wrong version on the installer it looks good.

That sort order dialog though... If only someone would give it some more advanced features to make everyone's life easier... ;)
Title: Re: Release 15.12, RC1 has arrived
Post by: eckard_klotz on January 24, 2016, 09:57:13 am
Hello Developers.

I wish you and all users of Code::Blocks a happy new year.

By "accident" I came to know that the new release "16_01" is available now  http://forums.codeblocks.org/index.php/topic,20871.0.html (http://forums.codeblocks.org/index.php/topic,20871.0.html) . Thus I tried it out. I do not know, if this is an official release or only an internal trial. But I wonder if it may be helpful to for us to set-up a new topic in the announcements for this.

However, this is not the reason for my post. I just want to inform you about an issue I have faced. When Code::Blocks starts I get an error-message, that the plug-in dll wxSmithContribItems.dll could not be loaded. It is the typical message you get if for example the sdk version has changed.

I'm working with Win 10. Since I want to use in the futures nightlies again, I have not installed 16_10 regularly. I have opened the Installer with 7-zip and copied the content I know from the nightlies into an own folder. This way I avoid to insert the application into diverse lists of the operation-system and I can use it parallel to the nightlies without changing the installation.

However, may it be that the installer influences the plug-ins, what not happens, if if I just copy them out of the archive?

Best regards,
                    Eckard.

     
Title: Re: Release 15.12, RC1 has arrived
Post by: killerbot on January 24, 2016, 10:06:00 am
we are preparing a completely new fresh build ....

So don't keep on to the one you already have downloaded ;-)
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 24, 2016, 11:28:08 am
So don't keep on to the one you already have downloaded ;-)
...and don't spy on what's not yet officially released. :-)

We will tell when its ready...
Title: Re: Release 15.12, RC1 has arrived
Post by: eckard_klotz on January 24, 2016, 12:13:01 pm
Hello Killerbot and MortenMacFly.

OK, I will try to limit my curiosity as far as possible to avoid the destiny of the cat.

How ever since my current project is a console-application the issue I mentioned is not really disturbing me and I just wanted to let you know. Until now I faced no critical problem for my work.

Best regards,
                    Eckard.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 24, 2016, 01:00:02 pm
Until now I faced no critical problem for my work.
That is good to know. And surely you can report stuff...
Title: Re: Release 15.12, RC1 has arrived
Post by: ssawgift on January 25, 2016, 06:55:28 am
Buttons on bookmark toolbar do not work - clicking on them has no effect. But I assume this has already been fixed because it's so obvious.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 25, 2016, 10:05:29 am
Are you talking about the browse tracker toolbar?
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on January 25, 2016, 03:30:34 pm
I see the target list is much smaller than before.
See screen shot below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2016-01-25%2022%2036%2027_zpsowxfsgtu.png)
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 25, 2016, 08:14:07 pm
I see the target list is much smaller than before.
Before what? It should size to "something" related to the longest target name.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on January 26, 2016, 03:20:29 am
I see the target list is much smaller than before.
Before what? It should size to "something" related to the longest target name.

I mean the height of the list is too short compared with thelast nightly build release
Title: Re: Release 15.12, RC1 has arrived
Post by: darmma on January 27, 2016, 06:23:46 am
After I downloaded 16.01 version in sourceforge.net, recompile my own project with 13.12-mingw and wxwidgets version 2.8.12 unicode.

But I met the following warning message.
Please let me know the cause. What's wrong ?

Thanks for your response.

* Solved : I recompiled all wxwidgets library again.


C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_adv.a(advlib_aboutdlgg.o): duplicate section `.rdata$_ZTV16wxStaticTextBase[__ZTV16wxStaticTextBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_msw_button.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_dlgcmn.o): duplicate section `.rdata$_ZTV16wxStaticTextBase[__ZTV16wxStaticTextBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_dlgcmn.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_msw_checkbox.o): duplicate section `.rdata$_ZTV14wxCheckBoxBase[__ZTV14wxCheckBoxBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_msw_stattext.o): duplicate section `.rdata$_ZTV16wxStaticTextBase[__ZTV16wxStaticTextBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_nativdlg.o): duplicate section `.rdata$_ZTV16wxStaticTextBase[__ZTV16wxStaticTextBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_nativdlg.o): duplicate section `.rdata$_ZTV14wxCheckBoxBase[__ZTV14wxCheckBoxBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_nativdlg.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_collpaneg.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_logg.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_cshelp.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_msw_bmpbuttn.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_prntbase.o): duplicate section `.rdata$_ZTV16wxStaticTextBase[__ZTV16wxStaticTextBase]' has different size
C:\wxMSW-2.8.12\lib\gcc_lib/libwxmsw28ud_core.a(corelib_prntbase.o): duplicate section `.rdata$_ZTV12wxButtonBase[__ZTV12wxButtonBase]' has different size
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 27, 2016, 07:36:53 am
Please let me know the cause. What's wrong ?
Most likely you mixed (wx-)debug with non-debug libraries / object files. Please note that this is not a C::B issue.
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on January 28, 2016, 10:47:02 pm
Buttons on bookmark toolbar do not work - clicking on them has no effect. But I assume this has already been fixed because it's so obvious.
Are you talking about the browse tracker toolbar?

Yes. They are not working (at least the toggle bookmark button). Interesting that no one has found this bug :D I use the browser tracker extensively but only over shortcuts, so i never had this problem..

greetings

ps. i will start to look into it...
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 28, 2016, 11:09:44 pm
Yes. They are not working (at least the toggle bookmark button). Interesting that no one has found this bug :D I use the browser tracker extensively but only over shortcuts, so i never had this problem..
Hmmm... working for me. Are you sure you enabled the feature globally (Menu: View-> BrowseTracker -> Settings -> Enable BrowseMarks)?
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on January 28, 2016, 11:18:36 pm
I think i am a bit confused, about the difference between "Bookmarks" and "Browser Marks"

Yes. They are not working (at least the toggle bookmark button). Interesting that no one has found this bug :D I use the browser tracker extensively but only over shortcuts, so i never had this problem..
Hmmm... working for me. Are you sure you enabled the feature globally (Menu: View-> BrowseTracker -> Settings -> Enable BrowseMarks)?
Yes this was it, the toolbar is working. But i didn't knew that this are two different features... I used always the Edit->Bookmarks->Toggle Bookmarks. What is the difference?
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 29, 2016, 07:09:29 am
But i didn't knew that this are two different features... I used always the Edit->Bookmarks->Toggle Bookmarks. What is the difference?
Jumpmarks should be more flexible in some ways... I actually don't know because for me, the bookmarks are just fine. What I can tell is that it requires another settings file (*.bmarks). Maybe oBFusCATed can say something about it...
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 29, 2016, 09:31:53 am
I'm not using the browse tracker plugin, so I don't know which features are useful and which aren't.
Title: Re: Release 15.12, RC1 has arrived
Post by: Pecan on January 29, 2016, 06:25:13 pm
I think i am a bit confused, about the difference between "Bookmarks" and "Browser Marks"

BrowseMarks are the original "..." marks that were internal to the BrowseTracker plugin only. IE., CB knew nothing about them.

Many request were made to use CB bookmarks instead, so that option passes the information to CB to set a bookmark.

However, CB bookmarks were not global. They don't work across editors.

Setting BrowseTracker to use CB Bookmarks causes BrowseTracker to remember the BrowseMarks as well as the CB bookmarks.

I'll look at the problem and see if I can find out why the tool bar does not work with BrowseMarks.

 
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on January 30, 2016, 10:02:21 pm
I think i am a bit confused, about the difference between "Bookmarks" and "Browser Marks"

BrowseMarks are the original "..." marks that were internal to the BrowseTracker plugin only. IE., CB knew nothing about them.

Many request were made to use CB bookmarks instead, so that option passes the information to CB to set a bookmark.

However, CB bookmarks were not global. They don't work across editors.

Setting BrowseTracker to use CB Bookmarks causes BrowseTracker to remember the BrowseMarks as well as the CB bookmarks.

I'll look at the problem and see if I can find out why the tool bar does not work with BrowseMarks.

 

Thanks for the explanation. Is this written somewhere in the wiki?
The plugin is working like a charm, so no need to look into it.
One thing is missing: In the menu View->BrowseTracker is no "toggle bookmark" entry, so it is not possible to give it a shortcut. I don't think it is to difficult to add it, so i can reasign Ctrl+B to the BrowseTracker bookmark...

greetings

[EDIT:] here is a patch