Método showBlockError(id,description)

[asanzo]

Esto permitirá informar un error asociado a un bloque. El intérprete de gobstones así podría informar la ubicación del error y así ofrecerle mejor experiencia al usuario.

Inicialmente podría implementarse con un highlight común, pero agregando quizás un comment al bloque.

[asanzo]

En el branch blockError estoy jugando con esto.

También podría ser así:

@fidel-ml @francofrizzo tenemos que discutir sobre cuándo usar cada una de estas estrategias:

• podemos mostrar un borde de un color alrededor de un bloque ó alrededor de un parámetro vacío. Puedo elegir grosor y color.
• podemos mostrar un warning con descripción en el bloque como el de la imagen.

Y tenemos que encontrar una combinación satisfactoria para:

• avisar sobre un error desde el intérprete, con una descripción. Los errores comunes me imagino que serán iluminar un Sacar problemático, ó un Mover problemático. (Este es el objetivo del presente issue)
• también avisar sobre un parámetro vacío (issue #91)

¿Qué opinan? Podemos usar combinaciones de estas cosas, pero hay que elegir alguna que represente bien cada tipo de error.

[fidel-ml]

¿Podés ofrecer un showBlockError en la API al que le pases color, grosory mensaje? Entonces es el intérprete el que elige cómo mostrar cada error... ;)

[asanzo]

Mmmmno. Necesitamos definir los niveles de información de forma abstracta, independientemente de su visualización. Ese es el laburo interesante y valioso.

No es responsabilidad del intérprete encargarse de saber de qué color debe mostrarse un warning o error. Sí es responsabilidad del mismo saber de qué tipo de error se trata.

Que se encargue después el frontend de gs-element-blockly de definir, cambiar, y redefinir la mejor forma de diferenciar y mostrar cada cosa.

"Que se encargue" es una forma de decir. Nos vamos a encargar nosotros, pero no tenemos que tocar el intérprete cada vez que queramos cambiar un color, es una locura acoplada.

Esto me lleva a hacer la pregunta: ¿Qué tipos de error vamos a querer mostrar? Pensemos no en un lenguaje industrial, sino en didáctica del error.

Yo distingo por ahora:

• antes de ejecución: falta de parámetros. (esto lo podría hacer desde el componente, en vez de hacerlo desde el intérprete)
• antes de ejecución: otros problemas de sintaxis y semántica (como la variable o parámetrosfuera de contexto, al menos hasta que lo pueda hacer yo desde el componente).
• en ejecución: Los primeros interesantes: Sacar lo q no hay, Mover donde no se puede.
• en ejecución: Los de tipo: usar nro, color, dirección, booleano, en los lugares equivocados.
• en ejecución: Los putos: repetir un nro negativo (¿Había negativos en gobstones?), dividir por cero, los overflow, y andá a saber qué más.
• en ejecución: los Boom de usuario

[fidel-ml]

Solo hay 2 niveles en Gobstones (o a lo sumo, 3). 1.- Errores sintácticos (o de formación de bloques) 2.- Errores de tipo 3.- Errores de ejecución

En Gobstones, 2 y 3 son errores de ejecución. Es interesante distinguir los errores de tipo de los de ejecución, pero no veo por qué distinguir diferentes errores de ejecución... (Caerse del tablero, sacar lo que no hay, dividir por cero, o que el usuario diga BOOM, son similares en naturaleza.) Para los errores de ejecución y de tipo en Gobstones, el tablero hace BOOM (y muestra la explosión). ¿Quizás para los errores de tipo podríamos mostrar otra cosa?

[fidel-ml]

¡Ah! Una repetición con valor negativo es como un skip... ;) ¿Vos decís que debería dar un error? FF

[asanzo]

Yo también estaba pensando en esos tres tipos :). Sólo preguntaba de paso si podría haber otros.

Mi pregunta en realidad se basa en una premisa: El error es bueno. El error es una oportunidad de aprender algo. Y otra premisa más, que es que va a haber errores.

Los distintos tipos de errores tienen relación con distintas fases en el aprendizaje. Un error de tipos es un error en la semántica: decidir que tu función devuelva algo y usarla en un contexto diferente es un error de entendimiento de la parte de tu problema que resuelve esa función. Señalártelo diferente te ayuda a entender con más agilidad cuál es tu problema. Un error de "te falta completar algo" es diferente. No sé si más o menos importante, pero seguro diferente, tu cabeza obra diferente. Entender que existen primitivas parciales te evoca a otra parte del cerebro, otra motivación, y es usualmente un problema algorítmico si te pasa ese error. Dentro de esta misma línea de pensamiento: el "boom" de "Completar", ¿No debería mostrarse parecido al error de "me faltan parámetros"?

Por razones parecidas se usan clases de excepción en un lenguaje industrial, y por las mismas razones llevadas al dominio de la aplicación, los lenguajes no sólo te dejan escribir tus propias descripciones de error, sino además clasificarlos. Y pensando en esto, hay una clara separación semántica, en el momento en que aprendes a tirar tus propios errores, entre error de programa y error de dominio. En este caso el error lo tirás a manopla porque descubriste un problema en tu dominio: no puedo repartir un caramelo si ya había repartido en este pupitre antes.

Hmmmm se me ocurre algo al vuelo, y es que quizás no es muy didáctico el color rojo.

Si te parece, voy a implementar lo más fácil y rápido por ahora, dejando el espacio para meter el upgrade de ser necesario.

[fidel-ml]

Me encantó tu argumentación. Y compro... Pero no tengo claro cómo hacer ahora. Habría que conversarlo.

Lo que no estoy seguro es que eso sea solamente un tema de los bloques... Es parte del intérprete de Gobstones determinar la naturaleza del error. Justamente, vos lo decís cuando mencionás a los lenguajes industriales. ;)

[asanzo]

Estuve discutiendo formas de mostrar información en los bloques con Jacquie, y me tiró un par de ideas, que dejo por acá y luego sigo trabajando:

• Le planteé que el rojo es fuerte, quizás disuasivo, y quiero analizar otras formas de llamar la atención.
• Quizás no diferenciar por el color / grosor del borde del bloque
• Mostrar el bloque en gris puede servir también
• Otra forma de mostrar ó bien un nivel distinto es haciendo que "tiemble" el bloque.
• Sino titilando el color / el gris.

[fidel-ml]

• Le planteé que el rojo es fuerte, quizás disuasivo, y quiero analizar otras formas de llamar la atención.

Me gusta que no sea rojo.

• Quizás no diferenciar por el color / grosor del borde del bloque
• Mostrar el bloque en gris puede servir también
• Otra forma de mostrar ó bien un nivel distinto es haciendo que "tiemble" el bloque.
• Sino titilando el color / el gris.

¿Es posible hacer que tiemble el bloque? ¿Y poner un "personaje" que le señale "Acá"? (Pienso en un docente, que aparece y le dice "Este es el que parece que está causando problemas" o algo así...) Las otras opciones, habría que verlas en acción para decidir. FF

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Program-AR/gs-element-blockly/issues/79#issuecomment-350849213, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqtmwHQjIE_FkT5agGlhNuf1cuaN7fks5s_ZFFgaJpZM4Pczr_ .[image: Web Bug from https://github.com/notifications/beacon/AIaqtgdF1SBp2TcgwiIPPZ9PFcF1G9DQks5s_ZFFgaJpZM4Pczr_.gif] {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/Program-AR/gs-element-blockly" ,"title":"Program-AR/gs-element-blockly","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/ 143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png"," avatar_image_url":"https://cloud.githubusercontent.com/ assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Open in GitHub","url":"https://github. com/Program-AR/gs-element-blockly"}},"updates":{" snippets":[{"icon":"PERSON","message":"@asanzo in #79: Estuve discutiendo formas de mostrar información en los bloques con Jacquie, y me tiró un par de ideas, que dejo por acá y luego sigo trabajando:\n\n- Le planteé que el rojo es fuerte, quizás disuasivo, y quiero analizar otras formas de llamar la atención.\n- Quizás no diferenciar por el color / grosor del borde del bloque\n- Mostrar el bloque en gris puede servir también\n- Otra forma de mostrar ó bien un nivel distinto es haciendo que \"tiemble\" el bloque.\n- Sino titilando el color / el gris."}],"action":{"name":"View Issue","url":"https://github.com/Program-AR/gs-element-blockly/issues/79# issuecomment-350849213"}}}

-- Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

[asanzo]

Me había tirado también la idea jackie :)

Por ahora queda así:

Y en el código definido claramente el lugar donde debe tocarse el css para mostrar diferentes errores: https://github.com/Program-AR/gs-element-blockly/blob/010420d0aff254bec824e41742cffdfb8e2cbfba/js/errors.js#L110

Después afinamos bien el tema de los colores y textos, cuando vayan probando.

[fidel-ml]

Ferpecto. Justo te iba a pedir cambiar el texto, pero lo vemos... (Me gusta más "Hay un error a causa de este bloque, o cerca de él", o algo así. No como pregunta, sino como afirmación, porque si lo estás mostrando es que hay un problema. Lo que no sabés seguro es si es o no culpa de este bloque...) FF

[asanzo]

Exacto, no sé si es justo este bloque. Bah, va a depender del caso, y el parser es un poco de quien depende.

Ah, evité la palabra "error" un poco por su estigmatización, y puse la pregunta pensando en los casos donde el error de tipos está lejos del bloque que estalla (si llamás a Cuadrado con un color en vez de un número, estalla el repetir que está dentro de Linea que está dentro de Cuadrado, y nunca ni en pedo te ayuda el error en el repeat).

Aún así no me molesta si lo cambiamos por un "Puede que haya un problema cerca de aquí..." o similar