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.
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!
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
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.
Bienvenidos al nuevo Open Minded. Disfruten la visita y siéntanse libres de opinar en todo.
Si deseas colaborar con nosotros para poder mantener el hosting y continuar escribiendo artículos, puedes hacerlo mediante una donación con PayPal.
