Closed OliverJAsh closed 8 years ago
How big is the project you are working with? It might be a case of the server just being overloaded with code, or a case of specific code causing slowness in the analysis. Can you reliably reproduce it? With code that you can share?
I can’t seem to reliably reproduce it unfortunately, however the project I’m working on is a reasonable size. I’ll update you if I can reproduce it at a later time.
I think it would be useful to add options to this implementation that allow for the specification of fetchTimeout
and also an implementation of --persistent
. flush
might also be useful, especially w/ --persistent
in case caching gets stuck w/ the wrong contexts at some point.
Any interest in this?
The analyzer is persistent by default. How would a fetch timeout work?
I was just going by the documentation on ternjs.net. So I clearly don't understand the implementation fully.
Per the docs regarding CLI:
--persistent
By default, the server will shut itself down after five minutes of inactivity. Pass it a this option to disable auto-shutdown.
Per the programming interface:
fetchTimeout
(number) Indicates the maximum amount of milliseconds to wait for an asynchronous getFile before giving up on it. Defaults to 1000
My comment intended to describe the potential utility of being able to control these values w/ user settings.
Right, I see what you are referring to. That timeout is just for i/o, and mostly useful when running in the browser and fetching files over HTTP. It won't make a difference during analysis.
The tern_arguments
option in Sublime Text an be used to pass arguments to the Tern server.
Okay. I guess I mistakenly equated that to the frequently experienced "timeout" dialog that appears when tern is doing some heavy thinking. It normally occurs after not touching the editor for awhile or mistyping something. After it happens, it usually doesn't return for awhile.
The only info I get in the sublime console is: error: timed out
.
Thanks for the tip on tern_arguments
. I totally missed that :)
@marijnh Just a quick update: I tried passing the --persistent
flag and this causes the application to hang. Tern fires up and starts working as usual, but when it gets to the state where it would normally time out, the application just hangs indefinitely.
I tried passing the --verbose
flag as well, but as expected there is no logging to Sublime's console (I'm not surprised that this wasn't baked in).
Not sure what's going on here, but if I get a free moment I'll try to dig deeper.
We have had cases before where specific code would trigger some infinite loop or combinatory explosion that caused Tern to run pretty much forever. A script (or set of scripts) that reproduces the problem would be very helpful.
I'm happy to oblige, but I don't want to waste your time. I'd like first to find the code the triggers this in Sublime, then see if I can reproduce it directly.
However, if you'd like to dig in now, I can tell you of one particular node module that is ubiquitously horrible: tsd. It's so bad, that I have to specifically disable it from loading in .tern-project
, because once it's been referenced via require('tsd')
, every keystroke triggers the timeout error.
I just stumbled on this yesterday.
I didn't look yet, but tsd
has a bucketload of dependencies, which probably knock the Tern server dead.
I should really start defining a policy in the node plugin (and other plugins that load files automatically) that helps notice cases like this, and just stops loading new files at a certain depth from the originally required file when a size boundary is exceeded.
But, as always, time is scarce. I've opened https://github.com/marijnh/tern/issues/308 for myself to track this.
Yes, I figured this was the case with tsd
. Frankly, I've never seen anything like it. It's a groaning monstrosity :P
I've written a rather big, scary patch to try and address this (attached to this issue). Could you get the latest code and see if it improves the behavior? It'll cause completions for tsd
to fail entirely, since it is too big to load as a dependency (by default), but it should make the Tern server survive such dependencies, and work properly for the rest of the codebase.
Big scary patch? @marijnh, tern itself it pretty big and scary to us mere mortals :-D I'll put it to use today and report back tonight.
I have spend the last two days with this. It really seems more stable. I wish I would have recorded metrics of the errors (i.e. frequency, project/file sizes, # and complexity of requires, etc). So my assessment could be more objective :(.
I still get timeouts on occasion, but only after I come back to the code after stepping away for a few minutes, something that always has triggered it. The fact that it breaks out of the really bad stuff is great, IMO.
I haven't noticed degradation in functionality that I could reliably say is caused by the patch (since I'm looking more closely, I'm likely to see more).
I think it's a good step.
Thanks for the feedback. Getting timeouts when coming back to code is not something I've experienced -- but then, I'm rarely working with projects that have big dependencies. Also, I work with the Emacs plugin, which might have different bugs than the ST one.
In any case, I don't have a theory of where that problem might be coming from. Is there an easy way to get backtraces in Python running in ST?
I will try to dig into it and see if I can figure something useful out. For me personally, I find that it is much better now, as I mentioned. If I can't dig out something fairly quickly, I'd much rather focus on something more useful.
Are you open to help on any of the following:
ts.d
in DefinitelyTyped is spectacularly attractive, and this is something that IntelliJ, et al. is able to do now to add hints to regular JS files)If you're interested in any of these, let me know and I'll open an issue
I updated the TypeScript parser a month or so ago. Is it already outdated again? (I bet they rewrote the whole parser again too, those bastards).
As for a repo of definition files -- that'd be a lot of work to maintain. I'd be happy if someone does it, but I'm already overloaded.
Specific bugs for JSDoc features you can report as issues. But please describe the desired behavior in detail (and link to relevant docs), since I don't use JSDoc, and am not very familiar with it.
The docs for Tern... well, it's a complex, multi-layered system and documenting all layers properly is a huge undertaking that, again, I probably won't find time for. Specific suggestions or pull requests welcome.
Cool, I think I have a decent idea of where you're at then. Regarding the TypeScript parser, I actually haven't tried it in a long time. I'll give it another go.
Tern is such an awesome achievement, so if I can make something valuable happen I'll submit a PR.
Does the timeout have to throw an alert? It would be a better user experience if it failed silently, no?
Is Tern in general any use when the timeouts start happening? Maybe a better response would be a dialog that allows you to turn Tern off for the remainder of the session? I'm somewhat suspicious of silent failure -- it is bound to confuse users.
No, it’s not any use. Every character you type, the caret pauses and then a timeout occurs. I have to disable the package completely.
On 5 May 2014, at 08:25, Marijn Haverbeke notifications@github.com wrote:
Is Tern in general any use when the timeouts start happening? Maybe a better response would be a dialog that allows you to turn Tern off for the remainder of the session? I'm somewhat suspicious of silent failure -- it is bound to confuse users.
— Reply to this email directly or view it on GitHub.
Attached patch makes it possible to turn off Tern for a project when an error pops up.
Disabled permanently or until the session is restarted?
Until the session is restarted. The plugin does not save anything to disk.
Closing this issue because commit 659ff49 provides a workaround.
I get "timed out" errors quite often (every 5 minutes or so). I'm using the Node plugin.