GBM 1.52 o de la timidez de SSI

Heiko Nitzsche ha actualizado su versión mejorada de GBM (Generalised Bitmap Module) una librería y una serie de utilidades para trabajar con diversos formatos de imagen de mapa de bits (como los formatos JPEG, GIF o PNG). La última versión anterior al trabajo de Nitzsche de la dll (GBM.DLL) forma parte de eComStation 1.2; el procedimiento multimedia para ver ficheros JPEG (un reemplazo del original hecho por IBM, programado por Chris Wolgemuth) depende de esa biblioteca.

El trabajo de Nitzsche no es moco de pavo: ha añadido nuevos formatos y mejorado el soporte de los formatos ya existentes, ha actualizado los visualizadores de imagen, ha añadido un plugin para Firefox (y familia) y otro para Lucide, así como un API que permite previsualizar las imágenes en los diálogos de apertura de ficheros y una extensión que permite acceder a todas estas funcionalidades desde REXX y además todo esto lo hace utilizando compiladores modernos (OpenWatcom 1.7).

De hecho, el conjunto de procedimientos multimedia parte de eSchemes Deluxe denominado Imagination que añade nuevos formatos de imagen al sistema multimedia de OS/2 está basado en el trabajo de Nitzsche.

Y ahora pasamos a Serenity Systems International, los responsables de eComStation y los listados de características de las betas de la próxima versión de su distribución de OS/2 (eComStation 2.0): en ningún lugar se habla de la inclusión de la versión de GBM mejorada por Nitzsche.

Y eso me hace preguntarme por qué SSI realiza tan timidamente muchas modificaciones al sistema operativo (las referentes a ACPI, controladores de tarjetas de red y demás controladores podría decirse que son por necesidad). Hay docenas de programas que podrían ser incluidos y GBM es solamente un ejemplo: programas de grabación de CDs y DVDs (Audio/Data-CD-Creator, dvddao, cdrtools, All2Iso), clientes para compartir archivos (ctorrent -del que parece existir un front-end-), clientes de correo (está incluido Thunderbird, pero RexxMail ¡es tan WPS...!), gestores de descargas (las últimas versiones de wget y el maravilloso Auto WGet Daemon), utilidades varias (la utilidad para el portapapeles ClipView), extensiones REXX (rxu, por mencionar el ejemplo más notable)...

Además, uno supone que no debería ser difícil para SSI sustituir el visor de imágenes incluido en OS/2 por algo más moderno (al estilo del de Windows XP), hacer un conversor de formatos de imagen, un editor de imágenes (al estilo del MS Paint) e incluir un capturador de imágenes sencillo (Gotcha es un punto de partida para hacer uno bien integrado con el sistema, el visor de GBM incluye otro capturador)... por mencionar solamente uno de los tipos de datos que puede manejar un sistema operativo.

¿Por qué no lo hacen? ¿Miedo a que el sistema pierda estabilidad? ¿Falta de recursos económicos y humanos (invertidos en el corazón del sistema, que es esencial para que todo lo demás funcione)? ¿Implicaciones legales? ¿Falta de ideas?

Como averiguar si un script está en una consola

En un mundo en el que las interfaces gráficas de usuario en general y los entornos de escritorio son algo omnipresente no deja de resultar muy curioso el hecho de que cada sistema operativo ha optado por métodos muy diferentes a la hora de ejecutar sus scripts diseñados para la consola desde el entorno de escritorio. Es decir, cuando hacemos doble click sobre el icono correspondiente al script.

Windows y OS/2, por ejemplo, abren una consola cada vez que se ejecuta un fichero bat o cmd (en el caso de OS/2, los ficheros cmd pueden ser programas escritos en REXX o incluso pueden ser programas escritos en Python o Perl no simples ficheros de proceso por lotes). Windows no ofrece muchas facilidades para ocultar la ventana de la consola. OS/2 ofrece bastantes alternativas para ocultarlo si es necesario y modos de ejecutar pequeños diálogos gráficos cuando la consola está oculta.

BeOS nunca abre una consola cuando se ejecuta un script. Tradicionalmente en BeOS todo aquel script que estuviese pensado para el escritorio utilizaba el comando alert de BeOS que permitía mostrar al usuario pequeños diálogos con sus correspondientes mensajes y botones.

Con los entornos de escritorio usuales en Linux (Gnome y KDE, aunque haya docenas más con muy buenas ideas, por cierto) lo habitual es que el comportamiento fuese el mismo que en BeOS. Actualmente lo usual en Gnome (por ejemplo) es que cuando un usuario hace doble click sobre un script aparezca un diálogo que le pide confirmar si quiere ejecutarlo, ejecutarlo abriendo una terminal, editarlo o cancelar la apertura.

Ocasionalmente puede ser interesante que un script averigüe si se está ejecutando en una consola o no y para ello el comando tty nos puede servir muy bien puesto que la salida de ese comando nos indica el número de terminal en el primer caso o nos dice "not a tty" en caso contrario. Así podemos hacer de forma sencilla lo siguiente:

  #!/bin/bash

  if [ "$(tty)" = "not a tty" ]; then
    echo "No es una terminal"
  else
    echo "Sí es una terminal"
  fi

  exit 0

Lo que en REXX quedaría como:

  /*bin/true;exec rexx "$0" "$@";exit # REXX */

  'tty | rxqueue'
  parse pull tty

  if tty = 'not a tty' then
    say 'No es una terminal'
  else
    say 'Sí es una terminal'

  exit 0

El código de retorno del comando nos da la misma información:

  #!/bin/bash

  tty=$(tty)

  if [ $? = 1 ]; then
    echo "No es una terminal"
  else
    echo "Sí es una terminal" # $? es igual a 0
  fi

  exit 0

En REXX:

  /*bin/true;exec rexx "$0" "$@";exit # REXX */

  'tty > /dev/null'

  if rc = 1 then
    say 'No es una terminal'
  else
    say 'Sí es una terminal' /* rc es igual a 0 */

  exit 0

Esto nos permite, por ejemplo, forzar la ejecución del programa en una terminal:

  #!/bin/sh
  # Ejemplo para BeOS
  # Cada entorno de escritorio tiene su propio ejecutable
  # para la terminal.
  myself=$0
  if [ "$(tty)" = "not a tty" ]; then
    Terminal -t "Ejemplo" /bin/sh -c "$myself"
  else
    echo 'Sí una terminal'
  fi

Con kdialog, zenity o xdialog podemos hacer pequeños scripts interactivos como en el siguiente caso:

  /*bin/true;exec rexx "$0" "$@";exit # REXX */

  current_date = date('S')

  'tty > /dev/null'

  gui = rc

  if gui = 1 then do
    'zenity --title "Escoja su fecha de nacimiento"' ||,
      ' --calendar --date-format %Y%m%d | rxqueue'
    pull birthday_date
    if rc = 1 then
      exit 1 /* Pulsado el botón "Cancelar" */
    end
  else do
    say 'Introduzca su fecha de cumpleaños (19770223):'
    parse pull birthday_date
    end

  age_in_days = say date('B', current_date, 'S'),
                - date('B', birthday_date, 'S')

  if gui = 1 then do
    'zenity --warning --text "Su edad en días es:',
      age_in_days '"'
  else do
    say 'Su edad en días es' age_in_days

  exit 0

La máquina expendedora de ooRexx

David Ashley, uno de los líderes del desarrollo del intérprete Open Object REXX (también conocido como ooRexx) anuncia hoy en comp.lang.rexx que el servidor de compilación de Open Object REXX está listo y la página asociada para acceder a él, también lo está. Tal como estaba previsto hace ya bastantes meses y como al parecer se comentó en el simposio internacional de este año.

Básicamente ese servidor es una máquina con un Fedora Core 6 y un conjunto de sistemas operativos ejecutados como invitados a través de un VMware Server 1.0.3. Por ahora las elecciones no son muy variadas: Fedora 7, Ubuntu 7, Windows 2000 y Windows XP. Esto deja fuera otros sistemas para los que ya existen versiones oficiales del intérprete (AIX, Mac OS X y Solaris) y versiones no oficiales (FreeBSD).

Lo que más me llama la atención de esta iniciativa es la enorme conexión que establece entre un lenguaje que deriva de REXX y SmallTalk (y que por lo tanto tiene una tradición tan larga que hace que sea fácil tacharlo de antigüedad) y algo tan en boga y de moda como son las máquinas virtuales.

La máquinas virtuales no son el único punto de conexión de ooRexx con cosas que no están nada trasnochadas: gracias a Rony Flatscher y sus alumnos tenemos BSF4Rexx que permite ejecutar código Java desde REXX (desde Object REXX de forma completamente transparente) y código REXX desde Java; gracias también a Rony se puede acceder a OpenOffice y su sistema de componentes UNO desde Open Object REXX permitiendo el control externo de la aplicación, así como el escribir macros en ooRexx; gracias a David Ashley también disponemos de una mod_rexx apto para las últimas versiones del servidor Apache; René Vincent Jansen insinua en su blog que la integración entre ooRexx y el sistema de scripting de Mac OS X es cada vez mejor...

En definitiva, la comunidad de viejos dinosaurios se mueve aun y se moderniza. Que el equipo de desarrolladores pongan al servicio de la comunidad esta máquina expendedora que escupe la versión binaria más reciente correspondiente al código almacenado en los depósitos Subversion resulta (al menos desde el punto de vista intelectual) muy estimulante.

Free Pascal Compiler 2.2.0 en OS/2 y eComStation

Ayer me enteré a través de Barrapunto de la salida de la versión 2.2.0 de Free Pascal Compiler, un compilador de Pascal y Object Pascal de código abierto multiplataforma (OS/2, Linux -versiones de 32 y 64 así como para arm-, FreeBSD, Windows -incluidos Vista y CE-...) y me llama bastante la atención que no se haya mencionado nada todavía en ninguno de los portales dedicados a OS/2.

Y me llama la atención porque Pascal, sus dialectos y sus derivados siempre han dado un buen puñado de programas populares y útiles para OS/2 (dejamos de lado el hecho de que en otros sistemas operativos uno de mis programas favoritos de todos los tiempos esté hecho en Delphi: Total Commander de Christian Ghisler).

Por poner un ejemplo, en este mismo instante estas líneas las escribo en el editor de texto de eComStation, el AE de Aaron Lawrence, que está hecho en Sibyl (una especie de Delphi para OS/2), mientras tengo un cliente IRC hecho con Virtual Pascal (Virtual IRC) conectado y escucho esa deliciosa excentricidad de Mike Oldfield llamada Amarok con el reproductor Z! hecho con Virtual Pascal. Y hay cientos de ejemplos así:

• En Virtual Pascal: el reproductor MP3 en modo texto Z! (también disponible para Windows), Web/2 (un estupendo servidor web, ligero y sencillo también disponible para Windows), Virtual IRC (un cliente IRC), Normal Player (un reproductor que usa el sistema multimedia de OS/2)...
• En Sibyl o su variante GPL WDSibyl (disponible para Windows): NewView (el nuevo visor de ayuda que es componente de eComStation), AE (el editor de texto que es componente de eComStation), el USB Resource Manager, el programa de configuración de TCP/IP de Reinhard Berger...
• En Modula, un lenguaje derivado de Pascal: FTPServer (un estupendo servidor FTP) y Weasel (un estupendo servidor de correo) ambos de Peter Moylan.
• En Oberon, otro derivado de Pascal, DrDialog (una herramienta gratuita de desarrollo RAD en REXX).

Viendo la tradición de Pascal en OS/2, me llama la atención que la comunidad en torno a este sistema operativo no se haya hecho hecho eco de la noticia de esta nueva versión del compilador FPC.

Como nota curiosa, he descubierto que el cliente IRC está programado con Virtual Pascal cuando mi amiga Nerea ha intentado pasarme un fichero a través de DCC y el cliente ha dado un típico fallo en tiempo de ejecución de los que dan los programas hechos con ese compilador. Y el fallo era por una razón bastante peculiar: ¡me había quedado sin espacio en mi partición de OS/2!

Macros REXX en IBM Works

Mientras intento recuperarme de la impresión de ver 300, la adaptación del cómic de Frank Miller al cine (Miller, aunque algunos no le perdonemos aun el guion de Robocop 2, parece tener bastante más suerte en esto que el pobre de Alan Moore), me gustaría hablar de cómo estaban implementadas las macros en una aplicación que ya tiene más de 10 años: IBM Works.

Las macros, desde el punto de vista de un usuario final, son conjuntos de acciones que permiten ahorrar trabajo al usuario en un programa concreto. Ejecutando la macro al pulsar una combinación de teclas, pulsar un elemento de un menú, seleccionarla en un diálogo o como permita el programa, el usuario puede evitar realizar tareas repetitivas como inserta el carácter hebreo aleph, selecciona el párrafo y dale otro formato...

Ocasionalmente, las macros pueden tener una lógica interna más allá de una secuencia de tareas repetitivas y entonces el modo de realizarlas es a través de un lenguaje de programación de macros. Y son de estas macros de las que quiero hablar.

El problema que siempre ha existido con los lenguajes de programación de macros es que son específicos de la aplicación: el cliente IRC mIRC tiene su lenguaje de macros, Microsoft Office hasta ahora ha utilizado una variante de BASIC (Visual Basic for Applications), Open Office ha utilizado otra variante de BASIC, Lotus SmartSuite utiliza LotusScript, el editor de audio Audacity usa su propio lenguaje...

Esto quiere decir que si el usuario desea aprender un lenguaje de macros, probablemente no pueda reutilizar sus conocimientos en otro sitio. Además, en algunos casos, la complejidad del lenguaje de macros para el tipo de tarea que desea el usuario puede resultarle excesiva (se encuentra con tipos de variables, declaraciones, módulos, objetos, métodos, sistemas de componentes y similares incluso para las macros más sencillas).

Cuando hace más de 25 años, Mike Cowlishaw creó el lenguaje de programación REXX, uno de sus propósitos era que fácilmente pudiera ser utilizado como un lenguaje de macros. Y cuando IBM empezó a introducirlo como lenguaje de scripts de todos sus sistemas operativos, también empezó a convertirse en el lenguaje de macros de muchas aplicaciones para esos sistemas.

En el mundo de la informática personal, dos sistemas operativos (uno ajeno a IBM) escogieron implementaciones de REXX como su lenguaje de macros preferido: OS/2 y Amiga OS.

En OS/2 existía un pequeño paquete de oficina llamado IBM Works cuya hoja de cálculo utiliza macros REXX aunque apenas aproveche las posibilidades de esto.




Como puede verse en la segunda imagen, la primera columna corresponde a nombres de personas, la segunda a un NIF (Número de Identificación Fiscal) y la tercera muestra una comprobación de la validez del NIF utilizando una función de la hoja de cálculo IBM Works: =rexx("isValidNIF.fnc",1,1,B4). La función rexx de IBM Works busca un fichero indicado en el primer parámetro (isValidNIF.fnc), decide que el valor de la celda será texto (si tuviésemos 0 en lugar de 1 tras la primera coma, trataría la celda como número) y lo ejecuta pasándole el número de parámetros indicado en el tercero de sus parámetros (en este caso uno)... Y el código de la macro no puede ser más sencillo:

/* isValidNIF.fnc */
  parse arg nif
  letras  = 'TRWAGMYFPDXBNJZSQVHLCKE'
  numeros = '0123456789'

  letra   = right(nif, 1)
  dni     = left(nif, length(nif) - 1)

  select
  when pos(letra, letras) = 0 then
    ret = 'ERROR: Último carácter no es una letra'
  when verify(dni,'1234567890') <> 0 then
    ret = 'ERROR: El NIF debe comenzar por un número válido'
  when letra = substr(letras, dni//23 + 1, 1) then
    ret = 'NIF válido'
  otherwise
    ret = 'ERROR: La letra no corresponde al DNI'
  end

return ret

En esta aplicación concreta, la utilización de REXX como lenguaje de macros se ve reducida a su mínima expresión (al contrario que en casos como gnuplot, gdb, Photo>Graphics, GoServe, EPM...) y a pesar de ello se aprecia la sencillez.

Esto no solventa uno de los problemas de los sistemas de lenguajes de macros: la dependencia de un lenguaje concreto.
Microsoft intentó eliminar la dependencia del lenguaje a través de su sistema de componentes COM que permite utilizar cualquier lenguaje para el que exista un WSE (Windows Scripting Engine) en cualquier aplicación que funcione como WSH (Windows Scripting Host) como son Internet Explorer o IIS, por ejemplo (y no es Microsoft Office, curiosamente), pero el sistema es incómodo para un no iniciado. OpenOffice desde sus últimas versiones permite ejecutar macros en más de un lenguaje, pero el sistema es tan barroco como el caso de los sistemas de Microsoft.
Quizás la aproximación que dando independencia de lenguaje conserva la sencillez es una de las que siguen virtualmente todos los servidores web y algunos editores de texto: la macro se ejecuta por el intérprete deseado y coge la információn necesaria de la entrada estándar, los parámetros y las variables de entorno y devuelve la información a la aplicación a través de su salida estándar. Así es como funcionan los CGIs en los servidores web y las macros en el editor de texto para programadores TextMate (aunque en este caso, la documentación del editor restringe el concepto de macro), por ejemplo.

Es una pena que a veces las cosas sean innecesariamente complejas.

Incidentalmente: en la distribución del intérprete newLISP para Windows puede encontrarse un ejemplo de fichero de Excel que incluye una macro en Visual Basic que define una función que permite ejecutar código newLISP en cualquier fórmula de Excel de un modo muy similar al ejemplo de IBM Works. Y el mismo sistema puede utilizarse para ejecutar código de otros lenguajes.

Synergy en OS/2

,a href="http://www.netlabs.org":Netlabs,/a: cumple 10 aos, lo que es un buen motivo de celebracin... No es que me haya equivocado de tecla, es que estoy usando el teclado y el ratn del porttil de mi hermana (Windows) en mi ordenador de sobremesa (eComStation). Y que nadie piense que he sido tan bruto como para despedazar el porttil y hacer una chapuza, simplemente estoy usando Synergy a travs de la red. Pero volvamos a mi teclado...

Hace unos días, Netlabs cumplía 10 años y explorando el directorio incoming en su servidor FTP como hago de vez en cuando me tropecé con un misterioso fichero llamado synergybart.zip. El bart me sugería quién era probablemente el autor (Bart van Leeuwen), pero el synergy me dejó descolocado y como la curiosidad extrema es uno de mis numerosos defectos, descargué el fichero y le eché un vistazo para encontrarme... que no llevaba ninguna documentación.

Una rápida búsqueda a través de Google permite ver que Synergy es un programa libre multiplataforma (hay versiones para Windows, Linux y Mac OS X) que permite usar el teclado y el ratón de un ordenador concreto (el servidor) en varios ordenadores conectados en una red. Es decir, podemos tener tres monitores correspondientes a tres CPUs distintas y controlar todos desde el mismo teclado y ratón. Moviendo el puntero a los bordes de un monitor, pasamos al siguiente...

El que comparte el teclado y el ratón funciona como servidor ejecutando synergys.exe con la configuración y los parámetros adecuados. En mi caso, el fichero de configuración synergy.conf es así:

section: screens
        salva:
        fran:
end
section: links
        salva:
                right = fran
        fran:
                left = salva
end
section: options
        screenSaverSync = false
end

En él se indican los nombres de los monitores y además la posición relativa de los mismos (fran está a la derecha de salva y salva está a la izquierda de fran).

Si mi máquina tiene mi como IP la 192.168.0.3 y la de mi hermana tiene como IP la 192.168.0.1 y la mía funciona como servidor, debo ejecutar synergys.exe --config synergy.conf --name salva en mi máquina y synergyc.exe --name fran 192.168.0.3 en el portátil de mi hermana. Mientras que en el caso en el que el servidor es el portátil, debo ejecutar synergys.exe --config synergy.conf --name fran en el portátil y synergyc.exe --name salva 192.168.0.1 en mi ordenador.

La versión de OS/2 del servidor parece no funcionar bien; solamente consigo que el puntero en el portátil se mueva, pero renqueando y sin que funcionen los botones y el teclado envía la señal al servidor en lugar de al cliente. (Digo parece porque puede ser culpa de la configuración.) La versión de OS/2 del cliente parece funcionar bien, salvo por lo que queda patente en el primer párrafo de la entrada.

De hecho, lo más espectacular es ver cómo se copia y pega texto del clipboard (portapapeles) de forma completamente transparente entre una máquina y otra. (ClipView, la utilidad de Dave Saville también permite compartir el portapapeles entre dos máquinas a través de la red.)

La sentencia parse version

La instrucción parse de REXX permite, entre muchas otras cosas, saber con qué intérprete y qué versión del mismo estamos trabajando. A través de la sentencia parse version rexxVersion, el intérprete da a la variable un valor que indica el nombre del intérprete, el nivel del lenguaje y la fecha del intérprete.

Así, por ejemplo, si es el intérprete de REXX clásico de eComStation el que interpreta el código, la variable valdrá REXXSAA 4.00 3 Feb 1999. Si es Regina, puede resultar algo como REXX-Regina_3.3(MT) 5.00 25 Apr 2004 en las versiones más recientes o REXX-Regina_3.0 4.95 25 Apr 2002 en versiones anteriores. Si es Reginald, puede devolver REXX-Reginald_4.6 4.00 13 Aug 2005, por ejemplo. Si es Open Object REXX, el resultado podría ser REXX-ooRexx_3.0(MT) 6.00 28 Mar 2005.

En el primer ejemplo, REXXSAA identifica el intérprete REXX como el que forma parte de OS/2 y eComStation (si bien el intérprete REXX que forma parte del sistema operativo PC-DOS de IBM también se identifica a sí mismo como REXXSAA como probablemente le ocurra a alguna implementación más de IBM). El número 4.00 corresponde al nivel del lenguaje: el 4.00 corresponde al definido por la segunda edición de The REXX Language de Mike Cowlishaw, el nivel 5.00 corresponde al definido por el estándar ANSI de 1996 y el 6.00 corresponde al superconjunto de REXX clásico que es Object REXX. Y la fecha se supone que indica la fecha del intérprete en el mismo formato que date().

El estándar ANSI especifica que el nombre del intérprete debe ser la palabra REXX en mayúsculas seguida del nombre del intérprete en si mismo. Pero en algunos casos, el intérprete no sigue esa norma, como en el caso del Object REXX de IBM, que devuelve OBJREXX 6.00 18 May 1999, o BRexx, que devuelve brexx 2.1.0 Mar 11 2003 (debe apreciarse que en este caso BRexx tampoco indica el nivel del lenguaje, sino su versión y que el formato de fecha no es el que se considera correcto por el estándar ANSI).

Entre los intépretes más modernos se ha extendido la costumbre de indicar la versión del intérprete y la indicación de si es o no multithreaded (multihilo):

• Regina (multihilo): REXX-Regina_3.3(MT) 5.00 25 Apr 2004
• Regina (ejecutable estático): REXX-Regina_3.3 5.00 25 Apr 2004
• Reginald: REXX-Reginald_5.0 4.00 9 Apr 2006
• Reginald Lite: REXX-RegLite_5.0 4.00 3 Apr 2006
• Open Object REXX: REXX-ooRexx_3.0(MT) 6.00 28 Mar 2005

El distinguir que intérprete y/o que nivel del lenguaje ejecuta nuestro código nos permite aprovechar características de un intérprete concreto o un nivel del lenguaje sin dejar a los otros fuera.

El manejo de ficheros en REXX es una de las cosas que más cambian de una implementación a otra del lenguaje. Utilizando parse version podemos hacer lo siguiente:

parse version rxInterpreter rxLevel rxDate
select
when rxLevel < 4 then
  IO_routines = 'EXECIO'
when rxLevel < 5 then
  IO_routines = 'ANSI'
when rxLevel >= 5 then
  IO_routines = '.STREAM'
otherwise
  nop
end

para decidir si usamos el comando EXECIO de los mainframes como sistema de manejo de ficheros, las funciones del estándar ANSI (stream, charin, lineout...) o el objeto Stream propio de Object REXX. O, si queremos dar soporte a BRexx y AREXX:

parse version rxInterpreter rxLevel rxDate
select
when rxInterpreter = 'AREXX' then
  IO_routines = 'AREXX'
when rxInterpreter = 'brexx' then
  IO_routines = 'BREXX'
when rxLevel < 4 then
  IO_routines = 'EXECIO'
when rxLevel < 5 then
  IO_routines = 'ANSI'
when rxLevel >= 5 then
  IO_routines = '.STREAM'
otherwise
  nop
end

En ese ejemplo, consultando la variable IO_routines, podemos decidir qué código queremos ejecutar.

Evidentemente este sistema es de utilidad limitada. Hay tantos intérpretes REXX para tantas plataformas que es imposible para cualquier programador conseguir que un programa de mediana envergadura se aproveche de parse version para que se ejecute en todos ellos.