Hace un mes publiqué en este blog una entrada reference al fraude a la hora de publicar en el ámbito científico, haciendo eco de otras entradas que hablaban sobre este grave problema. Seguramente desde antes de esas fechas ha aumentado por todo el mundo científico la preocupación por estos fraudes, que minan la credibilidad en un trabajo generalmente metódico y bien hecho como el de la investigación científica. Por ello el pasado 19 de Junio salió publicado un comentario sobre un informe bastante extenso sobre el fraude científico en Estados Unidos en la revista Nature, abordando el problema. El informe está cimentado sobre una investigación a 2212 investigador@s científic@s, de los cuáles 201 daban señales de malas prácticas. En Estados Unidos existe la ORI (Office of Research Integrity, oficina para la integridad en la investigación científica), que se encarga de evaluar todos los informes sobre prácticas científicas sospechosas en centros de investigación que reciben financiación del DHHS (Department of Health and Human Services, departamento de servicios humanos y salud), pero está limitado a sólo esos casos. También intenta prevenir estas prácticas fraudulentas mediante la educación y medidas disuasorias.


El artículo/comentario de Nature es mucho más extenso que lo que he explicado en las pocas líneas del párrafo anterior. Se nota que es un problema que preocupa bastante a las instituciones relacionadas con el mundo de la investigación, debido a que puede socavar los cimientos de la ciencia, y con ello su credibilidad y financiación (lo cuál sería un craso error). En el artículo comentario l@s autor@s intentan definir qué puede denominarse malas prácticas (para que no se convierta en una caza de brujas), los niveles a los que se produce o la necesidad de adoptar una tolerancia cero ante estos casos. Señal de esta preocupación es que el pasado 2 de Julio salió publicado en El País la noticia 'Científicos Tramposos', bastante extensa, que tomaba como base el comentario/informe de Nature (aunque no aparecía directamente referenciado). Esta noticia es una ampliación del informe comentado en el sentido de que, observando el panorama español y europeo, no hay ni en España ni en Europa organismos similares a la ORI estadounidense (aunque sí hay comités de ética, y además a nivel europeo se pueden aplicar sanciones). Aún con ello se están tomando medidas para crear algo similar a la ORI en el CSIC, según declaró para ese artículo Juan José de Damborenea, vicepresidente adjunto del CSIC.

Por lo que he leído de pasada en la noticia In scientia veritas? del 28 de Mayo de este año en la web de la Comisión Europea, se organizó a nivel de la Unión Europea del 16 al 19 de Septiembre de 2007 una reunión en Lisboa con investigadores de primera categoría, auspiciado por el ESF (European Science Foundation) y la ORI estadounidense, para generar un informe sobre el fraude científico que suplementara el informe anual de la OECD (Organization for Economic Cooperation and Development) de Febrero de 2007, elaborado en Tokyo. En esa misma noticia también se menciona la falta de armonía/uniformidad para coordinar la investigación científica (y de paso, la detección de los casos de fraude) a nivel europeo, la necesidad de adoptar un código de conducta internacional a nivel científico o evitar la fe ciega en lo que se financia o se publica, usando para combatir el fraude tanto nuevas herramientas como las herramientas ya disponibles (por ejemplo, el peer review).

Toda esta madeja la saqué gracias a mi compañero de trabajo Guillermo Comesaña, que fue quien se leyó la noticia de El País. En total hay mucho material que leer detenidamente para comprender todo el problema, y de todos los artículos mencionados no he tocado ni la décima parte. Aquí os dejo los enlaces, para que leáis tranquilamente:

• Comentario Repearing research integrity de Nature del 19 de Junio de 2008.
• Noticia Científicos Tramposo de El Pais del 2 de Julio de 2008.
• Noticia In scientia vertitas? de la web de la Comisión Europea del 28 de Mayo de 2008.
• (Menos relacionado) Informe anual del 2007 de la OECD.
  

En más de una ocasión lector@s de este blog me han solicitado enlaces a videos educativos o divulgativos relacionados con bioinformática y biología molecular. Sobre ésta última hay muchísimo material disponible (cada día más), y ejemplo de ello es el sitio MolecularMovies.org, que contiene tanto animaciones educativas como demostrativas. Estas animaciones pertenecen a diversos campos como síntesis orgánica, apoptosis, mototes moleculares (que suelen ser muy curiosos), etc... y son directamente descargables al ordenador (se encuentran codificadas en formato Quicktime, así que necesitareis el plugin de Apple o alguno compatible como mplayerplug-in,  totem o VLC). Los videos se encuentran originalmente alojados en la página web de sus creadores, y suelen incluir una descripción de lo que se muestra con ellos, y a veces también enlaces a material adicional.

Como muestra os enseño uno de esos videos, en este caso sobre apoptosis:



Gracias a Gloria Fuentes he encontrado este sitio. Aquí teneis el enlace:

• MolecularMovies.org.
  

Hace unos meses escribí en una entrada de este blog sobre la transición que en ese momento se produjo del antiguo formato de PDB al nuevo, con las ventajas y los consiguientes problemas que ello iba a acarrear. Ayer Guillermo Montoya me contó que justo tenía problemas para abrir PDBs en el formato nuevo con el programa Curves (no sé la versión que está usando), y que sirve para calcular una serie de parámetros sobre un DNA irregular (que no sigue de forma exacta la distribución helicoidal) comparado con su disposición ideal. Ayer lo solucionamos usando ficheros del antiguo PDB (que obviamente estaban en formato antiguo), pero no es la mejor solución porque sólo vale para entradas que ya estaban del antiguo PDB.
Hoy Gloria Fuentes nos ha contado a Guillermo y a mí que hay un programa que permite convertir los PDBs en formato antiguo al nuevo formato, y viceversa. El programa se llama Remediator, está hecho el laboratorio de los Richardson en la Universidad de Duke, y está disponible tanto en Perl como en Python. La principal diferencia entre las dos variantes de Remediator es el uso embebido o externo del Chemical Component Library, usado para aplicar las traducciones necesarias.

Espero que os sirva de ayuda.

Por el lado de Ana Rojas (¡que ya es cinturón negro de Jiu-Jitsu! y que le llegó a su vez por su amigo Andreu) me ha llegado el enlace a una entrada interesante del blog Bioinformatics Zen. En la entrada de ayer Creating a picture of different careers in bioinformatics aparece una encuesta para intentar crear un boceto de las distintas posibles carreras de un@ bioinformátic@. Esta entrada surgió a partir de los comentarios que suscitaron la publicación de The past and future of a career in bioinformatics el pasado 5 de Septiembre de 2007 en Bioinformatics Zen. Según la noticia, desde ayer 1 de Julio hasta el próximo 1 de Agosto no se hará público ningún resultado, y el formulario de la encuesta funcionará hasta el día 1 de Septiembre, momento en que su autor compilará todos los resultados para generar una nueva entrada de blog con los resultados de la misma, y algunas conclusiones.

Por si os interesa, voy a embeber la página de la encuesta en la versión completa de esta entrada, para que la podais rellenar.

Hace unos días, dejó Catalina en una hebra no relacionada la siguiente pregunta:

Como sabemos, existen diferentes programas para la visualizacion molecular tales como el RASMOL y el VMD. Me gustaría saber en qué se diferencian, ya que por lo que he leido son muy parecidos.

A nivel básico ambos programas se parecen, pero justo ahí divergen. Rasmol es una herramineta básica que apenas se mantiene hoy en día, pero que ha dejado su huella en el mundo de la bioinformática por haber estado en todas las plataformas, y por su sistema de scripts, que permite marcar/decorar secciones de las estructuras que estamos viendo, basándonos en sus propiedades. VMD es una herramienta principalmente usada en el área de dinámica molecular, que sigue estando muy mantenida (es capaz de aprovechar todos los procesadores/cores del sistema, e incluso la tarjeta gráfica). Además de soportar muchos más formatos de fichero que Rasmol (más de 60, por lo que he leído en su web), permite traducir entre ellos, viene con herramientas accesorias integradas (como un visor de alineamientos múltiples, por ejemplo) y que es capaz de interactuar con otras herramientas (como NAMD, a la hora de lanzar simulaciones he ir viendo resultados intermedios).


Existen otros programas para trabajar con estructuras 3D, como por ejemplo Pymol, Coot (usado principalmente por gente que trabaja en cristalografía de rayos X, determinando estructuras), Jmol (hecho en Java, disponible también como applet, y compatible desde las versión 10 a nivel de scripts con Rasmol), molmol (también tuvo su pequeño momento de gloria), etc... Y entonces os preguntareis, ¿por qué hay tantos programas que hacen lo mismo? Sencillamente, porque las características que los diferencian están especializadas en distintas parcelas de la bioinformática y la cristalografía de rayos X.

Mejor que haya diversidad a que haya imposibilidad.

Much@s de vosotr@s conocereis casos de personas que cambian radicalmente de trabajo o de estilo de vida. Gente que antes trabajaba para la empresa privada entra en el mundo de investigación (algun@s de mis compañer@s), gente del mundo de la investigación decide abandonarlo todo y se pone a viajar por todo el mundo (¿por dónde andarás, Josetxu?), etc.. En el número de este mes de la revista The Scientist aparece una entrevista a Sean Eddy, creador de HMMer.
Dentro de la entrevista me llamó la atención que era un adicto de un viejo videojuego llamado Empire, y que para él creó gran cantidad de rutinas para automatizar la mayor parte de las operaciones económicas y militares. Según él, casi todo lo aprendido al programar estas rutinas lo recicló para sus programas de alineamiento de secuencias y plegamiento de RNA.


HMMer es el software de Sean Eddy más conocido, por ser el estándar de facto en bioinformática para la búsqueda de motivos en secuencia, y usa para ello por dentro modelos de Markov ocultos. La base de datos PFam, que está compuesta por todos los motivos conocidos de proteína, así como de un nutrido grupo de motivos identificados por medios puramente computacionales o todavía no confirmados, se construye gracias al esfuerzo de sus curadores, pero también gracias a uno de los programas de HMMer, que a partir de los fragmentos representativos de secuencias que describen un motivo genera los perfiles HMM usados posteriormente para las búsquedas.

En cualquier caso, os recomiendo el artículo (enlace al artículo), que es mucho más extenso que las pocas líneas que he comentado aquí. ¡Qué cantidad de vueltas da la vida! L@s más caraduras ya le podreis decir a vuestr@ jef@ que estais jugando en el trabajo para perfeccionar un algoritmo revolucionario...

Recordando la frase de "Johnny 5" en la vieja película "Cortocirtuito 2" 'Datos, Datos, ¡Más Datos!' he creado el título de esta entrada. Los widgets son pequeños trozos de código que proporcionan funcionalidades sencillas, pero necesarias (calculadoras, información meteorológica, vuelos disponibles, etc...), integradas en algún tipo de entorno (escritorios, teléfonos móviles, navegadores, etc...). Por ejemplo ya hay un intento de estandarización de los widgets por parte de la W3C, Google tiene su propio sistema de gadgets para su iGoogle, Yahoo! provee su propio sistema de widgets (con programas para poder lanzarlos en diversas plataformas), el navegador Opera lleva bastante tiempo con esa tecnología, sistemas como Mac OS X (dashboard), Windows Vista (gadgets) o KDE4 (Plasma) los integran en el escritorio, y sistemas como Konfabulator o Superkaramba los popularizaron.

Uno de los primeros mensajes que subí a este blog fue el de ProteinGlimpse un widget hecho por un antiguo alumno, y ahora compañero de trabajo y amigo, Jaime Fernández. Pues bien, este widget como tal ha llegado a la versión 1.5, y pronto será usable en Linux gracias a las mejoras de KDE 4.1. Tanto él como yo y vari@s de mis compañer@s estamos involucrados en el desarrollo del sistema CARGO (enlace a la publicación), que intenta desarrollar el concepto de widget en el ámbito bioinformático.

Uno de ellos, José Manuel Rodríguez, estuvo investigando cómo poder integrar los widgets de CARGO en iGoogle, y tras perseguirlo un poco he conseguido que escriba la siguiente documentación de cómo hacer un iGoogle gadget:

Se ha creado para Cargo un iGoogle Gadget para poder así tener la funcionalidad de esta aplicación web en varios sitios. La vista inicial de Cargo como un iGoogle Gadget es la siguiente:

La API de Google Gadgets es un método simple para crear pequeñas aplicaciones que se ejecuten en varios sitios web, incluido la Página de iGoogle, Google Desktop, Google Page Creator y miles de sitios de Internet que utilizan Google Gadgets para tu página web. Google Gadgets llega a decenas de millones de usuarios cada semana; mejor aún, Google proporciona alojamiento gratuito, ancho de banda gratuito y un método fácil para enviar tus gadgets al directorio oficial, desde donde podrán acceder a ellos usuarios de todo el mundo.

Los gadgets son fáciles de crear. La Guía para programadores te explica cómo utilizar la API de Google Gadgets y cómo crear un gadget. En un nivel básico, un gadget es sólo un archivo XML que recoge contenidos o aplicaciones web ya existentes. Por ejmplo:

<?xml version="1.0" encoding="UTF-8" ?>

<Module>

<ModulePrefs title="hello world example" />

<Content type="html">

<![CDATA[

Hello, world!

]]>

</Content>

</Module>

Hello, world!

Una de las primeras decisiones que se deben tomar a la hora de crear un gadget es el tipo de contenido (vea los Principios de programación).

Tipo de contenido	Descripción
html	Con un tipo de contenido html, todo el contenido reside en la especificación del gadget. Un gadget que incluya type="html" contiene código HTML, posiblemente con JavaScript, Flash, ActiveX u otros objetos del navegador incrustados. Este es el tipo de contenido predeterminado.
html-inline	El código HTML del gadget se ejecuta como parte de la página principal en lugar de hacerlo en un iframe. De esta manera, el gadget podrá modificar la página principal, por ejemplo, para cambiar el color de la fuente.
url	Aquí el contenido del gadget se aloja en una página web remota a la que hace referencia una URL en la especificación del gadget. La página web remota es el lugar donde reside todo el lenguaje de marcas HTML y JavaScript. NO se puede insertar ningún código de lenguaje de marcas HTML ni JavaScript en la especificación del gadget propiamente dicha.

El iGoogle Gadget de Cargo se trata de un tipo “url”, con lo que la administración y mantenimiento del Gadget depende totalmente del servidor remoto.

La descripción del iGoogle Gadget de Cargo se muestra a continuación.

<Module>

<ModulePrefs title="Cargo" title_url="http://cargo2.bioinfo.cnio.es" directory_title="Cancer and Related Gene Online" description="CARGO displays biological information from different sources. We are thankful to the developers and Institutions for providing freely available services." thumbnail="http://cargo2.bioinfo.cnio.es/iGoogleGadget/cargo.png" width="365" height="400" author="Jose Manuel Rodriguez Carrasco" author_email="jmrodriguez@cnio.es" author_location="Madrid, Spain"/>

<Content type="url" ref="http://cargo2.bioinfo.cnio.es/iGoogleGadget/cargo.html"/>

</Module>

Aquí se detalla diferentes campos de información cómo el nombre del Gadget, una decripción, el tipo de contenido, etc. Cómo se ha dicho, el tipo de contenido de Cargo se trata de una URL.

A continuación se describen los pasos básicos que debes seguir para crear e instalar un gadget:

1. Usa un editor de textos para escribir la especificación del gadget y guárdala en un servidor público. Si no tienes acceso a un servidor público, puedes usar una de las alternativas disponibles.
2. Ve a http://www.google.com/ig. Si aún no dispones de una página de iGoogle, debes crear una como se describe en API de Google Gadgets: introducción.
3. Haz clic en Añadir elementos. Esto te llevará al directorio de contenido. Puedes usar dicho directorio para buscar gadgets y añadirlos a tu página principal.
4. Haz clic en el vínculo Añadir por URL, junto al botón "Buscar contenido en la página principal".
5. En el cuadro de texto Añadir por URL, escribe la URL de la especificación de gadget XML que deseas añadir y haz clic en Añadir. Para averiguar cuál es la URL, es posible que necesites ayuda del webmaster. También puedes usar el gadget del programador para añadir gadgets a tu página de iGoogle.

Espero que os sirva esta introducción.

¿Cuántas veces os habeis encontrado con que quereis aprender sobre alguna nueva herramienta que todo el mundo usa, pero que no dominais en absoluto? ¿O tal vez se os resbala un poco una técnica o concepto? Gracias a David G. Pisano (que lo ha encontrado), aquí teneis el enlace al sitio de CLC bio dedicado a Bioinformática. En este sitio podeis encontrar bastantes documentos en PDF escritos en inglés sobre temas como las bases de datos biológicas, comparativas de Blast contra Smith & Waterman, predicción de la estructura de RNA, detección de sitios de restricción, etc... Toda esta documentación está licenciada bajo Creative Commons - NonCommercial - NonDerivs 2.5, de forma que todo el contenido lo podeis copiar, distribuir y usar de forma libre siempre que sea para uso educativo, y se mencione al propietario (en este caso, CLC Bio).

Acabo de enterarme por mi compañero de trabajo Ildefonso Cases que la Fundación Juan March acaba de hacer públicas a través de su página web las grabaciones de audio de todas las conferencias y charlas que desde 1975 se han celebrado allí.


Por lo que Ildefonso nos ha contado por correo a mí y al resto de mis compañeros, las grabaciones abarcan toda clase de campos, desde Arte hasta Psicoanálisis, incluyendo un número de charlas sobre Biología Molecular. Por lo que ha encontrado Ildefonso, casi todos los personajes contemporáneos relevantes en la ciencia española han dado una ponencia en la Fundación Juan March en el rango de tiempo de las grabaciones: Severo Ochoa ^(g), Margarita Salas ^(g), Alberto Sols ^(g), Juan Oró (¡hablando sobre vida en Marte en 1975!), Miguel Beato ^(g), Manuel Perucho ^(g), Antonio García-Bellido ^(g), Mariano Barbacid ^(g), etc...

También hay registradas ponencias de afamados Premios Nobel, como Max Perutz, César Milstein, Sydney Brenner, Walter Gilbert, Aaron Klug, H. Gobind Khorana, John E. Walker, Paul Berg, etc...

La fuente que tomó Ildefonso para enterarse de esto es la noticia publicada hoy en El País, titulada "Recuperar la voz del saber".

Hace un par de días mi compañero de trabajo Martin Krallinger encontró el artículo que da título a esta entrada de blog: "The Ombudsam: Verification of Citations: Fawlty Towers of Knowledge?". En él sus autores exponen que una de las taras sobre el crecimiento del conocimiento científico es la prevalencia de referencias bibliográficas mal asignadas o erróneas. Por ejemplo, si un artículo es publicado con insuficientes referencias bibliográficas, será más difícil encontrar los trabajos anteriores relacionados. O también, el hecho de que parte de las referencias bibliográficas estén mal establecidas (mal escritas, son incorrectas o inadecuadas,...) puede hacer que otr@s investigador@s usuarios de programas automatizados de recuperación de información (por ejemplo, técnicas de text mining) obtengan resultados sesgados, incorrectos o incompletos.

Como no tengo acceso al artículo como tal (sólo está accesible su introducción), no puedo formarme una opinión mejor sobre el estudio, y cuál es el soporte estadístico para las afirmaciones que aparecen en la introducción. Un artículo también relacionado con las referencias bibliográficas fue comentado hace un par de años en el blog Cuaderno de Bitácora Estelar, en ese caso relacionando la popularidad de los artículos, medida en función del número de veces que se citan, con su mención o referencia en prensa.

Como podeis leer en un post anterior sobre cómo hacer funcionar Phrap, me encontré con el caso curioso de que, en una misma máquina de arquitectura IA64, los programas de Phrap compilados con GCC fallaban con Segmentation Fault, mientras que esos mismos programas compilados con el compilador de pago Intel funcionaban. Pues bien, tras estar investigando cómo hacer funcionar Phrap de forma nativa en las arquitecturas de 64 bits (x86-64 e IA64) compilándolo con GCC, me encontré con el meollo del problema: un fallo muy específico al hacer una conversión de tipos en el generador de código ensamblador del GCC.


Los programas más antiguos en C usados en bioinformática están escritos en el dialecto C de Kerningan & Ritchie, que es muy limitado en cuanto a lo que se podía hacer: las funciones devolvían a lo sumo un entero, no soportaba declaración de propotipos de función (con lo cuál no había validación de parámetros), los includes, ni macros (no había preprocesador) ... El código fuente de Phrap está escrito así, pero se nota que ha sido retocado ligeramente a posteriori, porque tiene algunos includes.

Por ello, como no había NULLs (son meros defines), en códigos escritos en este dialecto su función es suplida por el 0, y el casting del 0 al tipo de puntero correspondiente. A diferencia de las arquitecturas de 32 bits, en las arquitecturas de 64 bits los punteros de C tienen un tamaño distintos que los enteros. Así que si el programa usa el 0 en lugar del NULL como algún parámetro directo para llamar a una función, y el compilador no sabe que tiene que hacer una conversión implítica de tipos (porque no conoce el prototipo de la función a llamar), entonces se produce el desastre.

Hay dos maneras de solucionar el problema, que implican en ambos casos tener experiencia de programación en C, e introducir cambios en el código problemático. La primera es reemplazar todos los usos implícitos del 0 como representación de NULL en las llamadas a función por (tipo *)0, donde tipo es el tipo que corresponda. La segunda, que es menos invasiva, consiste precisamente en buscar la declaración de la función, y tomándola como base crear el prototipo de la función. En el caso de Phrap, todo se soluciona añadiendo al final del fichero swat.h las líneas:

int get_LLR(
	char * diffs,
	char * orig_qual1,
	char * orig_qual2,
	char * adj_qual1,
	char * adj_qual2,
	int length1,
	int start1,
	int end1,
	int length2,
	int start2,
	int end2,
	int reverse,
	Segment * segments1,
	Segment * segments2,
	int print_flag,
	FILE * fp,
	int q_start1,
	int q_end1,
	int q_start2,
	int q_end2,
	int ignore_ends
);

que corresponden a la declaración de la función problemática.

Hoy gracias a un mensaje de mi compañero de trabajo Jan-Jaap me he encontrado con la siguiente noticia publicada el 29 de Mayo en boingboing y en The  Chronicle of Higher Education: los editores y referees de las revistas se están encontrando cada vez más casos de retoque fotográfico de los supuestos resultados experimentales obtenidos por autores de manuscritos candidatos a ser publicados.


Es tal el nivel de fraude, que algunas revistas como las del grupo Nature Publishing se están planteando migrar de su modelo actual de detección del fraude mediante revisión aleatoria de un par de artículos por mes a otro más sofisticado. Este nuevo modelo usaría software que detectaría a nivel de imagen los "artefactos" que introducen los programas de retocado como Photoshop o GIMP.

Os recomiendo que os leais las noticias originales, porque no tienen desperdicio...

Enlaces:

• Enlace a noticia de fraude científico en boingboing.
• Enlace a noticia extendida de fraude científico en The Chronicle of Higher Education.
  

Phrap es uno de esos programas bioinformáticos muuuuy usado a la hora de ensamblar todos los contigs _{(¡que no hay que confundir con los EST contigs!)} obtenidos de secuenciadores que usan técnicas similares a la de shotgun. Este programa es gratuito para uso académico (previa solicitud a los autores), y está disponible tanto en código fuente como en módulos precompilados. El problema al instalar Phrap viene de que fue diseñado y escrito en entornos de 32 bits, con compiladores de 32 bits, en lenguaje C de Kerningan & Ritchie, y no compila muy bien que digamos en entornos de 64 bits con los compiladores actuales. El otro inconveniente es que no incluye un conjunto de datos de prueba, para ver si realmente funciona o falla.



Tras estar José Manuel Rodríguez, Andrés Cañada y yo toda una mañana probando combinaciones de arquitecturas y compiladores, llegamos a las siguientes conclusiones:

• Phrap se puede compilar y funciona en un Linux de 32 bits con el GCC, con la limitación de la cantidad de memoria que puede usar un proceso en este entorno (a lo sumo, 2GB~3GB).
• El software no funciona muy bien en entornos Linux x86-64 (32 y 64 bits) cuando es compilado con el GCC. Aquí tuvimos que forzar una compilación de 32 bits para que los programas del paquete Phrap no dieran el temido Segmentation Fault al empezar a ensamblar, imponíendoles así una restricción artifical (estos ejecutables no pueden usar más de 2GB~3GB por ser de 32 bits). Como no teníamos otros compiladores a mano, tuvimos que dejarlo así.
• En entornos Linux IA64 (64 bits) la cosa salió mejor de lo que esperábamos. En la máquina que tenemos con esta arquitectura (32 procesadores, 64GB de memoria), además del GCC, tenemos instalado el compilador de pago de Intel de C y C++. Con el GCC volvimos a tener problemas, pero con el ICC los ejecutables obtenidos funcionaron sin problemas. Creo que es debido a cómo empaqueta las estructuras de C y los tamaños de los tipos básicos.
  

Todavía nos queda hacer pruebas en Mac OS X, que tuvimos que postergar por temas de mantenimiento de nuestro CPD, pero sospechamos que se repetirá la misma historia: en 32 bits el programa funcionará, y en 64 bits el programa "petará", salvo que encontremos cómo compilarlo para que funcione.

Actualización 3 de Juio de 2008, 22:19:52: En un post de hoy mismo he publicado una solución mejor a la publicada en el segundo comentario para las arquitecturas de 64 bits.

Si trabajas en bioinformática, la mayor parte del tiempo estás dependiendo de programas que no has hecho para tu trabajo cotidiano. En ocasiones (más de lo habitual) es necesario usar programas que son antiguos o muy antiguos, y que no consigues que funcionen en los primeros intentos. Eso es lo que nos ha estado pasando hoy en el laboratorio, intentado hacer funcionar los programas del paquete Tops.


El programa Tops sirve para estudiar la topología de las proteínas, representándolas de forma esquemática. El primer artículo que menciona este paquete data de 1998, y sus autor@s originales ya hace tiempo que dejaron de mantener los programas. Esto es muy común en un mundo muy dinámico como el de la investigación científica, en el que las instrucciones o el código fuente de los programas más antiguos termina por perderse (si es que alguna vez se hizo público), y en el que los servicios bioinformáticos disponibles por web (tengan o no tengan éxito) terminan por dejar de funcionar. Esto ocurre por diversas causas, como no querer seguir manteniendo el software, no conseguir recursos para mantenerlo, se pierde tras una catástrofe como un incendio o una inundación, etc...

En esta ocasión tuvimos suerte, lo conseguimos hacer funcionar, pero ¿y la siguiente?