Programación

xharbour and dotnet

por

La semana pasada participé en un debate en la lista de noticias de xharbour. El tema inicial era un anuncio sobre un lenguaje xbase para la plataforma .Net pero luego se volvió bastante interesante, y trata sobre el porqué de mi interés en mono.

Massimo Belgrano: Seem that vo is near to the dotnet version http://www.vulcandotnet.com/. Any plan for xharbour dotnet version also for commercial distribution?

Marek Paliwoda: It seems they have also a Linux version running under Mono … If that’s true it is very likely that Vo will become a «killer app» for all other xbase products 🙂 .

I do not know about any attempts or plans to make xh for NET at this moment. I am affraid nobody is interested in such a version currently. Maybe something will change in a future …

Till that moment, all xbase developers interested in NET, can choose CuleNET or wait for an upcoming Vulcan.NET 🙂 .

José Luis Sánchez: I apologize.

VO a ‘killer app’ ?

I think that VO was the app who killed the best programming language developed ever for personal computers. And we are lucky that [x]Harbour guy’s returned it to live.

Marek Paliwoda: Not VO – Vulcan.NET

> I think that VO was the app who killed the best programming language developed ever for personal computers.

Maybe – if you are talking about *old* VO. But it is an over-simplification IMO. Look at VO community – seems to be bigger than xh community. How can you explain this taking info account that «VO killed the best language» ?

> And we are lucky that [x]Harbour guy’s returned it to live.
Undoubtly.

However look around – how many *new* developers are deciding to enter the xbase world, either with xharbour or other Clipper like products ? My observations are – very, very few. xbase becames niche – smaler and smaler. And xh did not change much in this trend. Maybe Vulcan.NET or CuleNET (or xh.NET) will ?

Tim Stone: Perhaps … but .NET products are still struggling. I’ve been involved in testing several and performance is very slow. I know a lot of work is going into .NET development, but I’m not sure how many «end products» are being embraced at this time.

I can see it more for document sharing and processing, but true database work relies on fast performance.

Marek Paliwoda: You may or may not believe, but here almost *all* new products from firms I have contacts with, are NET based. I doubt elsewhere is differently.

> I can see it more for document sharing and processing, but true database work relies on fast performance.

This is a very personal point of view. Mine is that true database work depends on a good database engine and a very good database project. NET helps building modern and rich user interface. All the rest (well, almost all) is done on a backend (database engine).

Thanks for sharing your opinion.

José Luis Sánchez: I don’t know which community is bigger, but I’m sure that if CA didn’t buy Nantucket now we would have a big community.

I really think that .Net is comming a mature environment, and with mono you can do development for Windows and Linux. In fact, I’m beginning with .Net framework and my goal is develop with mono in Linux in a couple of years. But I will learn C# for this, once I decided to jump to mono I will play the game with their own cards.

Marek Paliwoda: I went this route years ago. It was an amazing journey and I never regreted. I had to learn *lots* of things about NET : CLR, ASP.NET, assemblies, code security etc. One of the things I’ve learned is that *it doesn’t really matter* what language you choose to write NET apps. Language in NET is mostly «a sugar». That’s NET which gives you the power – not the language. You choose the language you preffer to utilise NET power. That’s why CuleNET and Vulcan.NET are important IMO. They open NET for us using our prefferd xbase syntax. While this does not guarantee that new programmers will choose xbase way to play with NET, it certainly opens new posibilites for those used to «old» Clipper, VO, Xbase++, etc. Xh gave us the hope for a very short amout of time unfortunately, due to amazingly quick technology progress.

The fact is that «old xbase world» is die-ing. And this process happens quicker and quicker. Will CuleNET and Vulcan.NET change this ? I don’t know … but I hope yes.

I wish I am wrong in my opinions.

Thanks for taking your time in this discussion.

José Luis Sánchez: I don’t think xbase world is die-ing. I develop shareware and for me xHB is the perfect lenguage, but I want to learn a new framework that give me new perspectives about my profession. I’ve decided learning mono but I will not leave xHB. I want to try for myself things like NAnt, NUnit that I can’t use with xHB.

Ron Pinkas: Can you please explain, what in your opinion is standing in the way of the xHarbour developers, prohibiting the support any new technologies?

IOW, what makes it so much easier, for the developers of any other development product, to support that «quick technology progress», to the point that xHarbour will simply not able to compete, beyond a «very short amount of time»?

I for one, see xHarbour as an amazingly powerful, modern, open, development tool, which has a track record, showing how quickly it can embrace and support, new technologies, platforms, etc..

Marek Paliwoda: Complete lack of interes from those who would be able to keep xh «up to date» due to their enough knowledge and desire. Sorry Ron, xh is descendant of hb. Hb had around 30 developers (AFAIK), xh has around 50 developers. How many of them *really* develop xh ? How many of them can devote all their time for xh ? How many of them are familiar with
new technologies and with xh internals (I am talking about *deep* knowledge here) ?

Before you will try to answer, please consider the fact that lately you were looking for voluntiers to take care of orphan xh modules like regex, hashes, network funcs, etc … without success so far 🙁 (hope this will change).

It seems to me those from other products had found talented individuals from which they created a development teams which work full time on their products. This is different than in xh.

Long ago I was conviced that OpenSource model of development is better than comercial. Now I think quite the oposite way. It is much easier for comercial companies to find talented individuals. This is a simple matter of economy 🙂

> I for one, see xHarbour as an amazingly powerful, modern, open, development tool, which has a track record, showing how quickly it can embrace and support, new technologies, platforms, etc..

Yeah … , like COM/OLE for example … This technology is more than 10 years old. I couldn’t call xh support for it even «basic» 🙂 . No type information, no support (or wrong support) for some COM types (like SAFEARRAY’s), no support for parameters by ref, no support for events/callbacks, no activex support, no support for DCOM, etc.

Sure, You couldn’t write anything other than that. Besides everything, you sell xh 🙂 .

Ron Pinkas: Marek,

People may be slow to take responsability, yet they are more than happy to contribute, as you well know. Additionaly, primary contributions seem to come from NEW Individuals, as they step forward to take advantage for new technologies that THEY NEED. This is how most great contributions arrived to xHarbour, and why we have some 50 developers.

Maybe you should ask yourself WHY is it, that I sell xHarbour, why are you here, and why are so many other tremendously creative developers [of
«main-stream» languages] here?

Marek: I mentioned about COM/OLE not because it’s something new (in fact I wrote it’s an old technology), but because having a working COM/OLE support would allow as at least using NET components thru NET/COM interoperability. Much like VFP and VO do. Sure it would be some kind of «hack» but better than nothing 🙂 – I am not sure if you realise that having xh for NET will reguire to rewrite xh almost from *scratch* if you want to have pure NET solution … Taking into acount that even an old technology is not well supported in xh I think it’s quite resonable to assume that the new one will have similar problems. You may or may not agree with this. Please note I am not against xh – I am still going to play with it 🙂 . But this does not mean I do not see xh problems (IMO),
and I am looking at other options also (CuleNET, Vulcan.NET).

…

El hilo completo se puede seguir en news://news.harbour.com

entrevista con Roberto López

por

Hace unas semanas se produjo un gran revuelo con el anuncio por parte de Roberto López de que MiniGUI pasaba de tener una licencia GPL a ser freeware, aunque posteriormente hubo una rectificación dejando de nuevo la licencia como GPL pero con la advertencia de su creador de que no aceptaría colaboraciones. Este hecho produjo un cierto revuelo, llegando el tema a ser barrapunteado.

Ante esto decidí ponerme en contacto con Roberto, quien amablemente respondió a mis preguntas.

La primera pregunta es obvia: ¿ que ha pasado con MiniGUI ? ¿ Porqué el cambio de licencia GPL a Freeware y vuelta atrás a GPL ?

Es lo que he explicado en dos comunicaciones a través de mi sitio el 16 y 23 de Julio.

En pocas palabras, lo que sucedió, es que algunos usuarios muy cercanos al proyecto (moderadores del foro de discusión en Inglés) decidieron publicar una versión alterna de MiniGUI, conteniendo contribuciones de código que habían sido rechazadas por diversos motivos. Los más notorios fueron, incapacidad o falta de interés de sus autores para solucionar problemas en su código, no preservar la compatibilidad con versiones anteriores de sus propias contribuciones, no respetar reglas básicas que permitan mantener la consistencia con el diseño general de la librería, etc.

La primera publicación de esta versión alternativa llevó la denominación 107, presentándose como una continuación de mi trabajo (mi última publicación hasta ese momento había sido la 106a).

Cuando tomé conocimiento de esto, supe, que como autor de la librería, tenía el derecho y el deber, de proteger mi trabajo y a los usuarios que confiaron en él, de acciones de este tipo.

Mi primera iniciativa fue la de publicar la librería (a partir de la versión 2.0) como Freeware, lo cual protegería el código de modificaciones inadecuadas, manteniéndola libremente disponible y gratuita.

Una parte importante de los usuarios, consideró que la no disponibilidad del código fuente, podría llevarlos a tomar la decisión de no continuar usando MiniGUI a partir de la versión 2.0.

Los motivos que expusieron, fueron, en algunos casos muy atendibles, por lo cual decidí tomarme un tiempo para considerarlos.

Finalmente, decidí volver a publicar la versión 2.0, ahora, de la misma forma que siempre (GPL+’Harbour Exception’), pero sin aceptar nuevas contribuciones de código.

En un mensaje reciente en tu página web dices «dejaré de aceptar nuevas contribuciones de código en todas sus formas». ¿ Has tenido problemas con las contribuciones de código ? ¿ No crees que de esta manera vas a reducir tu comunidad de usuarios ?

La primera parte de la pregunta la he respondido en el punto anterior.

En cuanto a los usuarios, si algo he aprendido en estos años, es que no es posible tomar decisiones que satisfagan a todos.

Algunos considerarán que mi punto de vista es el más acertado y continuarán usando mi versión de MiniGUI, otros creerán que alguna otra alternativa les es más conveniente y ya no contaré con ellos como usuarios. No está mal que sea así y no estoy preocupado por ello.

En la versión 2.0 incluyes en el paquete Harbour y el compilador MingW. ¿ Puedes explicarnos porque Harbour y no xHarbour y el motivo del cambio de compilador C ?

En cuanto a Harbour, cuando el proyecto se dividió, me pareció más razonable la posición de quienes opinaban que debían concentrarse los esfuerzos en completar el trabajo y hacerlo lo más estable y confiable que fuera posible, en lugar de extenderlo, cosa que debía hacerse en el futuro, eventualmente, una vez finalizada la primera versión.

Esta es solo una opinión de usuario y no pretendo influenciar ni molestar a nadie con ella.

Respecto del compilador de C, hace algún tiempo, un usuario de las primeras épocas de MiniGUI (Lorenzo Fiorini) me llamó la atención sobre la licencia de BCC (que hasta ese momento yo creí completamente gratuito).

No soy un especialista en licencias, pero, es bastante claro que BCC tiene serias restricciones en cuanto al uso que puede hacerse del compilador y de los ejecutables generados con él, lo cual es claramente contrario al espíritu de Harbour y al de MiniGUI.

Desde entonces, MingW, surgió como la alternativa ideal, ya que puede distribuirse libremente y los ejecutables generados con él no están sujetos a restricción alguna.

Yo realmente soy un profano en el uso de MiniGUI, ya que he usado Fivewin desde casi sus inicios. He probado MiniGUI y me ha sorprendido la facilidad de
su sintaxis y que está todo perfectamente ensamblado para comenzar a programar en 1 minuto. ¿ Que ofrece MiniGUI a gente como yo ? ¿ Crees que MiniGUI puede competir con los GUI visuales de última generación como Xailer o VXH ?

MiniGUI comenzó como un experimento en Diciembre de 2001, cuando la
crisis aquí, me dejo con mucho tiempo libre que decidí usar para iniciarme en el uso de la interfase Harbour-C.

Nunca fue pensado como un producto que pudiera competir con algún otro.

Yo solo quería una herramienta, que tal como el Clipper original, me permitiera, como programador, concentrarme en el problema a resolver y no en las complejidades del lenguaje utilizado para resolverlo.

Eso es todo lo que MiniGUI ofrece.

Muchas gracias Roberto, y mucha suerte en esta nueva etapa de MiniGUI.

and the winner is…

por

Después de una semana de vacaciones he vuelto y he visto la relación de nombres propuestos para el programa. Esperaba contestación de alguno de los incondicionales del blog y algo más, como así ha sido. Sobre el nombre, después de leer las propuestas creo que me quedo con la mía, pero vamos a repasar los nombres propuestos:

Sergio propone alejandría. El nombre me gusta, pero lo veo poco trabajado, es un nombre muy a bote pronto.

Lo mismo digo de Biblios propuesto por Antonio Almaraz.

Jepnov propone DocWher … no me gustan los nombres en inglés para los programas. Lo siento.

Memofe propone Musaeum … a mi los nombre en latín me pierden, pero no lo veo fácil de recordar. Agradezco mucho la explicación sobre las bibliotecas, me fascina la gente que sabe Historia.

Pepe propone DocBlog… no me gusta. Inglés y no recordable. Luego propone DocFinder – que no es malo – y PathFinder. DocFinder es bueno, pero me gustan los nombres en castellano.

Juanjo se deja llevar por la moda. Docu.men.to no es malo, pero no es original.

José Alberto propone varios nombres interesantes. Sobre Ptolomeo, Calímaco e Hipatia… pues lo mismo que con Musaeum. Le pones un nombre de estos al programa y acaban llamándole ‘el programa ese’ porque no se acuerdan del nombre. Los nombres en inglés… sorry. Los otros dos, pues no es una biblioteca lo que propongo catalogar, sino una hemeroteca.

El nombre de Ycaña… uffffff. No comments, que luego me dicen que hago amigos en todas partes.

Así las cosas veo difícil un ganador, por lo que opto a dejar el premio desierto. Agradezco a todos los participantes vuestra colaboración y os he enviado la última beta del programa. Esta beta es operativa y no tiene restricciones, aunque le falta todavía por terminar todo el tema de listados.

A todos esto el nombre elegido para el programa – un gestor personal de documentos – es:

Azeta

El nombre es corto, fácil de recordar y relacionado con la materia que maneja el programa. ¿ Os gusta ?

alanit naming contest

por

Estoy trabajando en el programa que será el sustituto de Hemerot. La nueva versión del programa pretende ser un gestor personal de documentos, que sirva tanto para organizar una hemeroteca como para saber donde guardas todos los documentos que bajas de internet o que generas tu mismo. En un post anterior ya puse unas pantallas del programa pero pasaron desapercibidas.

Para cada documento se guarda su título, un código, la materia, el tipo de documento, idioma, publicación número de páginas, autores, palabras clave, ubicación, fichero o sitio web, y un resumen. Tiene tablas auxiliares de materias, autores, publicaciones, palabras clave, tipos de documentos y ubicaciones. De todo esto se puede ver que documentos hay. Además tiene generador de listados, asistente de búsquedas y muchas cosas más.

El caso es que he decidido que el programa tenga un nuevo nombre y es lo que ahora mismo me hace falta. Antes de tomar una decisión me gustaría recibir propuestas de nombres para el programa, por lo que lanzo un concurso de nombres. Los lectores que querais proponer un nombre dejar un comentario. Entre todas las propuestas seleccionaremos una a votación en un próximo post y el ganador recibirá … un paquete de licencias de todos los programas de alanit, y una recomendación mia para trabajar con los HundredMonkeys.

Como ya estoy enviando betas a un grupo cerrado de probadores, los betatesters podeis participar, pero no podeis publicar mi propuesta.

Quiero dejar claro que el resultado no es vinculante, yo tengo un nombre en la cabeza y al final decidiré entre mi propuesta y la propuesta ganadora del certamen.

windbu vs dbfdesktop

por

Desde hace un montón de tiempo he manejado mis archivos dbf con WinDbu. Es la herramienta ideal para el programador xbase, ya que practicamente emula todos los comandos xbase desde el programa y cuenta con un montón de herramientas y opciones añadidas que facilitan la tarea de programar.

El problema es que Windbu sigue siendo una aplicación a 16 bits hecha con Clipper y con un look muy de Windows95. Ignacio Ortiz, su autor, está muy volcado con Xailer y quiza ese sea el motivo de que no haya una versión a 32 bits.

Hace un par de meses me puse a buscar alternativas a WinDbu. Entre las varias opciones que encontré me gustó especialmente DbfDesktop de SenderoSoftware. Aunque tiene lagunas, me gustó mucho su interfaz y su imagen, mucho más vistosa que WinDbu. También juega a su favor su precio, 39$ frente a 80€ de Windbu, aunque tengo que reconocer que WinDbu hace más cosas que DbfDesktop.

De momento los dos comparten mi disco duro, pero la verdad es que poco a poco cada vez uso más DbfDesktop.

altas de claves ajenas

por

Una de las nuevas funcionalidades que estamos implementando de cara a las nuevas versiones de los programas que queremos tener listas a vuelta de verano es el alta de claves ajenas. Al introducir un valor que es clave ajena de una tabla, si el valor no existe en la tabla se va a poder introducir en ese momento.

Por ejemplo, en este diálogo introduzco una temática en el artículo que no está dada de alta en la tabla de temáticas:

El programa detecta que la clave no existe y avisa

y permite introducirla en ese momento

Aunque parezca una tontería, de esta manera se hace mucho más sencillo introducir grandes volúmenes de datos en los programas, porque no pierdes el hilo de lo que estás haciendo. Si estás dando de alta una artículo no tienes que ponerte a pensar en dar de alta antes la temática sino que se hace sobre la marcha.

cambios en el interfaz

por

Hasta ahora en los formularios de edición de los programas, cuando un campo podía ser rellenado en base a una tabla auxiliar en la parte derecha del campo aparecía una imagen que al pincharla permitía abrir un formulario de selección sobre la tabla auxiliar. La manera de hacer esto está explicado en un post de mi anterior blog. Un formulario típico podía ser este:

En las nuevas versiones de los programas, las imágenes a la derecha de los Get desaparecen y son sustituidas por botones, de esta manera:

El motivo del cambio es quitarnos de en medio tanto gráfico como usamos ahora para tener una interfaz menos recargada, poder recorrer todo el formulario con el teclado, incluyendo la selección de tablas auxiliares, y poder tener dos botones al lado de un campo para permitir seleccionar y lanzar un archivo, cosa que necesito para la nueva versión de Hemerot que estoy preparando y al que corresponde la imagen.

crisis, pero no tanto

por

Quizá en un post anterior pareciese que iba a dejar de desarrollar shareware, olvidarme de Windows, migrar a Linux y a volar. No es exactamente eso lo que llevo en la cabeza. Después de mucho trabajo, mio y de Jaime, creo que los programas y la web de alanit están a un nivel bueno y hay que perseverar en el tema de marketing y distribución. Después de mucho darle vueltas, de hablar con Jaime y de plantear el tema en el foro de el negocio del software hemos sacado varias cosas claras:

  • Seguir adelante con la venta de shareware
  • Seguir un modelo de negocio basado en ofrecer una versión lite gratuita y una versión de pago con más funcionalidad.
  • Intentar establecer relaciones con sitiios de cocina para que promocionen el Puchero, que es el que tiene un público más objetivo.

El cambio sobre lo que estamos haciendo ahova va a consistir en dejar de ofrecer una versión de evaluación para ofrecer una versión gratuita. La versión de evaluación es similar a la registrada, sólo que limitada en los registros a introducir. El problema es que nos está resultando difícil conseguir aparecer en revistas sobre software debido a que prefieren versiones freeware, aunque sean menos potentes que las versiones de evaluación. Lo que vende es el título programa completo o programa gratis.

Las versiones de pago van a seguir siendo las mismas que ahora, y estamos en la fase de decidir que vamos a recortar de las versiones gratuitas, para que queden programas funcionales pero que les falte ese algo que incite al registro de la versión de pago.

crisis y revolución

por

Desde hace un par de semanas llevo dándole vueltas al tema de cambiar por completo de entorno de desarrollo.

La idea de dar el salto es debida a un cambio de la asignatura en la Universidad. El año que viene daré prácticas de una asignatura que exige uso de C y de plataforma Linux. Después de hablar con los gurús del departamento, me he decidido a instalarme ubuntu en mi PCl y sinceramente creo que ha sido una buena decisión. Gracias a la guia ubuntu y a la Guia Hoary Hedgehog he comenzado a manejarme con el sistema sin mucho apuro.

Una vez decidido comenzar a dar el salto a Linux he empezado a preguntar sobre posibles entornos de desarrollo en esta plataforma y al final he decidido que voy a aprender a programar con mono. Aprovecharé que tengo que volver a programar con C para aprender C# y comenzar a usar un lenguaje de programación moderno con todas las herramientas de última generación. A ver que tal va. Ya iré contando.

El motivo de dar el salto de xHarbour+FWH a mono no es debido a ninguna carencia de los primeros. Tengo que empezar a usar Linux de forma habitual y me atrae mucho toda la parafernalia de los build diarios, pruebas de integración y demás, así que voy a investigar todo eso.

montar un tree desde una DBF con FWH

por

En el Puchero se usa una clasificación arborescente denominada clasificación francesa y para jugar con ella la monto en un tree. Como he recibido varios correos preguntando la manera de montar el tree desde la dbf, aqui lo explico un poco.

Lo primero es montar una estructura de datos que permita ser representando en forma de arbol. Un arbol no es más que una jerarquía con varios niveles, y lo que tengo en mi dbf son varios campos -hasta 5 – para indicar en que rama del arbol estoy. Los campos se llaman FrN1, FrN2, FrN3, FrN4 y Frn5 de manera que el arbol lo veo así:

(1,0,0,0,0)
···(1,1,0,0,0)
······(1,1,1,0,0)
······(1,1,2,0,0)
···(1,2,0,0,0)

Una vez esto claro el arbol se monta así:

FUNCTION FrTreeLoad( oTree )
LOCAL oDatabase
LOCAL nStep
LOCAL oLink
LOCAL oLink1, oLink2, oLink3, oLink4, oLink5
LOCAL N1	:= 0
LOCAL N2	:= 0
LOCAL N3	:= 0
LOCAL N4	:= 0
oLink := oTree:GetRoot()
SELECT FR
FR->(DbGoTop())
DO WHILE ! FR->(EOF())
···IF FR->FrN2 == 0
······oLink1 := oLink:AddLastChild(FR->FrTipo,IIF(FR->FrHoja,1,2),IIF(FR->FrHoja,1,2),.t.)
······oLink1:Cargo := Str(FR->Frn1,2)+Str(FR->Frn2,2)+Str(FR->Frn3,2)+Str(FR->Frn4,2)+Str(FR->Frn5,2)
···ELSEIF FR->FrN3 == 0
······oLink2 := olink1:AddLastChild(FR->FrTipo,IIF(FR->FrHoja,1,2),IIF(FR->FrHoja,1,2),.t.)
······oLink2:Cargo := Str(FR->Frn1,2)+Str(FR->Frn2,2)+Str(FR->Frn3,2)+Str(FR->Frn4,2)+Str(FR->Frn5,2)
···ELSEIF FR->FrN4 == 0
······oLink3 := olink2:AddLastChild(FR->FrTipo,IIF(FR->FrHoja,1,2),IIF(FR->FrHoja,1,2),.t.)
······oLink3:Cargo := Str(FR->Frn1,2)+Str(FR->Frn2,2)+Str(FR->Frn3,2)+Str(FR->Frn4,2)+Str(FR->Frn5,2)
···ELSEIF FR->FrN5 == 0
······oLink4 := olink3:AddLastChild(FR->FrTipo,IIF(FR->FrHoja,1,2),IIF(FR->FrHoja,1,2),.t.)
······oLink4:Cargo := Str(FR->Frn1,2)+Str(FR->Frn2,2)+Str(FR->Frn3,2)+Str(FR->Frn4,2)+Str(FR->Frn5,2)
···ELSE
······oLink5:= oLink4:AddLastChild(FR->FrTipo,IIF(FR->FrHoja,1,2),IIF(FR->FrHoja,1,2),.t.)
······oLink5:Cargo := Str(FR->Frn1,2)+Str(FR->Frn2,2)+Str(FR->Frn3,2)+Str(FR->Frn4,2)+Str(FR->Frn5,2)
ENDIF
FR->(DbSkip())
ENDDO
oTree:UpdateTV()
oTree:SetFocus()
RETURN NIL



Lo que hago es recorrer el DBF que tengo ordenado por la concatenación de los 5 campos y cuando cambio de nivel añado una rama al nivel inferior.


El resultado:
alanit
Powered by  GDPR Cookie Compliance
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.