C::B usage/download stats?

[Wyrm]

I was wondering if the C::B development team tracks usage and download counts over the last few years? C::B has improved greatly over the last few years and I'm curious to see how C::B stacks up against competition.

[MortenMacFly]

This is really hard to tell, as it depends on you consider to include (i.e. all version, nightlies...) and unknown factors like counters on 3rd party repos.

For 12/11 only we have definitley crossed the 400.000 download counter meanwhile, but this does NOT include repos from 3rd party sources like for Ubuntu where we have no access to its counters and no sources like shareware/freeware sites, personal repos and so on.

So all I have count is 12/11 on BerliOS and SourceForge as the only primary location driven by us, but not our own additional private repos (i.e. Jens repo or pasgui).

[Wyrm]

I was actually expecting a lot more. IMHO C::B has matured enough to compete for the top spots among other open source IDEs, with many excellent features enabled. I hope you'll consider pushing it into Mint/Ubuntu distros because they are still offering outdated version 10 in standard packages.

Anyways, I've just donated $25 to your project. It's not much but perhaps you can buy beer for the developers, especially that kind soul on your team who enabled visual debugging within the IDE. I don't really have any feature requests. Just wanted to thank the developers for this excellent contribution to the open source.

[thomas]

Code::Blocks has 44,000 installations in the Ubuntu pop-contest. Only a bit over 2 million people participated in the pop contest, whereas Ubuntu advertised "at least 20 million daily users" and "setting goal for 200 million" back in 2011. So you can assume that the numbers in the pop-contest reflect considerably less than 10% of the real number.

In Debian's pop-contest, Code::Blocks scores 1746 installations out of 164770 submissions, but of course nobody knows how many users there exist in total.

The 5 biggest download sites give figurs in the 30k ballpark for 1.0, in the 40-45k range for 10.05 and in the 50-55k range for the 12.11 release each, with Softpedia claiming a stunning 107k downloads for 12.11. A dozen smaller sites give figures between 1.5k and 13k downloads each for various releases.

All in all, with these numbers, I do not think it's unreasonable or overly optimistic to assume one to two million installs total.

p.s.: Thank you for the beer, where do I get it?  

[MortenMacFly]

All in all, with these numbers, I do not think it's unreasonable or overly optimistic to assume one to two million installs total.

I would guess that, too. Just to remember: 12/11 only. MANY people still use / download 10/05...

p.s.: Thank you for the beer, where do I get it?  

I believe its given to the poor Greek.

But thanks anyways, its highly appreciated! :-)

[Wyrm]

Thomas: Thanks for the debugger!

Regarding the use counts, it's a good idea to use the popularity contests indeed. While the contest numbers are hard to scale to the absolute number of users, relative comparison between IDE's is rather interesting.

On Ubuntu pop contest website (http://popcon.ubuntu.com/) C::B is barely above KDevelop in usage and is far ahead of Eclipse CDT.
On Debian pop contest website (http://popcon.debian.org/) C::B has just barely overtook Eclipse CDT but stays about 2X behind KDevelop.
An interesting graph is the recent spike in the number of users in the Debian pop contest, see the bright red curve marked with + below. I won't post other IDE graphs to avoid starting flame wars but they don't seem to have such an explosive growth. Seems like your users like having official releases.

[p2rkw]

On debian most popular IDE is geany: http://qa.debian.org/popcon-graph.php?packages=geany

Heres another interesting graph about codeblocks: http://qa.debian.org/popcon-graph.php?packages=codeblocks&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&want_legend=on&want_ticks=on&from_date=2012-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

[macr0t0r]

I won't post other IDE graphs to avoid starting flame wars but they don't seem to have such an explosive growth. Seems like your users like having official releases.

Here at Lockheed, we are only allowed to install official releases.  I thought we were going to have to put Code::Blocks to bed and start moving our projects to Eclipse (10.05 debugger does not work with current GCC).  Obviously, I'll need to start getting more vocal in the forums in the hopes of getting more timely updates in the future.

In any case, I'm glad to see that Code::Blocks still has a healthy user-base.  It's a bit more barebones compared to the likes of Netbeans, but the scripting engine is indispensable since it allows us to easily create plugins that any user can install on the fly.  Keep up the good work!

- Jim

[Wyrm]

If I understand it correctly, geany is a multi-language IDE. Perl/Python developers are not C::B's target market. That's why I referenced Eclipse CDT rather than full Eclipse.

That said, those IDE's are also very good for their purposes. Some 5 years ago I was frustrated with crashes in KDevelop when I loaded a large project (thousands of files). So I haven't tried it since then. I hope it improved over the last few years.

Eclipse CDT was giving me a lot of hard time in mixed linking (partially static, partially dynamic). This is a really basic feature in C++ because some libraries (system, libstdc++, libpthread) are intended to be used mostly dynamically, while other dependent libraries should be static if your users don't have them in standard repositories. No matter how much they try to transform Eclipse into a C++ IDE, it is just not friendly for C++ development. It may be perfect for Java. On the other hand, in C::B I open project options and all compiler/linker tabs are right there with the configurable library order (append/prepend). You can immediately see that people who designed it understand the thinking process of a C++ developer.

I have just tried Geany as well. It doesn't allow you to place 2 tabs side by side. So half of the space on a widescreen monitor is wasted. In C++ you want to see a class header and its implementation side by side. I remember C::B supported it since version 10.

Another feature in C::B that I value very high: custom makefiles. This feature is indispensable when you evaluate other people's projects. Generally, I want to step through the code in the debugger to see what the code is doing. However, it is not my project and I'm not going to spend my time creating specialized project files for it *before* I've evaluated it and decided to commit my resources. Most projects support gmake and standard makefiles. So you can simply hook up your top level Makefile in C::B and build the project. Then, if you find the code useful it is worth going over and creating project files for whatever IDE you use.

The above may be a biased description but I did give a fair chance to several IDE's. They are mostly good but haven't fully met my expectations. Maybe I'm just too demanding.

I thought we were going to have to put Code::Blocks to bed and start moving our projects to Eclipse (10.05 debugger does not work with current GCC).

If I remember correctly, version 10 didn't fully work with GDB. I posted here a couple of years ago and some C::B developer (goes by name Obfuscated) helped me install a special branch that had latest debugger fixes and features. I believe they've fully merged it into version 12. C::B developers will correct me if I'm wrong. I'm now on GCC 4.7.2 and GDB 7.5 and everything works smoothly. However, I do need to mention that I have a bad habit of compiling C::B for my system from sources, rather than using precompiled binaries.

[macr0t0r]

Yes, version 10 did not have a really solid debugger plugin yet.  That's why I got excited that 12.11 was (finally...FINALLY!) released so that I could request an update for our servers.
I love Code::Blocks for its flexibility.  Lockheed is full of legacy software with crazy makefiles, and Code::Blocks was the only IDE that I could easily import those projects into and still be able to use the parse/build/debugger functionality.  Seeing that the scripting engine has been revamped quite a bit, I'm working on improving a few of our plugins.

Off topic:  the scripting documentation is....sparse (to be generous).  I generally had to look at the source code to understand the nuances.  However, like all open-source software, I know that the obvious answer is for me to update it if I don't like it.  Ugh...I'll have to carve some free-time out to update your scripting wiki.

- Jim

[Wyrm]

Seeing that the scripting engine has been revamped quite a bit, I'm working on improving a few of our plugins.
Off topic:  the scripting documentation is....sparse (to be generous).  I generally had to look at the source code to understand the nuances.  However, like all open-source software, I know that the obvious answer is for me to update it if I don't like it.  Ugh...I'll have to carve some free-time out to update your scripting wiki.

By scripting documentation, are you referring to the script language used in the "pre/post build steps" tab?

In the past I tried using post-build steps for my own regression system and I couldn't make it work exactly like I wanted to. I wanted to copy the newly built libraries and headers into a separate deployment directory and have test cases compile against that deployed installation. The deployment needs to be conditional on the target and successful build, so it shouldn't occur when my target is "clean". After a couple of hours I gave up on the post-build tab and wrote my own Perl script to do it from the command line instead.

If you can update the wiki or the documentation for this scripting it would be much appreciated.

[macr0t0r]

Gah!  Apparently I need to manually subscribe to threads that I participate in.  Sorry for the late response.

Currently, I don't use scripting in the pre/post steps because I'm currently using legacy code with their own makefiles.  I use the scripting to create my own plugins.  Unfortunately, the documentation is a bit light there, so I had quite a bit of trial and error.  Eventually I'll need to spend some quality time on the wiki and put in the missing info.  The biggest omission is that there is almost no information on how to make your contextual menus play nice with the FileTree items.  I managed to figure out how to make my context menus change when I right-click on a file, folder, project, workspace, etc. 

Squirrel, though.  I'm a little curious why you went with Squirrel instead of Lua.  It's so much easier to find documentation and examples for Lua scripting.  Ah, no biggie.  They're similar enough.

- Jim

[MortenMacFly]

Squirrel, though.  I'm a little curious why you went with Squirrel instead of Lua.  It's so much easier to find documentation and examples for Lua scripting.  Ah, no biggie.  They're similar enough.

Because at the time we decided to use scripting, Lua was way less sophisticated that Squirrel was (for c++, at least). This might have changed meanwhile... But it would be a major re-factoring to change the scripting layer. And as long as the current is doing the job just fine there is no need for such change.

[macr0t0r]

No worries with Squirrel.  As scripts go, I've already had to learn and use Csh, Bash, Awk, Python, Perl, Lua...what's one more?  In any case, I like how Squirrel supports function pointers so easily, so I'm okay with it.  The fact that Code::Blocks even has a scripting interface is enough to sell me!

- Jim

[LETARTARE]

hello to all,
@macr0t0r
The "Scripting commands" section has been updated to 12.11.

What would you find in the wiki "Scripting Code::Blocks" ?

cordially.