Author Topic: The 01 March 2017 build (11021) is out.  (Read 52590 times)

Offline Kilmatead

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 01 March 2017 build (11021) is out.
« Reply #15 on: March 07, 2017, 12:59:45 pm »
The new version of the code formatter seems to have trouble with ternary operators - any time it encounters one (even something simple like 'i ? 1 : 0' it throws an assertion:

Quote
File: C:\CodeBlocks\sf2\src\plugins\ast...\ASForematter.cpp
Line: 3229

Expression: currentChar == '+' || currentChar == '-'

Swapping out the astyle.dll for an older version solves it.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 01 March 2017 build (11021) is out.
« Reply #16 on: March 07, 2017, 09:38:52 pm »
Kilmatead: Can you post the full stacktrace or a minimal sample and steps to reproduce?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Kilmatead

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 01 March 2017 build (11021) is out.
« Reply #17 on: March 08, 2017, 11:41:55 am »
Reproducing is easy (at least for me, Win7 x64)... thinking it might be some conflict of settings, I removed the %appdata% codeblocks user-settings and tried it stock and the same thing happens every time.

So, just open CB (preferably at stock), use File -> New -> Empty File and type a nonsense line like:

Code
int i = 1 ? 0 : 0;

Then hit Plugins -> Source Code Formatter, and I immediately get the same broken assertion every time.  If I remove the ternary, then astyle formats just fine.  Changing settings in astyle makes no difference, it seems to happen for all styles/options (in this latest version - like I said, DLL's for astyle from previous nightlies work fine).

I first discovered this on a larger project, and narrowed it down to always (and only) happening on lines containing a ?: ternary.

As an extra added bonus, when used with stock settings CB itself crashes, no matter which option is chosen.  Under my usual setup I could at least 'Ignore' it and continue.


Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: The 01 March 2017 build (11021) is out.
« Reply #18 on: March 08, 2017, 01:07:08 pm »
To expand on Kilmatead issue.

I reproduced it on Windows 10 32 bit.

Code
#include <iostream>

using namespace std;

int main()
{
    int i = 1 ? 0 : 0;

    cout << "Hello world!" << endl;
    return 0;
}

Attched crash report.

Tim S.


C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 01 March 2017 build (11021) is out.
« Reply #19 on: March 08, 2017, 01:17:32 pm »
I can easily reproduce it here on Linux also.
It crashes in the version from my copr-repo (latest trunk) and on F26 with C::B 16.01 linked again system-astyle.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 01 March 2017 build (11021) is out.
« Reply #20 on: March 08, 2017, 01:26:23 pm »
Related bug-report:
https://sourceforge.net/p/astyle/bugs/423/

It's already fixed in astyle trunk.
« Last Edit: March 08, 2017, 01:29:12 pm by jens »

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: The 01 March 2017 build (11021) is out.
« Reply #21 on: March 09, 2017, 10:54:13 pm »
Built C::B svn 11019 on Kubuntu 16.10 64bit from Jens' source file at https://apt.jenslody.de/stable/pool/main/ (thanks!)

Seems to work fine.

My wish is that the toolbars either are more compacted or somehow configurable so I can remove icons i don't use. They take up far too much space both horizontally and vertically. I have to disable the Code completion toolbar even though I have a 24' screen.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 01 March 2017 build (11021) is out.
« Reply #22 on: March 10, 2017, 04:29:03 am »
My wish is that the toolbars either are more compacted or somehow configurable so I can remove icons i don't use.
The current implementation of all the toolbar's are "hard-coded", I mean many of toolbar are written in XRC resource files, so it is not configurable. Maybe there are some functions in wxWidgest which can hide some ununsed icons. So, patches are welcome. :)
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 cacb

  • Lives here!
  • ****
  • Posts: 536
Re: The 01 March 2017 build (11021) is out.
« Reply #23 on: March 10, 2017, 09:02:17 pm »
The current implementation of all the toolbar's are "hard-coded", I mean many of toolbar are written in XRC resource files, so it is not configurable. Maybe there are some functions in wxWidgest which can hide some ununsed icons. So, patches are welcome. :)

I just made a small experiment to see if it would work. I identified the file
codeblocks-16.01svn/src/plugins/codecompletion/resources/codecompletion_toolbar.xrc

and halved the widths of the 2 wxChoice items to 143 and 330 each, and then rebuilt Code::Blocks. That gave me a code completion toolbar half the width it was before. I still see most of what I need to see.  I realize this is not a general or even portable solution, but at least it shows where the issue is.

I didn't try to make the other toolbars more compact, they still waste space in particular vertically. The main problem seems to be caused by wxChoice items in combination with much "air" around.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 01 March 2017 build (11021) is out.
« Reply #24 on: March 11, 2017, 04:55:29 am »
The current implementation of all the toolbar's are "hard-coded", I mean many of toolbar are written in XRC resource files, so it is not configurable. Maybe there are some functions in wxWidgest which can hide some ununsed icons. So, patches are welcome. :)

I just made a small experiment to see if it would work. I identified the file
codeblocks-16.01svn/src/plugins/codecompletion/resources/codecompletion_toolbar.xrc

and halved the widths of the 2 wxChoice items to 143 and 330 each, and then rebuilt Code::Blocks. That gave me a code completion toolbar half the width it was before. I still see most of what I need to see.  I realize this is not a general or even portable solution, but at least it shows where the issue is.

I didn't try to make the other toolbars more compact, they still waste space in particular vertically. The main problem seems to be caused by wxChoice items in combination with much "air" around.
Long time ago, I have a patch to modify and configure the CodeCompletion's toolbar, see here: Code::Blocks / Tickets / #303 make code completion's toolbar configurable
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 March 2017 build (11021) is out.
« Reply #25 on: March 12, 2017, 10:22:55 am »
I didn't try to make the other toolbars more compact, they still waste space in particular vertically. The main problem seems to be caused by wxChoice items in combination with much "air" around.
Hi, cacb, can you look at this thread, it looks like this is the exact issue as you stated:
toolbar bottom edge is not shown corectly under C::B build with wx git master
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 cacb

  • Lives here!
  • ****
  • Posts: 536
Re: The 01 March 2017 build (11021) is out.
« Reply #26 on: March 12, 2017, 12:59:00 pm »
I didn't try to make the other toolbars more compact, they still waste space in particular vertically. The main problem seems to be caused by wxChoice items in combination with much "air" around.
Hi, cacb, can you look at this thread, it looks like this is the exact issue as you stated:
toolbar bottom edge is not shown corectly under C::B build with wx git master

Hi, yes it looks related at least. I added a couple of screenshots comparing what I see on Windows (an older wx2.8 based nightly build) compared to a local build on Kubuntu 16.10 using recent C::B source compiled against wx.3.0

See http://forums.codeblocks.org/index.php/topic,20938.msg148345.html#msg148345

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: The 01 March 2017 build (11021) is out.
« Reply #27 on: March 13, 2017, 07:15:23 pm »
It is a new warning in wx3 that asserts if the zip file doesn't contain any xrc files in it. For some of the plugins this is really the case.

You are right. There is a sanity check in wx code that prompts that dialog if xrc file is missing. However there is no way to stop this assert message.

For the time being we have to ignore this harmless message till a solution is found.
Be a part of the solution, not a part of the problem.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 01 March 2017 build (11021) is out.
« Reply #28 on: March 13, 2017, 08:48:16 pm »
We can just remove the calls for loading the resources, I think or even remove the empty zip files (I think there are some plugins without resources).
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 01 March 2017 build (11021) is out.
« Reply #29 on: March 13, 2017, 09:29:36 pm »
We get this message only, if C::B is started with the "-v"-switch to show more verbose debugging messages, so it should not be a problem for the default user.