Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on November 02, 2012, 01:34:21 pm

Title: The 02 November 2012 build (8500) is out.
Post by: killerbot on November 02, 2012, 01:34:21 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

The 02 November 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20121102_rev8500_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 02 November 2012 build (8500) is out.
Post by: march1993 on November 02, 2012, 03:22:59 pm
It seems that code completion doesn’t work properly with SDCC 3.2.0.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 02, 2012, 04:31:33 pm
It seems that code completion doesn’t work properly with SDCC 3.2.0.
What do you think shall we make out of this sentence, please? What does when not work with what versions - details, steps to reproduce etc... please.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: Jenna on November 02, 2012, 09:15:29 pm
As usual:
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 (fc16, fc17 and fc18) can be found in my rpm-repo (http://rpm.jenslody.de) .
Packages for CentOS/RedHat 5 and 6 will follow. can be found there (http://rpm.jenslody.de) too.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: march1993 on November 03, 2012, 02:53:31 am
It seems that code completion doesn’t work properly with SDCC 3.2.0.
What do you think shall we make out of this sentence, please? What does when not work with what versions - details, steps to reproduce etc... please.

install SDCC 3.2.0 and code::blocks 8500, then create a default MCS51 project, open main.c, input "INT", the code completion should pop up with "INT0" or "INT1". but code::blocks does nothing.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: march1993 on November 03, 2012, 02:54:25 am
It seems that code completion doesn’t work properly with SDCC 3.2.0.
What do you think shall we make out of this sentence, please? What does when not work with what versions - details, steps to reproduce etc... please.

install SDCC 3.2.0 and code::blocks 8500, then create a default MCS51 project, open main.c, input "INT", the code completion should pop up with "INT0" or "INT1". but code::blocks does nothing.

It seems that code::blocks works properly with an older version of SDCC.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ollydbg on November 03, 2012, 02:35:34 pm
I see a wired bug, When I try to use this nightly build version to build the cb, I have such build error:

Code
-------------- Build: tinyXML in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: AutoRevision in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: ConsoleRunner in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: Squirrel in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: Squirrel std lib in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: SqPlus in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: scintilla in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.

-------------- Build: wxpropgrid in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.
[100.0%] Running target pre-build steps
build_tools/autorevision/autorevision +wx +int +t . include/autorevision.h
'svn' is not recognized as an internal or external command,
operable program or batch file.
'git' is not recognized as an internal or external command,
operable program or batch file.
'svn' is not recognized as an internal or external command,
operable program or batch file.

-------------- Build: sdk in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.
[ 33.3%] Running target post-build steps
[ 66.7%] cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
[100.0%] zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
cmd /c "cd sdk\resources & zip -0 -q ..\..\devel\share\CodeBlocks\manager_resources.zip images\*.png images\12x12\*.png images\16x16\*.png"
'zip' is not recognized as an internal or external command,
operable program or batch file.
Process terminated with status 1 (0 minutes, 4 seconds)
0 errors, 0 warnings (0 minutes, 4 seconds)


But I have "zip" and "svn" command in my PATH, see the log:
Code

C:\>which svn
C:\Program Files\SlikSvn\bin\svn.EXE

C:\>which zip
E:\code\common_bin\zip.EXE

C:\>


So, I suspect the PATH variable was sometimes changed by compiler plugin? I will check an old nightly build version.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ollydbg on November 03, 2012, 02:56:31 pm
The bad thing is: if I rebuild C::B, I will sometimes see the warning message(see below)
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-11-03215542.png)
Does this mean that my "PATH" was locked by some one/software?
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ollydbg on November 04, 2012, 06:25:37 am
It looks like in my system, wxSetEnv failed.

See a related discussion: Re: C::B execution paths (http://forums.codeblocks.org/index.php/topic,16864.msg114942.html#msg114942)

Quote
In a private project of mine I had the issue that wxSetEnv is unreliable for some reason. So what I did was the following:
Code:

bool mySetEnv(const wxString& name, const wxString& value)
{
  // The WX-way...
  bool success = wxSetEnv(name, value);

  // The MinGW-way...
  wxString putenv_var = name + wxT("=") + value;
#if wxUSE_UNICODE
  std::string stl_putenv_var = (const char*)putenv_var.mb_str(wxConvLocal);
#else
  std::string stl_putenv_var = putenv_var.c_str();
#endif
  char buffer[stl_putenv_var.length()+1]; memset(buffer, 0x00, sizeof(buffer));
  memcpy(buffer, stl_putenv_var.c_str(), stl_putenv_var.length());
  success &= ( putenv(buffer)==0 ); // returns 0 on success
  // success &= ( _putenv(stl_putenv_var.c_str())==0 );

  return success;
}// mySetEnv

...then (and only then!), all my low-level code that relies on envvars being set worked properly. You may face a similar issue here.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: oBFusCATed on November 04, 2012, 10:37:20 am
This line is a bit strange:
Code
     char buffer[stl_putenv_var.length()+1]; 
because this is not a valid c++, but probably uses some language extension of gcc.

About the issue: have you looked at the code of wxsetenv? What does it do?
Have this problem been reported to wx devs?

They think it is fixed: http://trac.wxwidgets.org/ticket/1413
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ollydbg on November 04, 2012, 11:55:16 am
This line is a bit strange:
Code
     char buffer[stl_putenv_var.length()+1]; 
because this is not a valid c++, but probably uses some language extension of gcc.
Maybe, morten can say something about this.

Quote
About the issue: have you looked at the code of wxsetenv? What does it do?
see below:
Code
bool wxSetEnv(const wxString& WXUNUSED_IN_WINCE(var),
              const wxChar *WXUNUSED_IN_WINCE(value))
{
    // some compilers have putenv() or _putenv() or _wputenv() but it's better
    // to always use Win32 function directly instead of dealing with them
#ifdef __WXWINCE__
    // no environment variables under CE
    return false;
#else
    if ( !::SetEnvironmentVariable(var, value) )
    {
        wxLogLastError(_T("SetEnvironmentVariable"));

        return false;
    }

    return true;
#endif
}

I can not see any reason why SetEnvironmentVariable failed.
Quote
Have this problem been reported to wx devs?
I will report it if I have time.

Quote
They think it is fixed: http://trac.wxwidgets.org/ticket/1413
It said:
Quote
Changed 4 years ago by neis
Fixed by revision 42471, which should have ensured that it's correct in 2.8.0 and later.
But it appears that the bug is still here in wx2.8.12.


Edit:
See here: http://docs.wxwidgets.org/2.9.3/group__group__funcmacro__env.html

Quote
bool wxSetEnv    (    const wxString &     var,
      const wxString &     value
   )       

Sets the value of the environment variable var (adding it if necessary) to value.

Notice that under Windows platforms the program may have two different environment blocks: the first one is that of a Windows process and is always present, but the CRT may maintain its own independent copy of the environment. wxSetEnv() will always update the first copy, which means that wxGetEnv(), which uses it directly, will always return the expected value after this call. But wxSetEnv() only updates the second copy for some compilers/CRT implementations (currently only MSVC and MinGW which uses the same MSVC CRT) and so using wxGetenv() (notice the difference in case) may not return the updated value.

Parameters
    var   The environment variable to be set, must not contain '=' character.
    value   New value of the variable.

Returns
    true on success or false if changing the value failed.

See Also
    wxUnsetEnv()

Include file:

#include <wx/utils.h>


But I do not quite understand this description.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 04, 2012, 05:11:45 pm
This line is a bit strange:
Code
char buffer[stl_putenv_var.length()+1];
because this is not a valid c++, but probably uses some language extension of gcc.
Maybe, morten can say something about this.
Nope I can't other than it compiles and works just fine w/o specific extension (and why is it no C++, btw?!):
http://www.cplusplus.com/reference/string/string/length/
Its that same as char buffer[64]; or alike...
Title: Re: The 02 November 2012 build (8500) is out.
Post by: oBFusCATed on November 04, 2012, 05:14:53 pm
Its that same as char buffer[64]; or alike...
No it is not, it is the same as int a=5; char buffer[a];. Have you tried to compile it with -ansi?
Title: Re: The 02 November 2012 build (8500) is out.
Post by: p2rkw on November 04, 2012, 05:24:02 pm
Variable Length Array - it's in C standard but not C++: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
'64' is compile time constant, string::length is run time constant. 'const' qualifier only allow to call length() on const object.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 04, 2012, 05:31:07 pm
No it is not, it is the same as int a=5; char buffer[a];. Have you tried to compile it with -ansi?
No, why should I?

Variable Length Array - it's in C standard but not C++: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
So - according this its OK. And yes, of course I know its a variable and not a constant. I thought oBFusCATed meant the length() method not being standard and I wanted to point put that it returns a const size_t.

BTW: I think we are getting off-topic ...
Title: Re: The 02 November 2012 build (8500) is out.
Post by: oBFusCATed on November 04, 2012, 06:26:35 pm
No, why should I?
Because you're writing non-standard code which will break with another compiler, which doesn't support GCC extensions probably.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 04, 2012, 06:29:48 pm
Because you're writing non-standard code which will break with another compiler, which doesn't support GCC extensions probably.
OK - but I don't want to use another compiler and use several GCC extensions already because they are handy. But yes - its surely a portability issue.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: carra on November 05, 2012, 03:14:33 pm
I can confirm that the fix for custom abbreviations is working correctly now: the empty extra lines are no longer inserted due to Windows line terminators "\r\n".

However, this bug persists when the abbreviations are using scripts! I don't really know why, since I thought script execution should be unaffected by this.

For instance, if you write this abbreviation under Windows (using the windows EOL):

Code
[[ print("*line 1*\r\n*line 2*"); ]]

CodeBlocks 8500 prints the following:

Code
*line 1*

*line 2*

While 8248 and previous correctly printed

Code
*line 1*
*line 2*

Should I now change my scripts to Linux EOL '\n'? (and hope it won't break EOL consistency in my files)

EDIT: I have verified that the bug, however, does not happen if you execute that script line in the script console. So it has to do with abbreviations instead
Title: Re: The 02 November 2012 build (8500) is out.
Post by: Alpha on November 06, 2012, 02:54:07 am
However, this bug persists when the abbreviations are using scripts! I don't really know why, since I thought script execution should be unaffected by this.
That does not make sense... I will see if I can figure out why.

Should I now change my scripts to Linux EOL '\n'? (and hope it won't break EOL consistency in my files)
Yes, this is the recommended (by me ;)) method; code generation will match the editor's current EOL style just before insertion (if you would like to double check, set EditorTweaks to show EOL characters).
Title: Re: The 02 November 2012 build (8500) is out.
Post by: shurick on November 06, 2012, 04:31:11 am
Packages for openSUSE 12.1 (http://download.opensuse.org/repositories/home:/NarkoZ/openSUSE_12.1/), openSUSE 12.2 (http://download.opensuse.org/repositories/home:/NarkoZ/openSUSE_12.2/) (binaries and sources) for 32-bit and 64-bit.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: gd_on on November 07, 2012, 04:04:57 pm
I have a small problem when I build a recent svn version (8523) under windows : exchndl.dll does not seem to be build when I make a full All build (with CodeBlocks.workspace or more precisely CodeBlocks.cbp).
It is built only if I select specifically as Build target ... "exchndl". Is it normal ?

gd_on
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 07, 2012, 04:25:51 pm
It is built only if I select specifically as Build target ... "exchndl". Is it normal ?
Yes, it has been disabled for several reasons, one is it broke builds on some systems as people were unable to have the pre-requisites required for this target. To avoid noise we disabled it in "All". Hence you need this DLL for the crash report to work correctly. But its enough if you compile it one time explicitly once you have changed the compiler.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: gd_on on November 07, 2012, 07:46:02 pm
Thanks for the reply

gd_on
Title: Re: The 02 November 2012 build (8500) is out.
Post by: killerbot on November 07, 2012, 10:46:12 pm
It is built only if I select specifically as Build target ... "exchndl". Is it normal ?
Yes, it has been disabled for several reasons, one is it broke builds on some systems as people were unable to have the pre-requisites required for this target. To avoid noise we disabled it in "All". Hence you need this DLL for the crash report to work correctly. But its enough if you compile it one time explicitly once you have changed the compiler.

which reminds me, I was going to provide a new version, and forgot  :-\
Title: Re: The 02 November 2012 build (8500) is out.
Post by: gd_on on November 08, 2012, 10:29:11 am
Thanks for patch in svn 8519 : I'm (we are !) now able to generate fortran code with modules with multi-thread. Before, it worked properly only in mono-thread because modules in fortran are a little bit specials : two files are generated, a classic .o file and a .mod file. This last one may be/is necessary at compile time in other routines/modules, so in multi-threading, you might need a .mod file before the end of it's own build. Now, with the new priority gestion, it's solved since svn 8519.
Thanks again.

gd_on
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ollydbg on November 08, 2012, 02:55:25 pm
The bad thing is: if I rebuild C::B, I will sometimes see the warning message(see below)
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-11-03215542.png)
Does this mean that my "PATH" was locked by some one/software?

I found a workaround, for those who have the same issue, you can give C::B a new and clean environment, like, start C::B in the console with the command:
Code
@set PATH=E:\code\common_bin;C:\Program Files\SlikSvn\bin
start codeblocks.exe

Here, the PATH variable is set manually, and my c::b build and works fine.

I guess that my PATH have too many strings, which cause the SetEnvironmentVariable function fail. :)
Title: Re: The 02 November 2012 build (8500) is out.
Post by: White-Tiger on November 10, 2012, 04:55:57 pm
well this isn't about this specific nightly... but rather revision 8536, it simply breaks the windows build^^
It's not possible to define "unused" as this is often a variable name used with windows. eg. in "winnt.h" it is used for the "DECLARE_HANDLE" define. (MinGW64)
Title: Re: The 02 November 2012 build (8500) is out.
Post by: oBFusCATed on November 10, 2012, 05:02:08 pm
White-Tiger: http://forums.codeblocks.org/index.php/topic,17067.msg116546/topicseen.html#msg116546
Title: Re: The 02 November 2012 build (8500) is out.
Post by: gd_on on November 11, 2012, 05:26:31 pm
Something new in svn 8549 (or a bug ?), but, under Windows 7, an AppData has been created in my Program files (x86)\codeblocks folder and my previous default.conf is not found. Apparently, it's in this new folder that C::B parameters are stored. Is it normal ?
After reverting to svn 8543, everything is OK again. Is it a bug ? a new behaviour ? But, in that last case, if Program files is write protected, a standard behaviour in Windows 7, I'm not sure it's a good idea : within the user's profile it's better.

gd_on

Edit : I have made a full rebuild and an install in a clean empty folder, and everything is OK with svn 8549. Strange. Sorry for the noise !
Title: Re: The 02 November 2012 build (8500) is out.
Post by: AndyJ on November 14, 2012, 10:20:48 am
Thanks for all the great work recently!

I noticed a few nightlies back that on my 2 monitor Win-XP system CodeBlocks no longer remembers that it was last run maximised on my 2nd monitor (this used to work). It did however remember that it was on the the 2nd monitor if not maximised. With the latest nightly, it now always seems to start on my primary monitor regardless of where it was when it was last closed - any ideas?

Andy

Edit: Oops, this really applies to the Nov 11th nightly (which now seems to have become something different...)
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 14, 2012, 11:08:47 am
With the latest nightly, it now always seems to start on my primary monitor regardless of where it was when it was last closed - any ideas?
I know why, but the issue is that its not easily resolvable using wxWidgets as it missed important information on the about the display configuration. So either we implemented it ourselves for all platforms or wait until wxWidgets has the options to use.

Why it was changes is that with the previous version it was possible, that Windows appeared outside of a (single display) screen when being launched on a dual-monitor system before. This is worse than the effect now. Thus I decided to change it. If you don't like it, revert r8535. I'll think about to make this behaviour an option - although this would be an ugly hack.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 14, 2012, 11:16:21 am
Thus I decided to change it. If you don't like it, revert r8535. I'll think about to make this behaviour an option - although this would be an ugly hack.
...maybe I just found a better solution... gimme some time to test...
Title: Re: The 02 November 2012 build (8500) is out.
Post by: MortenMacFly on November 14, 2012, 01:38:19 pm
...maybe I just found a better solution... gimme some time to test...
The meanwhile committed fix should work for you (and others, of course). If you are willing to help, compile trunk and report back.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ambarj2009 on November 27, 2012, 08:16:06 pm
I'm having problems with this version (8500), the machine is rebooted, or Code :: Blocks terminates with an error. It does quite often.

After reviewing event viewer I saw that for this application the error:

Faulting application: codeblocks.exe, version 0.0.0.0, faulting module msvcrt.dll, version 7.0.2600.5512, fault address 0x00037742.

I have gcc 4.7.2 installed.

I appreciate any help.
 :'(
Title: Re: The 02 November 2012 build (8500) is out.
Post by: oBFusCATed on November 27, 2012, 08:25:50 pm
I'm having problems with this version (8500), the machine is rebooted, or Code :: Blocks terminates with an error. It does quite often.
Have you verified that you machine is stable without running codeblocks? Have you checked for hardware stability? Driver stability, etc?
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ambarj2009 on November 27, 2012, 08:43:12 pm
I'm having problems with this version (8500), the machine is rebooted, or Code :: Blocks terminates with an error. It does quite often.
Have you verified that you machine is stable without running codeblocks? Have you checked for hardware stability? Driver stability, etc?

Thanks for answering.  :D

Yes, it is stable. Although I do not think this is the problem. Everything is new. This week and last.

In these first two weeks switched to GCC version 4.7.2 and then change the version Code :: Blocks: From here the problems started.

The symptom is:
1) Start Code :: Blocks. All is well.
2) I open the project I work. All is well.
3) I continue with my work and in minutes the application falls Code :: Blocks, this in the best case.

Now I tried to disable SpellChecker. I changed it to use a dictionary in Spanish. It seems that for now remains. I do not know if this is the problem, if solved, will put a message.

The Spanish dictionary also recently installed it, but a little over a month and previous versions of Code :: Blocks seemed fine.
Title: Re: The 02 November 2012 build (8500) is out.
Post by: ambarj2009 on November 28, 2012, 08:56:20 pm
I'm having problems with this version (8500), the machine is rebooted, or Code :: Blocks terminates with an error. It does quite often.
Have you verified that you machine is stable without running codeblocks? Have you checked for hardware stability? Driver stability, etc?

Thanks for answering.  :D

Yes, it is stable. Although I do not think this is the problem. Everything is new. This week and last.

In these first two weeks switched to GCC version 4.7.2 and then change the version Code :: Blocks: From here the problems started.

The symptom is:
1) Start Code :: Blocks. All is well.
2) I open the project I work. All is well.
3) I continue with my work and in minutes the application falls Code :: Blocks, this in the best case.

Now I tried to disable SpellChecker. I changed it to use a dictionary in Spanish. It seems that for now remains. I do not know if this is the problem, if solved, will put a message.

The Spanish dictionary also recently installed it, but a little over a month and previous versions of Code :: Blocks seemed fine.

Hello again.

Well, I finally discovered that the problem was with the SpellChecker configuration. To disable it, no longer produce the problems indicated.

Thank you.
Until next time.  8)