Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on August 08, 2013, 11:43:49 am

Title: The 06 August 2013 build (9246) is out.
Post by: killerbot on August 08, 2013, 11:43:49 am
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 (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc471-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc471-TDM.7z
And the exception handler dll (for better crash reports) : http://prdownload.berlios.de/codeblocks/exchndl_gcc471-TDM.7z

The 06 August 2013 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20130806_rev9246_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 06 August 2013 build (9246) is out.
Post by: Jenna on August 08, 2013, 11:56:47 am
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .

The packages that are currently striked through are not yet available.
Debian comes this afternoon, RedHat/CentOS 5 might take a little longer as the default compiler there is gcc 4.1, but a header file of mozilla's encoding detection wants at least gcc4.4.
I hope I can fix this soon (maybe 4.1 is enough or I have to tweak mock to use gcc44 instead of gcc, if possible).
Title: Re: The 06 August 2013 build (9246) is out.
Post by: eckard_klotz on August 09, 2013, 09:47:37 am
Hello Everybody.

Thanks for the new build but unfortunately I still see the effect mentioned in my comments of the last nightly (Re: The 16 June 2013 build (9158) is out.):
Quote
Hello Everybody.

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

If I have the following source-example:

Code:
namespace a {
namespace b {
};
};

using namespace b;

The namespace b will be displayed on toplevel what not happens in this example:

Code:
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:
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.



What occurs since the parser seems to handle the using of a namespace like its declaration. Have I overseen something in the currently available configuration?
Alternatively I proposed in the followed discussion to implement a possibility to show derived classes in sub-levels of the browser-tree or to allow the user to add folders where he can place browser-nodes since my original intention is to reduce the the amount of lines showed on top-level.

Best Regards,
                         Eckard Klotz.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: Jenna on August 09, 2013, 06:05:01 pm
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .

The packages that are currently striked through are not yet available.
Debian comes this afternoon, RedHat/CentOS 5 might take a little longer as the default compiler there is gcc 4.1, but a header file of mozilla's encoding detection wants at least gcc4.4.
I hope I can fix this soon (maybe 4.1 is enough or I have to tweak mock to use gcc44 instead of gcc, if possible).
Finally it's done, sorry for the delay.
Actual packages on my server are svn r9251 :

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on August 11, 2013, 11:51:18 am
Maybe scintilla related bug under Windows:
The first line number does not show correctly, see the screen shot below:
(http://i.imgur.com/OqMrgEo.png)
Title: Re: The 06 August 2013 build (9246) is out.
Post by: frithjofh on August 11, 2013, 05:40:16 pm
Hi,

if I remember correctley, there was a setting somewhere, specifying the width of that grey column...

regards

frithjof
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on August 11, 2013, 06:31:59 pm
Hi,

if I remember correctley, there was a setting somewhere, specifying the width of that grey column...

regards

frithjof
That setting was in "left margin" in "Margins and caret" in Editor setting, I have the "Dynamic setting" checked.

Oh, I noticed that this issue happens when I use the CTRL+MOUSE-Wheel to enlarge the font size, but the "left margin" width was not enlarged accordingly.

EDIT: I tried NotePad++, the "left margin" width just changed as font size changed, so I believe this is a C::B bug.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: oBFusCATed on August 11, 2013, 09:35:20 pm
EDIT: I tried NotePad++, the "left margin" width just changed as font size changed, so I believe this is a C::B bug.
You have to try the latest Scite, Notepad++ might not have been running the latest scintilla.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: Jenna on August 12, 2013, 01:36:10 am
@ollydbg:
can you test the attached patch ?

Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on August 12, 2013, 03:51:58 am
@ollydbg:
can you test the attached patch ?

Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.

Hi, jens, thanks, I just test this patch, and it fix the problem I reported.

BTW: when I use CTRL+MOUSE_WHEEL to zoom the fonts, is there any way to "reset" the zoom value to the default value? I can't find a menu item...
Title: Re: The 06 August 2013 build (9246) is out.
Post by: Jenna on August 12, 2013, 05:49:17 am
BTW: when I use CTRL+MOUSE_WHEEL to zoom the fonts, is there any way to "reset" the zoom value to the default value? I can't find a menu item...

"Edit -> Special commands -> Zoom -> Reset", I use "CTRL+0" (CTRL+zero") as shortcut on my system.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: eckard_klotz on August 12, 2013, 04:59:07 pm
Hello again.

In the meanwhile I implemented A workaround like this:
Quote
#define USING_NAMESPACE using namespace
};}; USING_NAMESPACE CL_ACTION_GRAMM;
#undef  USING_NAMESPACE

The result is that that the symbol-browser shows a reduced list again since the parser is not recognizing the using namespace lines any more.

But to be honest this is a workaround of a workaround and what happens the parser will start to solve the preprocessor directive ]#define USING_NAMESPACE using namespace
.

I think the real solution is that the symbol-browser provides a configuration to hide inherited members from higher tree-levels if they are shown as inherited members. Inherited members can already shown as sub-nodes so the only work is to erase them in the tree-levels above. I know there are also users which prefer flat lists and accept if this list are very long so it should be configurable. But for users like me one advantage of object orientated programming is to design hierarchies and in this case you expect this hibachi in a symbol-browser also.

Best Regards,

                    Eckard Klotz.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: raynebc on August 20, 2013, 05:17:31 am
It took me a moment to realize why ALT+F wasn't bringing up the File menu like it always had done:  The F hotkey is overloaded and is now assigned to the Fortran menu as well.  Luckily this can be removed pretty easily by disabling the plugin, but it may be worth seeing if that menu can get another hotkey (I didn't check all plugins, but ALT+A and ALT+N don't seem to be tied to any of the default menus).
Title: Re: The 06 August 2013 build (9246) is out.
Post by: eckard_klotz on August 27, 2013, 01:44:38 pm
Hello Everybody.

I assume that currently no urgent problems have to be discussed here so I hope I'm allowed to discuss an additional symbol-browser point. This discussion may result in a requirement but currently I don't know in which requirement.

As I wrote before I see a problem in the long lists you get in the symbol-browser. In a object orientated software-project it may be possible to use the language depending hierarchy definitions to move elements from the top-level to deeper levels like class inheritance or nested name-spaces.

But in more old fashioned software-projects with no object-hierarchies like in C and not Cpp this will not help. The user has to define the hierarchy some how else. My proposal is to give the user to define package-hierarchies inside the symbol-browser which represent a user-define tree whose nodes can be used to carry all symbols like the user wants.


My idea is not to replace the current behaviour of the symbol-browser completely but to extend it. some more questions have to be discussed for example how to deal with change symbol-ids It may be useful to have a special tomb-package for symbols not found anymore or a delivery-package for new symbols. It may be good to add comment to every package and perhaps this may be used later to define a doxygen grouping definition. May be that this kind of browsing is to different compared with the currently used Symbol-browser what results in implementing a Package-browser parallel to the symbol-browser.

And may be you tell me that this already exists and I just was not able to activated it (Jens may remember the "disable the MouseSap-plugin" discussion we had in the last days, very embarrassing). So please help me to fill the vacuum between my ears.

Best Regards,
                      Eckard.

 

 
Title: Re: The 06 August 2013 build (9246) is out.
Post by: eckard_klotz on August 27, 2013, 03:07:40 pm
Hello Everybody.

Now I have an total other question:

I know how to create in one project several targets.
I saw also, that it is possible to use the target-definition for creating an independent project.
But is it also supported to merge a project into an other for adding its targets (together with all associated configurations)?

In my example I have on the one side projects which contain application-targets (release and debug) and on the other side projects with test-targets (unit-tests).  The independent test-projects are created by different colleges but once the tests are ready it is useful to have them in the application-project also. Here you are able to define a virtual target to compile and run altogether.

Currently we redefine all test-targets in the application-project by hand what may create more bugs. Thus a C::B function to copy a target from one project to the other may be very helpful.

Is there already something available?

Best regards,
                  Eckard.   
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on August 27, 2013, 06:34:04 pm
...
Currently we redefine all test-targets in the application-project by hand what may create more bugs. Thus a C::B function to copy a target from one project to the other may be very helpful.

Is there already something available?
...
If I remember correctly, copying settings cross projects is not available currently in C::B, I asked such feature request several years ago. So, patches are welcome. ;D
Title: Re: The 06 August 2013 build (9246) is out.
Post by: eckard_klotz on August 28, 2013, 08:09:04 am
Hello Ollydbg.

Thanks for your for your comment. It shows me 2 things.  I'm not the only one who sees the need for it and I did not overseen something.

Quote
So, patches are welcome.

The voice of my guilty conscience...

You are right. If I take a look to my last posts you may come to the conclusion there is somebody who requires greater changes and it is hard to see what is coming back. But since I work on my own open source-projects (http://forums.codeblocks.org/index.php/topic,18081.0.html) I hope you accept this as "payment". Currently I'm still busy with my last preparations for the next release-distributions. After that I want to start developing a c::b plug-in for Moritz what means, then I will start to explore the Code::Blocks binaries also. But since this took place only in my spare-time beyond my daily work, I will not be able to offer a patch for Code::Blocks in the next time.

How ever, when I started my two discussions here, I didn't expected that the developer team of Code::Blocks was just waiting for that, to learn what's coming next. My intention is more to ask the audience if my ideas are useful enough to create real requirements or not. But even if they are, I accept if the developer-team decides to put them in a queue to implement them later if I'm not able to do the implementation.

Best regards,
                    Eckard Klotz.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: darmar on August 31, 2013, 08:19:04 pm
It took me a moment to realize why ALT+F wasn't bringing up the File menu like it always had done:  The F hotkey is overloaded and is now assigned to the Fortran menu as well.  ....

I made a change in the code: renamed menu "&Fortran" (ALT+F) to "Fortra&n" (ALT+N).
Title: Re: The 06 August 2013 build (9246) is out.
Post by: nexon7 on September 03, 2013, 01:52:40 pm
Very Easy Tutorial for setting and using Codeblocks Nightly build and Latest TDM-GCC 32 Bit and 64 Bit compilers, managing poject settings and programming tips (handy for people using Visual studio side by side) are here, http://nexon7.wordpress.com/2013/09/03/how-to-install-codeblock-nightly-build-with-latest-gcc-compiler-32-bit-and-64-bit/
Title: Re: The 06 August 2013 build (9246) is out.
Post by: White-Tiger on September 03, 2013, 04:54:54 pm
I wonder if the wx29 build is ready/usable... it's been a while since 2.9 is available and Code::Blocks doesn't seem to support it (yet)... it's a shame.
So... since some commits are about wx29 compatibility fixes... is the wx29 build usable and if so why isn't there a Nightly yet?
There are still a lot of crashes in Code::Blocks.. most of them happen on project close or open... (besides I get a soft crash when trying to add a file to a project, using the wizard) and I hope wx29 fixes them :P (they improved a lot... and it might even work ;) Otherwise Code::Blocks has to use more locks/mutexes)
Title: Re: The 06 August 2013 build (9246) is out.
Post by: oBFusCATed on September 03, 2013, 05:15:32 pm
I wonder if the wx29 build is ready/usable...
I doubt, at least the watches windows is in pretty bad state I'm trying to fix, but it will take quite a while.
As far as I know wxSmith is broken, too, but I've not tried it, to confirm this.

... it's a shame.
Not enough man power, sorry.

There are still a lot of crashes in Code::Blocks.. most of them happen on project close or open... (besides I get a soft crash when trying to add a file to a project, using the wizard) and I hope wx29 fixes them :P (they improved a lot... and it might even work ;) Otherwise Code::Blocks has to use more locks/mutexes)
Don't be so optimistic, because the crashes most probably happen because there are bugs in our code.
So wx29 will just bring more crashes and problems for you. :)

I don't remember you reporting the crashes here. At least I don't remember reports for crashes about adding files...
And if you don't report them in reproducible way there is no chance they will ever get fixed.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: White-Tiger on September 03, 2013, 11:52:41 pm
well... most of them where named already... at least the project open and close crash...
But I can't really fix it, at least the call stack isn't that good... symbols missing, mostly only 1 codeblocks within all threads (and that can't be possible) everything else is either wxWidgets or Windows stuff..

The last function until the crash is always some stuff from wxWidgets... that's why I hope they might have fixed it.. and I know they fixed some stuff.

And that other one.. it's a soft crash... not a hard crash (and by soft crash I mean not crashing the app)
File->New->File... and try adding a file to the project

Script errors have occured...
Code
SquirrelFunction<> call failed
AN ERROR HAS OCCURED [the index 'RebuildTree' does not exist]

CALLSTACK
*FUNCTION [AddFileToTargets()] E:\zZ-Progra\CodeBlocks\share\codeblocks/templates/wizard/common_functions.script line [595]
*FUNCTION [CreateFiles()] E:\zZ-Progra\CodeBlocks\share\codeblocks/templates/wizard/h_file/wizard.script line [60]

LOCALS
[pf] INSTANCE
[pf_check] INSTANCE
[prj] INSTANCE
[tgtidx] 4
[the_file] INSTANCE
[the_wiz] INSTANCE
[this] TABLE
[auto_text] INSTANCE
[text] INSTANCE
[guard] INSTANCE
[ed_new] INSTANCE
[ed] INSTANCE
[fname] INSTANCE
[this] TABLE
and the edit box that shows the error is disabled... so you can't copy the text... (unless you read it directly from the window/control :P)
Title: Re: The 06 August 2013 build (9246) is out.
Post by: oBFusCATed on September 04, 2013, 01:05:28 am
And that other one.. it's a soft crash... not a hard crash (and by soft crash I mean not crashing the app)
File->New->File... and try adding a file to the project
Should be fixed in trunk.

Script errors have occured...and the edit box that shows the error is disabled... so you can't copy the text... (unless you read it directly from the window/control :P)
Should also be fixed in trunk.

See how easy it is when you provide enough information.
Now if you provide exact steps to reproduce the project open/close crashes, then probably someone could try to fix them.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: White-Tiger on September 04, 2013, 02:24:01 am
your changes work, thanks ;) I still wonder why you chose a different file to store that function then before... maybe because you couldn't locate the original file as I couldn't xD
[...]
See how easy it is when you provide enough information.
Now if you provide exact steps to reproduce the project open/close crashes, then probably someone could try to fix them.
well... I can't... (and I'm to lazy to fill reports... and yep I know it's bad :P)
The open crash is rare.. didn't happen that much... the real close crash is kind of rare as well.. most of the time it just hangs... and that's the main problem and I've said already as much as I can about it.

To reproduce the hang bug: close codeblocks, open codeblocks and as soon as it's open, close a project (closing the workspace might work or not.. the crash that happened on close was related to workspace close IIRC)
For this to work you'll need a slow PC (probably and very likely at least 2 CPU cores), probably not more then 2GB RAM, and main part: slow HD
It's simply the code-completion or any other thread that parses the project that's closed or something like that...

Anyway... I have no Idea why this crashed except for an already freed project, but here's a crash report:
Code
Error occured on Sunday, September 1, 2013 at 01:24:01.

E:\zZ-Progra\CodeBlocks\codeblocks.exe caused an Access Violation at location 004e3e54 in module E:\zZ-Progra\CodeBlocks\codeblocks.exe Reading from location 0000001c.

Registers:
eax=00000000 ebx=61a2e0ac ecx=00000000 edx=00000030 esi=0022dac4 edi=00000000
eip=004e3e54 esp=0022da18 ebp=0022da1c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

Call stack:
004E3E54  E:\zZ-Progra\CodeBlocks\codeblocks.exe:004E3E54  FileTreeData::GetKind  E:/zZ-Progra/CodeBlocks-SVN/src/include/cbproject.h:58
0048E62A  E:\zZ-Progra\CodeBlocks\codeblocks.exe:0048E62A  ProjectManagerUI::OnCloseProject  E:/zZ-Progra/CodeBlocks-SVN/src/src/projectmanagerui.cpp:1490
01191551  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01191551  _ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_
01216C4E  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01216C4E  _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
01216D1A  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01216D1A  _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
01217175  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01217175  _ZN12wxEvtHandler12ProcessEventER7wxEvent
01217109  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01217109  _ZN12wxEvtHandler12ProcessEventER7wxEvent
[...] ^ x 46
01327092  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01327092  _ZN12wxWindowBase9TryParentER7wxEvent
01217109  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01217109  _ZN12wxEvtHandler12ProcessEventER7wxEvent
01327092  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01327092  _ZN12wxWindowBase9TryParentER7wxEvent
01301271  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01301271  _ZN10wxMenuBase9SendEventEii
0128D73C  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:0128D73C  _ZN6wxMenu10MSWCommandEjt
012609F0  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:012609F0  _ZN8wxWindow13HandleCommandEttPv
0126431C  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:0126431C  _ZN8wxWindow13MSWWindowProcEjjl
012B2747  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:012B2747  _ZN10wxTreeCtrl13MSWWindowProcEjjl
0125DC8E  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:0125DC8E  _Z9wxWndProcP6HWND__jjl@16
771A86EF  C:\Windows\system32\USER32.dll:771A86EF  IsThreadDesktopComposited
771A8876  C:\Windows\system32\USER32.dll:771A8876  IsThreadDesktopComposited
771A89B5  C:\Windows\system32\USER32.dll:771A89B5  IsThreadDesktopComposited
771A8E9C  C:\Windows\system32\USER32.dll:771A8E9C  DispatchMessageW
01262B67  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01262B67  _ZN8wxWindow11DoPopupMenuEP6wxMenuii
004D1356  E:\zZ-Progra\CodeBlocks\codeblocks.exe:004D1356  wxWindowBase::PopupMenu  E:/zZ-Progra/wxWidgets-2.8x/include/wx/window.h:924
004888BF  E:\zZ-Progra\CodeBlocks\codeblocks.exe:004888BF  ProjectManagerUI::ShowMenu  E:/zZ-Progra/CodeBlocks-SVN/src/src/projectmanagerui.cpp:725
0048B8B1  E:\zZ-Progra\CodeBlocks\codeblocks.exe:0048B8B1  ProjectManagerUI::OnTreeItemRightClick  E:/zZ-Progra/CodeBlocks-SVN/src/src/projectmanagerui.cpp:1076
01191551  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01191551  _ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_
01216C4E  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01216C4E  _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
01216D1A  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01216D1A  _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
01217175  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01217175  _ZN12wxEvtHandler12ProcessEventER7wxEvent
01217109  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01217109  _ZN12wxEvtHandler12ProcessEventER7wxEvent
[...] ^ x 46
01327092  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01327092  _ZN12wxWindowBase9TryParentER7wxEvent
01217109  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01217109  _ZN12wxEvtHandler12ProcessEventER7wxEvent
01327092  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01327092  _ZN12wxWindowBase9TryParentER7wxEvent
012B15FD  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:012B15FD  _ZN10wxTreeCtrl11MSWOnNotifyEilPl
012653DC  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:012653DC  _ZN8wxWindow13MSWWindowProcEjjl
0125DC8E  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:0125DC8E  _Z9wxWndProcP6HWND__jjl@16
771A86EF  C:\Windows\system32\USER32.dll:771A86EF  IsThreadDesktopComposited
771A8876  C:\Windows\system32\USER32.dll:771A8876  IsThreadDesktopComposited
771A7631  C:\Windows\system32\USER32.dll:771A7631  IsRectEmpty
771A7695  C:\Windows\system32\USER32.dll:771A7695  SendMessageW
012B3307  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:012B3307  _ZN10wxTreeCtrl13MSWWindowProcEjjl
0125DC8E  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:0125DC8E  _Z9wxWndProcP6HWND__jjl@16
771A86EF  C:\Windows\system32\USER32.dll:771A86EF  IsThreadDesktopComposited
771A8876  C:\Windows\system32\USER32.dll:771A8876  IsThreadDesktopComposited
771A89B5  C:\Windows\system32\USER32.dll:771A89B5  IsThreadDesktopComposited
771A8E9C  C:\Windows\system32\USER32.dll:771A8E9C  DispatchMessageW
01242780  E:\zZ-Progra\CodeBlocks\wxmsw28u_gcc_cb.dll:01242780  _ZN11wxEventLoop8DispatchEv
btw.. a feature to have the last revision within that crash log would rock ;) maybe always write it to that file and overwrite it on next start if the last 4 bytes are the same as the revision or other kind of "magic bytes" Or just change exchndl directly.. you've got the code already, even though you never build it by default

@edit: I've put in the complete crashlog/stack-trace now... as it might be better :P "[...] ^" means exactly the above x times
Title: Re: The 06 August 2013 build (9246) is out.
Post by: White-Tiger on September 06, 2013, 12:16:06 am
anyway... here are a few suggestions / patches:
Link ConsoleRunner statically. This allows one to use a compiler with sjlj (and CB build with that) but also compile and run code with dwarf. Otherwise ConsoleRunner tries to find libgcc with sjlj but can't because Code::Blocks set's the environment variable to the dwarf tool-chain. (not sure how that "-static" works for Linux... but it's important for Windows... -static-libgcc doesn't work) Also I've set exchndl to be compiled when one compiles Code::Blocks... I can't see a reason for not compiling it as it's bad to go without it.
Code: diff
Index: src/CodeBlocks.cbp
===================================================================
--- src/CodeBlocks.cbp (revision 9294)
+++ src/CodeBlocks.cbp (working copy)
@@ -54,6 +54,9 @@
  <Compiler>
  <Add option="-Os" />
  </Compiler>
+ <Linker>
+ <Add option="-static" />
+ </Linker>
  </Target>
  <Target title="Squirrel">
  <Option output="sdk/scripting/lib/squirrel" prefix_auto="1" extension_auto="1" />
@@ -716,7 +719,7 @@
  </Environment>
  </Build>
  <VirtualTargets>
- <Add alias="All" targets="tinyXML;AutoRevision;ConsoleRunner;Squirrel;Squirrel std lib;SqPlus;scintilla;wxpropgrid;sdk;src;Abbreviations;AStyle;Autosave;Compiler depslib;Compiler;Debugger;Code-completion;Class wizard;Default MIME handler;Occurrences Highlighting;Open files list;Projects-workspaces importer;Scripted wizard;To-do;XP look &amp; feel;" />
+ <Add alias="All" targets="exchndl;tinyXML;AutoRevision;ConsoleRunner;Squirrel;Squirrel std lib;SqPlus;scintilla;wxpropgrid;sdk;src;Abbreviations;AStyle;Autosave;Compiler depslib;Compiler;Debugger;Code-completion;Class wizard;Default MIME handler;Occurrences Highlighting;Open files list;Projects-workspaces importer;Scripted wizard;To-do;XP look &amp; feel;" />
  <Add alias="Core app &amp; plugins" targets="sdk;src;AStyle;Autosave;Compiler depslib;Compiler;Debugger;Code-completion;Class wizard;Default MIME handler;Occurrences Highlighting;Open files list;Projects-workspaces importer;Scripted wizard;To-do;XP look &amp; feel;" />
  <Add alias="Third-party libs" targets="tinyXML;AutoRevision;ConsoleRunner;Squirrel;Squirrel std lib;SqPlus;scintilla;wxpropgrid;Compiler depslib;" />
  </VirtualTargets>

Allow ! (exclamation mark) within file paths on compiler warning/error. (It won't hurt Linux and I need it :P)

Also add another warning to "options_common_re-msvc.xml"
Code: xml
    <RegEx name="Linker warning (2)"
           type="warning"
           msg="1;4;2"
           file="3">
        <![CDATA[warning C4[0-9]+: (.+) (in ['"]([^'"]+)['"] and ['"][^'"]+['"])(: .*)]]>
    </RegEx>
and it looks like
Quote from: vc compiler
warning C4742: 'bHour12' has different alignment in 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\Tclock.c' and 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\format.c': 1 and 4
warning C4743: 'bHour12' has different size in 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\Tclock.c' and 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\format.c': 1 and 4 bytes
warning C4742: 'bHourZero' has different alignment in 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\Tclock.c' and 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\format.c': 1 and 4
warning C4743: 'bHourZero' has different size in 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\Tclock.c' and 'E:\zZ-Progra\_SVNs\T-Clock NG\Source\DLL\format.c': 1 and 4 bytes
(Windoze warnings always start with C4... and are 4 numbers)

Also it would be better to have the c/c++ template look like:
Code: c++
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{
puts("Hello world!");
return 0;
}
as the default one without params is almost useless... and printf isn't a good idea to print a static string without variables. And pls use tabs


Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on September 07, 2013, 06:09:23 pm
anyway... here are a few suggestions / patches:
Link ConsoleRunner statically. This allows one to use a compiler with sjlj (and CB build with that) but also compile and run code with dwarf. Otherwise ConsoleRunner tries to find libgcc with sjlj but can't because Code::Blocks set's the environment variable to the dwarf tool-chain.
I don't understand fully, I use nightly build C::B which is built from TDM GCC 4.7.1 sjlj, but I mainly use PCX's MinGW GCC 4.6.3 dwarf2, I don't have any issue.
Quote
(not sure how that "-static" works for Linux... but it's important for Windows... -static-libgcc doesn't work) Also I've set exchndl to be compiled when one compiles Code::Blocks... I can't see a reason for not compiling it as it's bad to go without it.
I think the reason is: exchndl need libbfd or other libraries which are not available for a normal MinGW distribution. If you enable them, many user will complain. :)
Title: Re: The 06 August 2013 build (9246) is out.
Post by: White-Tiger on September 08, 2013, 04:36:04 am
[...]
I think the reason is: exchndl need libbfd or other libraries which are not available for a normal MinGW distribution. If you enable them, many user will complain. :)
k... makes sense :P I'm using MinGW-builds... didn't had to add anything ;)

@edit:
you might ignore the ConsoleRunner stuff for now... I couldn't reproduce it :P I only know I had to use static... but I don't know why... nor do I have any idea what was different or what I did... (I just wanted to test the dwarf build of mingw-build to find out if it's able to cross-compile for x86_64 and not only for x86... and it couldn't... Why isn't there any compiler out there that uses dwarf on x86 and seh on x86_64 in one toolchain?)
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on September 08, 2013, 07:51:24 am
@edit:
you might ignore the ConsoleRunner stuff for now... I couldn't reproduce it :P ...
Ok.
Btw, when you say "ConsoleRunner", do you mean just click the "run" button of the toolbar when you create a console project?
Title: Re: The 06 August 2013 build (9246) is out.
Post by: White-Tiger on September 08, 2013, 03:18:10 pm
run or compile&run yes... nvm... it won't work right now...
I must have screwed up then anything else, so nvm :P
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on October 12, 2013, 02:46:52 pm
@ollydbg:
can you test the attached patch ?

Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.

Hi, jens, thanks, I just test this patch, and it fix the problem I reported.

Jen, can you commit this patch to trunk? Thanks.
Title: Re: The 06 August 2013 build (9246) is out.
Post by: Jenna on October 12, 2013, 06:27:39 pm
@ollydbg:
can you test the attached patch ?

Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.

Hi, jens, thanks, I just test this patch, and it fix the problem I reported.

Jen, can you commit this patch to trunk? Thanks.

Committed to trunk (svn r9398).

Jens
Title: Re: The 06 August 2013 build (9246) is out.
Post by: ollydbg on October 13, 2013, 01:28:22 am
@ollydbg:
can you test the attached patch ?

Just a quick and rough one. It also zooms the folding margin, but not the changebar and marker margin.
The changebar-margin is just 4 px small, so it does not really matter, and the maerker margin would need tweaking of all plugins that use it, and I do not have the time at the moment.

Hi, jens, thanks, I just test this patch, and it fix the problem I reported.

Jen, can you commit this patch to trunk? Thanks.

Committed to trunk (svn r9398).

Jens
Thank you.