Hola!
Sería muy útil, al igual que en el ide de eclipse, se pueda diferenciar en la representación gráfica del diagrama dinámico de variables y constantes, con algún dibujo, color, etc como un candadito por ejemplo.

          Con `powershell` se podría logear un warning

Tal vez este issue es más de CLI que de LSP.

Originally posted by @PalumboN in uqbar-project/wollok-lsp-ide#75 (comment)

Ahora que estamos mejorando el Diagrama Dinámico, una épica con todas las mejoras.

Actualmente se ve así:

• Renombrar List#asdfg -> a List o un/a List #82
• Teniendo dos (o más) referencias superpuestas solo se muestra una #68
• Agregarles el índice a las listas. #82
  • En Xtext creo que además todas las colecciones (List y Set) se mostraban en línea punteada (qué piensan?).
• Que se vean mejor las flechas, ahora están muy claras. Tal vez convenga hacerlas más gruesas también.
• #73
• Diferenciar las referencias de variables y constantes #59
• #70
• #71
  • Darle una iterada a los colores / formas de los objetos (revisar XText, Dodino hizo un laburo arduo y fantástico encontrando colores, lo que incluía también diferenciaciones para distintos tipos de daltonismo).
    • Distintos themes (var https://colorhunt.co/)
    • Control del tamaño de la font / UI en general
  • En la imagen de acá, las palabras true y false no se leen bien
  • Los objetos de las colecciones los haría más chicos que el resto (?
  • Rectángulos para los strings, así entran cómodos. Alf: Me gusta más la forma redonda para todos los objetos, se puede quizás jugar con el tamaño o el borde para diferenciar. Es cómodo para explicar dinámico vs estático que el diagrama dinámico tenga cosas redondas (u ovaladas) versus lo cuadrado/rectangular del diag de clases. Bah, además de cómodo me gusta la metáfora que instancia es redondo y clase es cuadrado.
  • Un color particular para los objetos del proyecto (no lang). Alf: En ese sentido, que los objetos "primitivos" o los que vienen dados tengan una forma parecida a un objeto propio me parece una buena decisión didáctica: al fin y al cabo todos son objetos y entienden mensajes. Si los objetos que le alumne no puede tunearse quiere que sean distintos, podemos jugar con el tamaño (como el ejemplo de achicar el objeto de la colección) y/o el grosor del borde.

Los ejecutables generados por electron para windows son de tipo "GUI", a diferencia de los ejecutables generado por pkg que eran de tipo "console". Esta diferencia hace que el CLI sea inutilizable, ya que al correr el stdin no funciona con aplicacion graficas.

Entonces habria que volver a pkg y analizar alternativas a electron para mostrar los diagramas y correr juegos, por ejemplo, se podrian mostrar directamente en el browser.

repo publico: https://github.com/hernanconiglio/pacmanBasicGame

Error que arroja:

 *  Executing task: /home/hernan/wollok-dev/wollok-ts-cli-linux run 'program.pacman' --skipValidations -p /home/hernan/Objetos1/pacmanBasicGame/src 

Running program.pacman on /home/hernan/Objetos1/pacmanBasicGame/src
Running program.pacman...

✗ Uh-oh... An error occurred during the run!
  wollok.lang.EvaluationError wrapping TypeScript Error: Could not resolve reference to pacman or its a reference to void
    at program.pacman [program.wpgm:4]
    at root [--:--]
    Derived from TypeScript stack
    at Evaluation.exec (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/interpreter/runtimeModel.js:283:39)
    at exec.next (<anonymous>)
    at Evaluation.execSend (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/interpreter/runtimeModel.js:395:37)
    at execSend.next (<anonymous>)
    at Evaluation.exec (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/interpreter/runtimeModel.js:268:49)
    at exec.next (<anonymous>)
    at Evaluation.execBody (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/interpreter/runtimeModel.js:330:34)
    at execBody.next (<anonymous>)
    at Evaluation.exec (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/interpreter/runtimeModel.js:256:49)
    at exec.next (<anonymous>)
✓ Game available at: http://localhost:3000
✓ Running game!

Ahora tiene un tamaño fijo, cambiarlo a que sea la pantalla completa

Ahora tanto si se imprime un objeto como un string se muestran igual:

Estaría bueno que los String se muestren con las comillas como en el IDE

Wollok cli intenta abrir ambas veces en el puerto 3000 y la segunda falla con:

✗ File c:/Users/juanm/OneDrive/Documentos/Developmeectos/facu/pdep/Wollok/prueba_file.wlk doesn't exist or is outside of project!
✓ Object diagram available at: http://localhost:3000
wollok> node:events:505
throw er; // Unhandled 'error' event
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
code: 'EADDRINUSE',
errno: -4091,
syscall: 'listen',
address: '127.0.0.1',
port: 3000
}

Como reproducir:

• correr el repl de wollok cli en una terminal
• una vez abrió, correr el repl de wollok cli en otra

Cuando se realiza toString() de un objeto en vez de devolver el nombre del objeto como un string devuelve un string con la ubicacion de este "." y el nombre del objeto.

Por ej:

Cabe destacar que como bien se ve en el ejemplo y como se especifico en este issue:
#4

Actualmente el objeto en cuestion para ser referenciado requiere su ubicación por lo que probablemente resolver ese issue resuelva este.

Puede ser configurable, pero pienso que el default debería ser que no se muestre. Solamente debería aparece si está en modo DEBUG o algo así.

Así se ve ahora en el LSP cuando falla un test.

Como dice @nscarcella , esto es un CLI, tiene sentido tener tests de CLI.

• La idea sería poder probar cosas como "escribo esto, pasa esto"
• Se pueden buscar herramientas. La primera que me saltó es esta, pero por favor googleemos más: https://github.com/node-modules/clet . Veamos si vale la pena hacer lo que hace esta persona que testea todo a mano o tener algo que facilite.

Situacion actual

El diagrama dinamico no sabe manejar multiples referencias al mismo objeto, por ej con este codigo esta todo bien

object pepita {
  var property hijo = manolo

  var property estaPensandoEn = juan
}

object manolo {}

object juan {}

Pero si lo cambio a que apunte dos veces al mismo pierdo una de las flechas

object pepita {
  var property hijo = manolo

  var property estaPensandoEn = manolo
}

object manolo {}

object juan {}

Comportamiento esperado

No tengo a mano un Wollok XText pero si mal no recuerdo era una unica flecha con los nombres de las referencias separados por comas

La idea es poder hacer wollok desde cualquier carpeta y que ande, sin tener que llevarnos el ejecutable a todos lados

1. Invalid version en nvm, porque no reconoce el formato lts/gallium en el archivo .nvmrc
2. Aún indicando la versión nvm no funciona: exit status 1: Acceso denegado.

Hay que pegarle una revisada a los logs de profiling como estos:

Quizás necesitemos otra herramienta de logging que me permita hacer esos profilings en lugar de usarla como un flag y nada más.

Estamos probando este proyecto y nos tira este error:
[ERROR]: missingReference at src/test.wtest:--

Llegamos a este mínimo test, si le cambiamos el nombre a la contante wollok por wollok2 el error desaparece.

import computadora.*
import programas.*

describe "TESTEOS DE PROGRAMA"{
	const windows = new SistemaOperativo(memoria = 2, disco = 2)
	const miPc = new Computadora(sistemaOperativo = windows, discoTotal = 150, memoriaTotal = 8)
	
	const wollok= new Programa(memoria = 1, disco = 4)

	test "ejecutar windows"	{
		miPc.ejecutar(windows)
		assert.equals([windows], miPc.programasEnEjecucion())
	}
}

tenemos que hacer logger.info(lo que le queremos decir a el/la estudiante) y logger.debug(el stack) al imprimir el error de autoimport, según lo charlamos acá: https://github.com/uqbar-project/wollok-ts-cli/pull/24/files/62d8e7952f1d563b50a8ffe8aad9fc0e000f6cb2#r915314135

Probado en Huayra (Debian based).
Es independiente de si lo corro en la carpeta actual o en otra.

✗ Uh-oh... An error occurred during the run!
  Error: Could not resolve reference to /home/alf/repos/pdep/2021/2021-o-recufeb/
    at Environment.getNodeByFQN (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/model.js:654:19)
    at Environment.<anonymous> (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/decorators.js:19:39)
    at Interpreter.run (/snapshot/wollok-ts-cli/node_modules/wollok-ts/dist/interpreter/interpreter.js:17:54)
    at Command.default_1 (/snapshot/wollok-ts-cli/dist/commands/run.js:25:72)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Command.parseAsync (/snapshot/wollok-ts-cli/node_modules/commander/lib/command.js:916:5)

La ruta del archivo debería ser c:\Users\juanm\OneDrive\Documentos\Development\proyectos\facu\pdep\Wollok\prueba_file.wlk, según el mensaje de error no encuentra el archivo en la ruta c:UsersjuanmOneDriveDocumentosDevelopmentproyectosfacupdepWollokprueba_file.wlk

Executing task: C:/Users/juanm/Downloads/wollok-ts-cli-win.exe repl c:\Users\juanm\OneDrive\Documentos\Development\proyectos\facu\pdep\Wollok\prueba_file.wlk -p c:\Users\juanm\OneDrive\Documentos\Development\Initializing Wollok REPL for file c:UsersjuanmOneDriveDocumentosDevelopmentproyectosfacupdepWollokprueba_file.wlk on c:UsersjuanmOneDriveDocumentosDevelopmentproyectosfacupdepWollok
✓ No problems found building the environment!
✗ File c:UsersjuanmOneDriveDocumentosDevelopmentproyectosfacupdepWollokprueba_file.wlk doesn't exist or is outside of project!
✓ Object diagram available at: http://localhost:3000

tal vez es imposible pero verdaderamente es muy molesto (pensando mas en un contexto de clase) que te reordene todo cada vez que detecta un cambio.

Dice que hay un problema al buscar las imágenes.

Eso pasa porque se espera que el proyecto tenga cierta estructura y si no pasa explota todo.

Además, el parámetro -p solamente funciona al nivel del package del program... básicamente falla al buscar la entidad si:

• El archivo con el program se encuentra en una subcarpeta del proyecto
• El archivo con el program se llama igual que otra cosa (por más que sí funcionan los tests por ejemplo)

Error:

The "path" argument must be of type string. Received undefined
at new NodeError (node:internal/errors:371:5)
at validateString (node:internal/validators:120:11)
at Object.join (node:path:1172:7)
at getImages (/Users/palumbon/git/wollok-ts-cli/dist/mac-arm64/wollok-ts-cli.app/Contents/Resources/app/build/commands/run.js:137:38)
at Namespace.<anonymous> (/Users/palumbon/git/wollok-ts-cli/dist/mac-arm64/wollok-ts-cli.app/Contents/Resources/app/build/commands/run.js:89:31)
at Namespace.emit (node:events:526:28)
at Namespace.emitReserved (/Users/palumbon/git/wollok-ts-cli/dist/mac-arm64/wollok-ts-cli.app/Contents/Resources/app/node_modules/socket.io/dist/typed-events.js:56:22)
at /Users/palumbon/git/wollok-ts-cli/dist/mac-arm64/wollok-ts-cli.app/Contents/Resources/app/node_modules/socket.io/dist/namespace.js:141:26
at process.processTicksAndRejections (node:internal/process/task_queues:78:11)

Probando los test de wollok-language/sanity/basics/booleans/literals
Tira este error en la consola [ERROR]: codeShouldBeReachable at literals.wtest:41

Llegué a este mínimo test, donde tira el mismo error:

test "and operator used with literals true and false"{
    assert.notThat(false && true)
}

También pasa con estos asserts:

//assert.notThat(false and true)
//assert.notThat(false && false)
//assert.notThat(false and false)
//assert.that(true || true)
//assert.that(true or true)
//assert.that(true || false)

Si tanto el .wtest como alguno de los archivos .wlk tienen el mismo nombre al intentar ejecutarlo falla.
Por ej en este repositorio:
https://github.com/obj1unq/2021s1-simulacro-superpoderoses-lgassman

Ambos archivos se llaman igual: "superpoderoses.wlk" y "superpoderoses.wtest".

El error es el siguiente:

Alguna estrategia charlada hoy:

• Separar React de P5 (el dibujador) , de el Environment (wollok-ts). Hoy el proyecto https://github.com/uqbar-project/wollok-game-web separa React de lo demás, pero hay que separar más todavía.
• Eso me va a permitir poder construir un cliente que sólo dibuje y lo ideal es que la evaluation esté corriendo en el CLI, el servidor.
• Esto va a permitir luego poder manipular el estado del game desde el CLI y hacer cosas como tener el diagrama dinámico.
• Quizás una comunicación entre ambos usando socket io.

Al intentar instanciar un mixin debería decirme idealmente "No se puede instanciar un mixin" (como figura en la doc )

• Tanto al instanciar en un REPL.
• Como al intentar levantar un programa que lo intenta instanciar.
• Aún sin las validaciones activadas.

Al correrlo en un repl

Lanza wollok.lang.StackOverflowException wrapping TypeScript RangeError: Maximum call stack size exceeded:

En Eclipse lanza este error en el repl:

Que tampoco es perfecto, pero al menos no es un stack overflow 😆

Al intentar instanciar en el código

Y si intento instanciar dentro del código:

mixin Mix { var property mix = 1 }

object instanciadorDeMixines {
	method instanciar() = new Mix() // Acá está el error
}

El ts-cli no me da info, sólo Uh-oh... Unexpected Error!:

Peeeero si lo pongo verboso tira TypeError: _a.isAbstract is not a function:

De lo que entiendo que hay una de las validaciones de new que le está mandando un mensaje a un nodo Mixin que no entiende isAbstract

Mientras que en Eclipse es coherente con lo que tira el REPL:

Y si lo intento ejecutar:

Cuando buildeamos dice

  • asar usage is disabled — this is strongly not recommended  solution=enable asar and use asarUnpack to unpack files that must be externally available
`

Tengo un proyecto con subcarpetas (y un archivo de prueba justo dentro de src):

ejemplos-de-clase-wollok
\->src
      \->clase01
            \->entrenador.wlk
...
      \->prueba.wlk

El problema es que no me encuentra archivos dentro de subcarpetas

Initializing Wollok REPL for file /Users/palumbon/git/ejemplos-de-clase-wollok/src/clase01/entrenador.wlk on /Users/palumbon/git/ejemplos-de-clase-wollok
[WARNING]: shouldNotDefineUnusedVariables at src/clase04/atencionDeAnimales_parte2.wtest:78
[WARNING]: shouldNotDefineUnusedVariables at src/clase04/atencionDeAnimales_parte2.wtest:79
[WARNING]: shouldNotDefineUnusedVariables at src/clase04/atencionDeAnimales_parte2.wtest:80
[WARNING]: shouldHaveAssertInTest at src/clase08/ejemplos_testing.wtest:19
✗ File /Users/palumbon/git/ejemplos-de-clase-wollok/src/clase01/entrenador.wlk doesn't exist or is outside of project!

Pero sí el que está justa debajo de src

Initializing Wollok REPL for file /Users/palumbon/git/ejemplos-de-clase-wollok/prueba.wlk on /Users/palumbon/git/ejemplos-de-clase-wollok
[WARNING]: shouldNotDefineUnusedVariables at src/clase04/atencionDeAnimales_parte2.wtest:78
[WARNING]: shouldNotDefineUnusedVariables at src/clase04/atencionDeAnimales_parte2.wtest:79
[WARNING]: shouldNotDefineUnusedVariables at src/clase04/atencionDeAnimales_parte2.wtest:80
[WARNING]: shouldHaveAssertInTest at src/clase08/ejemplos_testing.wtest:19
wollok:prueba> 

Supongo que será algo relacionado con la conversión de URIs y paths...

Estaría bueno poder crear un proyecto nuevo, con una estructura prederterminada.

Ejemplos:

• Proyecto nuevo: Para ser usado regularmente. Crea un archivo .wlk con la definición de un objeto.
• Tour: Para ver la sintaxis del lenguaje. Crea archivos .wlk .wtest .wpgm con distintas definiciones.
• Game: Crea un template del juego, con los archivos y directorios esperados para ejecutar un juego

También estaría bueno agregar un archivo con metadata del proyecto:

• En un momento se charló de tener un package.json (fuimos por esa idea en #85), pero podría ser cualquier nombre.
• Que tenga
  • nombre del proyecto
  • Versión
  • Versión de Wollok donde se creó / está funcionando
  • assets?
  • main?

          No me queda claro cuál es la mejor solución. De las formas que intentamos inferir con Tom, ninguna terminaba funcionando el 100% de los casos.

Prefiero ir con cosas menos mágicas, servir todas las "well known name folders" suena bien.

Originally posted by @PalumboN in #52 (comment)
Tambien en #52 (comment)

Este comando debe reiniciar absolutamente todo desde 0. Es para resolver el "TODO:" dejado en el código.

Posible descripción:

  :reload | :r  Reloads all currently imported packages returning to an initial state.

Necesitamos probar el cli contra varios proyectos que se usen en el aula para asegurarnos que corra más o menos bien.

Acá hay una posible lista de ellos para completar:
https://docs.google.com/spreadsheets/d/1Co9iVX3K69HxktaMaVHlHJicLAoZorYLdFiS9Moc-Ek/edit#gid=0

La idea es:

• Agregar ahí proyectos que sepamos que se usan en diversos cursos y unis (preferentemente con tests)
• Bajarse esos proyectos y correr wollok test con el cli sobre ellos y fijarse que pasen los tests
• Marcar brevemente en la planilla los proyectos revisados con OK si fue todo bien o no ok y algún comment si hubo algo mal
• Cargar todos los errores en issues en el proyecto correspondiente. (por ejemplo, si hay una validación que anda mal, cargarla en wollok-ts, o si es algo del cli cargarlo acá, cualquier cosa se puede mover sin drama)

Ahora que volamos Electron, hay que actualizar el CI para que deploye como se debe.

Hay que cambiar para que suba los archivos generados por pkg

Posible descripción:

:rr | Same as "reload" but additionaly reruns all commands written since last reload

• En #19 ya hablamos sobre cómo implementar esto.
• Hay que poder acceder a la lista de cosas escritas. Una posible forma de resolverlo sería ver si no se le puede preguntar la lista de cosas escritas en consola al objeto REPL. Otra posible forma sería guardarse esas cosas a mano.
• Luego, simplemente hacer un reload, y correr una por una esas cosas.
• Esto estaría bueno testearlo (que efectivamente haya corrido de nuevo, que funcione un doesnotunderstand anterior, etc.) Pero para eso probablemente sea necesario resolver antes: #21

Estaría bueno poder abrir Wollok Game desde el REPL también, así se puede usar junto al diagrama dinámico 🤩

Para eso estaría bueno que el juego se levante al hacer game.start().
Habría que configurar el drawer y "sobreescribir" la primitiva para que levante la ventana al buildear cualquier proyecto.

Con eso se podría evaluar el mensaje en el REPL y con eso levantar el juego ;)

Las llamadas a loglevel.setLevel() y la decisión de si ponerle verboso o no deben estar en 1 solo lugar, preferentemente fuera del repl, y en un lugar más general.

Tengo la sensación de que hay que hacerlo acá:

En común para todos los commands.

JUSTO hay un ejemplo en la documentación de commander en "Life cycle hooks" en la que también se usa para algo como logueo. Se puede agregar un hook "preAction" que setee el nivel de logueo que queremos, y ahí en ese hook leer el verbose y setear el loglevel a partir de eso.

          Cuando tengamos un _writer_ esto se podría generar desde un AST 👀

Originally posted by @PalumboN in #62 (comment)

El directorio o archivo que se corre debería tener el contexto actual, no tener que ir a buscarlo

En este ejemplo:

Si yo dije que quiero un REPL en src/arch1.wlk no debería tener que hacer import src.arch1.* para llegar a pepita, debería estar directamente disponible

Por ejemplo, acá:

Los time y time end deberían ser nivel debug, el log de abajo error, etc.

Sería genial poder escribir "wollok repl" en cualquier consola en cualquier carpeta y que eso abra un repl de wollok.

Hoy para hacer eso es tan sencillo como buildear este proyecto para obtener el ejecutable y:

• Poner la carpeta donde está el ejecutable "wollok" en el PATH del sistema operativo o bien
• Poner el ejecutable "wollok" dentro de una carpeta que ya esté en el PATH (como C:\Windows\System32 en windows, o /usr/bin en linux).

Si bien es algo bastante pavo de hacer (y hoy de hecho ya lo hacen, a veces, para instalar java) (no la mayoría), estaría bueno que este CLI no necesitara eso, y tuviera una forma de "instalarse" y "desinstalarse".

Veo dos caminos posibles:

• Buscar una herramienta como electron-builder que me da instaladores automáticamente para todo sistema operativo, me resuelve el tema de firmarlos y todo (Windows y Mac son especialmente molestos con el tema de la firma) o bien
• Resolverlo todo a pulmón como en pilas bloques, donde usamos electron-installer-debian para los deb de Linux, NSIS para Windows (con la herramienta makensis) y hdiutil para mac, que hacer los .dmg. Pero ya estos tienen problemas reportados en Pilas Bloques, así que yo investigaría de nuevo bastante.

Esta investigación puede ser un buen puntapié inicial por si queremos en algún momento empaquetar algo más que sólo el CLI.

¿@uqbar-project/wollok opiniones?

Seguí los pasos de instalación del IDE y se instaló correctamente, aunque cuando busqué wollok no me aparecía la extensión:

Sí cuando busqué @sort:updateDate

No es super importante pero por ahí falta alguna descripción en el archivo que genera las versiones y para la próxima se puede investigar.

Abrazo!!
La radio está buenísima!

• Basado en la estrategia definida en #33
• Extraer el diagrama de objetos del wollok-run-client

(quizás este issue vaya en wollok-ts)
Con el código de hoy, estoy pudiendo hacer en el REPL new pepita(), siendo pepita un wko:

Aunque al correr las validaciones da error, el mismo que el issue #35

object pepita{ var property energia = 100 }

object instanciadorDePepitas {
	method instanciar() = new pepita()
}

Da el error: TypeError: _a.isAbstract is not a function

Sería genial que no se pudieran instanciar cosas que no sean clases, y que eso se resuelva antes de validar, ¿quizás en el linkeo?

Lo típico en estos casos en dónde una función retorna más de una cosa con tipos únicos es hacerla retornar una tupla en lugar de un objeto (en este caso, el tipo sería [Interpreter, Import[]] eso, utilizado con deconstrucción y spread, te evita tener esas colisiones de nombre incomodas como la de la linea 29, dónde querés setear algo que se llama igual que un campo de lo que recibís, entonces no lo podés deconstruir fácil.

Originally posted by @nscarcella in #22 (comment)

También deberíamos arreglar su comment siguiente:

#22 (comment)

Ahora se muestran como "Boolean#" en vez de decir si es true o false

Ahora no se muestran los elementos dentro:

También, al ser objetos "especiales", se podrían mostrar distinto, como los números

No me deja correr un proyecto por errores no vinculados al proyecto mismo sino a wollok-ts:

Por las validations shouldUseOverrideKeyword y shouldCatchUsingExceptionHierarchy

Esto es usando node 16 y tampoco anda usando node 14 (sospecho que porque justamente el error está en wollok-ts???)

Ahora bien:

Si hago --skipValidations con node 16:

Sigue teniendo problemas con wollok-ts:

Si hago --skipValidations con node 14 es distinto:

Pero eso es porque replaceAll está a partir de node 15.

Acabo de cambiar el Readme en #2 para que mencione esto.

Investigar un toque VSCode: ¿puedo abrir una ventana/iframe apuntándole a una dire que yo diga? ¿puedo levantar wollok game en el vscode? ¿Puedo levantar un diagrama de objetos?

https://code.visualstudio.com/api/extension-guides/webview

Este issue tiene por objetivo saber cómo se implementa una "unión" entre una página cualquiera nuestra con VSCode, para intentar decidir qué hacer con el cli