Author Topic: The 16 June 2013 build (9158) is out.  (Read 191758 times)

Offline LETARTARE

  • Regular
  • ***
  • Posts: 395
  • L'ami de l'homme.The friend of man.
Re: The 16 June 2013 build (9158) is out.
« Reply #30 on: June 19, 2013, 09:16:42 am »
@mortenmaclfy
Quote
If the file is not existent in SVN, do:
svn add the_file
Files without targets are either an oversight or a desire for the author ?
Should we add them (but what target?) Or remove it?
A developer knows better than me.

@ollydbg
thank you for this last explanation, I discovered.

For other changes I'll try to do several patchs.
C::B  : svn11911, wx-3.1.1, plugins : QtPregen-2.7.2-sdk146
1-Vista Business Pack 2 32bits : gcc-8.1.0,
2-OpenSuse-15.1-Leap 64bits :  gcc-7.4.1,
=> !! The messages are translated by Deepl !!

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 150
Re: The 16 June 2013 build (9158) is out.
« Reply #31 on: June 20, 2013, 03:15:01 pm »
Hello Everybody.

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

If I have the following source-example:
Code: [Select]
namespace a {
namespace b {
};
};

using namespace b;

The namespace b will be displayed on toplevel what not happens in this example:
Code: [Select]
namespace a {
namespace b {
};
};


In both examples the namespace b will displayed as child of namespace a also. It seems that using namespace will be analysed like a lonly namespace if it is placed after the closing } of namespace a. This happens not if it is placed after the closing } of namespace b like here:
Code: [Select]
namespace a {
namespace b {

};

using namespace b;

}


Is this the wanted behaviour?

I use the official nightlies on Windows XP SP3 and this behaviour occures since 9156.

BestRegards,
                 Eckard Klotz.

ToApolytoXaos

  • Guest
Re: The 16 June 2013 build (9158) is out.
« Reply #32 on: June 20, 2013, 04:24:26 pm »
First of all, you don't need semicolon at the end of namespace.

I would suggest to avoid doing something like
Code: [Select]
namespace a {
    namespace b {
    }
    using namespace b;
}

because, with this way, if you have declared variables or classes that use the same name to both namespaces, the using directive will hide the outer namespace's names, thus causing nightmares detecting what the hell is going on with your code.

Here's what I have tested myself and works just fine.

Code: [Select]
#include <iostream>

namespace a
{
    int i = 0;
    namespace b
    {
        int i = 0;
    }
}

int main()
{
    std::cout << "a::i = " << a::i << '\n';
    a::i++;
    std::cout << "a::i = " << a::i << '\n';
    std::cout << "a::b::i = " << a::b::i << '\n';
    a::b::i++;
    std::cout << "a::b::i = " << a::b::i << '\n';

    return 0;
}

Please note that I explicitly use using::declaration rather than using-directive for the reasons I have stated above.
« Last Edit: June 20, 2013, 04:27:28 pm by ToApolytoXaos »

ToApolytoXaos

  • Guest
Re: The 16 June 2013 build (9158) is out.
« Reply #33 on: June 20, 2013, 04:39:14 pm »
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ?  ;)

Update: Issue remains with svn9161. To reproduce it, type
Code: [Select]
("") << ("") << (""), go to the most right bracket pair and use your left arrow to move towards the first pair. See how the right double quotes get highlighted all together.

« Last Edit: June 20, 2013, 04:43:20 pm by ToApolytoXaos »

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 150
Re: The 16 June 2013 build (9158) is out.
« Reply #34 on: June 20, 2013, 05:30:36 pm »
Hello ToApolytoXaos

Thankyou for your tip.

To be honest I don't uses namespaces for functional reasons but for a better display in the C::B symbol-browser. Unfortunatly all classes wil be displayed on top level even if they are child-classes of other classes. Only nested namespaces where displayed nested in the past. Thus I put around every class a namespace and and put a using-line at the end of the associated header.  You are absolutly right, if you say that this is a very confusing behaviour. But is there an other posibility to avoid long lists in the symbol-browser?

I would expect that only parentless classes or classes where the parents are not defined in project-sources would be displayed on toplevel. I would expect child classes under there parents. Alternativly an user specified folder-system (like they have implemented in Dev-C++) would be nice that gives the user the posibility to sort all ellements in the symbol-browser acording to his own wishes. This would be extreemly helpfull in c projects where in C::B all functions of a project are displayed in a long list as well as all variables all preprocessor-definitions all...

Best regards,
                   Eckard Klotz. 

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 16 June 2013 build (9158) is out.
« Reply #35 on: June 20, 2013, 05:38:15 pm »
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ?  ;)

Update: Issue remains with svn9161. To reproduce it, type
Code: [Select]
("") << ("") << (""), go to the most right bracket pair and use your left arrow to move towards the first pair. See how the right double quotes get highlighted all together.


I was not clear enough, that's what I wanted to say:
svn r9078 seems to be is the first bad revision ("* SDK: major update to core component wxScintilla: Pumped underlying scintilla to v3.3.1").

I did a bisecting, so I'm sure it starts with this revision !

ToApolytoXaos

  • Guest
Re: The 16 June 2013 build (9158) is out.
« Reply #36 on: June 20, 2013, 06:19:42 pm »
Hello ToApolytoXaos

Thankyou for your tip.

To be honest I don't uses namespaces for functional reasons but for a better display in the C::B symbol-browser. Unfortunatly all classes wil be displayed on top level even if they are child-classes of other classes. Only nested namespaces where displayed nested in the past. Thus I put around every class a namespace and and put a using-line at the end of the associated header.  You are absolutly right, if you say that this is a very confusing behaviour. But is there an other posibility to avoid long lists in the symbol-browser?

I would expect that only parentless classes or classes where the parents are not defined in project-sources would be displayed on toplevel. I would expect child classes under there parents. Alternativly an user specified folder-system (like they have implemented in Dev-C++) would be nice that gives the user the posibility to sort all ellements in the symbol-browser acording to his own wishes. This would be extreemly helpfull in c projects where in C::B all functions of a project are displayed in a long list as well as all variables all preprocessor-definitions all...

Best regards,
                   Eckard Klotz. 

Can you please Eckard provide an example with your issue? I would like to test it on my system.

ToApolytoXaos

  • Guest
Re: The 16 June 2013 build (9158) is out.
« Reply #37 on: June 20, 2013, 06:27:09 pm »
@jens: That makes things much clearer now :) thanks.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: The 16 June 2013 build (9158) is out.
« Reply #38 on: June 21, 2013, 06:59:30 am »

Well sorry to say that, but not for me. Here it works as expected - at least on Windows (see attached image).

I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 16 June 2013 build (9158) is out.
« Reply #39 on: June 21, 2013, 07:02:04 am »

Well sorry to say that, but not for me. Here it works as expected - at least on Windows.

I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 16 June 2013 build (9158) is out.
« Reply #40 on: June 21, 2013, 10:20:34 am »

Well sorry to say that, but not for me. Here it works as expected - at least on Windows.

I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.

The issue does not occur on windows.
I will look into it, later.

ToApolytoXaos

  • Guest
Re: The 16 June 2013 build (9158) is out.
« Reply #41 on: June 21, 2013, 02:59:56 pm »
eckard, I have downloaded the source files you have posted here and try to compile them. Obviously I'm doing something wrong ( lol ), but that's not the point.

I have created a new C::B project and imported your code and saw what you said about namespaces and classes. I hope I'm wrong, but seriously something's going on with Symbols' mechanism. It would show a namespace and when I double click it, instead of taking me to the actual namespace, it sends me on the first line of source file.

@devs: Which project should I look for Symbols? Is it part of SDK or as a plugin?

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 150
Re: The 16 June 2013 build (9158) is out.
« Reply #42 on: June 21, 2013, 03:43:20 pm »
Hello ToApolytoXaos.

Quote
Obviously I'm doing something wrong ( lol )

Sory I didn't mention that you have to use some preprocessor defines for the project to compile it. They are described in the readme. But especially for those things I planed to post my C::B project files in the future also. Furthermore you need the current boost-library (1.53) also since I use the spirit parser from it.

Quote
It would show a namespace and when I double click it, instead of taking me to the actual namespace, it sends me on the first line of source file.

Sory again, I did forget to mention this also. So let confirm me that also. Furthermore you will se that I use the namespace boost in the file prs_tpdef.h. But even I don't define this namespace somewhere else  (this will bedone in the spirit files wich are not part of my project) it is shown in the symbol browser.

Best regards,
                  Eckard.

ToApolytoXaos

  • Guest
Re: The 16 June 2013 build (9158) is out.
« Reply #43 on: June 21, 2013, 04:34:34 pm »
@MortenMacFly: Why "rename symbols" does not always work? It has a very peculiar behavior. "Symbol not found under cursor!" and other times it would let me rename my desired symbols.

It's one of those WTF moments...:D honestly!

Offline carra

  • Multiple posting newcomer
  • *
  • Posts: 114
Re: The 16 June 2013 build (9158) is out.
« Reply #44 on: June 27, 2013, 09:57:06 am »
I have found a couple of bugs in the toolbar docking system, let's see if you can reproduce this:

BUG 1: reappearing toolbars
---------------------------
- make a fresh install under Windows (removing previous default.conf)
- undock one (or more) toolbars, and close them clicking on their close button
- undock another toolbar, and the ones you closed before reappear again (undocked and apparently in their same position as before being closed)

BUG 2: docking beyond window width
--------------------------------------
- Close all toolbars but code completion, main and compiler
  (use the menu so that they won't reappear)
- Undock main and compiler toolbars, leave code completion at the left
- Redock both toolbars. Even if you try to place them under code completion toolbar, they are always added at its right. With my current window width (non fullscreen), I can't even see the rightmost toolbar.