- This topic has 40 replies, 3 voices, and was last updated 5 years ago by
.
-
Posts
-
Fedor,
Just in case you missed it, I sent you a private message about your account expiration.
The latest release will have fixed a number of issues you raised earlier, and we’re eager to have confirmation from your end, after a suitable amount of testing of course
1) Undo in JSON (and other files too)
2) Excess “Watch” tabs being opened
3) node_modules now automatically marked derived
4) Odd truncation of error / warning messages
5) Issues with renaming an unsaved file / save-as
6) The entire build / validation system has been reworked, and we’ve added the ability to run linting against the entire project as well. Please read this updated document for details. We’ve also put a significant amount of work into synchronization of errors and warnings between the editors, views and console output. Note that we’re still not using “ng serve” – it is something we have tried in the past and have researched, but is problematic -still being looked at.We’re going through your latest observations in detail, and will follow up with notes or questions if any. Again, sincerely appreciate the detailed feedback.
Hi Brian,
the editor performance-wise it works much better. Though still, I have to restart once in a while, after a few hours it starts to be sluggish (seems like a memory leak or fragmentation). But now it seems to be more consistent and reliable so not a critical problem.
Some critical problems:
Errors are still not in a good sync (happens a lot and makes a lot of friction):
– Non-existent old errors don’t go away. Sometimes they are without [Stale], sometimes with, sometimes [Stale] appears briefly then disappears (but the error stays forever). The red error mark is in the editor, the error mark is in problems view, but the error code is not highlighted in the editor text (and, say, if it is for already fixed import it is navigable and seems ok except the error mark).
Incorrect compiler parse (rarely).
Some screenshots attached.
Currently, I have to delete them manually from problems view.Most critical – after changes sometimes there is very long delay until navigation and code/import assist are available, showing tooltip ‘Loading…’. It sometimes stays like that for very long, far after tcs finished compilation.
While it may take time to update things (though when it happens, it takes way too long by any measure), the previous state of assist should still work until the update (with a Loading mark but not blocking suggestions), it is preferable having outdated assist than no assist.
And this ‘Loading..’ is not reflected anywhere in IDE progress or status, one can’t know there will be ‘Loading’ delay until hitting ctrl+space and being stuck.
This is an extremely annoying problem as it significantly slows down the pace of development, it happens especially at the time of fast changes when assist is desperately needed.
This happens usually on adding a new component, file rename, significant changes, broken code blocks, etc. but sometimes on small changes as well.
Sometimes only IDE restart helps as it is faster than waiting for ‘Loading’ finish.
During this ‘loading’, problems view is updated live (not on save) and sometimes slowly adding or removing errors after a long delay.Still, not all errors (especially templates) are displayed in problems view until opening the problematic file directly.
Some more observations:
Check for project issues / validate is VERY slow, for some files it takes several seconds per file (observing by the progress).
Lint – sometimes shows in Problems “loading reference ‘https://schemastore.azurewebsites.net/schemas/json/tsconfig.json’: Request vscode/content failed unexpectedly without providing any further details”
Validation runs ng lint without current project parameter, running on all projects in angular workspace (still finishes far before validation).
The manual lint/validate on the whole project is useful, but in general, there should be mode of continuous background linting. IDE knows exactly what changed and affected so it can do a better job than the whole workspace lint, showing problems continuously (maybe with some lag, indicated by progress status).
A non-existent template file for the component – no error even when opening the file.
Linting and validation build pipeline in project properties – broken link
Frequently there is notification “the task tsc: watch … is already active [Terminate] / [Restart]”
No scss validation, no errors on broken import in scss
Are there any findings or estimation for the assist delays after changes, did you succeed to reproduce it? I find myself frequently typing import paths manually or restarting IDE, if the fix seems out of reach soon I’ll probably give up.
Some observations on file locks and processes:
– A folder was locked system-wide on a failed folder move from IDE to explorer (similar to discussed before).
– Only “CodeMix Engine.exe” holds a handle to the folder – two different processes (from a bunch of a weird “CodeMix Engine.exe” processes hierarchy) hold handle to the folder and one of them also to a child folder.
– Closing ALL projects in IDE and all terminal windows did not release the lock and it continues to hold folder handles despite projects being closed.
– After time there NO any node js process running. Only CodeMix processes still hold the handle and the lock.
– After killing “CodeMix Engine.exe” that held the handle, new processes “CodeMix Engine.exe” are created and now they hold the handle, the folder is still locked.
– After killing the whole “CodeMix Engine.exe” processes tree the lock goes away and the move is successfully completed (outside of IDE).
– After the previous step IDE shows notification popups “Unable to open xx: File not Found” / [Create File]. Note, all projects are closed!
– In error log there are errors “Project is not open” and a bunch of errors for files and folders in the previously locked folder, e.g.:Project 'xxx' is not open. java.lang.Exception: Project 'xxx' is not open. at org.eclipse.core.internal.resources.ResourceException.provideStackTrace(ResourceException.java:42) at org.eclipse.core.internal.resources.ResourceException.<init>(ResourceException.java:38) at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:148) at org.eclipse.core.internal.resources.Resource.checkAccessibleAndLocal(Resource.java:210) at org.eclipse.core.internal.resources.Resource.getPersistentProperty(Resource.java:1115) at com.genuitec.eclipse.server.ui.editor.preview.TargetURLManager.getRawEnabledFor(TargetURLManager.java:496) at com.genuitec.eclipse.server.ui.editor.preview.TargetURLManager.urlFor(TargetURLManager.java:488) at com.genuitec.eclipse.server.ui.editor.preview.TargetURLManager.getProvidedURL(TargetURLManager.java:464) at com.genuitec.eclipse.server.ui.editor.preview.TargetURLManager.calculateTargetURL(TargetURLManager.java:199) at com.genuitec.eclipse.server.ui.editor.preview.PreviewController.calculateTargetURL(PreviewController.java:818) at com.genuitec.eclipse.server.ui.editor.preview.PreviewController.getBestURL(PreviewController.java:799) at com.genuitec.eclipse.server.ui.editor.preview.PreviewController.getTargetURL(PreviewController.java:793) at com.genuitec.eclipse.server.ui.editor.preview.PreviewBrowser.verifyPositionNow(PreviewBrowser.java:265) at com.genuitec.eclipse.server.ui.editor.preview.PreviewBrowser.lambda$0(PreviewBrowser.java:231) at org.eclipse.swt.widgets.RunnableLock._run(RunnableLock.java:40) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:50) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3933) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3564) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1173) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1062) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:628) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:563) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:151) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:155) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:199) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:391) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:246) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:595) at org.eclipse.equinox.launcher.Main.run(Main.java:1501)Resource 'xxx/foldername' does not exist. org.eclipse.core.internal.resources.ResourceException('xxx/foldername')[368]: java.lang.Exception: Resource 'xxx/foldername' does not exist. at org.eclipse.core.internal.resources.ResourceException.provideStackTrace(ResourceException.java:42) at org.eclipse.core.internal.resources.ResourceException.<init>(ResourceException.java:38) at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:330) at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:204) at org.eclipse.core.internal.resources.Container.members(Container.java:242) at org.eclipse.core.internal.resources.Container.members(Container.java:229) at com.genuitec.eclipse.code.core.projects.util.ProjectTypeDetector.checkContentOnCondition(ProjectTypeDetector.java:195) at com.genuitec.eclipse.code.core.projects.util.ProjectTypeDetector.isGo(ProjectTypeDetector.java:169) at com.genuitec.eclipse.code.ui.extensions.PackRecommender.lambda$1(PackRecommender.java:107) at java.util.concurrent.CompletableFuture.uniApply(Unknown Source) at java.util.concurrent.CompletableFuture.uniApplyStage(Unknown Source) at java.util.concurrent.CompletableFuture.thenApply(Unknown Source) at com.genuitec.eclipse.code.ui.extensions.PackRecommender.getRecommendationForFile(PackRecommender.java:90) at com.genuitec.eclipse.code.ui.editor.panel.PackRecommendationPanel$1.run(PackRecommendationPanel.java:98) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)I don’t experience any locks if I didn’t start CodeMix, say if I run ng serve. The theory was it is somehow related to tsc + node, but does it hold with the above? It seems to me like handle leaks in code mix and locks are produced by CodeMix, worse it seems like editor artifacts leak since no editor nor project is open.
Fedor,
1) We’re taking at a look at all your problems, but especially the validation and synchronization problems. While it’s working just fine on our test systems, we’ve expanded testing and noticed that there are other systems on which it is exhibiting problems.
2) Nobody on our team has been able to reproduce the “Loading…” delay. I know it does appear from time to time, but only for a second or so – delays of the magnitude you’ve described have never occurred. I believe the size of your project has something to do with it – so we’re trying now to reproduce with much larger projects. Earlier, you said there were ~ 3000 source files in your project. Are we thinking about 500-700 components and 3 to 4 files for each component? Trying to replicate at project similar to your scale as closely as possible.
3) Locking issues: We really appreciate all the detailed information provided and the additional tests you’ve carried out. IMHO, the locks are coming from the TS language server and I’m not sure if that shows up as an externally running process. You’ve provided a lot of information on this – I’ll let the dev team analyze, comment and test in more detail.
I have one question on this: I would think that the entire project (or maybe starting at the source folder level) should be locked and not a deeper sub folder only. By any chance do you know if only a specific folder (like say something corresponding to a single component) was locked, while other similar folders were not being locked by the IDE?
Thanks!
Hi Brian,
I recorded some test cases, please see attached with video and descriptions in appropriate txt.
https://www.dropbox.com/sh/wz5wb1pyl9ijr8l/AACr9Ssnevd6izenvqCVbIO4a?dl=0
Except case 06 all was easily reproducible on a tiny project.2) Please see case 06 for delays on the generated project of moderate size.
For the project size, in general, I would like to break the project down into smaller pieces (and we already do it in command line build by factoring out the code to libraries). But there are two problems:
a) you (or any IDE that I know) don’t provide a smooth workflow with Angular libraries or NPM packages. There is no automatic IDE build handling the dependencies and the details like in Java or Adobe Flex, one needs manually watch or rebuild libraries (I think I mentioned this before). So for a smooth work on a large project we just map library import paths to sources in tsconfig.json. This is suboptimal and wrong in general, but I didn’t find another way for simple development without quirks.
b) The way angular works, break down into libraries is probably not that useful IDE-wide, as of now it doesn’ reduce much the validation and compile burden.
I would be glad if you can share a smooth Angular workflow that will allow breaking the Angular workspace into separate projects that can work smooth in IDEs.
By the way, are there any plans to support Bazel? This seems the trending direction from Google including Angular, but unfortunatelly , as you know, they gave up on Eclipse and team up now with the other IDE for anything.3) The locks may come from ts server, but locks and Java exceptions like ‘folder does not exist’ ‘project is not open’ after ALL projects and terminals were closed in IDE don’t look right to me. Why there is anything monitoring a file on a closed project?
I did not check for locks but handles I think are held on the complete folder hierarchy where files were opened in editor. I’ll check more on occasion.
I’m also considering launching up next week a virtual machine to reproduce this, then I can either share the VM with you if the problem happens or if it works I’ll have a good environment. Playing with node/npm version may also solve this, you can see exact versions I use in the test-app project for 06.Warnings/errors obscure type definitions.
If there is a warning or hint on a variable, say ‘is declared but is never read’, the type hint on the variable is not shown, showing the warning instead. Frequently the type is required while fixing the warning, so it is problematic (actually problematic in any case). The tooltip/hint should list all hints available for the block, not suppress one by another.
Regarding locks, I saw that folders are opened from CodeMix without FILE_SHARE_DELETE and it opens and holds handles to all watched children subfolders. I found this:
https://github.com/nodejs/node-v0.x-archive/issues/8371
looks like this may be the issue? Who actually opens each and every folder, ts or CodeMix? When I run tsc watch alone, it is not holding open children folders. On the other hand, you were supposed to readily reproduce this on Windows if that indeed was the issue.I also did a clean upgrade of node to latest 12, IDE folder locking behavior is still the same (after upgrade, a first glance tcs watch seems to run faster on changes and the suggestion ‘Loading’ delay seems a little smaller, but need to be tested more for conclusions; the downside is angular cli builds seem to use more memory and are a bit slower; this is not CodeMix problem, of course, but may affect its performance on some systems).
———
Btw. I mentioned before idle AngularIDE CPU usage. After upgrading node, I did notice that standalone cli tsc watch constantly uses some CPU. After setting system-wide TSC_NONPOLLING_WATCHER=1, tsc watch CPU is zero and idle AngularIDE also went near to zero! (so far file changes are detected properly but tested only shortly).Note, there are still insignificant spikes from CodeMix Engine. It seems to poll source files constantly (see attached) through node, while tsc watch alone doesn’t poll them or access except on change. There are also no subfolder locks when the standalone tsc watch is running.
———
I have a question – if codemix already watches and recompiles files, why terminal tsc watch tab is needed at all? Also, why compile errors are not updated immediately when this tab finishes compilation (if it is used somehow, the CodeMix/watch tab interaction is not that clear to me)? Watch tab finishes sometimes long before CodeMix compilation/error update.———
Some observations for editor jitter (before node upgrade, didn’t had enough time to experience after), not sure if anything useful:
1) I monitored the java heap and it does not exhibit any obvious abnormalities at the time it happens. May be v8 heap/gc related.
2) It is not reproducible under exactly the same conditions after the error is fixed (no jitter after returning same error back)
3) Mostly happens when editing complex generics class definitions in<which completely break code structure for a large file (e.g. adding an{after `<‘)
4) Seems to happen only after some time editing and various compile errors go and return quickly.
Still not clear what happens, hard to reproduce consistently.Attached is a recording for the editor jitter.
As you can see from the video, it is a lot of pain to work with an IDE that behaves like this. This pain is not worth any IDE advantages, so I’m investing the time in hopes that we’ll solve this for years to come.
Something to note is that things were noticeably improved since upgrading to node 12 and setting the watch flag (as I described before). These come from performance and compile speed improvement though. Something is obviously wrong with the implementation if the compilation/error update blocks the input. It doesn’t matter what is the performance of the compiler, the implementation should never block the editor input.
Fedor,
Again, thank you for the massive amount of time you’ve put into the recordings and detailed descriptions. Some of these are obvious bugs with validation, while a few others would be ideal, but possibly out of scope for the immediate future.
I could replicate the Loading issue for instance, where it took a significant amount of time for the content assist to show up for an empty file.
As far as the file locking is concerned, the dev team is aware of your notes and questions; as they know how it works internally, I will have them investigate and respond accordingly.
The jitter you see is terrible, nobody can be expected to code like that. In our tests so far, we hadn’t been able to reproduce anything remotely like that; yes, we’ll take a look at how the compilation/validation is affecting typing.
Thanks again for the fantastic feedback, Fedor – much appreciated.
