Open Minded

Existe un plugin o complemento para Gedit (el editor por defecto en Gnome) que permite unir/dividir líneas en un texto. Esto permite que si tenemos un texto con líneas demasiado largas, podamos dividirlas en líneas de por ejemplo 80 caracteres. Este plugin me estaba siendo muy útil para manejar los textos en L^AT_EX. Sin embargo, debía ir haciendo la separación de líneas párrafo a párrafo, ya que el plugin sino mezclaba todos los parrafos en uno sólo. Para comprender lo que les digo, inténten usarlo.

Lo que hice fue hacer un parche para el plugin para que soporte párrafos. No es que haya tenido algún error ni nada, sino que esta funcionalidad me resulta más útil. Les dejo el parche, y adjunto además, un nuevo plugin igual al Unir/Dividir líneas pero con el parche aplicado para los que no quieran parchear el original. Éste tiene las mismas combinaciones de teclas, por lo que no será compatible a la vez con el otro (le cambie apenas el nombre para que no haya conflictos). Para utilizarlo cópienlo en su $HOME/.gnome2/gedit/plugins/

El plugin si se selecciona todo (CTRL+A), y se presiona la combinación de teclas (CTRL+SHIFT+J) funcionando logra lo siguiente (espero que las imagenes expliquen más que las palabras)

(CTRL+A)

(CTRL+SHIFT+J)

El parche a aplicar sobre /usr/lib/gedit-2/plugins/joinlines.py

220c220,221
<     while ord(char) and (not (char in (' ', '\t', '\n', '\r'))):
---
>     twoBL = False
>     while ord(char) and (not twoBL) and (not (char in (' ', '\t'))):           
222a224,233
>         if (char in ('\n', '\r')):
>             text_iter.forward_char()
>             char = text_iter.get_char()
>             if (char in ('\n', '\r')):
>                 while (char in ('\n', '\r')):
>                     text_iter.forward_char()
>                     char = text_iter.get_char()
>             else:
>                 text_iter.backward_char()
>             twoBL = True

Archivos del complemento modificados. Además el patch.
joinlines2.tar.gz

Actualización:
El que subí tenía un error (además que el parche era reverso). Ahora joinlines2.tar.gz apunta al script corregido. El parche anteriormente publicado se puede aplicar sobre el joinlines.py que trae Gedit. Debajo dejo un parche para corregir el error sobre mi script si ya lo están utilizando (o sea sobre joinlines2.py)

231d230
<                 twoBL = True
234c233
< 
---
>             twoBL = True

En un post anterior, escribí acerca de un “bug” que tenía el winepreloader, el cual no permitía ejecutar aplicaciones de 16 bit o aquellas que requirieran el área de memoria ahora protegida por el kernel. Sin embargo en su release candidate 1.0 esto fue solucionado.

En este artículo donde muestro como correr Smalltalk Express con Wine, se explica como actualizar el respositorio para tener la última versión de Wine.

http://nacho.larrateguy.com.ar/2008/03/04/smalltalk-express-corriendo-con-wine-de-nuevo/

Actualización:
La solución al bug, se puede ver acá

winevdm: Move the DOS memory range check to not trigger for Win16 apps.

Que lindo encontrarse con este error, más estando con una distribución que se va a convertir seguro en la principal en mi PC de escritorio y en el portátil. Estoy hablando de Hardy Heron, la nueva distro de Ubuntu.

Aunque según estuve investigando, el error se debe a una nueva política de seguridad en el Kernel. Acá se explica el por qué del cambio. Este error o mejor dicho advertencia (warning) es visible cuando quiero ejecutar cualquier programa mediante el Wine preloader. Especificamente me comenzó a ocurrir cuando quise probar el Smalltalk Express (que documenté aquí como hacerlo correr en GNU/Linux). Para mi desgracia luego de estos warnings terminó en un error.

Para ir al grano. La aplicación es de 16 bits, por lo tanto seguramente el error es reproducible con otras. Les pego el error que obtengo:

nacho@nacho-laptop:~/programas/oSTEXPRES$ wine VW.EXE
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:load_winedos Could not load winedos.dll, DOS subsystem unavailable
winevdm: unable to exec '--app-name': 16-bit support missing

Buscando por la red encontré varios bugs anteriores que daban el mismo error. Pero fue éste y precisamente éste comentario, el que me enseñó la luz. En un artículo de Kerneltrap se puede leer que se decidió para evitar futuros ataques, proteger ese espacio de memoria. Sin embargo hay un mínimo que se puede utilizar, continuando con la protección, y que permite que se ejecuten en este caso, las aplicaciones de 16 bits con Wine sin problemas.

Hay que editar el archivo /etc/sysctl.conf y modificar la línea con el valor 4096 (0 desactiva la protección)

# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
# vm.mmap_min_addr = 65536
vm.mmap_min_addr = 4096

para que el cambio se efectúe permanentemente. Si lo queremos hacer temporal, se puede hacer con

# echo 4096 > /proc/sys/vm/mmap_min_addr
o bien
# sysctl -w vm.mmap_min_addr=4096

En cuanto al proyecto Wine, están proponiendo un parche que al menos informe sobre esta incompatibilidad con el cambio en el parámetro del Kernel.

Para la cátedra de Administración de Recursos el año pasado, debíamos realizar un trabajo de investigación y desarrollo, en el cuál se mostraran nuevas tecnologías que permitieran integrar sistemas. Buscando cumplir con el objetivo asignado por la cátedra y a la vez investigar en algo que aún no hubiéramos profundizado fue lo que nos llevó a la plataforma Mono.

Milton ya estaba desarrollando un sistema utilizando esta plataforma, César ya había programado con .Net (C# y VB.Net) para un TP anterior y yo algo de Web Services ya había utilizado (consumido con PHP, pero nunca creado) y además estaba usando C# para algunas cosas.

Sin embargo queríamos probar la madurez del proyecto Mono, utilizar las últimas versiones de MonoDevelop como IDE y las librerías y compiladores que pudieramos. Se nos ocurrió implementar un sistema de mensajería instantánea al estilo Gaim, obviamente que con la única posibilidad de enviar mensajes de texto y ver la lista de usuarios conectados. Pero, a medida que avanzabamos, le ibamos agregando cosas.

(more…)

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.

(more…)