Un clon, por si las moscas

Que ciertas empresas pueden traicionar (o defraudar) a la comunidad sin previo aviso es algo que muchos sabemos desde hace mucho tiempo. Desgraciadamente, aun sabiéndolo, solemos olvidarlo o restarle importancia.

Uno de los ejemplos históricos más claros fue el de Sun Microsystems, que aunque impulsó fuertemente el software libre, también hizo lo contrario en los últimos años antes de ser fagocitada por Oracle. Y Oracle, claro está, fue peor aún. Otro ejemplo no tan recordado fue EyeOS, de mi “queridísimo” Pau García Milà (me robaba la comida en la oficina, aparte de programar como un chimpancé y enseñarnos el culo cuando se dignaba a pasar por las oficinas de Bananity).

Recientemente ha habido otro caso muy sonado, en el que Apple ha hecho desaparecer sin previo aviso los repositorios completos de FoundationDB en Github. Este no será nunca el caso de ColorSharp, ni el código es tan apetecible para una macrocorporación, ni yo permitiría que algo así sucediera. Sin embargo, visto lo visto, es mejor tomar precauciones: Github podría perder sus datos por un accidente, cerrar por algún problema económico (aunque no es creíble a corto plazo), censurar algunos repositorios (como de hecho sucedió, por tener que aplicar ciertas leyes estadounidenses)…

Por eso mismo he decidido mantener un mirror del proyecto en Gitlab: https://gitlab.com/Litipk/ColorSharp . Puntualizo, aunque el código de Gitlab es libre (a diferencia del de Github), me fío tanto de ellos como de los primeros. Que el código sea libre no los hace menos vulnerables a los problemas que he mencionado. Este clon no es para saltar de Github a Gitlab, sinó mas bien asegurar que habrá como mínimo un mirror. Y me estoy planteando crear otro en Bitbucket.

Apuntes y reflexión breve

Buenas.

Desde hace unas dos semanas no ha habido demasiado movimiento en el desarrollo de ColorSharp. Sin embargo han sucedido suficientes cosas como para que valga la pena escribir sobre ello.

En la entrada anterior comenté como había realizado algunos esfuerzos para ponérselo fácil a la comunidad y que alguien se animara a contribuir al proyecto. A lo que comenté, debo añadir que también creé una lista de correo para quien quiera discutir sobre lo que sea más pausada y organizadamente de lo que permite un chat tipo IRC.

De momento, tanto la sala de chat como la lista de correo están completamente muertas. Es normal, el proyecto sigue sin ser conocido y es de nicho, además de estar relativamente verde todavía. Considero que la estructura y el plan de desarrollo permitirán que la biblioteca supere en flexibilidad y funcionalidad a las otras bibliotecas de conversión de color que existen para .NET (de hecho ya las supera en algunos puntos), pero de momento lo conseguido sigue siendo insuficiente.

Continuando con el asunto de la actividad, por suerte no ha sido todo malo. Añadí mi proyecto a la página de Up for Grabs, y, oh casualidad, al día siguiente tenía un “pull request” pendiente de revisión para ColorSharp🙂 . Debo decir que aun no lo he integrado porque tengo que hacer más pruebas, pero debería darme brío para no desanimar al colaborador recién llegado. Además, me sorprendí viendo en mi buzón dos emails de dudas relativas a ColorSharp, aunque fueron enviados a titulo particular y no a la lista de correo. El asunto de los canales de comunicación debe ser tratado.

Otro punto que tenía pendiente hasta hace nada era la documentación. Finalmente he rellenado la wiki con explicaciones sobre la estructura de ColorSharp y como usar el proyecto.

Si nos fijamos en los artículos anteriores, podemos ver que mucho de lo que he comentado y me he propuesto sigue en el limbo. La creación de comunidad y asegurar que la experiencia “out of the box” es buena han sido los puntos que más han centrado mi atención la mayor parte del tiempo.

Parece mentira, pero pequeñas sutilezas pueden marcar una diferencia enorme en la actividad del proyecto y en la percepción que se tiene de él. Por ejemplo, actualmente tengo una lista TODO en un fichero dentro del repositorio, desde luego eso es mejor que nada, pero por muchos motivos es subóptimo.

Mi próximo movimiento, antes de tocar una sola línea de código, será mover toda esa información al bugtracker de Github. Esto servirá no solo para visibilizar la necesidad de “mano de obra” sino también para obtener una mejor visión sobre el progreso del proyecto.

Saludos!

Nueva versión: 0.10.0

Buenas🙂 , aquí llega una nueva versión con novedades interesantes, tanto en la gestión como en la propia biblioteca.

Mejoras en la gestión del proyecto

En primer lugar, estoy haciendo algunos esfuerzos para facilitar que desarrolladores externos puedan y/o quieran contribuir al desarrollo de ColorSharp.

El primer cambio interesante, aunque ha supuesto ningún esfuerzo, es integrar el repositorio de ColorSharp en Github con el servicio Gitter; desde ahora ColorSharp tiene una sala dedicada de chat, tipo IRC. Se puede acceder a este chat a tanto a través de su página web como a través de diversas aplicaciones móviles.

Otro cambio menor es que finalmente tenemos una guía para contribuir al proyecto. Es muy probable que esta guía tenga que cambiar mucho dado que hasta ahora ColorSharp ha sido un proyecto fundamentalmente unipersonal.

Como extra, y por el momento sólo de forma experimental, estoy empezando a trastear con Gitcolony para gestionar la revisión de commits y “pull requests”. Parece una herramienta muy interesante (aunque privativa😦, todo sea dicho) para gestionar las revisiones de código de forma más o menos automatizada y bien organizada.

Cambios interesantes

  • Añadidos los illuminants B, C, D50 y D55.
  • Añadida una clase para generar espectros lumínicos de cuerpos negros para una temperatura dada.
  • Añadidas las funciones de matching de 1964 (10º) de la CIE.
  • Reemplazado las funciones de matching ed 1931 (2º) de la CIE con datos más precisos.
  • Mejoras menores en la conversión espectro->color:
    • Separadas las estrategias de conversión espectro->color de las estrategias para conversiones color->color.
    • Ahora es posible escoger entre las funciones de matching de 2º y 10º.
  • Mejorada la documentación XML.
  • Eliminada la dependencia de la biblioteca MathNet.Numerics.

Ideas que han surgido sobre la marcha

Durante estos días en que he estado realizando los cambios de esta versión he descubierto un proyecto muy interesante: Public Lab, en especial uno de sus subproyectos, Spectral Workbench. Esto me ha hecho pensar que podría ser interesante integrar en la biblioteca una forma de interactuar con la API de Spectral Workbench para importar o exportar espectros.

Bien, de momento no hay muchas más novedades que comentar. Os dejo con esto, y como siempre, os invito a colaborar🙂 , y más ahora que os lo estoy poniendo más fácil.

Nueva versión: 0.9.1

Buenas,

hoy he liberado una nueva versión de ColorSharp (0.9.1). La lista de cambios no es demasiado larga, son los siguientes:

  • Añadido el espacio de color CIE UVW (1960).
  • Conversiones menos destructivas (ahora la información se preserva mejor)
  • Ahora los métodos ToSRGB, ToCIExyY y ToCIEUVW son virtuales y no abstractos para reutilizar código y facilitar la implementación de nuevos espacios de color. Esto se puede hacer gracias a la centralidad del espacio CIE XYZ (1932) dentro de la teoría de colorimetría.
  • Actualizada la dependencia MathNet.Numerics.

No hay mucho más que contar al respecto. Como siempre, os animo a colaborar y a preguntar si tenéis dudas🙂 .

Saludos!

P.D. (Edición posterior) :

Después de liberar la versión 0.9.1 he introducido dos ligeras novedades en el desarrollo y distribución de ColorSharp:

  • Ahora también distribuyo los paquetes de NuGet a través de Github (en la sección releases), para no depender exclusivamente de nuget.org . Esto puede ahorrar muchos quebraderos de cabeza si la biblioteca se usa para desarrollos empresariales y nuget.org falla.
  • Por fin he añadido soporte a Travis CI🙂 , antes era relativamente complicado, se tenía que trampear un poco el sistema, pero desde hace poco se le da soporte (beta) a Mono. Con este cambio todos los commits dispararán la ejecución de los tests dentro del entorno de integración contínua. Esto sirve para facilitar la integración de código ajeno (reduciendo el tiempo necesario de revisión), y para que cualquiera pueda hacerse una idea sobre la calidad del código sin tener que ejecutar sus propios tests.

Aproximación tímida a Pash

En el artículo anterior mencioné Pash sin entrar demasiado en los detalles sobre su desarrollo. Como ya comenté, esta herramienta me interesa debido a que puede llegar a ser crucial para el desarrollo de software libre ligado a Mono y otras tecnologías .NET.

Ayer creé una entrada para Pash en la AppDB de Wine (y soy el mantenedor oficial de ésta), además de un un “test”. Todas las pruebas que hice concluyen que Pash funciona relativamente bien en Wine (usando el reemplazo basado en Mono que proveen para .NET), salvo por unos mensajes de debug bastante molestos cuando se inicia la aplicación, y que reproduzco aquí (donde escribo [...] significa que se repite más de lo mismo):

fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:GetProcessWorkingSetSize (0xffffffff,0x153e92c,0x153e930): stub
fixme:win:RegisterDeviceNotificationA (hwnd=0x14b270, filter=0x253e5dc,flags=0x00000001) returns a fake device notification handle!
[...]
fixme:win:UnregisterDeviceNotification (handle=0xcafecafe), STUB!
fixme:win:RegisterDeviceNotificationA (hwnd=0x14b270, filter=0x253e5dc,flags=0x00000001) returns a fake device notification handle!
fixme:win:UnregisterDeviceNotification (handle=0xcafecafe), STUB!

Dichos mensajes de debug son de Wine, no de Pash (comprobado con el buscador de Github). Todavía no he reportado ningún bug porque tengo que asegurarme de qué consideran bugs y qué no en el equipo de desarrollo de Wine.

Sea como sea, parecen buenas noticias que funcione así de bien a la primera, las funcionalidades que he probado son:

  • Variables locales
  • Constantes globales de valores de verdad
  • Asignaciones
  • Comparaciones entre números
  • Operadores numéricos básicos
  • Operadores booleanos básicos
  • Llamadas simples a programas
  • Impresiones por pantalla
  • Ejecución de scripts simples externos.
  • Condicionales simples if-else .

Saludos!

P.D.: Agradeceré enormemente a quien se anime e integre Pash en Wine! xD.

Ahora es más fácil desarrollar con Mono

Buenas🙂 ,

parece que desde hace unas semanas el equipo de Xamarin se ha puesto las pilas y ha levantado repositorios públicos de paquetes para distintas distribuciones Linux, con lo que se ha facilitado bastante el desarrollo con las últimas versiones de Mono y Monodevelop (por ejemplo, yo tuve que compilar Mono y Monodevelop para poder trabajar cómodamente en el desarrollo de ColorSharp).

Hay repositorios para: Debian y derivados (como Ubuntu); Redhat, CentOS y Fedora; y también para SuSe y SLES.

Aquí está la página donde explican el proceso en pocos pasos para cada distribución: http://www.monodevelop.com/download/linux/ .

Además de los últimos paquetes de Mono y Monodevelop, también proveen el gestor de dependencias NuGet. Echo en falta que añadan también paquetes de Pash (un clon libre de PowerShell) en el repositorio, pero sigue siendo un gran paso.

Sobre NuGet y Pash

La dependencia que tiene ColorSharp de NuGet es casi evidente para los desarrolladores habituales de .NET. Por el momento solo distribuyo paquetes NuGet (todavía queda pendiente crear paquetes específicos para distribuciones Linux) y por otro lado también lo uso para obtener las dependencias de ColorSharp.

Pash no es tan importante para el trabajo que estoy desarrollando actualmente, pero cabe la posibilidad de que llegue a serlo. Desgraciadamente NuGet permite que sus paquetes incorporen scripts de PowerShell que se ejecutan durante (o al final de) el proceso de instalación. Esto hace que sea más complicado conseguir que nuestro código sea realmente multiplataforma si por casualidad cometemos el error de usar como dependencia uno de esos paquetes malditos.

De hecho, Monodevelop incorpora una versión modificada de Pash para mejorar la integración del IDE con NuGet (que aunque supuestamente bajo el auspicio de la fundación Outercurve, su desarrollo está demasiado ligado al de Microsoft Visual Studio).

 Otro problema que sigue pendiente en NuGet es que no da soporte a la operación ‘pack’ en entornos Linux (y creo que tampoco en Mac OS X, pero no lo puedo probar). Esta operación es la que se usa para crear los paquetes que he mencionado anteriormente. Esto no hace que ColorSharp sea menos libre ya que se pueden compilar los binarios a partir del código fuente usando solo herramientas libres, sin embargo está claro que dificulta y hace más incómodas ciertas tareas básicas del desarrollo de software.

Lo dicho, NuGet APESTA. El acoplamiento que existe entre esta herramienta y MS Visual Studio es horroroso, y cuando uno intenta hacer cosas ligeramente sofisticadas se encuentra con que son imposibles o se tienen que tocar a mano ficheros generados (y modificados) de forma automática, lo cual es una mala idea a todas luces. PIP, Gem, Composer, NPM, Bower y muchos otros sistemas del estilo le dan mil vueltas a NuGet. Esta gente no sabe trabajar con la comunidad.

Sobre compatibilidad cruzada

A lo largo del desarrollo he realizado algunos experimentos interesantes. Hasta el momento he conseguido ejecutar programas compilados en Windows (que usan ColorSharp como dependencia) en Linux a través de Wine; y viceversa, he podido ejecutar esos mismos programas compilados en Linux dentro de Windows a través de Cygwin. No he conseguido hacer funcionar el programa dentro de cygwin dentro de wine, ni dentro de wine dentro de cygwin: una lástima, habría sido divertido.

También he experimentado con NuGet dentro de Wine. No he conseguido nada debido a la dependencia de PowerShell. Sería bonito que Wine hiciera con Pash lo mismo que hizo con Mono, usar el proyecto libre para suplantar a la versión privativa y nativa de Windows, sin embargo no es así. Añado que ReactOS tampoco está por la labor😦 , tienen problemas mucho más graves que resolver.

Slow progress, but still advancing

Hi!

ColorSharp development has stalled in recent weeks, but there are minor improvements that deserve mentioning. In few words, there is more flexibility.

  • There are new constructors in the RegularLightSpectrum class.
  • Added HashCode and Equals methods to the spectrum classes, this is a requirement to make possible using spectrum instances in dictionaries and other similar data structures.
  • Minor (not significant) performance improvements.
  • Updated MathNet.Numerics dependency.

In a few days I’ll start again providing improvements to the library. In recent posts I’ve talked about performance, but I’ll prioritize architecture improvements (towards objects immutability and common interfaces implementation) and colour features extraction.