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.next.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_wx284.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10.7z
The 25 June 2007 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20070625_rev4177_win32.7z
- Linux :
http://prdownload.berlios.de/codeblocks/CB_20070625_rev4177_Ubuntu6.10+7.04_wx2.8.4.deb (not yet)
http://prdownload.berlios.de/codeblocks/CB_20070625_rev4177_suse100-102.wx28.i586.rpm (not yet)
http://prdownload.berlios.de/codeblocks/CB_20070625_rev4177_fc4+5.i586.rpm (not yet)
Resolved Fixed:
- devpak plugin: fixed minor memory leak
- Code Completion: Fixed recent bug that prevented the symbol tree from being updated. Also removed some obsolete code
- Fixed possibly huge memory leak in code-completion (patch #2075, thanks dmoore)
- The linker search paths are now also used as search paths for the dynamic linker automatically (LD_LIBRARY_PATH for unices, DYLD_LIBRARY_PATH for Mac and PATH for windows)
- wxWidgets Wizard:
* Now Empty project creation and adding pch support options are available separately on Linux.
* User selections will now be stored on Linux. - CodeSnippets 1.2.82 2007/06/25
- Use text, up to first '\r' or '\n' to determine if snippet is file link.
This Allows notes to accompany file link.
- Added MIME open support using Alt-double-click & "Open File" context menu
- Refactored EditSnippet and OpenFileLink
- Added "Open Url" support
- ReInstated ToolTips for wx284 using first line of snippet - fixed bug [ Bug #11443 ] Insert all class methods without implementation fails const
Regressions/Confirmed/Annoying/Common bugs:
- Some users have experienced crashes on startup with this particular build
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
for some reason this build refuses to startup for me in linux. I see the splash screen and it quickly disappears and nothing more ...
Quote from: killerbot on June 25, 2007, 10:06:26 PM
for some reason this build refuses to startup for me in linux. I see the splash screen and it quickly disappears and nothing more ...
Might be this (http://forums.next.codeblocks.org/index.php/topic,6223.msg48045/topicseen.html#msg48045) one ;)
Hello, I've been using Code::Blocks for a while and I'm not too much disappointed about it! However, today's build (4177) crashes on startup, when the splash screen is still visible (nice splash screen BTW!). I ran it ~6 times and I got access violations but there are 2 different situations. The first one occurred twice, then the second one occurred twice, then the first one occurred two more times. Here they are:
Error occured on Monday, June 25, 2007 at 16:17:41.
C:\CodeBlocks\codeblocks.exe caused an Access Violation at location 00000011 Reading from location 00000011.
Registers:
eax=00000011 ebx=010a6f00 ecx=00000001 edx=010c73a4 esi=00fc7b1c edi=ffffffff
eip=00000011 esp=019cfec4 ebp=019cfed0 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
Call stack:
00000011
619C3DAD C:\CodeBlocks\codeblocks.dll:619C3DAD _ZN16BackgroundThread5EntryEv
6CCFF82B C:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCFF82B _ZN11wxSemaphore7TryWaitEv
6CCFF93D C:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCFF93D _ZN11wxSemaphore7TryWaitEv
77C0A3B0 C:\WINDOWS\system32\msvcrt.dll:77C0A3B0 _endthreadex
7C80B683 C:\WINDOWS\system32\kernel32.dll:7C80B683 GetModuleFileNameA
Error occured on Monday, June 25, 2007 at 16:18:22.
C:\CodeBlocks\codeblocks.exe caused an Access Violation at location 619c3da9 in module C:\CodeBlocks\codeblocks.dll Reading from location 00000078.
Registers:
eax=010c39c0 ebx=010a6f00 ecx=00000001 edx=00000078 esi=00fc7b1c edi=ffffffff
eip=619c3da9 esp=019cfec8 ebp=019cfed0 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:
619C3DA9 C:\CodeBlocks\codeblocks.dll:619C3DA9 _ZN16BackgroundThread5EntryEv
6CCFF82B C:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCFF82B _ZN11wxSemaphore7TryWaitEv
6CCFF93D C:\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCFF93D _ZN11wxSemaphore7TryWaitEv
77C0A3B0 C:\WINDOWS\system32\msvcrt.dll:77C0A3B0 _endthreadex
7C80B683 C:\WINDOWS\system32\kernel32.dll:7C80B683 GetModuleFileNameA
The call stacks are mostly the same (but the first one has one more entry, 00000011...). It looks like "_ZN16BackgroundThread5EntryEv" is the culprit.
I ran yesterday's build successfully and it didn't crash. I extracted yesterday's build in the same location and it still works, so I believe this bug was introduced somewhere between build 4164 and build 4177. I think I can't really provide any further info.
Thanks in advance!
Hi,
I got similar issue when open C::B in this nightly. The address violation is introduced several times during C::B startup but not always. This is not happened in previous nightly. Can somebody tell me how to record the debug message to design team for analysis?
By the way, my system is winxp sp2.
Bad news guys, this revision is unusable. Killerbot, please wait until we fix that Loaderbase/Backgroundthread crash...
Hello,
I have downloaded this revision (4177) and it seems to be working very well for me. I am using Windows XP.
It is weird it does not work for you (whoever it does not work for). Could it be related to your system?
-- Wolf --
I tested it again. It crashed on me the first time i ran it, but not afterwards. I'm trying to replicate the crash.
Here's what i got:
Error occured on Monday, June 25, 2007 at 20:36:48.
G:\projects\codeblocks\src\output\codeblocks.exe caused an Access Violation at location 00000000 Writing to location 00000000.
Registers:
eax=00000000 ebx=0125df00 ecx=00000001 edx=047cd9e8 esi=01355d7c edi=ffffffff
eip=00000000 esp=0205fe44 ebp=0205fed0 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:
00000000
61A3BF06 G:\projects\codeblocks\src\output\codeblocks.dll:61A3BF06 BackgroundThread::Entry() G:/projects/codeblocks/src/include/backgroundthread.h:170
6417F82B C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:6417F82B _ZN11wxSemaphore7TryWaitEv
6417F93D C:\WINDOWS\system32\wxmsw28u_gcc_CB.dll:6417F93D _ZN11wxSemaphore7TryWaitEv
77C0A3B0 C:\WINDOWS\system32\msvcrt.dll:77C0A3B0 _endthreadex
7C80B683 C:\WINDOWS\system32\kernel32.dll:7C80B683 GetModuleFileNameA
Guys, I have a question is it legal to have non opensourse commercial project compiled with minGW?
Quote from: Grom on June 26, 2007, 05:29:39 AM
Guys, I have a question is it legal to have non opensourse commercial project compiled with minGW?
IANAL, Compiling with minGW GCC should not be an issue, but using the libraries might be one.
Tim S
PS: This question likely does not belong on this forum and most likely not in this thread.
I know that it doesn't relate to it... But here there are specialists.
-------------------
Error occured on Tuesday, June 26, 2007 at 12:30:52.
F:\CodeBlocks\codeblocks.exe caused an Access Violation at location 619c3da9 in module F:\CodeBlocks\codeblocks.dll Reading from location 00000005.
when I use plugin code statics .CB crash!
winxp sp2 nightly build svn 4177
Registers:
eax=03afb680 ebx=00dd8200 ecx=00000001 edx=00000005 esi=00dffc0c edi=ffffffff
eip=619c3da9 esp=0192fec8 ebp=0192fed0 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:
619C3DA9 F:\CodeBlocks\codeblocks.dll:619C3DA9 _ZN16BackgroundThread5EntryEv
627BDF7B F:\CodeBlocks\wxmsw28u_gcc_cb.dll:627BDF7B _ZN11wxSemaphore7TryWaitEv
627BE08D F:\CodeBlocks\wxmsw28u_gcc_cb.dll:627BE08D _ZN11wxSemaphore7TryWaitEv
77C0A3B0 C:\WINDOWS\system32\msvcrt.dll:77C0A3B0 _endthreadex
7C80B683 C:\WINDOWS\system32\kernel32.dll:7C80B683 GetModuleFileNameA
Usually 2 bug fixes cause to one more bug...
If code new code was run without bugs then there is a principal bug behind that code. :lol:
build on linux with rev 4181 (so with the reverted possible issue) : still does NOT start up, splash screen and then nothing ...
uh? :(
Killerbot, what's the stack dump?
After a rebuild, rev 4177 and 4181 works well for me (Ubuntu 7.04) !
pasgui
Quote from: Grom on June 26, 2007, 05:29:39 AM
Guys, I have a question is it legal to have non opensourse commercial project compiled with minGW?
short answer: Yes
long answer: see PM
I have done a make clean on another linux box, there it is ok. So this evening at home I will doe such a rebuild all too.
build 4181 is working fine but found something strange :
- can compile file with space in path but can't launch it with CB console
- can't compile files with ' character.
And moreover, before you release RC3 in 2-3 weeks, would it be possible to have a fix for the slowness of the right-click on Linux?
I'm using Code::Blocks build 4181 on Ubuntu 7.04 with wxWidgets 2.8.4 .
Suggestion for multiplatform project file :
- I've seen in Projects files version 1.6 that the output has : /path/./applicationName for Linux or /path/applicationName.exe.
Wouldn't it be better to implement something that put the ./ and/or the extension and also the name of the application (since the application name is the same as the project name most of the time)? Doing so there will only be the path of the project in the project file (I don't know if it's good or not ... >.<).
Thank you
Kurapix
I'm a new Subscript, I'm italian and i not speak english ;) excuse to me....
I Can't download the .deb build, when click download from this page http://prdownload.berlios.de/codeblocks/CB_20070625_rev4177_Ubuntu6.10+7.04_wx2.8.4.deb (http://prdownload.berlios.de/codeblocks/CB_20070625_rev4177_Ubuntu6.10+7.04_wx2.8.4.deb) i receive a 404.
thanks.
it's not been release : it says "(not yet)", meaning it is not yet there ;-)
I'm run linux at home -- running the devel or output version of the latest rev (4183) starts fine for me (killerbot: did you clean out devel?). So far, I can't replicate any of the reported crashes, but i'll keep testing...
Quote from: dmoore on June 26, 2007, 01:11:27 PM
I'm run linux at home -- running the devel or output version of the latest rev (4183) starts fine for me (killerbot: did you clean out devel?). So far, I can't replicate any of the reported crashes, but i'll keep testing...
@Killerbot:
Yesterday I was facing similar problem on Linux. Please do a clean compile. It should fix the issue. :)
Quote from: kurapix on June 26, 2007, 10:39:15 AM
...would it be possible to have a fix for the slowness of the right-click on Linux?
I'm using Code::Blocks build 4181 on Ubuntu 7.04 with wxWidgets 2.8.4
Look at Settings/Editor/Mouse Drag Scrolling/ and adjust "Context Menu Wait for Drag (millisecs)" or disable DragScrolling altogether if you do not use right-mouse-key drag scrolling.
See if that solves your slow right mouse. The wait is different on various systems. Depends on system speed and how many processes are hooked to the mouse.
Good news guys, i *FINALLY* found the cause for the random crashes on startup. Hopefully it'll be fixed tonight. Killerbot, hang in there...
take your time, if you think you can have them fixed before midnight (Brussels time ;-) , I'll wait with the nightly till then ...
I already committed them. Test it and tell me what you think :)
Quote from: rickg22 on June 26, 2007, 05:20:03 PM
I already committed them. Test it and tell me what you think :)
It did not crash for me, so I think it is better.
Tim S
Ubuntu 6.10 & 7.04 Amd64 .deb installer (build with wx263 and wx284) can be found here (http://www.esnips.com/web/CodeBlocks).
Please don't post more in this topic, the next build is out. Thanks :)
Quote from: rickg22 on June 26, 2007, 08:07:14 PM
Please don't post more in this topic, the next build is out. Thanks :)
I know, but I've just uploaded this nightly (rev 4177) for those who want to test it.
And I'll post in today's nightly in a few minutes, when the corresponding build will be finished and uploaded.
@Rick
svn update to latest rev --> make --> still the same issue
BUT
make clean and make --> all ok
weird that just make couldn't do the deal
Maybe the precompiled headers had something to do with it? But anyway, does the patch work?
no crashes, so seems to work