[Pipet Devel] updated model

Konrad Hinsen hinsen at cnrs-orleans.fr
Tue Dec 8 05:58:27 EST 1998

> > Another general class of code that is easy to integrate from Python
> > are the classical Unix-style command line tools (whatever language
> > they are written in), i.e. programs that read from standard input
> > and write their results to standard output.
> This is the class for which I would use a CGI/XML approach.  I think most

I am not quite sure what you mean by that. XML can be used only between
programs that understand XML, so very probably none of the existing
analysis programs that we want to include. And CGI is a technique used
for Web servers.

> analysis algorithms are not, nor need to be, interactive.  For the most part,
> simple algorithms can read from stdin or a file and write to stdout or a file

Sure, but if the authors of the programs decided that a curses-based
user interface would be nicer, we have to live with that!

> Yes, we will consider the case for which PyExpect can be used.  But for the
> core TULIP tools, we should have everything in Python or C, with a strong
> emphasis on Python:  The only situations where C should be used are (1) for
> compute-intensive routines, and (2) custom GTK widgets (otherwise, I would
> like to use the standard Python-GTK widget bindings).

Obviously. That's the easy case. What we need to worry about is legacy
code that we want to reuse.

> But even graphical programs can utilize stdin and stdout.  If they can do
> that, we have communication.

Yes, *if* they do!

> Konrad, you mentioned that you can link Fortran and C, and then wrap the C in
> Python.  Is that right?  Can you give us some details?

There isn't much to say about this; you just write a normal C module
for Python that happens to call Fortran routines. The difficulties

1) You must know how to call Fortran routines from C. Under Unix
   this is fairly standardized, the only difference being that some
   Fortran compilers add an underscore to the subroutine names and
   others don't. I don't know the situation for other platforms.

2) You must know how to link Fortran routines to a C program.
   This is very machine dependent; usually it comes down to linking
   with the Fortran standard library, but its name is different for
   each system. There may also be machine-dependent restrictions,
   for example it seems to be impossible to use Fortran code in
   shared libraries under DEC Unix.

Many public-distribution packages avoid these issues by including a C
translation of the Fortran code (via f2c), examples are the LAPACK and
FFTPACK routines in NumPy. Users who want petter performance and know
their system well enough can then substitute the real Fortran code.
I suggest the same approach for TULIP, it avoids so much trouble...

> for graphical applications led to the ubiquity of Macs in the lab.  I don't
> know about where you guys work, but all we have in the labs here are Macs.  I

All I have is Unix; I haven't yet seen a Mac in the building I work in!

> therefore believe a port to the Mac may be more important than a port to Windows.

OK, so what's the situation of GTK for the Mac?

> By the way, Konrad, what do you think we need for structural analysis in the
> *core* distribution of TULIP...the most important tools that may be accessed
> by other tools?

I don't really know what people *need*; I don't want to suppose that
my needs are typical. But I do have Python implementations of most
common structural analysis techniques, and can easily add more. Most
techniques I know deal with comparing different conformations of the
same protein, or of two closely related proteins.

Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-
Rue Charles Sadron                       | Fax:  +33-
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais

More information about the Pipet-Devel mailing list