Trying to play around with shaders on the browser and just installed the GLSL Lint extension for VSCode, which apparently needs to know the path to a glslangValidator binary before working properly.
Said binary can (I'm assuming) be found here: https://github.com/KhronosGroup/glslang/releases/tag/master-tot
However, I've already tried multiple combinations of installation paths, both within Linux and Windows, to no avail: the extension keeps spewing an ENOENT error as can be seen in the picture below:
Considering my setup (Using VS Code on Windows with WSL), where exactly should I place this binary file so that GLSL Lint can properly find it?
I tried, for example, both ~/glslang/bin/glslangValidator and C:\\Users\\{User}\\AppData\\Local\\Packages\\TheDebianProject.DebianGNULinux_31v5hhsz12ds6\\LocalState\\rootfs\\home\\glslang\\bin\\glslangValidator (among other installation paths), but so far none worked.
What am I missing?
I just figured it out--the problem is that using VSCode with WSL will change the file system that the path should be written in. Instead of downloading the windows binary glslangValidator.exe, you should download the linux binary glslangValidator. Check this link and copy the url of the latest release, then download it like so:
cd ~ # Or wherever you want it
wget https://github.com/KhronosGroup/glslang/releases/download/master-tot/glslang-master-linux-Release.zip
unzip glslang-master-linux-Release.zip -d glslang
Then, you need to set the glslangValidatorPath to the WSL path:
"glsllint.glslangValidatorPath": "/home/<username>/glslang/bin/glslangValidator"
*Of course, replace <username> with your username, and if you installed it in a different directory, use that path instead.
I'm using Windows and installed glslang in my root path. After that I set the path parameter like this and it worked:
"glsllint.glslangValidatorPath": "C:/glslang/bin/glslangValidator.exe"
Alternatively, you could add C:/glslang/bin to your PATH variable.
I am using Windows
The following helped me: change the extension of the vertex shader file to ".vert" and the extension of the fragment shader file to ".frag".
Related
I've scoured other forums that talk about this problem and have tried all of the recommendations I've found, but I cannot seem to get VSCode to recognize my Julia.exe path and execute commands in a .jl file. Every time I run even a simple .jl file, I get /bin/sh: julia: command not found (pictured below).
I have ensured that the executable path is set properly in the .json file, and have tried moving the executable to other locations (using an M1 Mac), but it seems it still cannot find/recognize the Julia.exe:
I have even tried just pointing to the binary folder /bin, and /bin/julia.exe (with the extension), and though VSCode does not generate the error when it cannot confirm the .exe path, the actual code still generates the error above.
I'm at my wits end here. I'm sure it's a simple answer that someone could spot in a second, or know the troubleshooting for, but I've never had this issue to this degree before with installing other languages like Kotlin. Any help is greatly appreciated.
Problem was fixed by the MacOS recommendation found here:
julialang.org/downloads/platform/#optional_add_julia_to_path
Copying the binary .exe elsewhere (outside of /Applications) and changing the executable path in VSCode fixed the issue.
I am creating a VSCode extension.
I want to get the exact path of the file that is currently open in the editor!
How do i get it!.
vscode.window.activeTextEditor.document.uri.fsPath
if you want the posix version on Windows platforms (you have to deal with the :)
vscode.window.activeTextEditor.document.uri.path
I've downloaded the sources for kdesvn from the github repo as I'm thinking to look into working on an addition to the project. Now turns out, I'm not even able to properly compile the downloaded sources: I've created a directory kdesvn-build changed into it and launched cmake ../ (as described on https://github.com/KDE/kdesvn/blob/master/INSTALL-cmake) which does some stuff but then stops saying:
CMake Error: The following variables are used in this project, but
they are set to NOTFOUND. Please set them or make sure they are set
and tested correctly in the CMake files: SUBVERSION_INCLUDE_DIR
Now, I don't know what SUBVERSION_INCLUDE_DIR should be set to nor could I find it searching around the web. Anyone?
It is a directory containing svn_*.h files. If you are on Linux, you'd need to install something like subversion-dev package. On FreeBSD headers are installed with main package, and the directory is /usr/local/include/subversion-1/.
I'm developing an extension for VS code(Using javascript). Now I need the path where VS Code installed.
There is a way for windows:
var child = require('child_process');
child.exec('reg query HKEY_CLASSES_ROOT\\*\\shell\\VSCode /v Icon', function (error, strOut, strError) {
//some code...
})
But it works while user installed VS Code correctly only. If this folder was copied from other machine (it means nothing of VS Code in Registry), this function will fail.
On the other hand, it couldn't work at all on Linux or OS X.
I wonder if there are APIs which can be helpful(I found nothing), or other ways can get that path.
I don't know why are you need directory of VSCODE but I needed the directory where are my extesion.
And it can be accessed as follows:
var myExtDir = vscode.extensions.getExtension ("publisher.name").extensionPath;
Where publisher and name are in package.json
VSCode is written and uses node.js, therefore you can access both the computer, user and node environment variables.
To get the used install path of VSCode you can use the following;
process.env.VSCODE_CWD
For instance, if the first thing my extension did was;
console.log(process.env.VSCODE_CWD) it would print out the following in the debug console C:\Program Files\Microsoft VS Code (This is where I have installed VSCode to).
You can now use
const vscodeInstallPath = vscode.env.appRoot;
I thought I'd add the answer that you found yourself in case other people come looking for the same thing.
path.dirname(require.main.filename);
in Ubuntu returns (for me)
/usr/share/code/resources/app/out
and in Windows, returns
c:\Program Files\Microsoft VS Code\resources\app\out
It should return something appropriate for OSX too.
This is the folder containing bootstrap.js, which is enough to determine where the application is installed (the default locations in this instance).
In my case, I wanted the path to one of the node modules (vscode-ripgrep) which is built as part of vscode, so I have to process the path a bit more, but it does the job.
I'm using Doxygen-1.8.7, which i have downloaded from official website in dmg version. I'm using 10.9.3 MacOS. I have installed graphviz 2.38.0.0 via macports.
I use Doxygen GUI to configure it and run. Everything works great, if i choose "use build-in diagram generator". But when i use dot tool, i get this:
error: problems opening map file
/Users/pavelantonov/qtProjects/doxygen/result/11-06
1207/html/inherit_graph_21.map for inclusion in the docs!
I've tried to change SHORT_NAMES and FULL_PATH_NAMES as i find in solution from 2008, but it doesn't help.
GraphViz/bin is in paths.
There are no white spaces in *.dot names.
I got this message 'problem opening map file for inclusion in the docs', if doxygen is not able to find graphviz/dot in the path.
Try setting the path explicitly using DOT_PATH in the doxyfile.
As albert, already mentioned remove any whitespace in the path to the output path.
Another good idea is to completely remove your output directory, e.g. html, and regenerate your documentation.
It also seems that doxygen is for activating dot.exe space sensitive. Make sure your path is like this or at least without whitespaces:
D:/Graphviz2.38/bin
based on experience of Graphviz 2.38 on windows 10
The following method worked for me on Windows 10 with Doxygen 1.8.14.
Open cmd and type dot -c. Then, delete the doxygen output folder and regenerate it.
Make sure you have graphviz in your path. My graphviz is installed at C:\Program Files\Graphviz 2.44.1. So, there is no problem, even if spaces are there.