I want to link LanguageTool to the ngram data I downloaded from their website. I was able to do this in the Visual Studio Code version of LTeX using the Language Model option. I believe this passes an argument to the executable. How do I set the Language Model path when using LanguageTool with neovim via coc-ltex?
We're trying to maintain a single set of Visual Studio Code extensions within our organisation, managed centrally. In our ideal scenario all end users have the same extensions installed, those extensions are updated on their behalf, and they are not able to install additional extensions.
We had achieved this to date by:
Installing extensions to a directory under C:\Program Files and setting the (undocumented) VSCODE_EXTENSIONS environment variable to point to that location.
Configuring a scheduled task (run as SYSTEM) that executes a powershell script with a list of extension_ids that calls code install-extension <extension_id> on each.
This solution worked until a breaking change in v1.74 expected to be able to write a new extensions.json file to the extensions directory.
Whilst we can get around this by creating a extensions.json file in that directory, I don't want to go too far down the wrong path. Is there a preferred method for centrally managing extensions for Visual Studio Code?
I am looking to build a VSCode Extension around a CLI tool which we have been working on. An example command would be
myCLI retrieve SourceName
This would be run from a specific directory (for example c:/workspace/myproject) which has been setup and contains a settings.json file for some config arguments.
This CLI has been designed that the methods which are called (for example 'retrieve') are exposed directly so the CLI itself is a wrapper also.
When trying to call these methods directly from a VS Code Extension, it is always checking in the C:/Program Files/Microsoft VS Code directory, which I understand is where the Extension is excuting from.
Now, the question: Is there any way for me to force that any time we call the method (for example 'retrieve') that this would look into the current workspace folder (C:/workspace/myProject) , and not the VS Code one (C:/Program Files/Microsoft VS Code)?
Notes which may change answers
CommonJS (not yet ESM)
We currently cannot pass in a full qualified path (for example C:/workspace/myProject), it is only looking for ./settings.json since it depends on where the CLI has bene run from
I want to avoid calling the CLI directly, as I would like to bring many of the CLI features into the VS Code Extension directly to improve user friendliness.
I want to be able to extend/override some of the VS Code source in my extension, but I'm not sure how to do so. Is this possible?
Extensions (as the name says) can extend the functionality of the host application (here vscode), but they are separate code parts which have no access to the host application code and structures (except those particularly exported for use by extensions).
If you want to modify vscode source code then clone the repo, change the code and build your own vscode application.
I have a Visual Studio 2010 solution that contains a library of functions, and I would like to be able to use MATLAB as one of several possible front-ends to this library. Therefore, I would like Visual Studio to automatically generate a mex file when I build the solution, without having to export all my build options and paths to mexopts.bat and open MATLAB to build the file from there. I have seen several suggestions to achieve something similar, for example in these posts:
Matlab 7.1+ and Visual Studio 2005
Compiling a MEX file with Visual Studio
How to use CMake and Visual Studio 2010 (64 bit) to build a MATLAB R2011a (64 bit) mex file?
However, they either seem a bit outdated (making references to files that are no longer to be found) or make use of external tools (eg. CMake). Does anyone know how to set up a new project (within the existing solution) in Visual Studio (2010 and newer) that will build a mex file for contemporary MATLAB releases?
After some experimenting with guidance from this page mentioned in the question, it seems like starting with an empty C++ project the following settings in the project's Property Pages are necessary and sufficient to build a working .mexw64 from Visual Studio 2010:
Configuration properties -> General:
Set Target Extension to .mexw64
Set Configuration Type to Dynamic Library (.dll)
Configureation poperties -> VC++ Directories:
Add $(MATLAB_ROOT)\extern\include; to Include Directories
Configuration properties -> Linker -> General:
Add $(MATLAB_ROOT)\extern\lib\win64\microsoft; to Additional Library Directories
Configuration properties -> Linker -> Input:
Add libmx.lib;libmex.lib;libmat.lib; to Additional Dependencies
Configuration properties -> Linker -> Command Line:
Add /export:mexFunction to Additional Options
$(MATLAB_ROOT) is the path to Matlab's root folder, eg. C:\Program Files\MATLAB\R2013a.
So far this has only been tried from a solution created from scratch and built for Matlab 2013a 64-bit. I assume that to build for 32-bit one only needs to change both occurrences of 64 to 32. I will update the post when I have confirmed that this works for an existing solution.
EDIT: As expected this works for projects added to existing solutions. Remember to set the new project to be dependent on the project that creates the library.
Edit 2: Following this question I can confirm that the above steps work in Visual Studio 2012, 2013, and 2017 too.
Quickly Setting up Visual Studio Projects for MEX files with a Property Sheet
All of the settings can be applied via property sheets, a mechanism for rapidly applying Visual Studio project configurations.
Steps:
Download the property sheet (MATLAB.props) from this GitHib repo.
It's short and sweet. I'd actual urge you to make your own to learn what's involved in the process. See the Property Sheet Details section below for a description.
Set the MATLAB root environment variables: MATLAB_ROOT for your 64-bit MATLAB installation, and MATLAB32_ROOT for any 32-bit MATLAB installations (e.g. C:\Program Files\MATLAB\R2014b\). This folder has the subdirectories bin, extern, sys, etc. Restart VS if it's opened.
Create an empty DLL project in Visual Studio, optionally creating a x64 solution platform. Do this by choosing "Win32 Project" and selecting DLL as follows:
In "Property Manager" (select from the View menu), for each project's build configuration, right click and choose "Add Existing Property Sheet...", and select the appropriate property sheet (32 or 64 bit). (See screenshot below)
That's it!
Just remember that when going between MATLAB to use your MEX file and Visual Studio to build a new version, it will be necessary to run a clear mex or clear specificMEXFileName to be able to overwrite it.
I build almost all my MEX files this way.
UPDATE (05/22/15): The file MATLAB.props now supports the Parallel Computing Toolbox for using mxGPUArray objects. If the toolbox path and library (gpu.lib) exist on your machine, they can be used. Just include the CUDA SDK "Build Customization" (that should be installed if you've installed the CUDA SDK and installed the Visual Studio integrations) to include cuda_runtime.h, etc. Finally, link with cudart_static.lib (but keep Inherit... checked or you will get other linker errors).
Property Sheet Details
There are only a few important settings in the property sheet:
Adding $(MATLAB_ROOT)\extern\include to the AdditionalIncludeDirectories paths (with inherited paths from parent configurations) -- the location of mex.h.
Adding $(MATLAB_ROOT)\extern\lib\win64\microsoft to the AdditionalLibraryDirectories paths -- the location of libmex.lib, etc.
Listing the libraries: libut.lib;libmx.lib;libmex.lib;libmat.lib.
Exporting mexFunction (it's a shared library): /EXPORT:mexFunction.
Setting the output file extention (e.g. .mexw64 for x64).
Not necessary, but it also specifies an output manifest that is NOT embedded in the library, sets MATLAB_MEX_FILE, and turns on generation of data required for profiling.
For completeness, note that there is a more formal "build configuration" system for project configuration, which includes a property sheet, but a loose property sheet is sufficient for setting up a simple MEX project.
A Note About -largeArrayDims
The -largeArrayDims option is a switch to the mex command in MATLAB that simply indicates not to define MX_COMPAT_32. So, in Visual Studio, you don't have to do anything since this is not defined by default. If you want the opposite behavior (-compatibleArrayDims), then define MX_COMPAT_32 in the Preprocessor section.
What's libut.lib for?
I include libut.lib, which provides a few nice functions for detecting a break (CTRL-C) from within a MEX file. The relevant declarations (although this is getting off topic):
// prototype the break handling functions in libut (C library)
extern "C" bool utIsInterruptPending();
extern "C" void utSetInterruptPending(bool);
For building/linking/compiling, automate visual studio with an extension or macro to
start a thin Matlab client (using -nojvm -noawt -nodesktop -nosplash commandline options, this starts in less than a second on my machine)
generate the binary by calling mex (including the other dependencies etc).
if debugging is activated, attached the visual studio debugger to your newly started thin matlab client(any break points you click in VS will be active).
I have automated this for visual studio 2010. This way, you work with your mex-wrapper entirely from the visual studio IDE, have 4 extra pushbuttons for debugging etc. Compile errors are echoed from a matlab terminal window instead of within Visual Studio. Find the Macros uploaded here:
http://www.mathworks.se/matlabcentral/fileexchange/39549-visual-studio-toolbar-for-mex-interface-with-video-tutorial