cd /directorio/origen
export DEST=/directorio/destino
find -type d -and -exec mkdir -p $DEST/\{\} \; -or -type f -and -exec cp \{\} $DEST\{\} \;
Estos comandos sobreescribirán archivos que existen en ambos directorios, para evitar esto se podría añadir un test en el comando de copiar, que cheque si el archivo ya existe o se puede hacer una comparación de fechas.
Creo que es posible mejorar este script, postearé aquí versiones mejoradas.
]]>Estoy emocionado y espero ver que tal me va a ir. También extraño un poco a mi familia y mi hogar de toda la vida, pero ni modos, para alcanzar la iluminación es necesario que nos desprendamos de nuestros enlaces mundanos.
Bien. Como dice Bob Esponja: “¡Estoy Listo!”, veamos que me lanza la vida.
]]>Ok, un poco exagerado, pero hay tantas cosas que se pueden hacer y tan poco tiempo para realizarlas y no hay ni siquiera la másm mínima señal de que las pueda alcanzar.
Quizá sólo debiera resignarme y vivir como hermitaño en el bosque. Hmm, un bosque con Internet.
]]>Esto se llama prueba funcional, que quiere decir que se prueba el programa completo para verificar que en realidad hace lo que se espera.
Primero intenté usar DejaGNU, pero después de pasar todo el dia de ayer simplemente haciéndolo funcionar, decidí abandonar esa idea. El problema con DejaGNU es que está escrito en un lenguaje llamado “Expect” que es una extención de Tcl, y los test se deben escribir en “Expect”. No soy un gran fan de Tcl, pero realmente intenté aprender a usarlo. Después de un rato me di cuenta que escribir los test era mucho más complejo que crear el programa original, así que decidí buscar algo más simple.
Entonces dí con una página muy interesante: open source software testing tools que lista una gran cantidad de herramientas enfocadas a la prueba de software. Después de leer los manuales de algunas herramientas noté que todas ellas eran endiabladamente complejas, lo único que necesito es correr un programa y verificar que su salida es la esperada, caracter por caracter.
Y fue así como decidí crear mi propia herramienta de pruebas. Elegí Python como lenguaje y creé un pequeño sistema de pruebas en unas pocas horas (Python es un buen lenguaje). El sistema simplemente ejecuta la herramienta, le pasa parámatros o simula entrada por el usuario y lee la salida. Si la salida no corresponde a lo esperado aunque sea por un sólo carácter entonces el test se considera fallido.
Lo más interesante es que ya logré capturar un bug en mi código, y con un test muy simple. Imprimía un espacio de más en mi programa y esto fue detectado rápidamente por mi sistema de pruebas. Este error hubiera sido muy difícil de detectar sin el sistema, ya que yo no puedo ver los espacios en blanco.
Sí, he escuchado que algunos se preguntan porque no hice el sistema en “tuu”. Bueno, pues, tuu todavía no existe y además no tendría mucho sentido probar un lenguaje con el mismo lenguaje verdad? Aunque en un futuro, talves haga un sistema de pruebas basado en tuu.
]]>Ya podría convertir tuu en una calculadora de escritorio, aunque deshabilité la generación de código para acelerar un poco el desarrollo de la gramática. Aún falta que acepte definiciones de funciones y, para que sea turing-completo, condiciones y ciclos.
También he comenzado con la documentación para desarrolladores, que es generada automáticamente desde el código fuente, utilizando Doxygen. Aún no he comenzado con la documentación para usuarios, pero al menos ya puse el sitio oficial para el lenguaje: http://tuu.mixtk.com. Sí, el sitio está en inglés, desafortunadamente todo el desarrollo tiene que hacerse en inglés para que sea relevante. No importa, ¡este blog siempre será en español!
]]>