Del dia 6 ya estaba enterado desde hace algunas semanas, se presentara con una conferencia magistral en el CiComp 07 en la UABC de Ensenada, este evento si tendra un costo.
jueves, octubre 25, 2007
Richard Stallman en Baja California
Asi es Richard Stallman estara los dias 5 y 6 de Noviembre aqui en Baja California, hoy me acabo de enterar que estara en Tijuana el dia 5 a las 3:00pm PST en el teatro Calafornix del Tecnologico de Tijuana, al parecer va a ser un evento sin costo, entrada libre.
Del dia 6 ya estaba enterado desde hace algunas semanas, se presentara con una conferencia magistral en el CiComp 07 en la UABC de Ensenada, este evento si tendra un costo.
Del dia 6 ya estaba enterado desde hace algunas semanas, se presentara con una conferencia magistral en el CiComp 07 en la UABC de Ensenada, este evento si tendra un costo.
Nota para mi ... como crear un iso a partir de un dmg en OSX
hdiutil makehybrid -iso -joliet -o isofile.iso dmgfile.dmg
Mi primer parche para Mono, toma 2
Ok, mi primer parche para Mono fue aceptado, y debido a la funcionalidad del par de clases que fueron modificadas por mi, es muy probable que los usuarios de Mono cada vez que ejecuten/compilen sus aplicaciones, ejecuten el codigo que escribi ;)
Por otro lado cuando desarrolle el parche, realice un programa con un par de casos de prueba, solo para asegurarme que mi codigo funcionara y que funcionalidad original de los metodos que modifique tambien, el caso es que ese programa de prueba yo ya no lo ejecute en MS .NET, solo en Mono, pues resulta que mi programa de prueba descubrio un "Bug" en el .NET - de acuerdo a Gert quien reviso mi parche de Mono -, y ahora existe un reporte para Microsoft para que solucione el problema, el cual aparece en .NET 2.0 y .NET 3.5, aunque existe otro reporte previo a este problema, Microsoft lo cerro indicando que ya estaba solucionado, pues resulta que no.
Definitivamente para mi fue un buen ejercicio, por haber solucionado mi problema, haber contribuido a Mono, descubrir el problema en OSX, confirmarlo en Windows, desarrollar el parche en OSX, compilarlo y probarlo en Linux y finalmente confirmarlo solucionado en OSX ;)
Bueno ahora a otra cosa ...
Por otro lado cuando desarrolle el parche, realice un programa con un par de casos de prueba, solo para asegurarme que mi codigo funcionara y que funcionalidad original de los metodos que modifique tambien, el caso es que ese programa de prueba yo ya no lo ejecute en MS .NET, solo en Mono, pues resulta que mi programa de prueba descubrio un "Bug" en el .NET - de acuerdo a Gert quien reviso mi parche de Mono -, y ahora existe un reporte para Microsoft para que solucione el problema, el cual aparece en .NET 2.0 y .NET 3.5, aunque existe otro reporte previo a este problema, Microsoft lo cerro indicando que ya estaba solucionado, pues resulta que no.
Definitivamente para mi fue un buen ejercicio, por haber solucionado mi problema, haber contribuido a Mono, descubrir el problema en OSX, confirmarlo en Windows, desarrollar el parche en OSX, compilarlo y probarlo en Linux y finalmente confirmarlo solucionado en OSX ;)
Bueno ahora a otra cosa ...
miércoles, octubre 24, 2007
Reflection falla al invocar miembros con el attribute ParamArray en Mono
Trabajando en un proyecto con Monorail, el cual estoy desarrollando desde OSX con Mono, el motor de vistas Brail fallaba al compilar una de las vistas, este problema se me presento solo con Mono, ya que en MS .NET la vista funcionaba como debia.
Investigando el problema, me di cuenta que Brail invoca por medio de reflection a los metodos que se indican dentro de la vista, y es precisamente aqui donde Brail fallaba al ejecutar; el metodo en cuestion era el metodo Create de la clase DictHelper dentro del Framework de Monorail, el cual se le pasan parametros de la forma: "property1=value", "property2=value", etc, y el metodo regresa un objeto del tipo IDictionary, este metodo acepta parametros de la forma: Create(params string args).
Params es una palabra clave de C# que permite definir un parametro especial que acepte una cntidad indefinida de parametos, por ejemplo Create esta definido come se mostro arriba, pero la forma en como lo puedo llamar es: DictHelper.Create("p1=v1", "p2=v2", "p3=v3"), es decir le paso un arreglo de parametros. .NET cuenta con un attributo ParamArray, el cual puede ser utilizado desde cualquier lenguaje, lo que sucede una vez que el programa ha sido compilado .NET toma los parametros y los convierte en un arreglo de parametros para que pueda ser pasado al metodo.
El problema de Mono es que no implementa funcionalidad para llamar mediante reflection metodos que usen la palabra clave params, pude haber creado un "bug" para reportar el problema a los desarrolladores de Mono y ya, pero al final me decidi a tratar de implementar el soporte para esta funcionalidad.
Despues de analizar como Mono invoca metodos por reflection, me fue necesario modificar los archivos Binder.cs y MonoType.cs.
El parche y programa de prueba lo envie a la lista de Mono-devel, de momento estoy a la espera de que lo revisen y me digan si lo aceptan o no.
Investigando el problema, me di cuenta que Brail invoca por medio de reflection a los metodos que se indican dentro de la vista, y es precisamente aqui donde Brail fallaba al ejecutar; el metodo en cuestion era el metodo Create de la clase DictHelper dentro del Framework de Monorail, el cual se le pasan parametros de la forma: "property1=value", "property2=value", etc, y el metodo regresa un objeto del tipo IDictionary, este metodo acepta parametros de la forma: Create(params string args).
Params es una palabra clave de C# que permite definir un parametro especial que acepte una cntidad indefinida de parametos, por ejemplo Create esta definido come se mostro arriba, pero la forma en como lo puedo llamar es: DictHelper.Create("p1=v1", "p2=v2", "p3=v3"), es decir le paso un arreglo de parametros. .NET cuenta con un attributo ParamArray, el cual puede ser utilizado desde cualquier lenguaje, lo que sucede una vez que el programa ha sido compilado .NET toma los parametros y los convierte en un arreglo de parametros para que pueda ser pasado al metodo.
El problema de Mono es que no implementa funcionalidad para llamar mediante reflection metodos que usen la palabra clave params, pude haber creado un "bug" para reportar el problema a los desarrolladores de Mono y ya, pero al final me decidi a tratar de implementar el soporte para esta funcionalidad.
Despues de analizar como Mono invoca metodos por reflection, me fue necesario modificar los archivos Binder.cs y MonoType.cs.
El parche y programa de prueba lo envie a la lista de Mono-devel, de momento estoy a la espera de que lo revisen y me digan si lo aceptan o no.
jueves, octubre 18, 2007
Tutorial de Ruby interactivo
En el sitio TryRuby se encuentra un tutorial en linea e interactivo donde se aprende como utilizar el lenguaje Ruby, sin necesidad de ser instalado localmente.
miércoles, octubre 03, 2007
Mas sobre la disponibilidad del codigo fuente de .NET 3.5
Con noticias en Slashdot como "Open.NET - .NET Libraries fo open source", a partir del anuncion de Scott, lo unico que se genera es confusion y discusiones sin sentido.
No, Microsoft no libera el .NET Framework como open source, libera el codigo para referencia, asi como los arhivos .PDB para propositios de depurar aplicaciones, como dije, el tener codigo fuente, no es la gran cosa, ya que con herramientas como reflector siempre se ha podido inspeccionar para tener mejor entendimiento, o bien se puede consultar la implementacion de alguna clase en el codigo fuente de Mono.
Aqui el unico punto importante es el acceso a los .PDBs para depuracion.
La apertura al codigo fuente de .NET, no es algo nuevo ya desde antes de la liberacion del .NET 2.0 se hablaba por parte de Microsoft de liberar el codigo fuente y los PDBs de Windows Forms.
Asi que las teorias conspiratorias sobre un plan maestro para eliminar Mono, publicadas en Slashdot, no tienen sentido; lo unico es que van tener que vigilar mas las contribuciones de codigo para evitar que se utilize el codigo liberado por Microsoft.
No, Microsoft no libera el .NET Framework como open source, libera el codigo para referencia, asi como los arhivos .PDB para propositios de depurar aplicaciones, como dije, el tener codigo fuente, no es la gran cosa, ya que con herramientas como reflector siempre se ha podido inspeccionar para tener mejor entendimiento, o bien se puede consultar la implementacion de alguna clase en el codigo fuente de Mono.
Aqui el unico punto importante es el acceso a los .PDBs para depuracion.
La apertura al codigo fuente de .NET, no es algo nuevo ya desde antes de la liberacion del .NET 2.0 se hablaba por parte de Microsoft de liberar el codigo fuente y los PDBs de Windows Forms.
Asi que las teorias conspiratorias sobre un plan maestro para eliminar Mono, publicadas en Slashdot, no tienen sentido; lo unico es que van tener que vigilar mas las contribuciones de codigo para evitar que se utilize el codigo liberado por Microsoft.
Microsoft va a liberar el codigo fuente de .NET 3.5 Framework
Scott Guthrie ha anunciado hoy, que Microsoft va a liberar el codigo fuente de la version 3.5 del Framework .NET que va a salir a finales de este año, el codigo fuente estara disponible bajo la licencia "Microsoft Reference License (MS-RL)".
Esta licencia, como su nombre lo indica, permite utilizar el codigo fuente unicamente como referencia, no es posible tomarlo, extenderlo, modificarlo, incluirlo en aplicaciones de terceros, etc.
Es decir, el .NET Framework 3.5 no se vuelve open source, como aparecio en la noticia de Dotnetkicks.
La unica ventaja que le veo a esto, es que va a ser posible depurar codigo desde el VS.NET con los simbolos y las referencias de codigo fuente del Framework, en cuanto a que sea novedad conocer el codigo fuente de las librerias para enteder su funcionamiento, pues no es nuevo, desde hace tiempo se a podido acceder a su codigo fuente con herramientas como Reflector.
Esta licencia, como su nombre lo indica, permite utilizar el codigo fuente unicamente como referencia, no es posible tomarlo, extenderlo, modificarlo, incluirlo en aplicaciones de terceros, etc.
Es decir, el .NET Framework 3.5 no se vuelve open source, como aparecio en la noticia de Dotnetkicks.
La unica ventaja que le veo a esto, es que va a ser posible depurar codigo desde el VS.NET con los simbolos y las referencias de codigo fuente del Framework, en cuanto a que sea novedad conocer el codigo fuente de las librerias para enteder su funcionamiento, pues no es nuevo, desde hace tiempo se a podido acceder a su codigo fuente con herramientas como Reflector.
Suscribirse a:
Entradas (Atom)