Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on November 16, 2013, 07:59:18 pm

Title: The 16 November 2013 build (9455) is out.
Post by: killerbot on November 16, 2013, 07:59:18 pm
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (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 16 November 2013 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20131116_rev9455_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 17, 2013, 01:21:58 pm
damn this is tiresome...
i am on latest linux mint 15 olivia as of now (based on ubuntu)
i tried to compile this version from svn. took me a long while to get all of the tools in place, but finally config gave me the go.
but when i make, i get this error:

/bin/sed: can't read 9455/src/sdk/libcodeblocks.la: No such file or directory
libtool: link: `9455/src/sdk/libcodeblocks.la' is not a valid libtool archive

along with remaining "friends":

make[4]: *** [libastyle.la] Error 1
make[4]: Leaving directory `/home/mario/VCN/codeblocks 9455/src/plugins/astyle'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/mario/VCN/codeblocks 9455/src/plugins/astyle'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mario/VCN/codeblocks 9455/src/plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mario/VCN/codeblocks 9455/src'
make: *** [all-recursive] Error 1


how do i just get the codeblocks nightly onto my unix system????
the library IS there...
it took me too long to just get to this point, why not just prepare a linux executable (at least debian/ubuntu) since you also provide windows?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Jenna on November 17, 2013, 01:55:40 pm
It's there , see my signature for debian, fedora amd centos/redhat.
For ubuntu see other nightly threads.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 17, 2013, 03:36:19 pm
It's there , see my signature for debian, fedora amd centos/redhat.
For ubuntu see other nightly threads.

Thanks!
i managed to install codeblocks (not 9455 though, but it came out yesterday. i expect to get updates with your repo though?) and that is great!
there are a lot of packages i don't really know (additional libraries, deb and debug, which i don't know whether to install seeing as i want the ide to fully work.....also some wxwidgets stuff) but it seems to be working though (hello world compiled no problem...gonna check out some other stuff though) :)
about ubuntu threads...i haven't found any strictly-ubuntu packages around, only yours.

Do you think there are other packages apart from the main ones i should install from your repo?

edit: codeblocks seems to be working perfectly, even with external libraries such as sdl2...
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 17, 2013, 03:38:43 pm
Check here: http://forums.codeblocks.org/index.php/topic,18528.msg126762.html#msg126762
Jens' packages are not compatible with ubuntu, probably you can read this on his page.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Jenna on November 17, 2013, 03:49:03 pm
Check here: http://forums.codeblocks.org/index.php/topic,18528.msg126762.html#msg126762
Jens' packages are not compatible with ubuntu, probably you can read this on his page.
Partly correct.
I have packages from my repo installed on my 13.04 test vm without issues.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 17, 2013, 04:24:51 pm
Check here: http://forums.codeblocks.org/index.php/topic,18528.msg126762.html#msg126762
Jens' packages are not compatible with ubuntu, probably you can read this on his page.

Thanks! I don't know why moore doesn't have his repos added to the codeblocks website...would be a hell of a lot easier for everyone.
Anyways jens' debian builds are working just fine for me, i'd switch to moore's but i noticed he doesn't give the actual build version name to his builds like jens (or i am missing the point...) because while jens' is named  "svn9453" and i KNOW it is a recent version, moore's is named "trunkbzr7726.lp" which i don't really know what it stands for....
Title: Re: The 16 November 2013 build (9455) is out.
Post by: dmoore on November 17, 2013, 04:32:43 pm
Thanks! I don't know why moore doesn't have his repos added to the codeblocks website...

because of annoying issues like:

Quote
but i noticed he doesn't give the actual build version name to his builds like jens (or i am missing the point...) because while jens' is named  "svn9453" and i KNOW it is a recent version, moore's is named "trunkbzr7726.lp" which i don't really know what it stands for....

I am using Launchpad's automated build service, which only works with bzr repos. The bzr repo that the packages are created from is here: https://code.launchpad.net/~damien-moore/codeblocks/nightly
Eventually I should be able to use the SVN repo number in the package name, but Ubuntu's build servers don't support this yet.

Code::Blocks itself will still show the actual SVN revision number that the build is based on in the splash screen and the about page.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: dmoore on November 17, 2013, 04:48:27 pm
Updated Ubuntu packages (i386 + AMD64 for Precise through Trusty) will soon be available here (https://code.launchpad.net/~damien-moore/+archive/codeblocks-nightly).

Code
sudo add-apt-repository ppa:damien-moore/codeblocks-nightly
sudo apt-get update
sudo apt-get install codeblocks codeblocks-contrib

Note: If you are using Code::Blocks from Pasgui's repository you will need to uninstall it and disable that repo before adding this one and reinstalling.

Workaround for possible crash related to compiler plugin at start up:
1. Open terminal, run "codeblocks --safe-mode"
2. Plugins -> Manage Plugins -> Compiler plugin -> Enable, then close the dialog
3. Accept all prompts
4. Close codeblocks
5. Start codeblocks as you normally would and everything should work normally.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: cacb on November 17, 2013, 06:20:12 pm
Check here: http://forums.codeblocks.org/index.php/topic,18528.msg126762.html#msg126762
Jens' packages are not compatible with ubuntu, probably you can read this on his page.

Thanks! I don't know why moore doesn't have his repos added to the codeblocks website...would be a hell of a lot easier for everyone.
Anyways jens' debian builds are working just fine for me, i'd switch to moore's but i noticed he doesn't give the actual build version name to his builds like jens (or i am missing the point...) because while jens' is named  "svn9453" and i KNOW it is a recent version, moore's is named "trunkbzr7726.lp" which i don't really know what it stands for....

I use Kubuntu and build C::B myself using Jens' preconfigured tarball source here
http://apt.jenslody.de/testing/pool/main/c/codeblocks/  (download filename *.orig.tar.gz)

HOWTO
1. download *.orig.tar.gz as explained above
2. Expand in folder with full ownership (I tend to get problems with e.g. Windows NTFS partitions, so use ext3/ext4 instead)
3. If you have special build of wxWidgets 2.8.12 like me, build against the official Kubuntu repository version. You may have to edit the debian/rules file in the expanded files, and add the option shown in red
Quote
DEB_CONFIGURE_EXTRA_FLAGS=--with-contrib-plugins=all  --with-wx-config=/usr/bin/wx-config --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info

4. Then just do
Code
$ sudo dpkg-buildpackage

the result is a collection of .deb files. The svn number changes every time, but for 9099 the installation was done like this
Code
$ sudo dpkg -i codeblocks-common_12.11svn9099_all.deb
$ sudo dpkg -i libcodeblocks0_12.11svn9099_i386.deb
$ sudo dpkg -i libwxsmithlib0_12.11svn9099_i386.deb
$ sudo dpkg -i codeblocks_12.11svn9099_i386.deb
$ sudo dpkg -i codeblocks-contrib-common_12.11svn9099_all.deb
$ sudo dpkg -i codeblocks-libwxcontrib0_12.11svn9099_i386.deb
$ sudo dpkg -i codeblocks-contrib_12.11svn9099_i386.deb

When upgrading, I typically get some warnings the first time this script is executed. By running the script one more time, all is fine.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 17, 2013, 06:29:31 pm
Thanks! I don't know why moore doesn't have his repos added to the codeblocks website...

because of annoying issues like:

Quote
but i noticed he doesn't give the actual build version name to his builds like jens (or i am missing the point...) because while jens' is named  "svn9453" and i KNOW it is a recent version, moore's is named "trunkbzr7726.lp" which i don't really know what it stands for....

I am using Launchpad's automated build service, which only works with bzr repos. The bzr repo that the packages are created from is here: https://code.launchpad.net/~damien-moore/codeblocks/nightly
Eventually I should be able to use the SVN repo number in the package name, but Ubuntu's build servers don't support this yet.

Code::Blocks itself will still show the actual SVN revision number that the build is based on in the splash screen and the about page.

OK, well, i hope ubuntu servers get to workin then...
Also, where might is suggest a feature for codeblocks i have always been waiting for (themes support)?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 17, 2013, 07:52:54 pm
Also, where might is suggest a feature for codeblocks i have always been waiting for (themes support)?
Theme support for what?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 17, 2013, 08:03:00 pm
A very peculiar behavior with code completion happens on my svn9455. I have created a goto label, named error and whatever I do apart from ESC, tab or enter auto-completes the already inserted word.

The code becomes error:error automatically, unless I interrupt it with escape. Since I have typed the entire word manually, why auto-completion stays popped up displaying the same keyword among other available options?

Am I doing something wrong I should know about?

P.S.: I forgot to mention; the issue is on self-compiled debian testing PC. hopefully to test it tomorrow on Windows PC at work.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 17, 2013, 09:16:56 pm
Also, where might is suggest a feature for codeblocks i have always been waiting for (themes support)?
Theme support for what?

well...i know wxwidgets is supposedly used to make codeblocks and it uses the same windows the system is using....apart from the fact i don't really care for the native "feel" (which is up to the devs i suppose), one thing i cannot stand is eye straining white "stuff" when coding. This is exactly why i prefer to use visual studio on windows....
if the devs could come up with a way to make ALL of the interface black, and maybe integrate a theme-module-loading system sort of thing, it would be SO great!
I KNOW there is currently a way to do this (which import configs to edit the editor and change system theme to get black look throughout all of codeblocks) but it sucks. for real. I think codeblocks is the perfect coding suite, to have on all platforms for best project compatibility, but it needs to think more about the ui now....

this is, of course, my point of view....
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 17, 2013, 11:34:53 pm
Sorry can't do anything about this on windows or OSX.
No matter how many people request this feature - it won't happen, btw.
I suppose also if you request this in the wxWidget's bug tracker - they'll close your ticket.

On the other hand:
One option you nave is to try to build wxGTK on windows and then build C::B with this version of wxWidgets.
Then you'll be able to use gtk+ themes :)
Another options it to build under cygwin, search the forum for a relatively new topic about this.

Both will be painful and they will require patching C::B or wxWidgets.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 18, 2013, 02:48:37 am
I have created a goto label, named error and whatever I do apart from ESC, tab or enter auto-completes the already inserted word.
The code becomes error:error automatically, unless I interrupt it with escape. Since I have typed the entire word manually, why auto-completion stays popped up displaying the same keyword among other available options?
I am unable to reproduce.  Can you post a minimal example the exhibits this?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 18, 2013, 07:23:27 am
Try something totally generic, like:

Code
#include <stdio.h>
#include <stdlib.h>

#define nil(T) ((T)(void *)0)

typedef struct demo_t {
    const char *name;
} demo_t;

int main(void)
{
    demo_t * d = (demo_t *) malloc(sizeof(demo_t));
    if (d == nil(demo_t *)) goto error;

    d->name = "demo";
    printf("Name: %s\n", d->name);

    free(d);
    d = nil(demo_t *);

error:    /* <--  Here, as I start typing, the auto-completion starts
                      and even when i reach the last character ':' from
                      goto label, it still insists to display it, as available keyword.
                      If I press tab key or enter, instead of keeping
                      the already typed label name, it re-enters it
                      right after the already typed label name.
             */
    if (d) {
        free(d);
        d = nil(demo_t *);
    }
    return 0;
}
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Miguel Gimenez on November 18, 2013, 02:29:04 pm
I'm updating regularly from Jens repository my Wheezy install. Yesterday my two Debian computers failed updating Codeblocks to svn9453 (not 9455, I don't know why). The error is in spanish, but translates to something like:

dpkg-deb (subprocess): decompressing archive member: lzma error: the compressed data is corrupted
dpkg-deb: errror: the subprocess <decompression> returned error code 2
dpkg-deb (subprocess): can't copy the member of the archive /var/cache(apt/archives/codeblocks-contrib_12.11svn9453-1_i386.deb to the decompression pipe: write error (broken pipe)

And later:

Errors found processing:
 /var/cache/apt/archives/codeblocks-contrib-dbg_12.11svn9453-1_i386.deb
 /var/cache/apt/archives/codeblocks-contrib_12.11svn9453-1_i386.deb

Extract from my /etc/apt/sources.list:

deb http://apt.jenslody.de/stable stable main
deb-src http://apt.jenslody.de/stable stable main

Thank you
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Jenna on November 18, 2013, 02:50:43 pm
I'm updating regularly from Jens repository my Wheezy install. Yesterday my two Debian computers failed updating Codeblocks to svn9453 (not 9455, I don't know why). The error is in spanish, but translates to something like:

dpkg-deb (subprocess): decompressing archive member: lzma error: the compressed data is corrupted
dpkg-deb: errror: the subprocess <decompression> returned error code 2
dpkg-deb (subprocess): can't copy the member of the archive /var/cache(apt/archives/codeblocks-contrib_12.11svn9453-1_i386.deb to the decompression pipe: write error (broken pipe)

And later:

Errors found processing:
 /var/cache/apt/archives/codeblocks-contrib-dbg_12.11svn9453-1_i386.deb
 /var/cache/apt/archives/codeblocks-contrib_12.11svn9453-1_i386.deb

Extract from my /etc/apt/sources.list:

deb http://apt.jenslody.de/stable stable main
deb-src http://apt.jenslody.de/stable stable main

Thank you


Sorry for this.

I will build new packages (946055) and upload them to the repo.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 18, 2013, 04:27:39 pm
Sorry can't do anything about this on windows or OSX.
No matter how many people request this feature - it won't happen, btw.
I suppose also if you request this in the wxWidget's bug tracker - they'll close your ticket.

On the other hand:
One option you nave is to try to build wxGTK on windows and then build C::B with this version of wxWidgets.
Then you'll be able to use gtk+ themes :)
Another options it to build under cygwin, search the forum for a relatively new topic about this.

Both will be painful and they will require patching C::B or wxWidgets.


Thanks! I was lucky enough, though, i managed to get a black-ish sort of theme for codeblocks by using mint's AWE-SOME theming utility, which allowes me to choose multiple choices of themes for different ui components of the system. thing is....i LIKE my white high-contrast system theme, so i do not want to apply the black theme ALL over the system.
Big deal, some might say, apply the theme only when you're coding (which btw is almost always...) and put back the old one when you arent. or get mint to load the theme only for that specific program (which i could not, of course i will look further into this when i can).
Now i CAN do this, but it sucks because is is SO NOT cross platform, thus defeating codeblocks main feature (cross compatibility and light package and easy to use interface all over, at least for me), plus it will take me a lifetime to get it working right (right color combos, my editor colors suck right now) and i will not be able to use it on other systems.
I mean...it would be nice to go to windows, download the package briefly, install, load my project and switch to black interface. WITHOUT spending one hour for the ui setup.
But it appears this cannot be...oh well.
At least the very minimum i would like for codeblocks to include are multiple preinstalled configuration colors for the editor. some nice looking ones.
Yesterday, when trying to get codeblocks to look blackish (which came out really bad, like i said), a friend of mine told me codelite ide has this stuff.
i checked this codelite, apart from the fact i dont really like the confusing interface or how it works with directories, it had a REALLY NICE/COMFORTABLE color layout selection. THAT, was perfect.
Even though, it appears, it also uses wxwidgets, it managed to have 3 working themes:
-white everywhere
-black for editor (and it was WAY better looking than my "themed" editor)
-black editor plus some black app components that apparently they were able to color

now i hope no one will tell me: use codelite.
I like codeblocks, and i will use that, end of story.
But i hope the devs can come up with something, or come up at LEAST with multiple EASILY configurable default themes for the editor. Something like black with much yellow...or aqua..or something other than white.

Thanks to anyone for reading...

*EDIT: i found an interesting config for the editor which has some great themes! The black "vim" is exceptional! But there are also others, like sublime text.
(to load use cb_share_config,, both on linux and windows. Then under editor options -> syntax highlighting, select theme  ;D)
How about including them in future releases?
links: http://www.mediafire.com/download/74hqm9nwyhfb4gv/CB_ColorTheme.7z
or     https://mega.co.nz/#!Ilh0nJoS!K_UQpGhPE4J6R7yRYIHr4BYGmzxAaqopca0hdgw5saw
Title: Re: The 16 November 2013 build (9455) is out.
Post by: beqroson on November 18, 2013, 05:46:43 pm
Hello mariobarbara.

I am just like you, someone coming from nowhere, asking for new features. There is nothing wrong with that. Although, for the sake of the developers working on this, each request deserves a counter opinion. In my opinion, when I have read this thread, you asked not for just one thing but many. And at that without following it up properly. I think that is a bit disrespectful. But, since I am a talker myself, that talks a lot too much, i can understand you. Then again, I can tell you already, NONE of your requests will be listened to. However, if I am wrong on that point, congrats to you because you are lucky.

Now I understand why an adminstrator told me; If I spray this forum with ideas that will get nowhere, I will get banned. I understood it when I was told, but not really. Now I can see it about twice as clear. I have not yet put up any ideas completely out of its scope or context (not that I am aware of), but I could have done it. Since I am that kind of creative person.

I will be five times as careful from now on. I suggest you do the same mariobarbara.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Jenna on November 18, 2013, 05:53:47 pm
I'm updating regularly from Jens repository my Wheezy install. Yesterday my two Debian computers failed updating Codeblocks to svn9453 (not 9455, I don't know why). The error is in spanish, but translates to something like:

dpkg-deb (subprocess): decompressing archive member: lzma error: the compressed data is corrupted
dpkg-deb: errror: the subprocess <decompression> returned error code 2
dpkg-deb (subprocess): can't copy the member of the archive /var/cache(apt/archives/codeblocks-contrib_12.11svn9453-1_i386.deb to the decompression pipe: write error (broken pipe)

And later:

Errors found processing:
 /var/cache/apt/archives/codeblocks-contrib-dbg_12.11svn9453-1_i386.deb
 /var/cache/apt/archives/codeblocks-contrib_12.11svn9453-1_i386.deb

Extract from my /etc/apt/sources.list:

deb http://apt.jenslody.de/stable stable main
deb-src http://apt.jenslody.de/stable stable main

Thank you


Sorry for this.

I will build new packages (946055) and upload them to the repo.

Can you please try it again and post a feedback here ?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: mariobarbara on November 18, 2013, 05:59:40 pm
Hello mariobarbara.

I am just like you, someone coming from nowhere, asking for new features. There is nothing wrong with that. Although, for the sake of the developers working on this, each request deserves a counter opinion. In my opinion, when I have read this thread, you asked not for just one thing but many. And at that without following it up properly. I think that is a bit disrespectful. But, since I am a talker myself, that talks a lot too much, i can understand you. Then again, I can tell you already, NONE of your requests will be listened to. However, if I am wrong on that point, congrats to you because you are lucky.

Now I understand why an adminstrator told me; If I spray this forum with ideas that will get nowhere, I will get banned. I understood it when I was told, but not really. Now I can see it about twice as clear. I have not yet put up any ideas completely out of its scope or context (not that I am aware of), but I could have done it. Since I am that kind of creative person.

I will be five times as careful from now on. I suggest you do the same mariobarbara.
Wha? I DID ask something, and i DID get my answer, BUT since i was already here i though i might put this to good use and let devs know what i think about codeblocks.
I don't know if they will listen to me, and  personally i do not think there is something as asking too many questions (unless they are dumb), ALSO, i believe a developer appreciates feedback from his users. Codeblocks is used all around the world (i am italian), and i could not think devs of this project would not appreciate my suggestions. I am not requesting, just suggesting.
Sure, i hope the devs will listen to me, but i do not pretend to force or annoy anyone for some app theming...
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Miguel Gimenez on November 18, 2013, 06:08:53 pm
Quote
Can you please try it again and post a feedback here ?

After executing apt-get -f install (as required by apt-get upgrade, due to the previous failure) I receive a message:

codeblocks-wxcontrib-headers:i386 conflicts with codeblocks-wxcontrib-dev:i386

Anyway, the upgrade continues and ends OK; Codeblocks 9455 now works as expected.

Thank you for the quick fix.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 19, 2013, 12:00:37 am
Try something totally generic, like:
[...]
Okay, I see.
Settings->Editor->Code completion->Code completion [tab] add the character ":" to Fillup characters.  (I think this setting should be changed to default.)
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 19, 2013, 11:37:53 am
Okay, I see.
Settings->Editor->Code completion->Code completion [tab] add the character ":" to Fillup characters.  (I think this setting should be changed to default.)
I have tried this and apart from the old problem, a new issue appeared; it displays the same available keyword twice and still insists to concatenate the word right after colon.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ollydbg on November 22, 2013, 01:29:14 am
I see this error: (see screen shot below)

(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2013-11-22081807_zps83148947.png)

It happens when I open a simple wx2.8.12 project(from wx wizard), or press the build button.

Title: Re: The 16 November 2013 build (9455) is out.
Post by: stahta01 on November 22, 2013, 04:45:12 am
I see this error: (see screen shot below)


It happens when I open a simple wx2.8.12 project(from wx wizard), or press the build button.



Have any CB project in the past used two scripts in the Compiler other options before?

I think two does NOT work; I deleted either one and the error went away on the next project re-build.

Tim S.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 22, 2013, 05:22:05 am
I see this error: (see screen shot below)

It happens when I open a simple wx2.8.12 project(from wx wizard), or press the build button.
Have any CB project in the past used two scripts in the Compiler other options before?

I think two does NOT work; I deleted either one and the error went away on the next project re-build.
Uh-oh!  I tested that before I committed it, but obviously I was not thorough enough. :-[
@devs: I think it would be best to just revert lines 748-749 of src/plugins/scriptedwizard/resources/wxwidgets/wizard.script for now (instead of trying to fix multi-script compiler options), do you agree?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 22, 2013, 05:46:45 am
@devs: I think it would be best to just revert lines 748-749 of src/plugins/scriptedwizard/resources/wxwidgets/wizard.script for now (instead of trying to fix multi-script compiler options), do you agree?
Code: line:748-749
    if (WxVersion < 2 && GetCompilerFactory().CompilerInheritsFrom(Wizard.GetCompilerID(), _T("gcc*")))
        project.AddCompilerOption(_T("[[if (GetCompilerFactory().GetCompilerVersionString(_T(\"gcc\")) >= _T(\"4.8.0\")) print(_T(\"-Wno-unused-local-typedefs\"));]]"));
On a second thought, maybe it would be better to keep those lines, and instead remove
Code: line:665
            project.AddCompilerOption(_T("[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T(\"gcc\")) >= _T(\"4.0.0\"))) print(_T(\"-Wno-attributes\"));]]"));
from the wizard.  I have been unable to discover what warnings -Wno-attributes is supposed to silence that come up in wxWidgets projects; however, if try to use GCC 4.8 on wx2.8.12 without -Wno-unused-local-typedefs the log is drowned with these warnings.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 22, 2013, 06:00:20 am
I have tried this and apart from the old problem [...]
Did the setting resolve your old problem?

[...] a new issue appeared; it displays the same available keyword twice and still insists to concatenate the word right after colon.
My apologies, but I do not understand your description.  Could you try to explain it again?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 22, 2013, 07:24:09 am
Did the setting resolve your old problem?
Nope, I'm afraid I haven't.

My apologies, but I do not understand your description.  Could you try to explain it again?
I did what you have suggested (with Fill up characters) and now it duplicates the goto label twice in auto-completion popped up window while the old issue remains the same.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: killerbot on November 22, 2013, 07:42:55 am
"-Wno-unused-local-typedefs" , yes, ensure for sure that one can remain, cause this one is a warning exploder for wx, boost , ...
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ollydbg on November 22, 2013, 04:05:02 pm
I see this error: (see screen shot below)


It happens when I open a simple wx2.8.12 project(from wx wizard), or press the build button.



Have any CB project in the past used two scripts in the Compiler other options before?

I think two does NOT work; I deleted either one and the error went away on the next project re-build.

Tim S.

Thank Tim, indeed, I see that the compiler options has such code:
Code
-pipe
-mthreads
[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.0.0"))) print(_T("-Wno-attributes"));]]
[[if (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.8.0")) print(_T("-Wno-unused-local-typedefs"));]]
-Winvalid-pch
-include wx_pch.h

@Alpha:
I don't know the reason we need "-Wno-attributes" options.
I do know that "-Wno-unused-local-typedefs" was used to remove build warnings.


Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 22, 2013, 09:56:23 pm
-Wno-attributes came from rev 4596:
Code
http://cb.biplab.in/websvn/log.php?repname=codeblocks&path=%2F&isdir=1&peg=9462&sr=4596&er=1&max=1&search=
I have removed -Wno-attributes from the wizard in trunk now, as -Wno-unused-local-typedefs looks to be currently a much more useful command.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: dmoore on November 22, 2013, 10:06:42 pm
-Wno-attributes came from rev 4596:
Code
http://cb.biplab.in/websvn/log.php?repname=codeblocks&path=%2F&isdir=1&peg=9462&sr=4596&er=1&max=1&search=
I have removed -Wno-attributes from the wizard in trunk now, as -Wno-unused-local-typedefs looks to be currently a much more useful command.

Why don't we have check boxes for these -W flags in compiler settings?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: MortenMacFly on November 22, 2013, 10:44:24 pm
Why don't we have check boxes for these -W flags in compiler settings?
Seems nobody configured it in the related XML compiler settings.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: Alpha on November 25, 2013, 04:21:45 am
Why don't we have check boxes for these -W flags in compiler settings?
Seems nobody configured it in the related XML compiler settings.
During the conversion to XML, I pretty much tried to do a straight copy of what existed.  My personal opinion is that there are already too many flags, and that uncommon/special case flags are better suited to be manually entered.
Do note that the GUI does support Right click->New flag, so if you want your local version to have more flags, it is as easy as that.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: MortenMacFly on November 25, 2013, 07:30:03 am
Do note that the GUI does support Right click->New flag, so if you want your local version to have more flags, it is as easy as that.
Sure thing, but as (at least) -Wno-unused-local-typedefs is relevant to wxWidgets it should be natively supported.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 25, 2013, 02:30:00 pm
I went to Create a new project, right-click on GTK+ project, then Edit this script. The file opens in new tab window; I switch from Code::Blocks to Firefox using Alt+TAB, I come back to Code::Blocks and I get

(http://i39.tinypic.com/2eyffiw.png)

Is this normal, or I hit a bug?

P.S.: Special thanks goes to @oBFusCATed for his reply to this request; if I have found a bug, he should get the credit for this :D

http://forums.codeblocks.org/index.php/topic,18620.msg127477.html#msg127477 (http://forums.codeblocks.org/index.php/topic,18620.msg127477.html#msg127477)
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 25, 2013, 02:47:44 pm
Is this normal, or I hit a bug?
Yes, I think it is normal, but I don't know if this is a good behaviour.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 28, 2013, 02:45:34 pm
Currently compiled svn9468 on Windows 7 machine (at work) and auto-completion does not work properly.

As soon as I insert (*prd->st_info)->, instead of seeing the desired variables, I see whatever prd
has in it.

See the entire sample below:

Code: c
/*
 * Placed in Public Domain where applicable permitted by law.
 * USE IT AT YOUR OWN RISK!
 */
#include <stdio.h>
#include <stdlib.h>

#define nil ((void *)0)

typedef struct {
    int postal_code;
    const char *address;
} street_info_t;

typedef struct {
    street_info_t **st_info;
    const char *company_name;
} generic_t;

street_info_t * str_constructor(void) {
    street_info_t *tmp = (street_info_t *) malloc(sizeof(street_info_t));
    if (tmp == nil) {
        return nil;
    }
    return tmp;
}

void str_destructor(street_info_t **self) {
    if (*self != nil) {
        free(*self);
        *self = nil;
    }
    return;
}

generic_t * constructor(void) {
    generic_t *tmp = (generic_t *) malloc(sizeof(generic_t));
    if (tmp == nil) {
        return nil;
    }
    return tmp;
}

void destructor(generic_t **self) {
    if (*self != nil) {
        free(*self);
        *self = nil;
    }
    return;
}

int main(void)
{
    generic_t *prd = constructor();
    street_info_t *street = str_constructor();

    prd->st_info = &street;
    prd->company_name = "Disney Land";
    (*prd->st_info)->address = "Mikey Mouse avenue, Neverland";
    (*prd->st_info)->postal_code = 1010;

    printf("Company Name: %s\n", prd->company_name);
    printf("Address: %s\n", (*prd->st_info)->address);
    printf("Postal code: %d\n", (*prd->st_info)->postal_code);

    str_destructor(&street);
    prd->st_info = nil;

    destructor(&prd);

    return 0;
}
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 28, 2013, 02:47:05 pm
Is this a regression in this build?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ollydbg on November 28, 2013, 03:13:28 pm
@ToApolytoXaos (http://forums.codeblocks.org/index.php?action=profile;u=36043), If I remember correctly, we don't handle the parentheses correctly in CC. (It need some kind of operator precedence parsing of the statement, but currently we don't have this feature)
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 28, 2013, 03:15:02 pm
Ah OK, no worries. So it's not a bug, but a lack of feature :) nice. Also, should not be logical to offer only C keywords if you use a project as C, unless it's used in C++ as extern C? Most of the times I get full list of unnecessary keyword tags.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 29, 2013, 06:25:57 pm
Question: Why after I close a project from C::B, then close C::B itself, and reopen it each file's end-of-line mode converts to Windows? That's happening only under GNU / Linux :/
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 29, 2013, 06:42:57 pm
Can you describe the exact steps needed to reproduce this with a hello world project?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 29, 2013, 06:54:55 pm
Yeah, just create a simple project, add a file naming it main.c or main.cpp, add some code in it, compile it, run it, save / close the project, then close codeblocks, reopen it and see the balloon tip at bottom right corner saying about opening different line ending.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 29, 2013, 07:06:22 pm
This tooltip warns you that the file has mixed EOLs.
Can you enable the visibility of the EOL characters and to check what is the default style, and on which lines the EOLs differ.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 29, 2013, 07:37:18 pm
Indeed with C header / source files the header name includes UNIX end of line, whereas the body and the C++ files are using Windows end of line.

In settings / editor is set to auto.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 29, 2013, 08:35:22 pm
Are the line with wrong EOL typed by you or are they autogenerated by a wizard (file or project)?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on November 29, 2013, 08:55:51 pm
Are the line with wrong EOL typed by you or are they autogenerated by a wizard (file or project)?
I don't mess with EOL at all; it's the wizard's job to handle such things. Also, I went to Tweaks and changed the EOL and upon close and reopen the file, it still holds the old EOL :/
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on November 29, 2013, 09:35:32 pm
Set "Ensure consistent EOL" in the editor settings and you're ready to go.
Probably the wizards doesn't change the EOLs for template files.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: stahta01 on December 03, 2013, 01:45:48 pm
Windows NON PCH (Precompiled Header) build issue.

I am testing some rarely built projects for wxWidgets 3.0 issues and got error building ModPoller Optional Plugin.

Tim S.

Code
Index: src/plugins/modpoller/ModPoller.h
===================================================================
--- src/plugins/modpoller/ModPoller.h (revision 9479)
+++ src/plugins/modpoller/ModPoller.h (working copy)
@@ -13,6 +13,7 @@
 #endif
 
 #include <cbplugin.h>
+#include <editormanager.h>
 
 class ModPoller : public cbPlugin
 {
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on December 03, 2013, 08:38:30 pm
In svn...
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on December 06, 2013, 03:37:38 pm
Set "Ensure consistent EOL" in the editor settings and you're ready to go.
Probably the wizards doesn't change the EOLs for template files.
Done so; the issue remains the same. Oh well, I will try to ignore it then, unless it becomes really annoying.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on December 06, 2013, 03:39:45 pm
You have to change the file in order for the "ensure eol" logic to trigger. It won't fix all files in the project.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: dirk_1980 on December 07, 2013, 06:03:39 pm
Hi,

maybe it is a bug or i have forgotten to turn something on.

After i have made a update i have seen this, maybe it was the same in the last version i used


If i write code like:
#define TEST
#ifdef TEST
....   // this code is not active in the Editor (wrong colour)
#endif

If i write this:
#define TEST 1
#if (TEST == 1)
....   // this code is active in the Editor (right colour)
#endif

Is it a Bug or is it my mistake?
Dirk
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on December 07, 2013, 06:12:02 pm
Works for me with both variants. Are you using this nightly build?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: dirk_1980 on December 07, 2013, 06:13:59 pm
Yes of course.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on December 07, 2013, 06:38:04 pm
Then can you post the full source file or an example project that can be used to reproduce this?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on December 18, 2013, 09:15:33 pm
Code
*** Error in `codeblocks': corrupted double-linked list: 0x0bf06690 ***
======= Backtrace: =========
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x75e52)[0xb5b40e52]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x782ce)[0xb5b432ce]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_malloc+0x53)[0xb5b443e3]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(_ZN12wxStringBase11AllocBufferEj+0x44)[0xb6927654]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(_ZN12wxStringBase16AllocBeforeWriteEj+0x38)[0xb6927838]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(_ZN8wxString11GetWriteBufEj+0x24)[0xb6929854]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(_ZN8wxString9FromAsciiEPKc+0xa4)[0xb692a084]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(_ZN16wxDynamicLibrary10ListLoadedEv+0x15e)[0xb694d50e]
/usr/lib/i386-linux-gnu/libwx_gtk2u_qa-2.8.so.0(_ZN13wxDebugReport18DoAddLoadedModulesEP9wxXmlNode+0x22)[0xb6eaaf32]
/usr/lib/i386-linux-gnu/libwx_gtk2u_qa-2.8.so.0(_ZN13wxDebugReport10AddContextENS_7ContextE+0x45b)[0xb6ead2db]
/usr/lib/i386-linux-gnu/libwx_gtk2u_qa-2.8.so.0(_ZN13wxDebugReport6AddAllENS_7ContextE+0x17)[0xb6eaeb37]
codeblocks[0x808b066]
/usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0(wxFatalSignalHandler+0x23)[0xb6966cf3]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb77d8400]
[0x94a1a06]
======= Memory map: ========
08048000-081b2000 r-xp 00000000 fe:00 753836     /usr/local/bin/codeblocks
081b2000-081ba000 r--p 0016a000 fe:00 753836     /usr/local/bin/codeblocks
081ba000-081bd000 rw-p 00172000 fe:00 753836     /usr/local/bin/codeblocks
081bd000-081c2000 rw-p 00000000 00:00 0
0910c000-0c136000 rw-p 00000000 00:00 0          [heap]
a78e0000-a78e1000 ---p 00000000 00:00 0
a78e1000-a80e1000 rwxp 00000000 00:00 0
a80e1000-a81ff000 rw-p 00000000 00:00 0
a81ff000-a8200000 ---p 00000000 00:00 0
a8200000-a8a00000 rwxp 00000000 00:00 0
a8a00000-a8a21000 rw-p 00000000 00:00 0
a8a21000-a8b00000 ---p 00000000 00:00 0
a8b0e000-a8b0f000 ---p 00000000 00:00 0
a8b0f000-a930f000 rwxp 00000000 00:00 0
a930f000-a935c000 r--p 00000000 fe:00 13541624   /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
a935c000-a9378000 r-xp 00000000 fe:00 1278640    /usr/local/lib/codeblocks/plugins/libIncrementalSearch.so
a9378000-a9379000 r--p 0001c000 fe:00 1278640    /usr/local/lib/codeblocks/plugins/libIncrementalSearch.so
a9379000-a937a000 rw-p 0001d000 fe:00 1278640    /usr/local/lib/codeblocks/plugins/libIncrementalSearch.so
a937a000-a9385000 r-xp 00000000 fe:00 15351896   /usr/local/lib/codeblocks/plugins/libSmartIndentCpp.so
a9385000-a9386000 r--p 0000a000 fe:00 15351896   /usr/local/lib/codeblocks/plugins/libSmartIndentCpp.so
a9386000-a9387000 rw-p 0000b000 fe:00 15351896   /usr/local/lib/codeblocks/plugins/libSmartIndentCpp.so
a9387000-a9442000 r-xp 00000000 fe:00 1278635    /usr/local/lib/codeblocks/plugins/libHexEditor.so
a9442000-a9445000 r--p 000ba000 fe:00 1278635    /usr/local/lib/codeblocks/plugins/libHexEditor.so
a9445000-a9447000 rw-p 000bd000 fe:00 1278635    /usr/local/lib/codeblocks/plugins/libHexEditor.so
a9447000-a9448000 rw-p 00000000 00:00 0
a9448000-a94ac000 r-xp 00000000 fe:00 1278608    /usr/local/lib/codeblocks/plugins/libDoxyBlocks.so
a94ac000-a94ad000 ---p 00064000 fe:00 1278608    /usr/local/lib/codeblocks/plugins/libDoxyBlocks.so
a94ad000-a94af000 r--p 00064000 fe:00 1278608    /usr/local/lib/codeblocks/plugins/libDoxyBlocks.so
a94af000-a94b0000 rw-p 00066000 fe:00 1278608    /usr/local/lib/codeblocks/plugins/libDoxyBlocks.so
a94b0000-a94c8000 r-xp 00000000 fe:00 1278543    /usr/local/lib/codeblocks/plugins/libdefaultmimehandler.so
a94c8000-a94c9000 r--p 00018000 fe:00 1278543    /usr/local/lib/codeblocks/plugins/libdefaultmimehandler.so
a94c9000-a94ca000 rw-p 00019000 fe:00 1278543    /usr/local/lib/codeblocks/plugins/libdefaultmimehandler.so
a94ca000-a954e000 r-xp 00000000 fe:00 1278628    /usr/local/lib/codeblocks/plugins/libheaderfixup.so
a954e000-a9550000 r--p 00084000 fe:00 1278628    /usr/local/lib/codeblocks/plugins/libheaderfixup.so
a9550000-a9551000 rw-p 00086000 fe:00 1278628    /usr/local/lib/codeblocks/plugins/libheaderfixup.so
a9551000-a9568000 r-xp 00000000 fe:00 1278598    /usr/local/lib/codeblocks/plugins/libCppCheck.so
a9568000-a9569000 ---p 00017000 fe:00 1278598    /usr/local/lib/codeblocks/plugins/libCppCheck.so
a9569000-a956a000 r--p 00017000 fe:00 1278598    /usr/local/lib/codeblocks/plugins/libCppCheck.so
a956a000-a956b000 rw-p 00018000 fe:00 1278598    /usr/local/lib/codeblocks/plugins/libCppCheck.so
a956b000-a95a1000 r-xp 00000000 fe:00 1278561    /usr/local/lib/codeblocks/plugins/libtodo.so
a95a1000-a95a2000 ---p 00036000 fe:00 1278561    /usr/local/lib/codeblocks/plugins/libtodo.so
a95a2000-a95a4000 r--p 00036000 fe:00 1278561    /usr/local/lib/codeblocks/plugins/libtodo.so
a95a4000-a95a5000 rw-p 00038000 fe:00 1278561    /usr/local/lib/codeblocks/plugins/libtodo.so
a95a5000-a95e3000 r-xp 00000000 fe:00 1278644    /usr/local/lib/codeblocks/plugins/libkeybinder.so
a95e3000-a95e4000 ---p 0003e000 fe:00 1278644    /usr/local/lib/codeblocks/plugins/libkeybinder.so
a95e4000-a95e6000 r--p 0003e000 fe:00 1278644    /usr/local/lib/codeblocks/plugins/libkeybinder.so
a95e6000-a95e7000 rw-p 00040000 fe:00 1278644    /usr/local/lib/codeblocks/plugins/libkeybinder.so
a95e7000-a9674000 r-xp 00000000 fe:00 1278648    /usr/local/lib/codeblocks/plugins/liblib_finder.so
a9674000-a9675000 ---p 0008d000 fe:00 1278648    /usr/local/lib/codeblocks/plugins/liblib_finder.so
a9675000-a9678000 r--p 0008d000 fe:00 1278648    /usr/local/lib/codeblocks/plugins/liblib_finder.so
a9678000-a967a000 rw-p 00090000 fe:00 1278648    /usr/local/lib/codeblocks/plugins/liblib_finder.so
a967a000-a96ca000 r-xp 00000000 fe:00 1278567    /usr/local/lib/codeblocks/plugins/libAutoVersioning.so
a96ca000-a96cc000 r--p 0004f000 fe:00 1278567    /usr/local/lib/codeblocks/plugins/libAutoVersioning.so
a96cc000-a96cd000 rw-p 00051000 fe:00 1278567    /usr/local/lib/codeblocks/plugins/libAutoVersioning.so
a96cd000-a96d5000 r-xp 00000000 fe:00 15303333   /usr/local/lib/codeblocks/plugins/libSmartIndentHDL.so
a96d5000-a96d6000 r--p 00007000 fe:00 15303333   /usr/local/lib/codeblocks/plugins/libSmartIndentHDL.so
a96d6000-a96d7000 rw-p 00008000 fe:00 15303333   /usr/local/lib/codeblocks/plugins/libSmartIndentHDL.so
a96d7000-a96f2000 r-xp 00000000 fe:00 15303328   /usr/local/lib/codeblocks/plugins/libSymTab.so
a96f2000-a96f3000 r--p 0001b000 fe:00 15303328   /usr/local/lib/codeblocks/plugins/libSymTab.so
a96f3000-a96f4000 rw-p 0001c000 fe:00 15303328   /usr/local/lib/codeblocks/plugins/libSymTab.so
a96f4000-a96fc000 r-xp 00000000 fe:00 1278583    /usr/local/lib/codeblocks/plugins/libCccc.so
a96fc000-a96fd000 r--p 00008000 fe:00 1278583    /usr/local/lib/codeblocks/plugins/libCccc.soAborted

The following crashing happens when I start C::B and switch to another window while still loading its plugins. I guess it has something to do with "Focus on Window" event (if that's the event name)?

Version: svn9470
OS: GNU / Linux Debian testing (jessie), 32-bit
GCC: 4.8.2 (32-bit)
Desktop Environment: MATE 1.6.0
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on December 18, 2013, 11:36:21 pm
The following crashing happens when I start C::B and switch to another window while still loading its plugins.
Can you post the exact steps, which can be used to reproduce this 100% of the time?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on December 19, 2013, 05:50:36 pm
The steps are:
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on December 19, 2013, 08:22:43 pm
Can you do this same thing inside a C::B started under gdb?
Title: Re: The 16 November 2013 build (9455) is out.
Post by: ToApolytoXaos on December 19, 2013, 10:27:52 pm
With the latest build (svn9492) it works fine from both gdb and "Run". Previous problematic version was crashing from gdb as well; that's where I got the report and posted it here the first place.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: BlueHazzard on January 15, 2014, 11:25:47 pm
The steps are:
  • Ctrl-F2 to open "run" window. Type "codeblocks" in it.
  • Run it and as soon as you see the splash window, alt-tab to switch to another window so "Focus Window" event switch to that.
  • While it loads and you are on the window I have mentioned before, just before the finishing of GUI drawing, alt-tab to switch window again and voila; you got it crashed.

i have the same issue. Latest svn version.
If i start c::b and alt tab to a other window, c::b will load till the end, but as soon i switch back, i get a crash report:
Code
<frame level="0"/><frame level="1" function="wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&)" offset="0000007e"/><frame level="2" function="wxAppBase::ProcessIdle()" offset="00000074"/><frame level="3"/><frame level="4" function="g_main_context_dispatch" offset="00000135"/><frame level="5"/><frame level="6" function="g_main_loop_run" offset="0000006a"/><frame level="7" function="gtk_main" offset="000000a7"/><frame level="8" function="wxEventLoop::Run()" offset="00000048"/><frame level="9" function="wxAppBase::MainLoop()" offset="0000004c"/>
from gdb:
Code
#0  0x00007ffff548ab18 in main_arena () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6f782b4 in wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&) ()
   from /usr/local/lib/libwx_gtk2u-2.8.so.0
#2  0x00007ffff6f78764 in wxAppBase::ProcessIdle() ()
   from /usr/local/lib/libwx_gtk2u-2.8.so.0
#3  0x00007ffff6efc92e in wxapp_idle_callback ()
   from /usr/local/lib/libwx_gtk2u-2.8.so.0
#4  0x00007ffff30d8f05 in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff30d9248 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff30d96ba in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff78d4fe7 in gtk_main ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#8  0x00007ffff6f10278 in wxEventLoop::Run() ()
   from /usr/local/lib/libwx_gtk2u-2.8.so.0
#9  0x00007ffff6f7850c in wxAppBase::MainLoop() ()
   from /usr/local/lib/libwx_gtk2u-2.8.so.0
#10 0x000000000046459e in CodeBlocksApp::OnRun (this=0x84aee0)
    at /codeblocks_sf/src/src/app.cpp:809
#11 0x00007ffff6e90045 in wxEntry(int&, wchar_t**) ()
   from /usr/local/lib/libwx_gtk2u-2.8.so.0
#12 0x0000000000461b19 in main (argc=1, argv=0x7fffffffe448)
    at /codeblocks_sf/src/src/app.cpp:276

greetings
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on January 16, 2014, 01:21:35 am
BlueHazzard: Please specify your OS/distro and WindowManager or DesktopEnvironment.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: BlueHazzard on January 16, 2014, 08:29:46 am
Linux Mint 15
cinnamon 1.8.8 64
Title: Re: The 16 November 2013 build (9455) is out.
Post by: raynebc on January 18, 2014, 10:55:59 pm
I've been experiencing a problem for a while where when I try to open a particular source file in my project, it opens in CodeBlocks as if it is empty.  Right clicking on it in the management window and selecting properties indicates it's recognized as having 0 lines of source code but being about 39KB in size (which is an accurate size for the file in question).  The paths displayed for the file look fine and the fact that the file size is given means the IDE is seeing it.  "Project>Reparse current project" doesn't resolve the issue and I can't find that any other files in my project are affected.

I tried reproducing this problem by opening the exact same CodeBlocks project file in several nightly builds I've used in the past year or so.  In the 11-10-12 nightly (12.11 RC1), the source file opened properly.  In the 11-23-12 nightly (12.11 RC2) it did not open it correctly.  In the 12.11 stable release, it opened correctly.  In the 4-12-13, 8-6-13 and 11-16-13 nightly builds, the source file once again does not open correctly.

I don't see how it could be a problem outside of CodeBlocks itself, there are no permissions or file encoding issues that I can discern, and the fact that some of the builds open it correctly should rule stuff like that out anyways and verify that the project file itself is not corrupted in some way.  Anytime I want to view/edit the file I end up having to open it in another program like a text editor, and EditPad again confirms that the file is in the same encoding as other source files in the project.  The project in question is here if anybody wanted to try to reproduce it:
http://code.google.com/p/editor-on-fire/source/checkout
Title: Re: The 16 November 2013 build (9455) is out.
Post by: oBFusCATed on January 19, 2014, 01:32:54 am
What is the path/name of the file inside the project, so one can try it?
Can you please use revisions instead of dates? And using this strange format for dates doesn't help, too.
Also please post your OS version and if you're using any strange (non English) locale.
Title: Re: The 16 November 2013 build (9455) is out.
Post by: raynebc on January 19, 2014, 01:45:12 am
The relative path is "src\alogg\src\alogg.c".  At first I wondered if having two like-named folders in that path was confusing CodeBlocks, but the IDE has no problem with another source file at "src\minibpm-1.0\src\MiniBpm.cpp".

The revisions from this forum's Nightly Builds subforum are:
11-10-12 (Nov 10, 2012) r8549
11-23-12 (Nov 23, 2012) r8598
4-12-13 (Apr 12, 2013) r8982
8-6-13 (Aug 6, 2013) r9246
11-16-13 (Nov 16, 2013) r9455
And 12.11 stable is r8629.

Windows XP Pro x64, US English locale, non Unicode programs use Japanese language.  That last setting usually has little effect besides causing backslashes to display as the Yen symbol, and wouldn't explain why some builds of Codeblocks display the file while others don't.