The 05 February 2008 build (4861) is out.

[killerbot]

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.

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

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc421.7z

The 05 February 2008 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20080205_rev4861_win32.7z
  - Linux :
   none

Resolved Fixed:

• Fixed debugger to get the child pid in windows. Was broken with newer GDB versions. Bug #12944 (also contained the fix, thanks)
• New comment types: stream and box (patch #2173)
• Added editor folding level limit option (patch #2335)
• DragScroll 1.2.07 2008/02/2 - Fixed: On some Linux's context menu missing in loggers bec mouse events always reported right-mouse was dragged. (Jens fix)
• Remote debugging settings are now correctly stored per-project (internally)
• Fixed folding icons inconsistency in split-view mode (bug #13062)
• Fixed crash happening with a right click in ThreadSearch code preview editor

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)

[Jenna]

Binaries for debian i386 and amd64 and sources (.tar-balls also usable on Windows) can be found in my repository (see signature).

[pasgui]

Build for Ubuntu i386 can be found here

Best regards, pasgui

[Wavesonics]

Glad to see C::B just keeps getting more and more stable

[cacb]

I have not yet downloaded this build, so apologies if the problem I am about to describe has been fixed  :lol:

I am using C::B on Windows and Linux Kubuntu i386. On Linux, there is a serious C::B problem that isn't seen on Windows: Sometimes, typically when you are debugging or reviewing build errors, you can end up with two views of the same file. If you edit one, the other becomes out of date. This is extremely confusing as you often end up compiling something else than what you have recently edited.

Is this a known problem?

[mandrav]

I am using C::B on Windows and Linux Kubuntu i386. On Linux, there is a serious C::B problem that isn't seen on Windows: Sometimes, typically when you are debugging or reviewing build errors, you can end up with two views of the same file. If you edit one, the other becomes out of date. This is extremely confusing as you often end up compiling something else than what you have recently edited.

Is this a known problem?

I 've seen this before and it had to do with symlinks. Let me explain.
I had my project, say, in ~/projects/frm/tests/unit/des. Now, for convenience, I had that directory symlinked to ~/projects/frm/des_test.

So, I opened the project file from inside the symlink (~/projects/frm/des_test/something.cbp). Then I started debugging. When I landed in a file of that project, the debugger opened the file from its real path (~/projects/frm/tests/unit/des/somefile.cpp).
The result was that the same file was open twice from two different locations.

Is this the same as what you 're describing? If so, the only work-around is to open the project file from its real path... Ideas/patches to properly fix this are welcomed

[indigo0086]

Hey, the parser's working...

I'm scared

[cacb]

I 've seen this before and it had to do with symlinks. Let me explain.
I had my project, say, in ~/projects/frm/tests/unit/des. Now, for convenience, I had that directory symlinked to ~/projects/frm/des_test.

So, I opened the project file from inside the symlink (~/projects/frm/des_test/something.cbp). Then I started debugging. When I landed in a file of that project, the debugger opened the file from its real path (~/projects/frm/tests/unit/des/somefile.cpp).
The result was that the same file was open twice from two different locations.

Is this the same as what you 're describing? If so, the only work-around is to open the project file from its real path... Ideas/patches to properly fix this are welcomed

You may be right... The "hard" path to my project is /media/sda6/wxDev/proj... but I normally access it via ~/work/wxDev/proj... as work is pointing to /media/sda6 (I have a dual boot win/linux setup and "work" is the common name for this partition on both systems, using a disk label on Win and a symlink on Linux). I have not noticed the paths associated with the different files, I shall certainly check when the problem occurs again. It will for sure, this happens all the time. It looks like the same problem.

How about stripping the path from such files and compare the names? Or maybe it is possible to check the path for symlinks?

It is certainly an annoying thing, and not easy to understand. I might try to access it using the "hard" path and see if that helps, but I suspect this will affect a few of users.

[JGM]

Hey, the parser's working...

I'm scared

what do you mean?

[Jenna]

You may be right... The "hard" path to my project is /media/sda6/wxDev/proj... but I normally access it via ~/work/wxDev/proj... as work is pointing to /media/sda6 (I have a dual boot win/linux setup and "work" is the common name for this partition on both systems, using a disk label on Win and a symlink on Linux). I have not noticed the paths associated with the different files, I shall certainly check when the problem occurs again. It will for sure, this happens all the time. It looks like the same problem.

How about stripping the path from such files and compare the names? Or maybe it is possible to check the path for symlinks?

It is certainly an annoying thing, and not easy to understand. I might try to access it using the "hard" path and see if that helps, but I suspect this will affect a few of users.

If your kernel is newer then 2.4.0 you can use mount instead of ln.
I just tested it on my debian-system and it works.

Here is a part of the mount manual:

Code

       Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
              mount --bind olddir newdir
       After this call the same contents is accessible in two places.  One can also remount a single file (on a single file).

       This  call  attaches  only  (part  of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place
       using
              mount --rbind olddir newdir

       Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along  with
       --bind/--rbind.

If you are a normal user, you might need to use

Code

sudo mount --bind olddir newdir

[Jenna]

If you are a normal user, you might need to use

Code

sudo mount --bind olddir newdir

or put

Code

olddir newdir none user,bind

in /etc/fstab

[Xaviou]

Ubuntu 7.04 -> 7.10 Amd64 tar.gz archive (containing '.deb' installers builds with wx2.8.7) can be found here

[cacb]

If you are a normal user, you might need to use

Code

sudo mount --bind olddir newdir

or put

Code

olddir newdir none user,bind

in /etc/fstab

Many thanks ... this appears to work :lol:  I used the /etc/fstab method.  I will have to gain some experience using C::B with this setup and see if it fixes the problem with opening the same file twice.

[indigo0086]

Hey, the parser's working...

I'm scared

what do you mean?

The parser used to never parse on my startup but now it seems to.