Mostly Written In...

TWiki is mostly written in Perl (all server side code) with only a small amount of JavaScript for AJAX frontends, WYSIWYG editing plugins and skins.

Please set TWiki to be 'mostly Perl', and also update the license 'analysis' to reflect fact that it is entirely GPLed - have set license to GPL already.

Another TWiki note: it has been under revision control since at least Feb 2001 (first CVS, now SVN with all CVS checkins imported), based on revision log for one key module. So I think that qualifies as long history of revision control.

Where are you getting this Javascript and TWiki stuff from? This is a python Django Project!

oops, Think I misunderstood where this link came from. Why is this in my PyCon-Teck project summary?

I dont knwo why it claims that 60% of the code is javascript when there are only 2 JS files (500 lines) and 10K+ lines of python.

There is an evn:externals of the dojo javascript framework, but ohooh should exclude all svn:externals as that is not development local!

Re: MLDONKEY

The mostly written in C/C++ for mldonkey is incorrect. It's actually written in a language called OCAML

Regards NL

ohloh clearly needs to work in in this feature, judging by the comments.

Struts2 is Java, but since it includes dojo is marked as mostly Javascript.

Obviously the problem with Javascript may be that JS ist distributed as source code in a project. So if you add several JS libraries (prototype etc.) to the project then Ohloh probably (wrongly) adds those files to your projects and rises your JS count. It's probably not clever enough to detect JS libraries you only distribute. Worse: It may add the JS licenses to your projects and claim your project uses X and Y licenses.

Prolog is also obviously not a language covered yet; the system thinks all my Prolog code is Perl...

Same for R; the system thinks all the R code that Bioconductor is primarily written in is XML... It would be better, maybe, to report something like "unknown language" instead. In fact, not all files in a project can be tagged with a programming language: documentation, config files, data files, etc... Bioconductor packages contain a lot of data!

Its funny that JideBuilder is written 100% in Groovy but the report says "mostly in JavaScript"

SBCL (http://www.ohloh.net/projects/5299) is written in Common Lisp, but Ohloh says it's primarily written in C/C++.

We have C components:

:; find . -name '*.[ch]' | xargs wc -l | tail -1
  34115 total

but they are dwarfed by the amount of code in Lisp:

:; find . -name '*.lisp' | xargs wc -l | tail -1
  395570 total

Commits to .lisp files don't seem to be counted as Lisp either.

In fact, those 400,000 lines of code don't even show up in the code report:

http://www.ohloh.net/projects/5299/analyses/latest

By the way, if you want to try and differentiate Common Lisp from random generic Lisp, Common Lisp sources usually have a line that looks like one of these:

(in-package :cl-user)
(CL:IN-PACKAGE "MY-PACKAGE")
(common-lisp:in-package #:this-is-rather-long)

so maybe looking for a line like:

/^\(([^\)]*:)?in-package\s/i

would be a decent tact? It won't get everything, but it'll get a lot.

There's no standard for file extensions, but *.lisp is quite common, *.cl is also used, and I believe *.lsp is used by 8.3 holdovers.

There is a problem with OCaml projects. For some reason they are treated as Objective-C

Objective-C extensions: m, mm

OCaml extension: ml

omniORB is mostly written in C++, not Perl! In fact, there are only about 300 lines of Perl in the whole thing, compared to over 300,000 lines of C++.

Mostly written in JavaScript ?

Code says it correctly (mostly written in HTML+CSS) but on the Report tab Ohloh Summary states "Mostly written in JavaScript" which is obviously wrong...

@Robin Luckey

Thanks a lot for your nice reply. Now I get it !

Here's my suggestion which imho shouldn't be hard to implement:

What about having some switch (maybe radio button or dropdown) to determine in project info setting if it is mostly markup/template/documentation project or coding/programming project ? Default state would be set as is now. Then it would count on with markup files (CSS/HTML/TXT) or exclude them as you currently count in "Project Cost" and generate the Ohloh Summary based on that.

Would be great new enhancement for some projects like mine :)

Jason (On JideBuilder's code), you're right, if the whole project is scanned that way, JavaScript will win over Groovy, but the fact is that the javascript code is part of the documentation, not production code. So I guess that without a project profile (how files are distributed) the measures will not be 100% accurate, but as each project may follow its own convention, this task will be huge and almost impossible to accomplish automatically.

Would it be possible to add more information (optional step of course) when registering a project, like source dir, test dir, doc dir ? that might help the tools make more accurate measurements =)

Jason, I like the language chart, but sometimes it is inaccurate in terms of language importance to the project. In my project it is PHP which is the most important language, but I use tons of Javascript for minor things the project can live without. It would be lovely to override preferred language in project settings.

Hi, First off: your tool is interesting! FreeNAC is mostly (90%?) PHP, with some embedded SQL statements. I do not know why you say its mostly SQL, there must be something about our code.. It also say 0% comments which is not true either.

Also I submitted the trunk for analysis, as per your instructions. But, most of the (incremental) work takes place in the branches, not trunk, which is used for very new features.

First SVN submits were in June'06, not this winter, so there seems to be an ageing issue too.

Regards, Sean

Hi,

about the prolog files, i think that if you can find lines that begins with :- and/or lines that contains one word followed by a :- it will work.

By one word i mean one predicate, something like : bla(blo, [hop], lol(bing))

I don't think that rules can have multiple predicate in the head ...

I know that Vim look at the % to recognize them

Unison is mistakenly reported as "objective C" instead of ocaml (or objective caml, which may explain the confusion).

Some mozilla related projects are complaining about being called shell script based projects because of a single file (configure).

Configure (typically generated by configure.in) is interesting in that it's likely to get thousands of small changes. As such total commit count is not going to solve the problem of "total lines of code misdetermines the language"

For reference: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/configure 1.1916 cltbld 2007-10-13 14:21 Automated update from host egg.build.mozilla.org

Configure of course tends to be massively long.

Unfortunately, a java project which commits its javadoc (or a perl project that commits its html generated pod) will be dwarfed in the total number of files (documentation > sources).

I think the trick is to try to generate an algorithm that determines "copying". If configure seems to be a derivative copy of configure.in (good luck), or foopy.html seems to be a derivative copy of foopy.pl / foopy.java, then it should be discounted.

I'm not sure how well that'll work, a project with heavy manual documentation will probably still be penalized, but overall it might enable you to count by numbers of files.

Another thing you could do is drop languages used in only one file.

I was wondering if this would penalize the mozilla despot project (which I believe is not yet imported into ohloh, I might do that just to see what happens)

http://mxr.mozilla.org/webtools/source/despot/

From memory, despot basically has one file (despot.cgi) and a help file (help.html), but it does actually have a couple of other .pl files, so today it'd probably be counted as perl. When enough of despot is converted to use .templ's, despot would probably be called html.

And I don't know that I'd mind.

Probably the simplest solution is to list the major language, and the second language and a note about which calculation would make the second language the major language.

It of course only works for 2, and would fail for perl+html+js, but it should probably help for configure :).

To add to this comments, Queplix is written 100% in Java2EE, but it includes GWT Google Web Tool Kit. However, the project was marked as "written mostly in Java".

What about ignoring configure scripts (and perhaps autogenerated makefiles) in language detection?

Hey guys,

what about adding some control files to the repositories root:

ohloh.ignore:

*.js

ext/*

ohloh.languages:

*.phtml=PHP

*.pl=Perl

etc..

Regards, Arno

ohloh.externals:

could reference the usage of other opensource projects, so that this is not counted to belong to this project but maybe as a boost for the kudo rank of the used project?

For example:

path = Name [ProjectId]

ext/.* = ExtJs Framework [123123]

I have a bunch of sample files that are used as input to my program and do not constitute source code of the program. Ohloh however looks at these files as well, and counts them as part of the source code.

The result is that a project that is 100% perl is reported as Mostly Javascript, since its job is to parse HTML files.

Project name: RSSyn

Can you change the Project's Mostly written in part from C# to D as most of the C# stuff is old(I am switching it totally over to D). Please do so quickly.

that's for Dinstaller

Haskell projects appear to be listed as C/C++ .

So while the commits from the git repo (I had to convert from darcs to upload) appear, instead, it appears *.cabal files are treated as C/C++. This is the Haskell make-like system, so should probably be treated as Haskell source too.

See, e.g., project xmonad

Haskell extensions: .hs .hsc .lhs .cabal Comments introduced with: -- Nested comments : {- and -}

FreeBASIC Compiler Is marked as being written mostly in VisualBASIC. This is wrong. FreeBASIC is a self-hosting compiler. This means that FreeBASIC is written mostly in FreeBASIC.

Angstron is not written in shell script! I have a few scripts , but a have other gazillion of .h files ,with lots of C++.

btw, great site!

NewStrider, the language your project is written in is determined by what language has the most lines of code. Your entire project has around 32k lines of which 21k fall to your shell script "configure".

Remove it from your repository. You don't need it there anyway because that is what you have the autogen.sh for.

The gtk2hs project source is identified as mostly Pascal, not Haskell. :)

This library uses the c2hs preprocessor, meaning it has files with extension *.hsc, *.chs and *.chs.pp -- these are Haskell files.

"Mostly written in Python"

Your scanner has mis-matched Pyrex code (.pyx .pxd .pxi), a hybrid of C and Python, and Python, or it's picked up setup.py and two small .py files as the only source code.

This applies to SymPy and PySoy at the very least, I know there's at least a dozen other major projects that use Pyrex.

Hi,

I know that you are dealing with a gzillion languages out there, but you could also add Modelica on your list. The file extension is ".mo".

Cheers adrpo/

"Mostly written in shell script" for Munin is not entirely correct. The core and many of the plugins are written in Perl; only some the plugins are written in shell script.

NetBeans project categorized in mostly written in JavaScript

http://www.ohloh.net/projects/netbeans#

When I know that the project is mostly written in Java. There must be some way to tell Ohloh about the mostly written language.

Not sure about the Python count either. Zenoss is listed as a C++/C project, but a quick count of my source tree shows 2500 C files, 1 CPP file and nearly 9000 Python files.

SCPlugin is marked mostly shell, actually shell: 34% Objective C: 32% HTML: 13% C: 13%

but David A. Wheeler's SLOCCount calls it Objective-C: 6954 (47%) C: 6894 (46.4%) C++: 379 (2.6%) Ruby: 285 (1.9%) Shell Script: 261 (1.8%)

which I find much more credible

OK, really strange: ohcount 1.0.1 says sensible things about scplugin (objective_c: 85 files, shell: 10 files, c 12 files), so why does ohloh say wrong things?

Interesting other discovery: my run of ohcount showed 8497 lines of shell, which rather startled me (though still not constituting "mostly," as claimed in the project summary). I looked, it's true, sort of ... but 8127 of those lines are in a copy of "libtool" that we heisted from MacPorts, we don't maintain ourselves. I wonder if there shouldn't be a way to exclude something like that? It's binary, read-onlyu to us....

The unhelpful answer: what are you doing with a It's binary, read-only file in your version control then? The easy way to fix this is so that only versioned stuff is in your version control system. Pull the rest in at compile/run time

The helpful answer: this is a known problem. It also applies in spades to ./configure files in lots of C/POSIX projects and ant/xml files in lots of java projects.

clisp is claimed to be written mostly in shell script due to a bunch of configure scripts. there should be a way to eliminate generated files from the count; at least the generated configure files have "Generated by GNU Autoconf" on the 4th line.

Your language sniffer doesn't work well for me. This project: http://www.ohloh.net/projects/10160 is claimed to be "Assembly" but it does not contain 1 line of assembler. It's a 100% C project.

One another: dtach is marked as being mostly shell-script.

That is a funny one :)

Probably the automated process doesn't rule-out the ./configure script (which is obviously wrong!). Being a relatively small C program, the configure script wins by KO :)

This should be corrected...

Hi Robin,

Are there any plans for Ohloh to consider the "libtool" shell script to be its own separate grouping, much like what happens with configure/autoconf? For my small C project (libdmtx) the actual C code might never grow bigger than the scripts generated by Autotools.

Ordinarily this wouldn't be a big deal, but I'm a little worried that people learning about my project for the first time might be scared off by the prominent "Mostly written in shell script" on the summary page. Those who are seeking a high performance library might immediately move on to the next search result without reading any further.

Thanks, Mike

I guess no fix or update's been done for this? It's reporting my project, which is written in Ruby and for which we have written *no* Javascript, beyond small pieces of boilerplate from the Rails engine, as being "most Javascript".

Robin If you view the URL in my post, you'll see that it refers to a 100% C project (psdparse) yet your sniffer incorrectly identifies it as Assembly. https://www.ohloh.net/p/10160/analyses/latest

Jason, Robin: My apologies. 100% user error on my part. The enlistment pointed to the wrong project. In this case your sniffer is innocent. I'll review my projects sometime to make sure the license and language sniffing is accurate, it seemed to have problems with license detection in the past.

Thanks and apologies for the false report.

The code analysis for Djime shows about 3k lines of javascript. About a month ago we had some jQuery files within the project, but moved it out, since it wasn't a part of the project. Still Ohloh is showing that the project is mostly written in javescript.

with your tool, I got a count of:

177 lines of javascript 2539 lines of python

My local dev version is a bit ahead of the master branch, but the ratio should still be the same.

It would be nice if you could change the most written in from javascript to python, since this clearly is the case.

Thanks.

My project, BOINC Manager (https://www.ohloh.net/p/boincmanager), has mostly written in C++, which is correct, as most of the code at this point is a C++ library we're using. However, we have negative lines of XML, so C++ shows as 147% of our project, and XML is <1% and -5600 lines of code. Is this related to the cumulative counting bug above?

Thanks Robin. I'll keep an eye on it, let you know if there's any more problems. Not sure what XML could've been removed, but I've been in the process of cleaning up the trunk with a new contributor, possible something in there. Thanks again.

The MirPorts Framework is actually mostly written in BSD make. It is understandable that make is skipped for regular projects which may have huge build systems, but in this case, the build system is the actual project.

I'm guessing the same problem Thorsten has identified is also what's seen in the Solaris Package System.

I posted some time ago about the code counter not working properly, apparently a known bug that would take a while to fix. Would like to know if there is any progress on that end?

Hi Robin, thanks for your speedy reply.

It doesn't seem like the problem is like you describe. The reason being that there only is one branch on the tracked git repository. Also the numbers of actual javascript lines is close to 200, but ohloh say that we have around 2800 lines. I think the problem is, that somewhere down the line when the jQuery library file(s) was removed from the project itself, ohloh's counter didn't get that and is still counting those files as being part of the project. At least that's the only thing that's making sense to me, at the extra lines of code is roughly the lines of code we had for jQuery. I could be completely off here, but I think it would be worth checking out, to see if there is a bug in the ohloh tracker regarding deleting files. We have previously remove other jQuery files that ohloh did track, so I'm not sure what is causing this problem. But I highly doubt that it could a problem with ohloh counting branches twice. The differece is just too big (15 times), and with the main repository having 1 branch and my own having 2 that doesn't count for the big difference.

Another thing is that the amount of python code is pretty precise, so it wouldn't make sense that the javascript files would get counted extra.

Well enough of me talking about lines of code in the project. Hope this helps you finding out the cause of the problem.

~Jakob

Please add the .zsh extension for the zsh scripting language. Zsh is an excellent and commonly used shell, very similar to bash with some great extensions. What is currently parsing bash will cope with it.