Bug en el compilador

A la hora de enseñar computación, una de las primeras cosas que se les dice a los alumnos es que las probabilidades de que encuentren un bug en el compilador son mínimas y que en realidad cualquier error es de su programa.

En realidad cuando se está programando todo el tiempo, sobre todo en Fortran, uno se topa frecuentemente con bugs del compilador. En general no es difícil saber que hay un bug, normalmente termina con un segmentation fault o un mensaje de Internal Compiler Error (ICE), el problema es que no siempre es claro qué lo gatilla. Además para resolverlo la única opción es hacer un "workaround", es decir modificar el código para que haga lo mismo de otra manera para evitar el bug, y poner un comentario para que el próximo que modifique el código sepa por qué se hace así.

Normalmente los bugs aparecen en compiladores cerrados, siendo los peores el compilador Intel para Itanium y el compilador Sun, pero pasa en todos. Curiosamente g95 y gfortran que si bien son mucho menos maduros tienen menos bugs que los compiladores propietarios.

Ayer me pasó precisamente lo contrario, encontré un bug en gfortran cuando se usa con OpenMP, el compilador da un ICE cuando la variable de inducción de un loop OpenMP se usa en una subrutina. Este es un ejemplo:
program testbug
integer :: ii
!$omp parallel do
do ii = 1, 1000
end do
contains
subroutine something()
ii = 0
end subroutine something
end program testbug
El workaround en este caso es simple, usar otra variable en las subrutinas, y de hecho, no me gusta mucho reusar las variables de inducción de la forma que gatilla el bug.

Al hacer el commit de octopus, Tobías Burnus vio el mensaje y me preguntó por el bug, como tenía una idea de por qué se causaba, logré aislarlo (con el código que mostré recien) y se lo envié. El vió que el bug aún está en la versión de desarrollo de gfortran y por lo tanto lo reportó. Esta es la entrada en el BTS de gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33880


Posteriormente, Jakub Jelinek, quien implementó OpenMP en GCC, descubrió que el bug también aparece en C.

Que Tobías lo hiciera fue suerte, porque a mí me hubiera tomado más tiempo reportar el bug, y seguramente lo hubiera hecho a través de Debian (a GCC solo se reportan bugs hechos con la versión liberada por ellos).

Evolution versus Emacs

Los que usamos Unix hace un tiempo estamos acostumbrados a las convenientes combinaciones de teclas de Emacs, como por ejemplo Ctrl+D para borrar, Ctrl+A para ir al principio de la línea, etc., que no solo funcionan en Emacs sino que en bash y en general en cualquier línea de comandos.

Sin embargo los desarrolladores de Gnome, probablemente debido a su secreto amor por Windows, han ido progresivamente eliminando estas combinaciones y reemplazándolas por sus versiones güinditas, mucho más primitivas y engorrosas de usar. Por suerte hay una clave perdida en el registro de Gnome (¿ven que les gusta güindous?) que permite reactivar el uso de esas combinaciones y eso lo mantiene a uno más o menos feliz.

Resulta que estoy intentando cambiarme a un MUA gráfico, y como primera opción probé Evolution. Todo iba más o menos bien, hasta que resultó que mientras escribía un email apreté Ctrl+A y la porquería en vez de ir al principio de la línea, como un programa educado haría, seleccionó todo el texto. Investigando descubrí que se ha reportado varias veces el error, pero los desarrolladores de Evolution los cierran.

¿Cuánto come un auto?

Con la moda de los biocombustibles, una pregunta válida es, ¿cuánta comida usa un auto? Pues haciendo el cálculo pensando en que una persona come unas 2000 kilocalorías diarias y que un auto tiene una potencia de unos 100 HP, se puede llegar a que un auto, usado una hora y media diaria requiere la misma cantidad de energía que 50 personas. Es bastante, ¿no?