c3compiler

Ayer hice el registro del compilador C3 de Bruno Cantero. El principal activo de C3 es su estabilidad. Por las pruebas que hice con la versión de evaluación, C3 es el compilador xbase de 32 bits más estable que hay ahora mismo en el mercado. Además es el más parecido a Clipper, con lo cual la migración de los sistemas desarrollados en Clipper a 32 bits es cuestión de dias. Por decirlo en plata, C3 se traga casi todo el código Clipper sin rechistar.

Manuel Calero ya ha migrado casi por completo GST+, su impresionante programa de gestión, a 32 bits con C3. Hace poco dijo que necesitaría un año para hacerlo y lo ha conseguido en cuestión de semanas. Hay una demo del programa que contiene versiones en 16 y 32 bits y se puede descargar del sitio web de Manuel.

Es posible que xHarbour sea más avanzado tecnológicamente que C3, pero lo que tengo claro es que ahora mismo pretender hacer algo con xHarbour es jugar con una caja de bombas. Es cierto que el despliegue de medios técnicos y humanos de xHarbour es impresionante, la web es una pasada, hay un montón de gente trabajando en el proyecto, cada dia inventan algo nuevo, pero… no lo veo claro. Es como estar haciendo una casa con todos los oficios metidos dentro: el electricista hace las rozas antes que el fontanero, el pintor pinta antes que el carpintero termine las puertas,… más de una vez hay que deshacer lo hecho y rehacerlo de nuevo. El poco tiempo que tengo para programar no puedo dedicarlo a hacer experimentos. Sorry, Patrick.

C3 es un clon de Clipper a 32 bits. No más, pero tampoco menos. Es cierto que C3 tiene carencias: le hace falta una buena lavada de cara a la web, la documentación está incompleta y alguna cosa más, pero creo que ahora mismo es la mejor opción. Yo voy a tomar ese camino. Tengo ya FWC3, que me regaló Antonio Linares por ajuste de cuentas pendiente, y mi intención es que este sea mi entorno de desarrollo durante este año.

hp 2175

A mediados de diciembre mi vieja impresora falleció sin previo aviso. El scanner también estaba muy malito y sólo escaneaba bien sólo la mitad de las fotos. Ante este panorama decidí – o más bien entre los dos cacharros me
decidieron – que tenía que comprar una nueva impresora. Estuve mirando precios y modelos y al final me decidí por una impresora multifunción hp 2175.

Es una de estas que imprime, escanea y hace copias. La tengo un par de semanas y estoy muy contento con ella. La calidad de impresión es buena, he escaneado un documento de varias páginas y he generado un PDF sin abrir el manual y tiene algo que añoraba en mi anterior impresora: una opción para imprimir a doble cara incluida en el driver de la impresora. Se que hay programas para hacer esto, como FinePrint y seguro que alguna más, pero creo que algo así es un valor añadido importante en una impresora.

navidad

Lo que toca hoy es desear a todo el mundo paz y felicidad. El que cada uno lo consigamos depende mucho de nosotros mismos, asi que lo que deseo es que cada uno pongamos todo de nuestra parte para ser todos más felices.

últimos comentarios

Gracias a un post de Enrique Barbeito me he enterado de la manera de mostrar los últimos comentarios en el blog. Ya está puesto, si mirais el bloque de la izquierda en la parte inferior vereis los cinco ultimos comentarios de avemundi y podeis ir a leerlos.

componentes de terceros – desde allí

La otra cara de la moneda es dedicarse al desarrollo de componentes. Mientras que hacer software de gestión es algo, más o menos, al alcance de la mayoría de programadores hacer componentes es subir un peldaño más. Pero para hacerlos y atreverte a comercializarlos hay que tener valor, mucho valor. Comercializar un control supone poner tu trabajo en manos de un montón de personas inmisericordes que te van a exigir lo imposible.

Yo colaboré con Paco García en los inicios de Canalfive. Paco hacia los controles y yo la documentación y mentenía la web. Pero lo realmente complejo era el soporte. A Paco lo freían. Paco hacia tenedores y la gente los queria usar como cucharas. Y correo va y lio viene. Era increible. Además Paco nunca decía a nadie ‘esto no se puede hacer’ y había veces que para un usuario en partícular rehacía medio control. Una locura.

Yo no soy capaz de hacer controles. Alguna vez he hecho alguno muy simple y siempre he tenido que pedir ayuda a otra gente. En eso soy bastante torpe, y por eso no oculto mi admiración por los que son capaces de hacerlo. Muchas veces intento retocar algo de otra persona y a veces lo consigo, pero la verdad es que los controles no son lo mio. El tener el código fuente de un control para mi no asegura su continuidad. Además de tener el código tienes que saber donde meterle mano y hacerlo con delicadeza.

componentes de terceros – desde aqui

Una de las cosas buenas y malas que le puede suceder a un determinado entorno de desarrollo es que cuente con abundantes componentes desarrolladas por terceros. Es una cosa buena porque enriquece el entorno, y es mala porque demuestra que al propio entorno de desarrollo le faltan controles.

La existencia de desarrolladores de componentes de terceros también demuestra que el entorno cuenta con un amplio número de seguidores que hacen rentable que otras empresas o personas – los terceros – dediquen su esfuerzo a completar el entorno con nuevos componentes. Es evidente que no existe la misma cantidad de componentes para Fivewin que para Delphi, por poner un ejemplo, de igual manera que los programadores que usamos Five somos bastante menos que los que usan Delphi.

Cuando comencé a desarrollar software utilizaba muchos de los controles de la extinta CanalFive: su grid, folders, meters y su calendario. Ahora con xHarbour lo único que uso es el calendario, debido a que no he podido – mejor dicho no he sabido – migrar el grid, los folders de Fivewin ya son nativos y toman el aspecto de XP y el meter me dio unos problemas muy raros y decidí no usarlo en Colossus.

Con esto intento plantear uno de los mayores problemas que como desarrollador tiene usar componentes de terceros: que te vuelves componentesdeterceros adicto y te puedes encontrar con problemas de compatibilidad de los componentes al evolucionar el entorno de desarrollo, lo cual se agrava si el desarrollador del componente ha bajado la persiana.

¿ Y porqué bajan la persiana ? … continuará

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:

\xharbour\bin\harbour colossus.prg  -jes_ES.hil -i\fwh24\include;\xharbour\include -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 \xharbour\utils\hbdict 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.

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.