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