apuntes de make

Después de una semana renqueante por culpa de una gripe, al visitar las news de C3 me encuentro con que Rodrigo Soto ha elaborado una exahustiva explicación de como usar la utilidad make para compilar y enlazar una aplicación. Está en http://apuntesc3.tripod.cl/tlink32/tlink01.html y está realmente bien explicado. Son esas cosas de las que mucha gente presume saber pero sólo están al alcance de unos pocos.

funcionamiento de i18n en xHarbour

Uno de los temas de los que ultimamente hablo con mucha gente es del i18n de xHarbour, de lo bueno y de lo malo que tiene y de cómo intentar dar soporte de internacionalización en Harbour o en C3. Ya hice un primer post sobre el tema, pero recapitulamos, pues creo que el personal está perdido.

La manera de acometer la i18n en xHarbour es utilizar la llamada a la función i18n() para las cadenas que queramos traducir que pasaremos como parámetro. Una vez hecho esto generamos una lista de cadenas que se guardan en un fichero con extensión .hil Para ello llamamos al compilador con el parámetro -j, algo así como:

xharbourbinharbour colossus.prg  -jes_ES.hil -ifwh24include;xharbourinclude -n</p>

Con esto lo que hace el compilador es localizar todas las cadenas que están como parámetros de la función i18n() en el archivo fuente colossus.prg y las mete ordenadas en el fichero es_ES.hil. Esto lo hacemos para todos los fuentes de nuestra aplicación, con la particularidad de que el proceso es acumulativo, es decir que las cadenas del fuente se acumulan al archivo .hil. Por eso se aconseja borrar cada vez el fichero .hil y generarlo por completo.

Una vez tenemos el fichero .hil lo traduciremos al idioma que queramos usando la utilidad hbdict que se encuentra en xharbourutilshbdict y al que pasamos como parámetros los archivos de entrada – que hemos generado previamente – y el de salida que guardará la traducción hecha y que el programa genera si no existe. Con este programa traducimos una a una las cadenas que se encuentran en el fichero .hil y lo guardamos en un fichero con extensión .hit. Desde dentro de nuestro programa lo único que haremos es decir en que idioma queremos que se muestren las cadenas con las siguientes instrucciones:

HB_I18NSetLanguage( "en_US" )
REQUEST HB_LANG_EN
HB_LANGSELECT('EN')</p>

Si no decimos nada el programa mostrará las cadenas tal como aparecen en las llamadas a la función i18n(). El fichero .hil no se incluye nunca en la distribución, ya que se trata de un archivo de trabajo que sirve como guia para realizar la traducción con el hbdict. Sólo incluiremos en nuestra distribucíón el archivo .hit del idioma en que queramos que esté nuestro programa.

Ventajas de este método:

  • Que está todo hecho y funciona bien, salvo algo que comentaré más adelante.
  • Si añades una cadena nueva al fuente, regeneras el archivo .hil y llamas a hbdict, este acopla el .hil nuevo al .hit viejo y unicamente tienes que traducir la cadena nueva. De alguna manera hbdict tiene memoria. No se cómo lo hace pero lo hace.
  • Los ficheros .hit se cargan internamente en arrays de manera que la ejecución del programa no se ralentiza. Además tiene un formato de texto bastante extraño y está a salvo de que nadie meta las narices ahí.

Problema: que al ser hbdict un programa en modo texto usa páginas de códigos con lo que si usas acentos abiertos y cedillas no hace bien la traducción. Esto me está pasando con la traducción de Colossus a catalán, y por eso estoy haciendo un programa en Windows similar. De momento bilingüa tiene esta pinta y cuando lo termine será una contribución a xHarbour y el código estará disponible.

20031120.jpg

La menera amanuense de hacer esto es meter las cadenas en un DBF con tantos campos como idiomas y cade vez que tengas que traducir algo tirar del fichero. El problema que veo es que tienes otro DBF en tu aplicación, seguramente esto será más lento que el sistema de xHarbour y que estás más expuesto a que te toquen la traducción con cualquier herramienta que abra DBF. Recordar que con el método xHarbour el .hil nunca se distribuye, por lo que no se puede usar hbdict para tocar a mano una traducción ya hecha.

¿ Opiniones ?

debate de ideas o sobre software y coches

Una de las cosas que me animó a hacer este blog es intentar promover un debate de ideas acerca de la programación en general y el uso de entornos xbase en particular. Los foros de consultas técnicas están muy bien para eso, para resolver dudas, pero siempre he echado de menos los debates de ideas sobre programación. Me encanta leer artículos sobre experiencias de programación, uso de metodologías… sobre cosas que no son estrictamente de programación, sino digamos del envoltorio. Me gusta mucho la web de Joel Spolsky, es algo que he dicho mil veces, donde igual se habla de programación pura y dura que de como diseñar una oficina para que los programadores estén agusto. Pagaría por leer algo asi en castellano. José Alberto Hernandis ha comenzado un blog sobre programación que va en esta linea, se llama softinspain y la verdad es que tiene muy buena pinta.

A veces pienso que los programadores somos como los mecánicos y el software que hacemos son coches. A muchos de nosotros sólo nos interesa el motor del coche, mientras que al que se monta en el coche lo que menos le importa es el motor y da más importancia a la habitablidad del coche, la comodidad, la tapicería y el maletero. Y nosotros con la cabeza metida en el motor todo el dia. Creo que los progamadores deberiamos prestar más importancia al coche en su conjunto y menos al motor. Por eso son muy importantes los debates de ideas, porque te hacen levantar la cabeza del teclado y mirar hacia el horizonte para saber hacia donde vas y no sentir que vas en una ola que no sabes donde se dirige.

Por eso me ha gustado el debate entre René y Carles en los comentarios al post fivewin.info, porque este tipo de debates es lo que yo quiero leer. René, Carles: muchas gracias.

En el blog hay abierto un foro de debate para que todos podais abrir hilos sobre cualquier tema que os interese.

editor de recursos de PellesC… ahora si que si

Hace algún tiempo hablé del editor de recursos de PellesC. El caso es que he estado intentando usarlo, pero hasta hoy no he dado con la manera de hacerlo y encajarlo con xHarbour. Comprobareis que soy un poco chapuza, pero creo que todo esto puede servirle a más de uno.

Hasta ahora usaba el editor de recursos de Borland C++ 5.01 y todo iba bien. Sin embargo no me gustaban varias cosas, pero principalmente que de vez en cuando me hacia una de indios y me dejaba inservible el .RC porque al salvar los recursos mezclaba las lineas de texto de los mismos y armaba una gordísima. Además me parecía una barbaridad tener instalado el Borland C++ 5.01 si realmente usaba para compilar xHarbour la versión gratuita del Borland C++ 5.5.

Con el editor de recursos de PellesC tenía basicamente un problema: no era capaz de leer los .RC que el editor de recursos de Borland pero si leía bien los .RES. Sin embargo al leer un .RES, salvarlo como .RC el compilador de recursos de Borland no tragaba y me daba error.

La solución a todo esto es un poco enrevesada, pero basicamente consiste en editar los .RC con el PellesC y usar su propio compilador de recursos para generar el .RES que luego el link de borland meterá en el ejecutable.

Lo primero es tener un .RES, abrirlo con el PellesC y guardarlo como .RC. Si te creas un .RC desde cero con el PellesC tambien sirve. Antes de compilar con el MAK de la aplicación hay que generar el .RES y esto se hace de la siguiente manera:

pellescbinporc /Ipellescinclude2 programa.rc

Como los ficheros de cabecera de PellesC están en varios directorios los he copiado todos a un subdirectorio que se llama include2… ya dije que era una chapuza.

Luego hay que editar el .MAK de la aplicación para decirle que no use el compilador de recursos de Borland y que enlace directamente el .RES que acabamos de generar. Esto se hace comentando estas lineas:

# Application directories & filenames ########################################
...
#APP_RC   = $(APP_RES_DIR)$(APP_NAME).rc
...
# Borlanc directories & flags ################################################
...
#BORLANDC_RES_EXE     = $(BORLANDC_EXE_DIR)brc32.exe
...
# Explicit Rules #############################################################
!if $(RES_FILE) == YES
#$(APP_RES) : $(APP_RC)
#   $(BORLANDC_RES_EXE) -r $**
$(APP_EXE) :: $(APP_RES)
@if exist $(APP_EXE) $(DEL) $(APP_EXE) > nul
!endif

Y con esto he desinstalado el Borland C++ 5.01. PellesC se puede descargar desde http://www.smorgasbordet.com/pellesc/. Si alguien prueba esto y quiere compartir sus experiencias estaré encantado de leerlas.

fivewin.info

Fivewin.info es – era – una de las mejores webs sobre Fivewin. Mantenida por Patrick Mast, recogía noticias sobre Fivewin, aportaciones del autor de la web y de otros usuarios a Fivewin. Desde hace meses está sin actualizar. Patrick tomó la decisión de participar empresarialmente en xHarbour.com y ha dejado de mantener la web, algo por otra parte totalmente entendible. En un futuro próximo xharbour.com pretende ser competidor de Fivewin con su propio GUI y Fivewin.info era uno de los puntales de Fivewin. Lo bueno de Fivewin.info era que tenía actualizaciones casi a diario y eso creaba un gran sentimiento de comunidad. Todos los fivewiners teniamos un sitio de referencia donde aparecían las noticias más importantes de nuestro entorno de desarrollo favorito.

Han surgido otros intentos de hacer portales basados en lenguajes xbase como Olivares2000 y Puertosur, pero, siento decirlo, no es lo mismo. Quiza sea porque estos dos sitios están restringidos a usuarios en español, pero desde que Fivewin.info dejo de actualizarse parece como si hubiera menos usuarios de habla inglesa de Fivewin o es que los que hay hacen menos ruido que antes. Una cosa que no entiendo es porqué Antonio Linares no crea un sitio parecido… creo que es un error de estrategia monumental. Lo cierto es que Fivewin ha perdido apoyos importantes y eso a la larga puede pasarle factura.

Una cosa que me hizo mucha gracia las primeras veces que visité Fivewin.info fue la foto de Patrick en la portada. Luego comprobé que era de mucha utilidad: en la reunión de Olivares2000 en Marbella iba hablando con Manuel Calero hacia la sala donde se iba a celebrar la reunión y vi dos hombres con bigote dentro de la sala. Uno era Patrick, lo conocí enseguida por la foto de su web, y le pregunté a Manuel quien era el otro. Me contestó: Antonio Linares. Vaya, pensé, conozco antes a Patrick que al padre de la criatura. Antonio, creo, no tiene ninguna foto en su web.

saturación

Recuerdo que cuando terminé la carrera era un lector voraz de revistas de informática. Todos los meses me gastaba unos buenos cuartos comprando Binary, Datamation y Chip. Además siempre caía alguna PcNosecuantos y me leía todas las revistas todos los meses. Unos años después estuve suscrito a DataBased Advisor y Clipper Advisor. Dejé la suscripción pero seguí comprando revistas, normalmente Byte España y alguna de PC’s.

Este més no he comprado ninguna revista de informática, aunque debería decir de PC’s porqué de informática creo que no queda ninguna, y la única revista por la que pregunto a mi kioskero es … esta.