principal nivel superior enviar artículo buscar administrar acerca de ... rdf rss main |
from the dept. Se estuvo trabajando sobre Cython, se migro de los chroots a máquinas virtuales verdaderas, en casa con virtualbox, en la oficina con qemu. Derivado de esto se estuvo haciendo pruebas por el error raro que nos aparece al hacer una instalación limpia y compilar con cython. Al crear una nueva instancia de Debian 6 (Stable/Squeeze) se encontró que en efecto con solo llenar las dependencias de Birdcage, al usar solo cython para compilar arroja errores, no entendía el por que de este comportamiento, por lo que busque en google errores similares sin demasiado éxito. Posteriormente se me ocurrió que podría ser alguna dependencia que instalara pyrex y que por eso no funcionaba, una a una fui revisando las dependencias que sugería pyrex, probando con apt-get -s install python-pyrex que es simular que sucedería de instalarlo y además mostrar las dependencias. Llegue a instalar todas las dependencias excepto el propio pyrex y eso no lo resolvió. Curiosamente instalar pyrex y construir el modulo, para después desinstalar pyrex y usar cython si funciona, como en ocasiones anteriores se había resuelto. Sin embargo al regresar a una instalación en limpio aún sin pyrex, resultaba el mismo error, por lo que opte por revisar el FAQ[1] de cython y posteriormente la documentación[2] especialmente en como construir código con cython, de ahí encontré que los pasos que hace cython para construir los binarios, entonces di con una cosa interesante al correr cython con cada .pyx, me encontré con que automaton.pxd, genome.pxd, rule.pxd y topology.pxd[3] tenían terminadores de línea de MSDOS por lo que cython no los podía compilar regresando un error, utilice dos2unix para corregirlos y entonces encontré otra cosa interesante, al hacer cython sobre cada uno de estos archivos se obtiene un .c del mismo pase a la máquina virtual donde ya había instalado pyrex y descubrí que en algún momento configuramos que se ignoraran los archivos .c (ya que son generados al compilar). Con esto queda claro el por que no nos funciona si no instalamos pyrex, resulta que cuando resolvemos instalandolo, compilando y después haciéndolo con cython, este ultimo no borra los .c que genero pyrex y compila limpiamente, pero realmente no genera los .c, la solución para poder usar cython directamente en una instalación nueva y no hemos instalado pyrex. Primero en birdcage es necesario hacer cython *.pyx lo cual genera los archivos .c necesarios, después ya se puede ejecutar: python setup.py build y funciona correctamente. Si tenemos una instalación mixta y queremos usar cython tan solo debemos en el directorio de birdcage borrar los .c y dar cython *.pyx y entonces si, la compilación será con cython. Seguro que hay una manera más sencilla, pero se me ocurría que en setup.sh se puede añadir el paso de cython *.pyx para birdcage me comenta Ernesto que hay otras formas de hacerlo, por curiosidad cambie setup_code.py en mi VM y de pyrex.distutils lo puse a cython.distutils (supongo que tambien ahi hay que poner una condicional como en Birdcage para elegir el compilador) y ya me funciona birdcage y worldish completamente en cython, que dicho sea de paso requiere muchisimas menos dependencias que pyrex. Pendientes Darle una revisada a los archivos de las listas en linux y borrar el spam que tiene. Probar las herramientas de empaquetado Escribir un roadmap del empaquetado Empaquetar Birdcage Documentar el sistema de respaldos vía rsnapshot Leer los siguientes documentos: http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/developers-reference/ Leer sobre los cambios en la GPL3 puesto que es la licencia elegida para Birdcage http://www.gnu.org/licenses/quick-guide-gplv3.html http://www.gnu.org/licenses/why-affero-gpl.html Preguntas ¿El sistema de Intel debe seguir en producción? Al elegir GPL3 para Birdcage estamos básicamente haciendo que lo que dependa del mismo requiera la misma licencia, ¿queremos eso para worldish y derivados? Me interesa jugar con linode, ¿es posible, cuando? Por cierto http://ouroborus.sourceforge.net/ redirige aún a http://www.spacemonkey.info/ouroborus/index.html que no tiene los cambios que se han hecho en http://ouroborus.info ¿quien cambia esa redirección? ¿y/o hace que el sitio de spacemonkey se actualice del svn? < Reporte de actividades abril 2 | Reporte de actividades marzo 2011 >
|
|
|||||||||||
|
"Any system that depends on reliability is unreliable." -- Nogg's Postulate | ||
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest ©1999 Butch Landingin. |