Forum Posts

The following project has been marked as a duplicate a long time ago: https://www.ohloh.net/p/haskell4nix Could you please remove this entry in favor of "cabal2nix", which is the successor?

The following project hasn't downloaded any code for quite a while even though its enlisted repository is on-line and work fine: https://www.ohloh.net/p/nixos/enlistments Could you please check what is going on there?

The enlistments of https://www.ohloh.net/p/hsemail/enlistments show that the project's history hasn't been updated in over 3 months. I'm not sure what the issue is, but the enlisted URL works fine for ... [More] me. Is there a way for me to re-start the fetching process? And if there is not, could one of the admins please trigger another fetch attempt? [Less]

The project https://www.ohloh.net/p/nixos/enlistments hasn't been updated in 27 days despite the fact that the enlisted repository works fine for me. Could someone please re-start the updating process?

The code analysis of the GNU Autoconf Archive says that 46% of the code is written in Python. However, that cannot possibly be true. The vast majority of source code in that project is written for ... [More] Autoconf, i.e. it resides in m4/*. Is it possible that the statistics gatherer doesn't recognize these files correctly? [Less]

Hi Robin, thank you very much for updating the installation; the new results for the Autoconf Archive are much more accurate. Thanks! I notice that OHLOH doesn't consider Autoconf code when ... [More] computing project costs. As a result, it believes that the Autoconf Archive requires less than 1 person-year to duplicate from scratch. In fact, however, it took more like 10 person-years to accomplish that. I guess that the algorithm considers only commits to python scripts and Makefiles? [Less]

Hi Robin, is there any chance that the line counter could be changed to honor *.m4 files? Even a trivial solution would be better than the current state where those files are completely ignored ... [More] , IHMO. The statistics for the autoconf archive are really way off. :-( Take care, Peter [Less]

Hi Robin, you are right. It's going to be hard to come up with an automatic scheme to decide whether Autoconf code is supposed to be included in project cost calculations or not. Custom-written ... [More] Autoconf code can be quite sophisticated and is thus "expensive". On the other hand, Gnulib or Automake can generate a fairly large amount of Autoconf code almost effortlessly and thus "inexpensively". I wouldn't know of a way to distinguish these two cases. There's probably no silver bullet to answer that question. Allowing a human to decide -- to configure the calculator -- is probably the way to go. Take care, Peter [Less]

Hi Robin, I've attached a patch to the Trac ticket. It worked fine for me, and the tests suite still succeeds, too. I hope it's useful. Take care, Peter

Hi Robin, *.m4 files that are inputs for Autoconf can be parsed with the same parser as the configure.ac scripts. Now, the vast majorify of *.m4 files will be directed at Autoconf -- especially in a ... [More] free software environment. There are other uses, though, that the Autoconf parser would not be able to recognize. M4 is just a general-purpose text pre-processor, like cpp. Sendmail, for example, uses m4 to generate its configuration file, which is totally unrelated to Autoconf. So does the SELinux kernel. As a rule of thumb, it's probably safe to assume that an *.m4 file is related to Autoconf if it contains the string "AC_DEFUN", which is the command used to define an Autoconf macro. There is also the file "aclocal.m4", which is commonly used by the Autoconf and Automake package. Oftentimes, Autoconf macros reside in a directory called "m4" or "build-aux", which might a clue, too. I hope this helps! [Less]