Dear Lazyweb, In my newest project I need to use Fortran routines and variables in C. From the source code point of view this requires only to declare the needed Fortran entities in your C code whilst taking the right types of the variables and the name mangling of the Fortran compiler into account. Here is an example. Consider you have the following Fortran code: To use the array v and the subroutine Foo() in C, you need to add (something like) the following declarations to your C source code: If only a handful of Fortran routines are needed to be called from C, declaring them by hand may be feasible. This is however error-prone and becomes impracticable for more than a handful of routines. Especially if the routine signatures change frequently. So what I d like to have is a tool that generates a C header file containing all declarations of Fortran entities from a given Fortran source file. Or if such tool does not exist, a tool that extracts variable declarations and routine signatures from a Fortran source file into a format that is easier to parse than Fortran itself would also be helpful. Any suggestions?

I m still working with SLHA files and noticed that people are using C/C++, Fortran, or also Mathematica programs for batch manipulation and processing of SLHA files (for example for repeatedly increasing some parameters in a SLHA file, feeding this file to some program and reading its output). For someone experienced with the shell (no, not that shell) this sounds like an easy task doable in a few lines of shell code. There is however no simple way to manipulate SLHA files on the command line.
The script I m presenting in this post, slha-io.sh, tries to close that gap. Its description is:

This script is a very simple (and stupid) tool to get or set data in SLHA (SUSY Les Houches Accord) files. It can output complete blocks or individual data lines and replace existing data lines with user given input. It is stupid because it does not check after replacing data lines if the resultant file conforms to the SLHA. So care must be taken when using the set action.

But as so often, it is best described by examples. The basic things you can do with slha-io.sh are (MSSM.in is the SLHA file in these examples):

$ slha-io.sh MSSM.in get modsel
Block MODSEL            # Select model
 1    0                 # MSSM
 4    1                 # R-parity is violated
Block SMINPUTS          # Standard Model inputs
$ slha-io.sh MSSM.in get sminputs 6
 6   1.729000E+02       # m_top(pole)
$ slha-io.sh MSSM.in get sminputs 6   awk '  print $2  '
1.729000E+02
$ slha-io.sh MSSM.in set sminputs 6 \
  " 6   1.730000E+02       # m_top(pole)"
$ slha-io.sh MSSM.in get sminputs 6
 6   1.730000E+02       # m_top(pole)

Here is another example of using slha-io.sh to create a batch of files where a parameter is constantly increased from 70 to 80 in steps of 0.5:

for NUM in  seq -f "%.8E" 70 0.5 80 ; do
    FILE = "m0_$NUM.in"
    cp MSSM.in "$FILE"
    slha-io.sh "$FILE" set minpar 1 " 1  $NUM  # m0"
done

Maybe this script is useful for one or two! By the way, more sophisticated tools for SLHA I/O are SLHALib and SLHAio.

One of the most interesting books I’ve read in the past years is without doubt G del, Escher, Bach by Douglas Hofstadter. There he introduces TNT and asks the reader to translate the statement “b is a power of 2″ into TNT. My proposed solution, which I wrote down two years ago, is:
∼∃a: <∼∃c: a=(c+c) ∧ ∀d: b=(SSa⋅d)> This is based on the following equation:
u ⋅ n u=2k+1 : k, n ∈ ℕ = ℕ∖ 2ⁿ n ∈ ℕ
Which means that every natural number except powers of 2 can be written as a product of an odd natural number u and a natural number n. This can be easily understood. Just take the prime factors of an arbitrary natural number. If one of these prime factors is odd, the number can be written as a product of this odd prime factor and the product of the remaining prime factors (which can be even or odd). If there is no odd prime factor, all prime factors must be even and since 2 is the only even prime number the original number must be a power of 2. I’m wondering if my solution is correct and how other people have written this statement in TNT.

Since I was watching Don Armstrong’s talk about Debbugs’ SOAP interface I wanted to use devscripts' bts to get a list of boinc’s top five bug reporter. Finally, this is possible with devscripts (>= 2.10.36):

bts status file:-  bts select source:boinc archive:both  \
    egrep "^originator"   cut -f2-   sort   uniq -ci   sort -n \
    tail -n5
 2 Riccardo Stagni <unriccio@email.it>
 3 Martin Michlmayr <tbm@cyrius.com>
 6 Robert Millan <rmh@aybabtu.com>
 6 Thibaut VARENE <varenet@debian.org>
10 Sandro Tosi <matrixhasu@gmail.com>

Sweet - Thanks Debbugs and Devscripts maintainers!
And congratulations Sandro (or thank you - whatever you find appropriate)!

Over the last few days I’ve converted some Subversion repositories used for Debian packaging to Git. None of these Subversion repositories contained upstream sources because of Subversion’s storage inefficiency. With Git I wanted to change that and also track the upstream sources in my repositories. To move a Git repository from a debian-only to debian+upstream layout I found zack’s recipe very helpful. The actual conversion to Git was done with git-svn. I cloned the Subversion repositories with git-svn’s --prefix=svn-import/ and --stdlayout options so that the trunk and all branches and tags were imported as remote branches with svn-import/ prepended. Then I created local branches of the previous Subversion branches and removed the remote remnants, for example:

git checkout -b debian/backports/etch svn-import/branches/etch-backports
git branch -d -r svn-import/branches/etch-backports

The Subversion tags are imported as svn-import/tags/<version> where <version> is the Debian version number. I don’t need branches for every version of my packages but I wanted to convert these tags to real Git tags but without losing the actual commit dates and messages. To achieve this I wrote this small script:

#!/bin/bash
for branch in  git branch -r ; do
    if [  echo $branch   egrep "svn-import/tags/.+$"  ]; then
        version= basename $branch 
        subject= git log -1 --pretty=format:"%s" $branch 
        export GIT_COMMITTER_DATE= git log -1 --pretty=format:"%ci" $branch 
        echo "Tag $version [Y/n]?"
        read yesno
        if [ -z $yesno ]   [ $yesno = "Y" ]; then
            git tag -s -f -m "$subject" "debian/$version" "$branch^"
            git branch -d -r $branch
        fi
    fi
done

For each remote branch that contains svn-import/tags/ it gets the version number, the commit message of the tag and exports GIT_COMMITTER_DATE (man git-tag) with the value of the date the version was tagged in Subversion and then asks you if it should tag the parent of the tag branch with the original commit date and message and remove the then unnecessary tag branch. The “safety measure” is there because people sometimes commit directly to Subversion tags (ugh!) and then "$branch^" would not be the commit you want to tag. To decide which Subversion tags are safe to tag with this script, gitk --all can be of great help. P.S.: This is my first post on Planet Debian, so hello Planet!