Open Minded

Cantidad de líneas visibles en una terminal

Posted on the Mayo 13th, 2009 under GNU/Linux,Software Libre by nacho

Mini post: Estaba corriendo jBoss y la salida de logging quería ir leyéndola en la consola. Si bien voy guardando logging en un archivo, me molestaba que se pudieron ver “pocas” líneas en la Gnome Terminal.
Buscando entre las preferencias encontré la solapa Desplazamiento, donde podía elegiar la cantidad de líneas. Una curiosidad tonta, pero que no había visto en 4 años de uso Gnome.

Autocompletado en bash personalizado (para tus programas!)

Posted on the Abril 9th, 2009 under GNU/Linux,Probando herramientas,Software Libre by nacho

Bash incorpora una característica que permite el autocompletado en una terminal de los parámetros que acepta un programa. Para esto utiliza un script con diversas funciones, y permite que incorporando un archivo y ciertos comandos, podamos definir como se autcompletarán los programas que querramos.

Por ejemplo, tenemos hecho un programa con Milton y Daiana, que acepta varios parámetros. Hay algunos que no los usamos hace tiempo, y para no estar consultando la ayuda, pensamos que estaría bueno que se autocompletara.

El programa está hecho en mono, y se ejecuta haciendo

$ ./programa.exe

o bien

$ mono programa.exe

Aquí el archivo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# Author: Nacho
# /etc/bash_completion.d/programa
# copy it there and enjoy magic, compadre!
#
_programa() 
{
    local cur prev opts
 
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts="-h -? --help -r --reemp -e -f --extrae-flex -c -g -d --vft"
 
    if [[ "${cur}" == -* ]] ; then
        COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
    else
        _filedir  '@(xml|sql)'
    fi
}
complete -F _programa $filenames programa.exe
complete -F _command $filenames mono

La línea 12 indica las opciones que acepta el programa.
La línea 17 indica que se listen (si no es que estoy intentando poner alguna opción) los directorios y archivos pero los XML y SQL únicamente.
La línea 20 indica bajo que nombre de ejecutable se completará y qué función es la encargada de tal tarea.
La línea 21 es la que indica que “mono” es un “command” al igual que otros definidos (sudo, fakeroot, nohup) que requieren autocompletado luego para el programa que le sigue.

En vez de listar la línea 12, se podría haber hecho que el programa en cuestión devuelva por defecto la lista de los parámetros que acepta. La forma de hacer esto sería reemplazar esa línea por:

12

    opts=`mono programa.exe -p`

Python tiene un módulo para realizar esto en forma más sencilla: optcomplete.

Espero les sea de utilidad!

Postgresql y update muy lentos (cuando hay alta carga)

Posted on the Febrero 10th, 2009 under Probando herramientas by nacho

Este es un mini post, para tenerlo a mano y que alguno que busque lo encuentre. Postgresql en los escenarios que la he probado, ha resultado más lenta que MySQL usando MyISAM e InnoDB. Por supuesto esto con la configuración que trae de base en una instalación Debian, Ubuntu o con el instalador (con perfiles) en Windows. O modificándole muy pocos parámetros.

Hace un tiempo ya que para un trabajo que estamos haciendo buscábamos la forma de acelerar los updates en Postgres. No es que fuera algo intolerable, pero a veces necesitabamos correr varias consultas que actualizaban unos 2M registros en base a si cumplían o no unas 40 expresiones regulares bastante complejas.

Bueno, me dirán, por qué no usaste MySQL entonces. Bueno, porque no je. En realidad porque en cuanto a extensibilidad usando los lenguajes en Postgres (plpythonu, plpgsql,plphp y quizá pljava) teníamos más flexibilidad. Tenía mejores capacidades de gestión de expresiones regulares y posibilidad de usar tipos de datos vectores (para los matching de las reg. exp.).

El post corto se está alargando y me voy a explayar en otros. Lo que intentamos fue meter commits entre medio de los updates, pero de nada servía. Incluso encerrar en una transacción varios updates. Tampoco.

Leyendo encontré que tiene que ver en la performance de PgSQL las copias que se genera de cada tabla que se está accediendo para mantener consistencia en cuanto a las consultas d ediferentes usuarios. Los checkpoints que va haciendo en el log (log de transacciones, no el log de errores) del sistema son los que estaban afectando. En definitiva aumentando el tamaño de los segmentos de los checkpoints debería haber una mejora en performance.

Este parámetro se cambia en

/etc/postgresql/8.3/main/postgresql.conf

checkpoint_segments = 256

Si hubiese mirado el log (avisos y errores) de PgSQL quizá me hubiese dado cuenta. Se la pasaba imprimiendo:

2009-02-10 11:23:09 ARST LOG: los checkpoints están ocurriendo con demasiada frecuencia (cada 2 segundos)
2009-02-10 11:23:09 ARST HINT: Considere incrementar el parámetro de configuración «checkpoint_segments».

Prometo en otro post contar los resultados y ordenar esto.

Fuentes:
http://pugs.postgresql.org/node/499
http://www.linux-es.org/node/660
Por qué: http://www.network-theory.co.uk/docs/postgresql/vol1/Increasecheckpoint_segments.html
http://archives.postgresql.org/pgsql-performance/2008-06/msg00119.php

Generando PDF de alta calidad con LaTeX

Posted on the Noviembre 27th, 2007 under Probando herramientas by Nacho

Hace un tiempo que venimos trabajando con LaTeX para la documentación de los trabajo prácticos de la facultad. El gurú es Milton, pero de vez en cuando tuve que cambiar un par de estilos y me fui introduciendo en el tema.

Cada vez que hacíamos una entrega, nos dábamos cuenta que la calidad de los PDF generados no era la mejor. Las fuentes salían mal formadas, y si imprimíamos el documento desde Evince prácticamente era una calidad de impresión de imagen, y no calidad de texto como estábamos acostumbrados. Sospechaba que se trataba del hinting de las fuentes utilizadas pero nunca había tenido tiempo de buscar al respecto. Sin embargo por ahí andaba la solución.