La Ciencia Española No Necesita Tijeras

Hasta ahora la ciencia en España no tiene un presupuesto como para tirar cohetes. Donde yo estoy ahora, gente valida (gran parte de de ellos becarios en mesas en los pasillos o hacinados en salas comunes), físicos gastan el tiempo realizando programas de mierda a disgusto porque no hay dinero suficiente para comprar programadores de verdad y dejar que los físicos dediquen el tiempo a lo que realmente saben y disfrutan, hacer física.

Buscar el error del usuario

Buenos días,

Los datos son:

Nombre de usuario: bbernat
email: boromirb@blablabla.com
Teléfono: 5556664242

Un saludo, Boromir Bernat

On Wed, 2009-06-03 at 18:19 +0200, Misma Mente wrote:
> Necesito que nos pases los siguiente datos para crearte una cuenta:
>
> Nombre del usuario:
> email:
> Teléfono:
>
> Un saludo, Misma
>

Ante este intercambio de correos entre un administrador y un usuario. ¿Cual es el fallo que cometió el usuario?

A mi me dejo con la boca abierta, ver la desfachatez de la gente.

Cosas que hacer en la tesina

Este último mes lo que más me ronda por la cabeza (a parte de pillarme un ordenador nuevo para volverme a pasar el Fallout 3 en condiciones) es terminar de escribir la tesina final del máster que estoy haciendo. El trabajo que me había planteado hacer esta terminado (y pocas ganas tengo de hacer más sobre el tema), ahora solo me queda poner por escrito en unas 40~50 páginas que es lo que he hecho, para que vale lo que he hecho y que conclusiones saco de todo lo anterior.

Como hablar del contenido de la tesina me aburre hasta a mi, he decidido comentar brevemente las herramientas que voy usando para hacerme más amena la tesina.

• Darcs: Para llevar el control de los cambios que realizo sobre los documentos de la tesina. De esta manera me aseguro poder trabajar desde varios ordenadores sin pisarme los ficheros.
  
• Latex: La única opción seria para escribir un documento. Con Xelatex para poder usar la fuente Gentium. Con el paquete lineno mientras voy escribiendo el documento ver donde cometo los errores. Con el paquete listings para colorear automáticamente los extractos de código. Y con el paquete glossary para facilitarme la vida.
  
• Makefile: Generar el documento final a partir del fichero Latex puede requerir unos cuantos pasos, mejor usar un fichero Makefile para hacerlo más comodo. Si tengo tiempo igual me miro para hacerlo en scons que aun me gusta más que el make. Ademas se puede configurar el darcs para que no guarde un cambio si el make falla. Un seguro extra frente a errores.
  
• Unison: darcs viene bien para el control de ficheros pequeños y de texto, ya que guarda las diferencias y lo hace muy rápido. Pero para ficheros binarios, guarda el fichero completo cuando hay un cambio. Con ficheros de varios megas puede ser muy pesado. Para estos ficheros es mejor usar unison que no guarda versiones y solo sincroniza cambios entre diferentes directorios. Y darcs puede configurarse para que llame a unison cada vez que se registra un cambio.
  
• Emacs: Casi dos años llevo usando este editor y no lo cambio. Con flyspell para chequear la gramática, longlines para cortar las lineas automaticamente, y highlight-changes para colorear los ultimos cambios mientras escribo.
  
• Inkscape y Gimp: Los ficheros gráficos los genero con estas dos herramientas. Los gráficos vectoriales (svg) los convierto a ficheros bitmap (png) con el make, de manera que con darcs solo guardo los svg (much más livianos y no son binarios).
  
• Escribir una entrada en el blog: esto que estas leyendo.

Y bueno, después de este descanso mental, seguiré escribiendo la tesina. Espero acabarla pronto.

Read more >> Options >>

Coloreado de cambios con Emacs

Hace mucho que no escribo, hoy voy a hablar un poco del Maravilloso Emacs. Editor que uso para editar cualquier fichero de texto desde hace poco más de un año. Y que me encanta. Y como lo hecho de menos cuando tengo que usar el Horroroso Vim.

En concreto, quiero comentar una pequeña funcionalidad de Emacs. Como colorear las partes nuevas en el fichero que estés escribiendo en un momento dado. Bueno, a partir de aquí, los párrafos entre paréntesis (lo que otros llaman código Lisp) va en el fichero de configuración de Emacs.

Primero creamos una función que nos limpia el coloreado de los cambios.

(defun clear-highlight ()
(interactive)
(if (boundp 'highlight-changes-mode)
(highlight-changes-remove-highlight (point-min) (point-max))))

Luego añadimos un par de accesos de teclado.

(define-key global-map (read-kbd-macro "<f3>") 'highlight-changes-mode)
(define-key global-map (read-kbd-macro "<f4>") 'clear-highlight)

Y ya esta. Ahora cuando apretemos por primera vez F3 con un fichero abierto, se activa la funcionalidad. Lo que escribamos a partir de entonces se colorea diferente. Si volvemos a apretar F3, se quita el coloreado, ..etc. Y con F4 lo que conseguimos es limpiar el coloreado como si empezáramos a editar de nuevo el fichero (ojo, no quiere decir que deshaga los cambios)

Aunque si quieres que te active el coloreado de cambios nada más abrir el fichero, puedes hacerlo con una linea como la que sigue. En este caso activa el coloreado para ficheros de LaTex.

(add-hook 'latex-mode-hook 'highlight-changes-mode)

Y si se quiere que se limpie el coloreado actual automáticamente cuando salvamos, bastaría con añadir una llamada a nuestra función clear-highlight cada vez que se salva.

(add-hook 'after-save-hook 'clear-highlight)

¿Se borró o no se borró?

Hola de nuevo, hacia mucho que no escribía en el blog, y mucho más que no lo hacía criticando el código de los demás.

El Mal Código de hoy es un pequeño ejemplo cosas que sobran en un lenguaje moderno. En concreto la creación y destrucción explicita de variables.

void MiClase::Fin(){
   this->p->Save();
   this->p->Delete();
   if( this->p ){
       delete this->p;
       this->p = 0;
   }
}

En el ejemplo anterior, la única operación útil para el programador es Save. El programador en un momento dado desea salvar p, signifique lo que signifique. El resto del código es a lo que se ve obligado por usar C++. Llama a un método Delete, y por lo confuso que le resulta C++, piensa equivocadamente que actúa como un destructor. Pero a la vez, siente cierta inseguridad. ¿Se habrá borrado el objeto? Como por convenio, los punteros se asignan a cero/null si no apuntan a ningún objecto, realiza la comprobación y si aun apunta a algún sitio, entonces hace la destrucción a mano y pone a cero el puntero.

El error, creo yo, que esta causado por partir de dos supuestos bastante feos. El primero, que el código de Delete esta llamando a su vez al destructor del objeto y y el segundo supuesto, que el destructor del objeto asigna cero a los punteros que tiene asignado (en nuestro caso p). Algo tan simple como lo que pongo a continuación, permitiría llamar al destructor desde Delete.

void PClase::Delete(){
   ...
   this->~PClase();
}

Simple pero mortal. Ya que de ser así estaría llamando al destructor dos veces ya que el segundo supuesto (que ponga a cero p) es casi imposible que se cumpla (se puede hacer pero sería un código tan horrible que os causaría pesadillas).

Mi solución

Para mí la solución es bastante simple, contando con que el código de la clase de p se mantiene. Si puede darse el caso de que p no apunte a ningún lado, se hace la comprobación al final. Y luego, seguro que Delete no llame al constructor, todos los pasos serán necesarios.

void MiClase::Fin(){
   if( this->p ){
       this->p->Save();
       this->p->Delete();
       delete this->p;
       this->p = 0;
   }
}

Epílogo

Para mí lo que parece obvio, es que en un trozo tan pequeño de código, con tan solo 5 lineas significativas, 4 de ellas son necesarias por usar un lenguaje de bajo nivel. Y os aseguro que el ámbito donde se usa este código no necesita de ese bajo nivel.