spawn E2BIG when linting #38
Comments
|
If I had to guess, you have specified an invalid executable path in the configuration |
|
The package settings (javaExecutablePath)? Without changing the path setting (on default), it seems to work fine with a smaller Tree View (seven folders deep, 200 files), but not when the tree view's root is one directory up (~5,000 files). |
|
I've seen the same issue. I managed to get it to work by reducing my classpath to an acceptable length, but that's just gonna work for so long. A change in the linter plugin is needed where stuff to |
|
This problem may likely be avoided, by moving the classpath-argument to the option-parameter ( |
|
In favor of #58 i'm closing this issue for now. |
There are multiple problems with the previous approach of
scanning the current project and including each and every
file to linter javac.
* It takes a long time since every source java file in
the current project is recompiled with every save.
* The command line may become "too long" (see AtomLinter#38)
* It consumes a lot of computer resources (CPU, memory etc)
These problems increase with the number of source files.
Using sourcepath will let javac find the required sourcefiles
by itself, greatly reducing the number of source files it needs
to recompile. This is one of the things we need to make in order
to resolve AtomLinter#98.
It is still not optimal. Javac does not include any caching of the
files it compiles, so saving the same file twice (without editing it)
will recompile it twice as well as any java file referenced by it.
In this commit I also:
* Added ordering to the config variables (I really wanted
the sourcepath option to be next to the classpath option).
* Moved all `if (@verboseLogging)` to the `@_log` method
* Some spacing and cleanup
There are multiple problems with the previous approach of
scanning the current project and including each and every
file to linter javac.
* It takes a long time since every source java file in
the current project is recompiled with every save.
* The command line may become "too long" (see #38)
* It consumes a lot of computer resources (CPU, memory etc)
These problems increase with the number of source files.
Using sourcepath will let javac find the required sourcefiles
by itself, greatly reducing the number of source files it needs
to recompile. This is one of the things we need to make in order
to resolve #98.
It is still not optimal. Javac does not include any caching of the
files it compiles, so saving the same file twice (without editing it)
will recompile it twice as well as any java file referenced by it.
In this commit I also:
* Added ordering to the config variables (I really wanted
the sourcepath option to be next to the classpath option).
* Moved all `if (@verboseLogging)` to the `@_log` method
* Some spacing and cleanup
I am getting spawn E2BIG errors when saving .java files in Atom.
It might have something to do with the number of files in the project folder, as open a window including only a single folder from the project does not produce the error.
Steps
Expected:
Atom updates linter display without error
Actual:
No linting, following error displayed:
#### Setup:Atom 1.2.3
Mac OS X 10.11.1
The text was updated successfully, but these errors were encountered: