I recently installed the Haskell extension in Visual Studio Code which is powered by the Haskell Language Server. Each time I open a different Haskell file in the editor a new process named "haskell-language-server-1.0.0-linux-8.6.5" is created. The result of this is that each time I hover over a word in my program I see everything, like types or errors written two times. More important each of these processes consumes about 1 Gb of RAM and eventually my system crashes. Is there anything I could do to avoid all of this?
I encountered The same problem.
To solve this problem, I opened the folder containing all wanted files, i.e.,File -> Open Folder. This solution is sufficient if you have all wanted files located within a single folder. This folder can contain other folders that also contain haskell files (or any similiar recursive file structure), and still only one language server will be created
If you want to use files that are located in different folders, there are two options depending on how many language servers you are willing to tolerate:
Single Language Server: Move all folders containing wanted files to a new folder; as visual studio code views this as a single folder, only a single language server is spawned.
Specific Limit of Language Servers: Create a workspace and add folders containing wanted files to it. More specifically: a) Close any current workspace, folder, or file( these actions can be found at the bottom of the file menu), b) add wanted folders to workspace by File->Add Folder to Workspace, c)(optional) If you want to use such a setup in the future you can save this workspace by File -> Save WorkSpace as. Each added folder that is added directly through the Add folder to Workspace action will spawn a new language server;it is the number of folders opened this way that determines the amount, not the total amount of folders open.
Related
I have a very big android project and I want to search for all the entries in androidTest for certain lines of code. In this project I have a separate folder with a big amount of modules grouped up in different directories.
I'm trying to write a scope that will show only entries located in folders called androidTest.
The scope, I suppose, is file:*androidTest*/, but it does not find all the entries (does not search through all the files in project)
Did someone entered this problem?
I tried to use file:*androidTest*/ pattern but it definitely does not work properly.
I save several projects in a same folder by manual click Project -> Save Project As...
and I used to use cmd + ctrl + p to open Switch Projectlist to switch between projects
and everything's works fine.
but today, I accidentally remove my Switch Project list in by click Project -> Open Recent -> Clear Items, so my Switch Project list is empty now...
I know I could add them back through reopen ALL my projects. due to the number of projects is pretty a lot, that will be kind of annoying to add them back one by one.
I wanna know if there's a smarter way to do that for me.
maybe import all my *.sublime-project files from folder or something.
thanks
Short of manually opening every project, I don't think there is any way to do something like this directly. There isn't a command or plugin endpoint that I'm aware of that lets you open a project by name or filename, so it's not possible to create a plugin to do the work, and Sublime doesn't have the ability to pre-load the list of packages directly either.
That said, it is possible to manually update the list of recent projects, but whether or not that is more or less work than opening all of the projects is something to consider.
If you use Preferences > Browse Packages from the menu or the command palette, a file browser will open on your Packages folder. From there go up one directory level and go inside of the Local folder, where you will find a Session.sublime_session file.
Sublime saves it's state into this file when you quit it, and uses it to restore state when you start it again. Here you will find all of the saved information, such as the windows and files that were open and so on.
Changing this file will change the data that Sublime loads, so you can modify the session file to set up the data that you want. You need to make sure that you modify the file while Sublime is not running or your changes will be ignored and clobbered away. Also it's a good idea to make a backup of the file before you start in case things go pear shaped.
Down near the bottom of the file you will find a top level key named workspaces, and inside of it a recent_workspaces key:
"workspaces":
{
"recent_workspaces":
[
"/home/tmartin/local/src/OverrideAudit/OverrideAudit.sublime-workspace",
]
}
This is where the list of recent projects is stored for use in the menu and the quick switch project command. Particular things to notice are that the entries are naming sublime-workspace files, and that the paths are absolute.
NOTE: On windows, the filenames stored in the session file are in a format like /C/Users/tmartin and not c:\users\tmartin; on that platform you need to make sure that you adjust the paths accordingly. As long as there is already at least one entry in the list when you look at the session file, you can easily see how to construct the paths that you need.
Despite the name of the commands and menu items, what you're actually switching between is different workspaces. Every sublime-project is associated with a sublime-workspace file, which acts as a dedicated sublime_session file for that particular project. This mapping is one-to-many in that you can have multiple workspaces for the same project file, allowing you to reference the same paths in multiple windows but have different window layouts.
While Sublime is not running you can edit this file to add in the full paths to all of your workspace files; when you start Sublime up the list will be populated (every sublime-workspace file knows what sublime-project it is associated with).
What remains is whether or not it's quick to come up with the list of files in a way that you can easily paste them into the session file.
I thought VS Code saves all the relevant metadata in .vscode folder and .code-workspace file and as these are contained within the workspace folder I assumed it's all self-contained and shouldn't cause problems when moved. But apparently I was gravely mistaken.
After moving my workspace folder to a new location and altering folder paths saved in .code-workspace file accordingly all my opened editor panes and the bottom panel are gone. What I have now is a nice Welcome window.
I'm aware of what the official guide recommends, but that's only moving .code-worskpace metafile - the folder still stays in place.
I've just run into the same issue. My workspace wasn't saved to a file at all (I just use the "Open with Code" option on each project folder), and the Save Workspace As option didn't help as it just created a JSON file with a couple of empty objects in it (which probably makes sense as I haven't really modified any workspace settings, I just want to preserve my open editors and things like that).
On Windows at least, it seems that those kinds of "workspace" settings are actually stored within subfolders of %APPDATA%\Code\User\workspaceStorage, and an SQLite database file is used to store the actual settings, so this is what I ended up doing:
Move your folder to the new location on disk (close all VS Code windows first)
Open the new folder location with VS Code (you'll just get the Welcome tab at this stage, but we just need it to create a settings storage folder for the new location). Then close VS code again.
Open %APPDATA%\Code\User\workspaceStorage in File Explorer, go into each subfolder and open workspace.json (in any old text editor). In my case at least, it only contains a folder property, which is path of the folder that this settings folder relates to (but just changing this won't help us at all, it was the first thing I tried). Use this to figure out which of these subfolders relate to the old and new paths.
Copy state.vscdb from old to new, and delete state.vscdb.backup in new.
Open state.vscdb in new in some sort of SQLite database file editor (I used DB Browser for SQLite and it worked fine, but there's also SQLiteStudio which looks like it might be better in general).
Run an UPDATE query to update all the paths in the database. They seem to be stored in three different formats/levels of escaping - between folders there can be a forward slash, two backslashes, or four backslashes. In my case I wanted to move my project folder from the root of my Windows user folder into my usual documents folder which is within OneDrive, so my query was along the lines of the following, as I only needed to change the middle section of each path. You might have to do something more complicated if you are moving to a different drive for example (would need to have a look at all the existing paths in the database to see how they are encoded).
UPDATE `ItemTable` SET `value` = REPLACE(REPLACE(REPLACE(`value`, 'User/Project', 'User/OneDrive/Documents/Project'), 'User\\Project', 'User\\OneDrive\\Documents\\Project'), 'User\\\\Project', 'User\\\\OneDrive\\\\Documents\\\\Project')
After saving the database, I just opened the new folder in VS Code, and everything seems to have loaded up exactly as it was in the old location :)
(Also just in case anyone is curious, the subfolder names in workspaceStorage seem to be some sort of hash based on the path, because if you delete the subfolder that relates to a folder you've previously opened in VS Code and then open that folder in Code again, it recreates the same subfolder name. So that means just updating the old workspace.json and database file in-place won't work)
Scenario 1 - Moving the .code-workspace file The xxx.code-workspace file that defines your project folder location(s) is in JSON format. It has a "folders" section and a "settings" section. If you just mant to move the location of the xxx.code-workspace all that is needed is to go to File->Save Workspace As..., browse to the new location, select the name you want to give the workspace and it will save it with a .code-workspace extension. All of the "path" entries in the "folders" section are changed to a path relative to the new location.
Scenario 2 - Moving the entire workspace. If you want to move the entire workspace to a new location and the .code-workspace file is in the root directory of your workspace, just move the old workspace to the new location. The contents of the .code-workspace file will still be correct. Just select File->Open Workspace..., navigate to the new location and open the .code-workspace file.
Scenario 3 - When you .code-workspace folder is stored in a different location. If you store all of your .code-workspace files in a location apart from the actual workspace, the simplest way to move the workspace is a two step process:
With your workspace open, do File->Save Workspace As... and save the .code workspace file to the root directory of your workspace.
Move the workspace to the new location.
File->Save Workspace As... and save the .code workspace file to its location.
Close VS Code and delete the .code-workspace folder that's in the root directory of your resource, so that future settings changes will be saved to the correct workspace.
we actually build an InstallShield project for our application with the functionality to include files dynamic into a component. All files will be taken which are in a specific place.
Because of problems, which are not part of this question, we want to change this to components where we add files explicit to custom separated components.
The question is, is there a best practice for this? We have the small fear that we easily can forget to add files to the component we new created. These can be dll files, .config files, pdfs or just xml.
(We build the installer every night using TFS.)
We found a solution for the problem.
What we wanted to solve:
During the build we want to be informed if files got removed
During the build we want to be informed if new files are missing
we solved this by two more or less easy things.
1. Information if a file is removed
This is easy sone, we have all files added explicitly, each single file is an own component now, if one file is missing the whole project does not build with the exact error message.
2. Information for missing files
For this we wrote a small tool which runs by a prebuild event of the installshield project.
There it opens the *.ism file as an xml file and searches for the "Files" table.
Than it takes all files from the drop folder and looks if all files are in there.
If there are files missing but we don't expect them, like pdb files or test dlls, we have an additional text file we just called "IgnoreList".
The tool skips these files by the check.
Now we are on a very good state to get informed directly on the next morning if the project was able to build or not, and if not what happened, so we can be sure that in the final target application are files are there :-)
I am using visual studio 2012 with Microsoft TFS 2012.
On the workspace that is created on my c: drive, a hidden folder $tf is created. I suspect TFS from creating this folder. It's lurking diskspace as the current size is several gigabytes now and it's about 25% diskspace of the total amount of gigabytes needed for the complete workspace. So this hidden $tf folder is quite huge.
The structure is like this:
c:\workspace\$tf\0\{many files with guid in filename}.gz
c:\workspace\$tf\1\{many files with guid in filename}.gz
Does anyone know if I can delete this $tf folder safely or if it is absolutely necessary to keep track of changes inside the workspace?
TFS keeps a hash and some additional information on all file in the workspace so that it can do change tracking for Local Workspaces and quickly detect the changes in the files. It also contains the compressed baseline for your files. Binary files and already compressed files will clog up quite a bit of space. Simple .cs files should stay very small (depending on your FAT/NTFS cluster size).
If you want to get rid of these, then set the Workspace type to a server workspace, but lose the advantages of local workspaces.
Deleting these files will be only temporarily since TFS will force their recreation as soon as you perform a Get operation.
You can reduce the size of this folder by doing a few things:
Create small, targeted workspaces (only grab the items you need to do the changes you need to make)
Cloak folders, exclude folders containing items you don't need. Especially folders containing lots of large binary files
Put your dependencies in NuGet packages instead of checking them into source control..
Put your TFS workspace on a drive with a small NTFS/FAT cluster size (a cluster size of 64Kb will seriously enlarge the amount of disk space required if all you have are 1KB files.
To setup a server workspace, change the setting hidden in the advanced workspace setting section:
The simple answer: I deleted the $tf files once: the net result was that newly added files showed up in my pending changes, but when I changed an existing file, the change did not show up in my pending changes. So I would not recommend deleting this folder.
To answer the original question, the answer is yes. However, in order for TFS to track changes, it will need to be recreated, albeit with fewer folders and much smaller disk space. To do that:
First delete all the tf$ folders currently in your current workspace folder.
Next, move all of the remaining contents of the original folder to another empty folder, preferably one on another drive;
Perform a "Get latest" into the original (now empty) workspace folder (this will cause a single tf$ folder to be created in that original folder).
Now copy all of the contents you moved into the backup folder over the top of the 'Get latest' results in the original workspace folder.
By performing these steps in that order, you will end up with the tf$ entries TFS needs, but in a single folder and much more compact - additionally, the deltas of any changes you made that had not been checked in will be preserved and TFS will recognize them as pending changes as it should.
Our Certitude AMULETs C++ solution has 72 advanced projects in it, and we have to do this once a month to keep compiling and search speeds reasonable.
I deleted the $tf directory, and GetLatest behaved - it asked me if I wanted to keep the local files or replace with server. I could then check as normal.
The mildly annoy part was about 30 files I had locally that I had told to ignore appeared.