Valkertown Blog

Me encanta GNU-Screen lo uso todo el tiempo y es dificil vivir sin él, me he acostumbrado demasiado a tenerlo andando todo el tiempo; sin embargo siempre he tenido una queja sobre los scrollbars y el mousewheel de los emuladores de terminal, hacer scrollback con las combinaciones de teclas que trae screen es bastante aburrido y lento, de echo ni siquiera funciona shift+pup/pdw algo a lo que todos estamos muy acostumbrados y realmente molesta de screen. Bien la solución viene (como era de esperarse ) al modificar las termcaps y ajustar todo el ambiente.

Esto soluciona parcialmente el problema pues todas las sesiones de screen quedan compartiendo el mismo scroll-buffer sin embargo es suficiente en muchos casos.

En el .screenrc añadi:

termcapinfo xterm ti@:te@
termcapinfo xterm ‘hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007′
termcapinfo rxvt ti@:te@
termcapinfo rxvt ‘hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007′


Esto para que funcione con xterm y rxvt(atern,unicode-rxvt,…).

Al invocar screen es conveniente ajustar la variable de entorno TERM para que el ajuste sea coherente:

rxvt -e screen -T rxvt
xterm -e screen -T xterm


Esta linea en el .bashrc corrige un defecto de algunos emuladores de terminal con los comandos que se extienden más allá del ancho y estos solo retornan al principio de la linea esto se vuelve sumamente molesto con el tiempo.

shopt -s checkwinsize


Una buena opción para utilizar al invocar tanto xterm como rxvt :

$ urxvt -j
$ rxvt -j -s
$ xterm -j -s

Esto acelera considerablemente el scroll de las terminales y la ejecución de algunos programas que se ven retardados por esto

Del manual :

-j This option indicates that xterm should do jump scrolling.
Normally, text is scrolled one line at a time; this option
allows xterm to move multiple lines at a time so that it does
not fall as far behind. Its use is strongly recommended since
it makes xterm much faster


-s This option indicates that xterm may scroll asynchronously,
meaning that the screen does not have to be kept completely up
to date while scrolling. This allows xterm to run faster


EOT

RANT: Si MATLAB es supuestamente la mejor herramienta para analizar datos en ingenieria por que ese programa tiene tantos problemas para trabajar con archivos mixtos? Quizá fue un problema por parte del programador, pero este tiene suficiente experiencia con este programa como para decir que esta tarea es especialmente obscura. Definitivamente la capacidad de integración de MATLAB en un ambiente de producción/análisis conjunto es pobre y deja mucho que desear.

Para quienes quieran entender la idea del proyecto, es muy sencilla:

Toma de datos -> Almacenamiento y Categorización de datos -> Preprocesamiento -> Procesamiento y Análisis -> Almacenamiento y generación de reportes.

Esto resume un sistema general de trabajo, pero realmente matlab se ha quedado por fuera ya que se nego a participar rapidamente en el ciclo de forma que todo el proceso quedará completamente automatizado para poder generar reportes con muchos diferentes análisis.

Realmente me he convencido que Matlab podrá estar muy bien para estudiantes, pero cuando se trata de trabajo serio pongo en duda su útilidad, por lo que realmente pienso que nisiquiera los estudiantes deberian perder el tiempo con él.

Al final python no brillo por su velocidad en el análisis ni por su excelente uso de la memoria, pues con las cantidades de datos que se le alimentaron hicieron que varias fallas aparecieran. Sin embargo brillo por la facilidad con la que resumi casi tres meses de trabajo en matlab en 24 Horas de programación en Numeric de Python más todo el trabajo de automatización y trabajo con bases de datos. Por favor, una vez más escuchenme Open Source es simplemente mejor, no se dejen engañar por los botoncitos y los colorcitos!!!

EOR
EOT