Generalizar ejecutar_tarea_xxx().
También se elimina Tarea.rechazar_si_falla y Tarea.terminar_si_falla, pasando
a ser una simple tabla de relación porque no tenía mucho sentido tanto
anidamiento de funcionalidad.
Crear clase Ejecucion y heredar Entrega y ComandoEjecutado de ella.
Para implementar las pruebas, me es muy conveniente que Prueba y Entrega tengan
una interfaz similar, y siendo que Entrega tiene prácticamente los mismos campos
que ComandoEjecutado (de quien hereda Prueba), creé una superclase que engloba
los campos en comun, Ejecucion. Es necesario regenerar la DB (una vez más :).
Agregar comentario para recordar qucorregir algo.
El tiempo de ejecución de un comando debería medir sólo la ejecución (no el
unzip, rsync, diff y otras tareas), pero por ahora uso el id de ComandoEjecutado
de forma temprana (no debería) y por eso lo creo antes.
Bugfix: no trata de guardar 2 veces el stdout/err, honra rechazar_si_falla y otros.
También evita crear un zip vacío si no hay archivos_a_guardar y honra el
Comando.terminar_si_falla.
tailor [Sun, 11 Mar 2007 22:36:04 +0000 (22:36 +0000)]
mergeador de grupos
* Pantalla para mezclar los grupos. Solo se puede acceder desde la edicion de un
curso, porque solo se puede trabajar con grupos de un solo curso.
* Crea nuevos cursos si es necesario, elimina los que quedan vacios.
* Todavia tiene algunos bugs.. Pero mas o menos anda.
Unfixes de unicode para evitar bug de Python (!?).
Saco unicode porque parece haber algún bug loco en Python con excepciones con
unicode. Ver bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1678647&group_id=5470&atid=105470
Cambiar RET_FAIL para que sea signal-friendly.
Si retorno es negativo, se espera que el programa termine con una señal de
número igual a -retorno. Por eso RET_FAIL mejor definirlo con un valor inválido
para señales.
Modifico permisos en Enunciado y Ejercicio para que un Entregador pueda consultarlos.
Los permisos ahora por default son para entregar y todos los metodos administrativos fueron
cerrados para admin. El Entregador solo puede listar y show y de esta forma puede bajar los
enunciados, ver las fechas de entrega, etc. Se ocultan columnas de las tablas que no son necesarias
y se sacan links cuando el usuario no es ADMIN.
Mejorar función unzip().
Ahora unzip() soporta un parámetro extra, que es un diccionario que indica donde
descomprimir ciertos archivos en particular, si no se los quiere descomprimir en
el path por default especificado.
Agregar nombres especiales para stdin, stdout, stderr y stdouterr.
Se agregan constantes para poder cambiar fácilmente el nombre de los archivos
especiales y se agrega el archivo especial stdouterr, que sirve para indicar que
se quiere guardar stdout y stderr todos juntos (entrelazados) en un mismo
archivo.
Agrego metodos selectByAlumno a clases donde son utiles.
La UI pregunta muchas cosas y se tiene como identity un Alumno y estos
metodos simplifican la vida :)
Si el ejercicio es Grupal pongo como Entregador el grupo del Alumno
Queda por filtrar que el Grupo sea del mismo Cuatrimestre que el Ejercicio
y esas cosas.
Tambien tengo que resolver como mostrar las Entregas que se hicieron tanto
individuales como Grupales (estas ultimas NO se ven ahora por mas que se registren)
agrego un zip de prueba para las Entregas
Es un archivo "vacio" chiquito para probar que se suba el archivo y se valide
que sea ZIP, no es una entrega :)
Agregar archivos a guardar y a comparar en el modelo.
Ahora Comando tiene archivos_a_guardar (una lista de nombre de archivos) y
archivos_a_comparar (un ZIP con el contenido de los archivos con resultados
esperados a comparar con los resultados obtenidos), en vez del archivos_salida.
ComandoEjecutado tiene, por su parte, archivos_comparados y archivos_guardados,
conteniendo los diff y archivos a guardar respectivamente.
Como CasoDePrueba y Prueba heredan de los ComandoXxx, se extiende a ellos.
Heredar a Prueba de ComandoEjecutado.
De la misma forma que CasoDePrueba hereda de Comando por razones puramente
funcionales, ahora Prueba hereda de ComandoEjecutado.
Ejecutar comandos con shell y almacenarlos como strings.
Se eliminar todo lo relacionado con Parametros (ParamValidator, modulo
sercom.validators -que tenía sólo eso-, ParamCol, etc.) y se almacenan los
comandos como simples string porque ahora se ejecutan los comandos usando el
shell. La razón para no hacer esto en el sistema viejo era la carencia de un
chroot completo, cosa que ahora sí tiene el sistema. Esto además de simplificar
el modelo de datos, hace mucho más flexible la especificación de comandos/casos
de prueba, ya que se pueden utilizar cosas propias del shell (como el glob).
Agregar soporte para nombres de usuario/grupo .
Ahora en el archivo de configuración se pueden especificar nombres de
usuario/grupo (en vez de ids) que se resuelven buscando en /etc/passwd y
/etc/groups (via módulos pwd y grp).
Avanzar sobre implementación de Tester.
- Se agrega configuraciones propias de sercom.
- Se cambia de usuario efectivo para hacer operaciones que no necesitan
privilegios.
- Se mejora el código de debug.
- Se 'seguriza' la ejecución de procesos.
- Se evita capturar la excepción SystemExit.
- Se utiliza el modulo subprocess para toda la ejecución de comandos (rsync
incluido).
- Se mejora el manejo de excepciones.
- Implementación preliminar de ejecución de ComandoFuente.
Arreglar gettext en tester.
La función _() llama por default a un gettext lazy de TG si no se está en medio
de un request, para que se resuelva luego en "tiempo de request" con la info de
lenguaje del browser. Esto en el tester no es necesario y hace que se rompa, así
que se usa el plain_gettext() de TG.
Hago que se borren los elementos de FROM que ya estan en TO al editar.
Esto para los docentes de un curso, para que no aparezcan como disponibles aquellos
ya asignados. No veo forma de generalizarlo por lo que sera C&P :S
Nuevo Widget con 2 listas para pasar datos de una a otra.
Esta lista tiene el objetivo de pasar cosas de FROM a TO dando un layout horizontal
que queda mas piolas ;).
Crea 2 listas ${name}_from y {$name}_to que son pasadas al controller (previamente hay que
seleccionar desde JS todos los items de las listas que se deseen leer, puede ser una sola o
ambas). Como propiedades utiles tiene :
* title_from : El titulo que va arriba de la lista FROM (la de la derecha)
* title_to : El titulo que va arriba de la lista FROM (la de la izquierda)
* El resto igual que MultiSelectField
No puse el texto de los botones configurable porque se rompe muy facil el layour :S, pero creo
que con los titulitos se da a entender.
Desde JS se accede con form_${name}_from y form_${name}_to a FROM y TO respectivamente. Para inicializar
los valores de FROM se usa directamente el atributo options de MultipleSelectField y a TO se lo debe
inicializar desde JS.
Cambiar modelo para que almacene archivos.
Ahora las clases Entrega, ComandoFuente, ComandoPrueba y CasoDePrueba guardan
los archivos como un stream de bytes en formato .zip. Además se vuela el código
de Entrega que no tenía mucho más sentido y se pone como notNone=True y
default='' a algunas observaciones donde tiene más sentido para concatenar.
Mejorar model.Grupo para manejo de miembros y tutores.
Ahora los métodos remove_miembro() y remove_alumno() en vez de eliminar las
clases de la DB les setea la fecha de baja. También se agregan las propiedades
'alumnos' y 'docentes' que devuelven una lista de AlumnoInscripto y
DocenteInscripto respectivamente (no devuelve Miembro/Tutor!) con los objetos
*activos* (es decir, baja=None).
Actualizar parte de tareas y pruebas del modelo.
Nuevo modelo de la parte de pruebas. Ahora un enunciado tiene tareas: "tareas
de fuente" (TareaFuente) y "tareas de prueba" (TareaPrueba). Ambos no son mucho
más que contenedores de Comandos (ComandoFuente y ComandoPrueba), pero con un
cierto orden. Las cosas "de fuente" se aplican a los fuentes, una sola vez. Un
Comando/TareaFuente podría ser compilar. O pasar un analizador estático de
complejidad, o un detector de copias. Un Comando/TareaPrueba, se corre sobre
cada CasoDePrueba que tenga el Enunciado y podría ser una prueba llana y
sencilla, o correrlo con valgrind, etc.
Cada entrega tiene ComandoFuenteEjecutado, que es el resultado de correr un
ComandoFuente sobre una cierta entrega. También cada entrega tiene varias
Pruebas, cada una con información de la corrida de un CasoDePrueba. Cada
prueba, tiene a su vez varios ComandoPruebaEjecutado, que representan como fue
corrido cada ComandoPrueba sobre ese CasoDePrueba para esa entrega.
Faltaría resolver el tema de los archivos, que seguramente van a ser guardados
en el filesystem, pero conceptualmente, cada comando tiene archivos de entrada
(entrada para el comando) y archivos de salida (archivos generados por el
comando). Además la entraga tiene que tener archivos asociados, el código fuente
que entrega el alumno.
projects / software / sercom.git / log