Checking expected timeouts on check_error too - Fixes mumuki/mumuki-laboratory#1207

[afska]

Fixes mumuki/mumuki-laboratory#1207

Este PR es sobre los errores:

1. Otro problema más raro aún es que en https://mumuki.io/primaria/exercises/5589-repeticion-condicional-practica-al-infinito, si se envíe el código tal cual está, da verde (pero debería fallar, porque falta un bloque)

Esto sucedía por varios problemas:

• gobstones-blockly generaba while(not(())) { ... } con el código en cuestión
• () es una tupla vacía en XGobstones
• not de una tupla vacía es un error en tiempo de ejecución, da boom
• El ejercicio tenía un solo initial_board pero ningún test, entonces no rompía. Si hubiera sido:

expect_endless_while: true
check_head_position: false
examples:
 - initial_board: |
     GBB/1.0
     size 2 2
     cell 0 1 Negro 4 Rojo 4 
     cell 1 1 Azul 6 Rojo 4 
     cell 0 0 Negro 4 Rojo 4 
     cell 1 0 Negro 4 Rojo 4 
     head 1 1
   final_board: |
     GBB/1.0
     size 2 2
     head 0 0

... habría funcionado.

Con este PR ahora también se puede hacer:

expect_endless_while: true
check_head_position: false
examples:
 - initial_board: |
     GBB/1.0
     size 2 2
     cell 0 1 Negro 4 Rojo 4 
     cell 1 1 Azul 6 Rojo 4 
     cell 0 0 Negro 4 Rojo 4 
     cell 1 0 Negro 4 Rojo 4 
     head 1 1
   error: "timeout"

...lo cual es más cortito y también aviva al runner de que hay un test que correr.

⚠️ Mergear esto es un chiche nomás. Se puede hacerlo andar de la primera forma sin necesidad de hacer otro deploy.

2. La UI se congela al correr un ejercicio con loops infinitos

Esto lo estuve viendo pero no es tan fácil, la forma de solucionarlo para mí es con Web Workers pero hay varios temas a solucionar:

• No pueden acceder al scope global, ni a ningún dato que no se pase mediante .postMessage(...) que solo admite datos planos y no objetos con comportamiento.
• Pueden importar scripts (en este caso el código del intérprete) pero solo mediante un importScripts que los baja de la red, y esto desde el runner se complica porque corren dentro de labo
• Habría que hacer un refactor grande en gobstones-code-runner para hacer el parseo e interpretación en el mismo paso y que la interfaz sea siempre asincrónica

Igualmente lo veo posible, pero es una tarea de varios días así que lo cargué en un issue aparte (#128)

[flbulgarelli]

Hola! Excelente y clarísimo. Mi única duda es: si ahora tenemos el errror-timeout como una opción más, ¿qué aporta el expect-endless-while? ¿No es redundante?

[afska]

Sí, buen punto. Lo dejé por retrocompatibilidad de ejercicios. También lo usa el precompile hook para saber si responder :aborted o no, pero podría mirar en los examples si alguno tiene error: "timeout" y ya. Veo si puedo sacarlo! On Oct 3, 2018 11:09 AM, "Franco Leonardo Bulgarelli" < notifications@github.com> wrote: Hola! Excelente y clarísimo. Mi única duda es: si ahora tenemos el errror-timeout como una opción más, ¿qué aporta el expect-endless-while? ¿No es redundante? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#127 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjmCGbznmcYuEXI8VBl9yXtXIdFPUiPks5uhMUAgaJpZM4XFVLg> .

[flbulgarelli]

Ok. Esta bien, no es necesario. Era solo para entender.

Me gustaría que el expect-endless-while siga a andando por retrocompatibilidad, pero que no sea necesario si pones error timeout. O viceversa.

[afska]

@flbulgarelli con el último cambio el check_endless_while ya no sería necesario. Si alguno de los examples chequea por el error "timeout", no retorna más :aborted como antes.

[flbulgarelli]

¡Excelente!