Fix #1648 autocomplete with ts #1649
Conversation
|
Oh crap! It seems I did a local commit while working on |
| newArrayList | ||
| val untypedMethods = obj.allUntypedMethods | ||
| if (!obj.isTypeSystemEnabled) { | ||
| untypedMethods |
There was a problem hiding this comment.
No entiendo este cambio. El issue habla de un problema con el type system activado y la solución habla de un downcast. Pero el downcast en el código original ocure justamente cuando el ts está DESactivado. ¿De qué me perdí?
There was a problem hiding this comment.
El issue original ocurría con el type system activado.
Pero haciendo pruebas, me encontré con un ClassCastException cuando el type system no estaba activado, por ejemplo cuando quería trabajar esta expresión
const a = new Date()
a. // forzamos el autocomplete
...ject.wollok.ui/src/org/uqbar/project/wollok/ui/contentassist/WollokDslProposalProvider.xtend
Outdated
Show resolved
Hide resolved
|
No digo que tienen que ver con `ese` synchronized. Ni idea.
Sí afirmo que ver con "los synchronized" en general... y nada, vi uno que
me pareció innecesario y lo reporté.
El lun., 27 de may. de 2019 a la(s) 06:59, Fernando Dodino (
notifications@github.com) escribió:
… ***@***.**** commented on this pull request.
------------------------------
In
org.uqbar.project.wollok.ui/src/org/uqbar/project/wollok/ui/contentassist/WollokDslProposalProvider.xtend
<#1649 (comment)>:
> @@ -60,14 +60,12 @@ class WollokDslProposalProvider extends AbstractWollokDslProposalProvider {
}
def synchronized getAllMethods(EObject obj) {
Yo no se si el synchronized ya estaba o se lo puse yo, pero yo no tuve
problemas de deadlock con el autocomplete ni vi issues asociados a esto.
Todos los temas de deadlock están en el scope provider, cuando trata de
levantar los archivos que vienen con la biblioteca core de Wollok.
Puedo intentar sacárselo y hacer las pruebas el martes, a ver qué sucede,
pero me juego varios pesos a que los deadlocks no tienen que ver con este
synchronized.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1649?email_source=notifications&email_token=ABDLKOJDVZXJLIMG53LOBJ3PXOWINA5CNFSM4HPWUPHKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOBZX2L7I#discussion_r287728678>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABDLKOOVIAN34JX2WK65XETPXOWINANCNFSM4HPWUPHA>
.
|
|
Bueno, lo acabo de probar y funciona ok, así que ahora pusheo la versión sin |
|
Y sería muy costoso hacer que tire todos los mensajes posibles cuando no sabemos qué tipo es? |
El tema es que cada mensaje depende del method container, habría que ver si a) es posible, b) se puede cachear porque me preocupa que le afecte la performance (si bien pagina el autocomplete, es una operación que demoraría un cierto tiempo). Si querés abrí un issue como propuesta y lo vemos. @npasserini Y sí, totalmente, lo mergeamos así vamos liquidando temas pendientes... |
|
Qué gil, me olvidé de mergear :^P |
Since there was a downcast to
WMethodContainersometimes we got a ClassCastException and autocomplete didn't work for variables or arguments.This is the test with Type System activated
And with Type System deactivated
