Author Topic: The 02 November 2012 build (8500) is out.  (Read 139638 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: The 02 November 2012 build (8500) is out.
« Reply #15 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: The 02 November 2012 build (8500) is out.
« Reply #16 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline carra

  • Multiple posting newcomer
  • *
  • Posts: 114
Re: The 02 November 2012 build (8500) is out.
« Reply #17 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: [Select]
[[ print("*line 1*\r\n*line 2*"); ]]
CodeBlocks 8500 prints the following:

Code: [Select]
*line 1*

*line 2*

While 8248 and previous correctly printed

Code: [Select]
*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
« Last Edit: November 05, 2012, 03:26:03 pm by carra »

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 02 November 2012 build (8500) is out.
« Reply #18 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).

Offline shurick

  • Multiple posting newcomer
  • *
  • Posts: 35
Re: The 02 November 2012 build (8500) is out.
« Reply #19 on: November 06, 2012, 04:31:11 am »
Packages for openSUSE 12.1, openSUSE 12.2 (binaries and sources) for 32-bit and 64-bit.
Packages for openSUSE http://codeblocks.esy.es  (binaries and sources) for 32-bit and 64-bit.

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: The 02 November 2012 build (8500) is out.
« Reply #20 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
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: The 02 November 2012 build (8500) is out.
« Reply #21 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: The 02 November 2012 build (8500) is out.
« Reply #22 on: November 07, 2012, 07:46:02 pm »
Thanks for the reply

gd_on
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5193
Re: The 02 November 2012 build (8500) is out.
« Reply #23 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  :-\

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: The 02 November 2012 build (8500) is out.
« Reply #24 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
« Last Edit: November 08, 2012, 03:00:34 pm by gd_on »
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 02 November 2012 build (8500) is out.
« Reply #25 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)

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: [Select]
@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. :)
« Last Edit: November 08, 2012, 03:02:29 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline White-Tiger

  • Multiple posting newcomer
  • *
  • Posts: 83
Re: The 02 November 2012 build (8500) is out.
« Reply #26 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)
Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline gd_on

  • Regular
  • ***
  • Posts: 494
Re: The 02 November 2012 build (8500) is out.
« Reply #28 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 !
« Last Edit: November 11, 2012, 06:18:32 pm by gd_on »
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline AndyJ

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 02 November 2012 build (8500) is out.
« Reply #29 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...)
« Last Edit: November 14, 2012, 10:22:39 am by AndyJ »