In VS Code, I have a Vue project with less than 50 files but upon running the dev server VS Code throws Error: ENOSPC: System limit for number of file watchers reached.
My VS Code Watcher Exclude settings have the following ignore patterns.
**/.git/objects/**
**/.git/subtree-cache/**
**/node_modules/**
I tried to figure out what files could possibly be setting me over the max_user_watches limit on my machine, which is 8192.
With a StackExchange answer from user "mosvy" and a script derived from that answer by another user "oligofren", I've found that the following sources are likely causing this.
| Watchers | Source |
| -------- | ------ |
| 4033 | /usr/share/code/code --max-old-space-size=3072 /usr/share/code/resources/app/extensions/node_modules/typescript/lib/tsse |
| 3889 | /usr/share/code/code /usr/share/code/resources/app/extensions/node_modules/typescript/lib/typingsInstaller.js --globalTy |
| 99 | /usr/share/code/code /usr/share/code/resources/app/out/bootstrap-fork --type=watcherService |
I'm not sure why any of these are being watched, but the first two seem to be ignoring VS Code's Watcher Exclude setting of **/node_modules/**
If possible, is it safe to exclude all three of these in the Watcher Exclude settings of VS Code?
I don't want to break my VS Code install.
Update
The Watcher Exclude settings above are what VS Code has listed as default. I added the same settings
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/**": true
}
directly to the settings.json file and the two node_modules sources listed above were removed and the error went away for that session.
After restarting VS Code and verifying that settings.json still included the changes I made, the two node_modules sources from before are no longer being excluded.
I had the same issue.
I did not found a solution, but a workaround.
Just disable this built-in extension: TypeScript and JavaScript Language Features
Related
I have a project structure like this
+-project
+-.clang-format
+-.git
+-.gitattributes
+-.vscode/settings.json
+-src
| +-somefileA.cpp
| +-someFileB.cpp
+-third_party
+-ffmpeg
| +-.clang-format
| +-.vscode/settings.json
| +-src
| +-.git
| +-.gitattributes
| +-src
| +-ffmpeg.c
+-zlib
+-.clang-format
+-.vscode/settings.json
+-src
+-.git
+-.gitattributes
+-src
+-zlib.c
I need ffmpeg.c and zlip.c and someFileA.cpp to all be formatted differently when viewing in VSCode. Some use tabs of 4, some use tabs of 8, some don't use tabs but indent by 2, some have an 80 column line limit, some have 100 column line limit, etc..
Is there a way to get VSCode to format these differently in the same instance of VSCode ?
I see I can add multiple "root" folders to a "workspace" in VSCode but:
(a) these aren't "root" folders, they're subfolders
(b) I'm not using workspaces, yet another file that is unrelated to my project that would have to get synced.
(c) ideally I wouldn't have to have to manually add more folders as more third party libraries are added. They're sub folders of a bigger project so ideally it would just work.
The same way .clang-format and .gitattributes work by covering the subtree they're in, I tried putting a .vscode/settings.json with different settings but no luck.
Are there other solutions?
Was setting up Airflow (2.1.4) in a virtual environment followed by an install of a third-party plugin "pip install simple-dag-editor"
Plugin installed successfully, however upon checking the plugin list, there were duplicated entries.
(venv) root#test-server:/opt/airflow$ airflow plugins
name | source | flask_blueprints | appbuilder_views
==================+============================================================+=======================================================+=============================================================
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
Airflow portal also resulted in 2 entries in the "Admin" section
Any idea what is happening? I tested the setup again both on a docker container and standalone on the server. Both instances did not result in the duplicated entries therefore I am suspecting it is related to running Airflow in a Python virtual environment. The server is running on CentOS 7.
I believe you might have plugin installed twice in two different places:
In "plugins" folder as simply a python package
Installed as python package
Aiflow Allows for both types of installations, and I think if you have both - it will install both.
If you change the airflow log level to verbose, you should be able to see two entries:
"Loading plugins from entrypoints"
"Loading plugins from directory: <DIRECTORY>"
They should be followed by attempts to import the plugins.
The solution would be to remove the plugings from the "plugins" directory.
It's also possible that you have two packages that have the same entrypoint - for example if you installed it with different package name before, it could also be discovered twice. Airflow checks all pacakges available and if they have appropriate entrypoint declared, it will load it as plugin. But if you enable DEBUG logging level, you should see details. You can easily set airflow logging level by config option (or environment variable):
https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#logging-level
I want to create an automated script for setting up VS Code.
Part of this is the installation of the extensions and configuring them as necessary.
So I was able to install the extensions via CLI, but can't find how to change the extension settings by only using the command line.
For example - I want to change Jest Runner settings. I found this on their readme:
Jest Runner will work out of the box, with a valid Jest config.
If you have a custom setup use the following options to configure Jest Runner:
| Command | Description |
| --- | --- |
| jestrunner.configPath | Jest config path (relative to ${workFolder} e.g. jest-config.json) |
| jestrunner.jestPath | Absolute path to jest bin file (e.g. /usr/lib/node_modules/jest/bin/jest.js) |
| jestrunner.debugOptions | Add or overwrite vscode debug configurations (only in debug mode) (e.g. `"jestrunner.debugOptions": { "args": ["--no-cache"] }`) |
| jestrunner.runOptions | Add CLI Options to the Jest Command (e.g. `"jestrunner.runOptions": ["--coverage", "--colors"]`) https://jestjs.io/docs/en/cli |
| jestrunner.jestCommand | Define an alternative Jest command (e.g. for Create React App and similar abstractions) |
| jestrunner.disableCodeLens | Disable CodeLens feature
| jestrunner.codeLensSelector | CodeLens will be shown on files matching this pattern (default **/*.{test,spec}.{js,jsx,ts,tsx})
But don't know how to access it via cmd.
Any thoughts on how to do this?
Thanks!
Was able to find a solution now.
So it turns out that the settings are actually stored in:
<userFolder>\AppData\Roaming\Code\User\Settings.json
From there I can open up the json file and add in the commands as specified by the extension's readme.
I have downloaded a copy of the 1.1.0-RELEASE tagged source code for Spring RESTdocs, but "gradlew build" is failing during the test phase. 273 of 502 tests are failing with variations on this error:
org.springframework.restdocs.request.RequestPartsSnippetTests > requestPartsWithOptionalColumn[Markdown] FAILED
java.lang.AssertionError:
Expected: is adoc snippetPart | Optional | Description
---- | -------- | -----------
a | true | one
b | false | two
but: was:Part | Optional | Description
---- | -------- | -----------
a | true | one
b | false | two
The problem looks to be that the string "adoc snippet" is prefixed to the start
of the expected output. I don't think that's right, although I can see in the AbstractContentSnippetMatcher.describeTo() why it's happening and it doesn't look very conditional so maybe it's the test's actual result that's wrong?
I have made no changes to the source code* but I don't see other people reporting this problem, so I'm mystified. I'm entirely new to gradle. Is there some kind of config I need to set up to make the tests pass? Should I be using a different target?
(OK... 1 teensy change: I removed the new-line-at-end-of-file check from the checkStyle - I'm downloading from Github onto a Windows PC.)
The problem is that the files in the zip have Unix-style line endings but, when run on Windows, Checkstyle and the tests expect Windows-style line endings.
Typically a Windows Git client will take care of this for you by converting the line endings when you check out the code. For example, the default configuration of Git for Windows is to check code out with Windows-style line endings but commit changes with Windows-style line endings.
You may be able to find a Windows utility that will batch-convert the line endings from LF to CRLF. Failing that, it's probably easiest to install a Git client (such as Git for Windows that I linked to above), ensure it's configure to perform line ending conversion, and then:
> git clone https://github.com/spring-projects/spring-restdocs
> cd spring-restdocs
> gradlew build
Hi I am facing an issue in starting the Apache DS. My environment is as follows.
Windows 7
64 Bit
I have 2 JVM's running (32 and 64bit) I have given the 32 bit JVM for the Apache DS.
When I start the service it says "windows couldnt start ApacheDS - default service on Local computer Error 1067 The process Terminated Unexpectedly"
When I check the logs in the instances folder shows the following log
STATUS | wrapper | 2013/07/15 15:27:55 | --> Wrapper Started as Service
STATUS | wrapper | 2013/07/15 15:27:55 | Launching a JVM...
INFO | jvm 1 | 2013/07/15 15:27:55 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
INFO | jvm 1 | 2013/07/15 15:27:55 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
INFO | jvm 1 | 2013/07/15 15:27:55 |
STATUS | wrapper | 2013/07/15 15:28:01 | <-- Wrapper Stopped
Can Someone please help me to start the Apache DS Service
Go to the
Program Files\ApacheDS\instances\default\conf
and modify the log4j.properties Change all FATAL log level to the DEBUG and restart the service. You can find what is the main reason of problem in new log files that are produced in the
Program Files\ApacheDS\instances\default\log
For example I have this problem after change the log level, I found the main error is
ERR_250_ENTRY_ALREADY_EXISTS ou=system already exists!
And this is an open issue in the ApacheDS
https://issues.apache.org/jira/browse/DIRSERVER-1954
Hope this help you!
Open Installation path and go to below path or where ever you have installed your Apache DS,
open C:\Program Files (x86)\ApacheDS\conf\wrapper.conf xml file in text mode
find below path,
Path to java executable
wrapper.java.command
you need to update "wrapper.java.command=" with you the java installation path example as below,
wrapper.java.command=C:\Program Files\Java\jre1.8.0_221\bin\java.exe
follow above path or find the java directory and update,
you are fine to fire your ApacheDS service, go to services(or C:\Program Files (x86)\ApacheDS\Manage ApacheDS --> Double Click) find ApacheDS and start.
This isn't my solution - but I think this answer the temp directory problem with also explaining why it occurs - Please find the link and the answer below:
https://issues.apache.org/jira/browse/DIRSERVER-2007
I tested this change (since it made it into the lastest version of ApaceDS server) and it is still not working on Windows 2008 when running as a service, but the problem is not the length of the path but the ability to write the temp directory. On my system the TEMP & TMP environment variables are set to:
%SystemRoot%\TEMP for System and for User is it %USERPROFILE%\AppData\Local\Temp.
Since the ApacheDS service is running as "Local System account" I would assume it would be trying to write to %SystemRoot%\TEMP. For whatever reason (and I can think of a few) ApacheDS can't create a temp file in that folder.
I fixed by creating a tmp folder in the instance directory and added the following line to wrapper.conf:
wrapper.java.additional.6=-Djava.io.tmpdir="%INSTANCE_DIRECTORY%/tmp"
That fixed the problem. I think it would be better if ApacheDS explicitly set it's temp folder to someplace it controlled and knew it could write to. A sys admin that wanted the files somewhere else could make a symlink or change the wrapper.conf. Those temp files contain ldap data so it would be better from a security standpoint to keep them with the rest of the instance data. If the instance is going to have its own log folder it might as well have its own temp directory.
Might it be, that you have selected javas /bin folder during installation as Java root directory?
If so, set it one level higher, as /bin is not the root directory.
If you have the below error all you gotta do is create a 'Temp' Directory in 'C:\Windows\system32\config\systemprofile\AppData\Local' and that's it.
C:\Windows\system32\config\systemprofile\AppData\Local\Temp\tempks1231340801626329934ks
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
at java.nio.file.Files.newByteChannel(Unknown Source)
at java.nio.file.Files.createFile(Unknown Source)
at java.nio.file.TempFileHelper.create(Unknown Source)
at java.nio.file.TempFileHelper.createTempFile(Unknown Source)
at java.nio.file.Files.createTempFile(Unknown Source)
at org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:318)
at org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:219)
at org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:152)
at org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:175)
at org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)*
I got the same issue. I managed to solve that, and I succeeded. The solution is as follow:
Open Java settings in Control panel (Control Panel>Programs>Java on,
my case, windows 7)
The setting screen shows up. Then click on Java tab. Click View...
button
At the User tab, click on Find button
After that, you choose the folder that contains the x86 JRE.
Finally, click Finish to add that x86 Run-time Environment to be used by programs that need the x86 version to run.
That's all. Try it.
delete file C:\Program Files (x86)\ApacheDS\instances\default\conf\config.ldif