These are chat archives for ceylon/ceylon-ide-eclipse

9th
May 2016
David Festal
@davidfestal
May 09 2016 09:43
Don't know what happens, but this morning, after my last pull on Friday or Saturday, the IDE is seriously broken regarding unresolved references
they are not reported anymore as errors in either the editor or the problems view
which finally brigs strange backend errors during binary generation
didn't take the time to look at what changed
@gavinking : do you think that could be related to the recent changes in the typechecker regarding the TypecheckerUnit, etc ... ?
Bastien Jansen
@bjansen
May 09 2016 09:45
or maybe this change: ceylon/ceylon-ide-eclipse@e366edb
David Festal
@davidfestal
May 09 2016 09:47
I don't think so, it only filters the Backend errors
and now the typechecker error markers are missing
let me pull everything again and see if it's fixed
Gavin King
@gavinking
May 09 2016 10:52
@davidfestal well sure, it could be related
but my bet is it was broken before that
since, as I observed, the collection of unresolved refs was not being used in any nontrivial way
David Festal
@davidfestal
May 09 2016 14:00
@gavinking : OK, it was a bug you had already fixed during the week-end
everything's OK now
Gavin King
@gavinking
May 09 2016 14:01
which one?
David Festal
@davidfestal
May 09 2016 14:01
ceylon/ceylon#6258 apparently
Gavin King
@gavinking
May 09 2016 14:02
oh right
yeah
David Festal
@davidfestal
May 09 2016 14:02
but I didn't realize I had this bug in my IDE at first
and then all sort of strange things happened of course
Gavin King
@gavinking
May 09 2016 14:31
suddenly I have cimpile errors in tests for ceylon-ide-common
because of
shared import test.ceylon.collection "1.2.3";
David Festal
@davidfestal
May 09 2016 14:31
Ah, it's not new though
but I'll have a look
can you share the detail of the errors ?
Gavin King
@gavinking
May 09 2016 14:45
well it can’t find that module @davidfestal
David Festal
@davidfestal
May 09 2016 14:46
is it when you run the complete build ?
with ant ?
Gavin King
@gavinking
May 09 2016 14:46
in the IDE
David Festal
@davidfestal
May 09 2016 14:47
Ah
let me have alook
This test.ceylon.collection should be compiled
to be available for ceylon-ide-common
normally it is when you do the build
David Festal
@davidfestal
May 09 2016 14:52
In the ide-quick target, the sdk ant build calls the compile-test-collection target
so that it is availble in the ./ceylon-sdk/modules outout folder for use by ceylon-ide-common
Bastien Jansen
@bjansen
May 09 2016 14:54
btw @davidfestal have you fixed errors in units tests of the delta package?
David Festal
@davidfestal
May 09 2016 14:54
no, not for now
Bastien Jansen
@bjansen
May 09 2016 14:54
ok
David Festal
@davidfestal
May 09 2016 14:54
a global pass on all the common and eclipse IDE tests
is on my task list after the abstraction integration into IntelliJ is stable and usable
Gavin King
@gavinking
May 09 2016 15:12
alright, it’s better now
Gavin King
@gavinking
May 09 2016 15:49
by the way, it seems to me that the IDE is performing subjectively significantly better now
still not quite perfect, but I think it’s a substantial improvement
David Festal
@davidfestal
May 09 2016 15:50
related to the typechecker optimization you think ?
Gavin King
@gavinking
May 09 2016 15:50
that and the thing I did to not force typechecking every time you open the completion window
David Festal
@davidfestal
May 09 2016 15:50
Yes, that's a great point
since, of course, the local typechecking is synchronized wit the model modification involved in the central typechecking
Gavin King
@gavinking
May 09 2016 15:51
i still think we can make incremental compile far smarter though, BTW
Bastien Jansen
@bjansen
May 09 2016 15:51
oh I guess I can do the same in IntelliJ then?
Gavin King
@gavinking
May 09 2016 15:51
yes, you should
Bastien Jansen
@bjansen
May 09 2016 15:51
it's currently typechecking the file every time autocompletion is called
David Festal
@davidfestal
May 09 2016 15:52
@gavinking : while working on the build abstraction
I've thought of a simple way to avoid binary generation, even when using project dependencies
Gavin King
@gavinking
May 09 2016 15:52
@bjansen yeah so what you need to do is keep a copy of most-recently-typechecked version of the document and do a string comparison
to decide if it’s really necessary
David Festal
@davidfestal
May 09 2016 15:53
That would be an option
but quite interesting
of course
a easy to do very soon
Bastien Jansen
@bjansen
May 09 2016 15:53
@gavinking if the strings are different, you typecheck again?
Gavin King
@gavinking
May 09 2016 15:53
another obvious thing is that right now we block the whole workspace while doing binary gen
AFAICT that is totally unnecessary
David Festal
@davidfestal
May 09 2016 15:54
in the mid-term, the tasks of my SOW will also have a great impact to increase performance
That's what I'm saying
Gavin King
@gavinking
May 09 2016 15:54
binary generation could happen in a lower-priority job that doesn’t block the ws
@bjansen right, exactly
David Festal
@davidfestal
May 09 2016 15:54
I'll provide the option to avoid doing it synchronously
Gavin King
@gavinking
May 09 2016 15:54
@bjansen now, there might be an even smarter way to do it with some kind of dirty flag checking
you can try that if you like
but the string comparison was working well enough for me for now
i’m assuming these source files aren’t enormous
David Festal
@davidfestal
May 09 2016 15:55
so @gavinking : there is much planned to further increase perfs
on my task list
That's globally what I'm going to work on (apart from support) after the build abstraction
Gavin King
@gavinking
May 09 2016 15:56
but note what I’m saying: split it into two jobs: (a) typecheck and update the model (b) generate binaries
David Festal
@davidfestal
May 09 2016 15:56
Already done in the build abstraction
Gavin King
@gavinking
May 09 2016 15:56
oh ok, great
David Festal
@davidfestal
May 09 2016 15:56
even more
Gavin King
@gavinking
May 09 2016 15:56
furthermore, i think the global workspace lock is crazy
David Festal
@davidfestal
May 09 2016 15:56
the build abstraction is split in 4 steps that feed immutable list
lists
Gavin King
@gavinking
May 09 2016 15:56
at maximum it should be a lock on the project
David Festal
@davidfestal
May 09 2016 15:57
Sure
when integrating the build abstraction into the Eclipse plugin
we should be able to remove this lock
maybe not at the first step, but finally yes
because now the uild abstraction takes care of the delta
Gavin King
@gavinking
May 09 2016 15:58
but frankly I think it’s unacceptable that the build ever blocks saving the editor
David Festal
@davidfestal
May 09 2016 15:58
so that we won't be relying on the incremental builder delta as before
Bastien Jansen
@bjansen
May 09 2016 15:58
I concur
David Festal
@davidfestal
May 09 2016 15:58
I agree with you yes
Gavin King
@gavinking
May 09 2016 15:58
I should be able to save files as a please
it’s up to the builder to handle that
David Festal
@davidfestal
May 09 2016 15:59
yeah
Gavin King
@gavinking
May 09 2016 15:59
either by queuing up multiple builds, or, better, by cancelling and “merging”
David Festal
@davidfestal
May 09 2016 15:59
yes, the fault is to the global scheduling rule we use for the ease
Eclipse scheduling rules are quite cumbersome to implement I find
but with the astracted build we shoud be able to get freed of this
Gavin King
@gavinking
May 09 2016 16:00
i don’t think it’s a big problem that the builds block each other
but they shouldn’t block the editor
David Festal
@davidfestal
May 09 2016 16:00
I know
but the standard save action
is made under the workspace scheduling rule
afair
or at least locks it at a step
Gavin King
@gavinking
May 09 2016 16:01
well we could look at what JDT does
since JDT doesn’t seem to suffer from this … or does it?
David Festal
@davidfestal
May 09 2016 16:01
the JDT does specific stuff during the save
it's not the standard resource save
it's using it's own JDT model
Gavin King
@gavinking
May 09 2016 16:01
ok, so we steal it
David Festal
@davidfestal
May 09 2016 16:02
not possible, it's fully related to the JDT-specific stuf
Gavin King
@gavinking
May 09 2016 16:02
ok
David Festal
@davidfestal
May 09 2016 16:02
Compilation unit
and the Java model delta construction from the resource delta
this code is very complicated afair
but again, once we remove the "Ceylon incremental typechecking" from the Eclipse incremenetal project builder
and reduce the need of constant binary generation
(after integrating the buid abstraction)
this will be much better
of course
Gavin King
@gavinking
May 09 2016 18:49
@bjansen OK, instead of comparing the whole text contents of the editor, I’m now just using a dirty flag
that I set when the editor is modified
when the text is modified, rather
seems to work well
Bastien Jansen
@bjansen
May 09 2016 20:21
ok
in IntelliJ, the default settings show the completion popup immediately, which means basically that every time you type a character it'll try to show the popup, so I'm not sure how I can optimize the calls to the typechecker
maybe when a "special character" is typed, something like [^\w]
currently, it can feel slowish in certain files where the typechecker takes more than a few 100 ms
Gavin King
@gavinking
May 09 2016 20:48
i don’t think it makes sense to show it for every character
at most for . and for letters
but if that’s really the behavior you’re going for
it might be better to wait for the asyn typechecking job to finish before displaying the completion popup
@bjansen you know you can enable that behavior in Eclipse too, right?
it works fine, though perhaps it isn’t great for huge source files