The 28 september 2006 build is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.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

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26_gcc_cb_wx2.6.3p2.7z

The 28 September 2006 build is out.
  - Windows : http://prdownload.berlios.de/codeblocks/CB_20060928_rev3000_win32.7z
  - Linux :
         http://prdownload.berlios.de/codeblocks/CB_20060928_rev3000_Ubuntu6.06.deb
         http://prdownload.berlios.de/codeblocks/CB_20060928_rev3000_fc4+5.rpm (not yet)


Resolved Fixed:

• Added a new option to the files extension handler: open with associated application (windows only)
• Fixed bug that recently crept in C::B plugin wizard
• Greatly improved updating of the watches tree. Also fixed all related bugs (e.g. #6687)
• The watches tree is currently disabled for the CDB debugger (until the relevant code is rewritten)
• Added all date and time related macros as editor abbreviations. See http://forums.codeblocks.org/index.php?topic=4110

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)
• menu items with icon not correctly aligned (since wx263)

[killerbot]

pfff , berlios is sucking bigtime for the moment. Finally they show the uploaded files again, but when trying to publish them, it fails and it even throws away the files :-(

so maybe tonight's build is at risk too ......

[BCCISProf]

Seems to work now.

[RJP Computing]

pfff , berlios is sucking bigtime for the moment. Finally they show the uploaded files again, but when trying to publish them, it fails and it even throws away the files :-(

so maybe tonight's build is at risk too ......

Why the continued use of berlios? SourceForge seems to be more stable and the svn access is implimented now. Are there any plans to switch back to SourceForge?

[mandrav]

Are there any plans to switch back to SourceForge?

None whatsoever...

[thomas]

In my opinion, these problems are home-made, anyway.

Lieven is a very zealous person, and thus, he puts this unnecessary pressure upon himself to provide a fresh build every day, almost accurate to the minute. He even posts a note of absence in case he has to go abroad due to business! Few projects have such a dedicated packager.

If it was me, I would offer one or two builds per week, and maybe an extra build if something revolutionary has been added, and that would be it.
This would not cause anybody to miss out on anything, really. It would mean a lot less work, and a lot less trouble if the server doesn't work for a while. If you are not committed to release every evening, then what's the matter if you upload the build the next day...
It would also mean less revision fuzz and forum noise for each and every subtle bug or tiny feature that may be occurring in one particular build.

Most projects publish snapshots a lot less often than that, and people are fine, it is no problem at all.
Contrarily, it greatly reduces the amount of bandwidth people spend on downloading things they don't really need. Most commits are useful to only a small subset of users, so fewer releases (with more commits in each) have features for a broader user base.

Regarding Sourceforge, while there are no plans to ever turn back to them, we might use it as an inofficial backup site both for downloads and anonymous Subversion access in the future. The web updating system will thus be able to balance the load between the two sites and offer redundancy.
However, while the Subversion repository can be trivially mirrored as an automated process (cron.hourly), this will be virtually impossible for the upcoming daily diffs, as files have to be "activated" by hand after uploading. It might work out well for the weekly/bi-weekly snapshots, though.

[kkez]

I don't agree with you. A nighly build every day is (was) useful to test the features that were implemented on the same day, since there were a lot of them. Are there so many people that build from sources and do that every day? I don't think so. This way, everyone can test it. What if you add a feature and, a week after, someone discover a bug that was introduced with that feature? How do you spot that bug in the bunch of features added that week?

Another example: some times ago (when i wasn't able to build C::B from source) i maintained the most recent 10/15 nightly builds. Having spotted a bug, i tested all the nightly builds (from the newer to the older i had) and i was able to see between which revisions that bug was introduced, so i could search in a specific piece of code.

But. Now that we're approaching THE DAY and you developers start to commit less frequently, it's ok to drop that "behavior". But it was the right thing to do before

[killerbot]

good news : reuploaded and even able to publish it !!!

By the way, thanks for the nice words, but don't forget those linux builders :
Daniel
Bill
Michael
Seth

They perform a superb job !!!

Keeps me from switching OS's all the time ;-)

And we should also credit Peter6 over at the mozilla forums, since he was 'publishing' nightly build information for firefox and was an example for these nightly threads. Now I don't nightly upgrade my Firefox anymore but in the pre 1.0 days I did and it was very cool :-)

[afb]

If it was me, I would offer one or two builds per week, and maybe an extra build if something revolutionary has been added, and that would be it.

This is how the "nightly" builds for Macintosh work... (sometimes even months between)

[Last-Attacker]

Hi, don't wanna sound like I'm wining or anything... I really appreciate the new C::B IDE!
I would like to report 2 bugs with the codecompletion component (don't know if you already knew it, just say if you do):

• Doesn't parse std::vector class
  If you included <vector> and type "std::" , it will come up with all the std associated stuff but type in "vector" and it won't be found. Looks like its only "vector" that it is not finding. Otherwise, all the other classes and includes are parsed.
• Gives wrong member item because of it.
  Lets say you have a structure (block_info_t) and a variable (block) of that structure and you do:
  "block."
  then sometimes it puts a '0' after the dot. Weird.
  I have the following structure for an OpenGL project:
  

Code

struct block_info_t
{
	float tex_u;		/** X-coord on Texture */
	float tex_v;		/** Y-coord on Texture */
	float x1;		/** Top Left X-coord in World */
	float z1;		/** Top Left Z-coord in World */
	float x2;		/** Bottom Right X-coord in World */
	float z2;		/** Bottom Right Z-coord in World */
	float sec_width;	/** How wide is this block? */
	float sec_height;	/** How long is this block? */
	float one_over_width;	/** Cached for vertex shader */
	float one_over_height;	/** Cached for vertex shader */
	float scale_val;	/** Scale value of this block */
	int lod_val;		/** LOD level of this block */
	int vertex_count;	/** Amount of verticies in this block */
	GLuint gl_buf_id;	/** OpenGL Buffer ID reference for block */
};

Now I have the following declaration of it:

Code

std::vector<block_info_t> mClipmap[LEVELS];

If I type:
"mClipmap[0][0]."
it puts a '0' afterwards like so:
"mClipmap[0][0].0"[/li]

Hope this is useful.

[killerbot]

@ Last-Attacker, could you file this as a bug report on the berlios project page.

[nix_BB]

• Greatly improved updating of the watches tree. Also fixed all related bugs (e.g. #6687)

Great work!!