When I originally authored ohcount I decided to lump the languages together because I couldn't disambiguate some files purely based on their name and content. How should one classify a header file containing a few lines of C-looking code? Couldn't that also be compiled into a C++ project?
One idea might be to start splitting up C and C++ code on a line-by-line basis. This would be rather strange for some people, since a "pure C++" project would undoubtedly end up looking like it contained a fair amount of C.
In short, I support your cause but am at a loss for how it could be done.
Sorry to double-post on this, but I was bothered by your original assertion: "C/C++ makes as much sense..." I see your point, but imo your analogy's a little stretched.
C++: Bjarne Stroustrup developed C++ in 1979 at Bell Labs as an enhancement to the C programming language and named it "C with Classes".
Alright. I've attached a crude first attempt at a patch to the bug.
Perhaps a better analogy would have been BASIC/VisualBasic.NET? There's a huge difference between most modern C++ code and the way things would be done in C; C++ stopped being used just as a collection of extensions to C a long time ago.
So it seems this has been fixed. Thanks! I suppose projects with "C/C++" code now need to be reindexed. Is this being done automatically or on a case-by-case basis?
We're basically in a position now where everything on Ohloh needs to be recounted. This won't come quickly, so we're just going to start recounting from the oldest to the newest, as server resources allow. This will take several months.
I'm more than happy to bump any particular project to the front of the queue. Just let me know...
As long as you're offering, could you bump OpenVRML?
Has something happened with this?
When OpenVRML got bumped a few weeks ago, it was accurately portrayed as being almost entirely C++. But now the code analysis shows 52% C++ and 46% C. What happened here?
I forgot when I initially posted this that I have a C library dependency that I've imported into my source tree. So while the numbers still seem a bit off, they're not as surprising as I'd initially thought.
Would it be possible to bump Quadra to the front of the queue? Thanks in advance!
No problem -- Quadra is on the way.
Could you please bump coreboot as well? Thanks!
No problem, a recount is on the way.
A question: how fast is the recount, in lines per second (or even better: KB/s)? If it's slow enough, you could look at distributed volunteer computing: have your users re-count the code :)
Now, if the problem isn't that it's slow, but it's way too much data... Then the only way to speed it up is having more CPU power on your side, which means $$$...
The comparison page needs updating too...
It currently uses the no-longer-a-language C/C++ category. So to a casual observer it looks like nobody uses C or C++ any more! A temporary solution would be to change the first default language filter to just C, or just C++.
aha! Seems like someone fixed the compare page, now it shows C as the first language.
Robin, any chance you could bump OpenVRML for a full recount again?
Ohloh still says the ratio of C to C++ is significantly higher than I know it to be; but I'm not sure exactly why that is. OpenVRML's repository does have a good chunk of C code from a dependency that I keep in the repo; still, I think there should be about 20% more C++ than C. At the moment, Ohloh thinks the project has more C than C++. :-/
Also, it would be nice to pick up fully Ohcount's awareness of Automake and Autoconf.
It does look like our report for OpenVRML doesn't match the results I get with our latest build of the counter. Running a count by hand, I'm getting 75K C++ and 53K C.
So I've gone ahead and started a full recount, which should take a few hours to complete.
Thanks, Robin. The numbers you quote are in line with my own expectation. However, the recount appears to have completed and they aren't reflected there. In fact, the numbers post-recount look pretty much the same as before. Any idea what might cause this discrepancy?
I did some digging, and I found a bug in our Subversion importer. The problem first comes up at revision 417. In this commit, a lot of files are moved from a branch onto the trunk. Our importer gets confused, and considers these all to be new files instead of replacement files. From this point on, our system has a C code total that is 50K too high.
I'm working on a fix right now, and should have something deployed today. I'll start a new recount once it's ready.
Thanks for helping me find this, Robin
OpenVRML's svn repository was started with several years of CVS repository data imported using cvs2svn. While cvs2svn does an acceptable job for the most part, there is some squirrelliness.
Thanks for looking into this.
The recount is finally complete -- and it looks like we are finally getting right numbers. Let me know if anything still looks out of place, but I believe this bug is now fixed.