Say my current project is called project_x. Normally, in the Project ToolWindow the outermost directory displayed would be the directory project_x, alongside things such as External Libraries. Kind of the default, as one would expect.
However, IntelliJ displayed a message that I cannot exactly remember, but which said something like "an external change has occured". It then asked me whether to rebuild the current project, and I did.
Problem: now, the outermost directory displayed is my User folder, i.e.: Username [project_x] -> IdeaProjects -> project_x
I find this annoying, and would like to know how to revert back to the default settings. Help would be appreciated.
What it currently looks like (it contains my entire user-dir):
What it should look like (ignore the theme):
Edit: Well, while it did work for the above project, it did not work for the other one (made matters worse tbh). So this probably is not a solution in general.
Ok, I figured it out.
I noticed that the blue square next to a directory means that it's the source root. (Both my users directory and my actual project directory had such a blue square, the former obviously not wanted...).
So I did some googling on how to remove such a source root. I didn't find the right answer, but got close enough to figure it out on my own (no idea if I caused any damage to my project though):
Go to File -> Project Structure -> Modules
After looking around I noticed that on the left side I had two modules, one of them having my users directory as source root. I deleted that one, which solved my problem.
I'd still appreciate it if somebody could explain to me why this happened, and how to avoid this in the future, because in the time between asking and answering this question, it has happened to me again...
Related
I recently started making music using GarageBand's MIDI software. I've made it up to a certain point, where losing all my progress would be disastrous.
Here's the issue I have:
When I go to File > Save/Save As or just cmd+S or cmd+shift+S, or Share > Export Song to Disk, instead of functioning and saving the file (I checked in Finder; last time I exited the app without saving due to this issue, the untitled garageband file disappeared) properly onto the app, it would either do nothing or give me the rainbow wheel of death for 10-20 seconds and then proceed to not function.
I've searched online for answers to this, and there were several (2) users I found that had the same problem. Their post either had no answer or the answer was unintuitive (such as always using a different, more complicated method to save, like messing around with the garageband files themselves everytime to save).
I'm looking for an answer to this issue that would result in slightly more convenient, one-time edits to the app / any software beneath that would fix this issue, if there are any. However, if the community has any alternate way to save the file right now, I would greatly appreciate it.
======
Also:
Since I'd assume most of the solutions would involve closing the app and then making edits, then reinstalling it, please tell me if I could just copy the notes (not the tracks) onto a text document and paste it into the new file after. I would prefer to save my music.
Try this . . .
First QUIT Garageband (yes you will lose unsaved work).
Find the Garageband folder where all the .BAND files are saved. Usually it is in Users -> Username -> Music -> Garageband.
Move older .band files into another folder (EG: "Garageband OLD")
Then start a new project (or open a project still in the Garageband folder).
Save and Save-As should now work.
It seems there is some sort of file limit for the Garageband folder. In my case the file limit is either 170 .band files or about 125GB.
I am currently using Garageband 10.3.5 on High Sierra.
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
I've been using SVN to track my projects, and I've run into a problem several times.
svn: Directory "/programming/projects/mydirectory" containing working copy admin area is missing
I bet you're familiar with that one. What seems to be making this happen is when I try to "svn add" a directory that I don't have write permission to. Instead of saying "you don't have permission to do that, try something else," SVN puts my working copy in a messed-up state where it can't be updated or checked in.
Why does it do that? That seems like the Wrong Thing. I've searched up ways to fix this (the simplest thing seems to be "svn --force delete mydirectory") but I'm still puzzled as to why SVN can put my working copy in a messed-up state instead of throwing an error message based on a very simple condition.
Basically, there are many many ways to "partially" mess up your working directory.
By experience, I've never reached a situation where I've been unable to recover and where I had to get local diffs, remove my checkout, recheckout, reapply, ...
By playing quite a lot with: svn cleanup, revert/update folders that are in "!", remove some messy stuff, revert some wrongful adds, you always get back on your feet.
This is obviously a disadvantage, because you have much manual fiddling to do, but on the other hand, it's probably better to always err on the side of caution: when something unexpected happens, just make sure disk state is consistent is recoverable and stop, let the user see what exactly is wrong, rather than risking to make a bad decision.
Why complaining about this here? Create a script, which reproduces the bug and post it to the svn users mailing list. Then maybe the bug will be fixed. Your chances are much higher than here on stackoverflow..
You can even say that you have contributed to the subversion project.
In the 2009.1 version of Perforce Visual Client for 32-bin Windows, the "Reconcile Offline Work" option does weird things. In the middle box where the "Local files not in depot" should be displayed, I never get anything. What I do see is that the first time I reconcile a folder, it looks like perforce is filling the box with the "local files not in depot" because a list flashes quickly before my eyes. Then all of a sudden, the list quickly disappears into thin air and I'm left with an empty list. Does anyone know how I can get this feature to show me the files that I have not yet added? It seems like the "Modified files" and "Depot files missing from workspace" features work fine.
Also, as a side note, "Reconcile Offline Work" seemed to work fine in the 2009 beta version.
I had exactly the same problem.
The solution for me was obscure but trivial.
I simply changed the root directory of my client workspace from "C:\depot" to "c:\depot".
Yes, that's right, all I did was to change the drive letter from uppercase to lowercase. And, yes, I verified that changing the drive letter back to uppercase breaks it again and that changing the drive letter back to lowercase again fixes it again. So, this is not just a coincidence.
This is almost certainly a bug in the Perforce reconcile feature.
If you look closely at the reconcile paths, they all appear with a lowercase drive letter, even if you specify an uppercase drive letter, so my guess is that the matching algorithm is simply doing a case-sensitive comparison on the file paths. This is appropriate for everything but the drive letter. Their file lister probably always sets the drive letter to lowercase, so an uppercase drive letter on your client workspace root will never match.
This certainly sometimes happens. I seems the problem is likely to occur if I change the workspace view somehow and/or upgrade P4V to new version. So the solution which worked for me in the past was to trash the problematic workspace and create a new one (sometimes have to choose a different name too).
Perhaps deleting the .p4qt and .p4scc in your user home directory can help too.
Incidently, I did have a conversation with Perforce support on the related subject some time ago, and as the problems like this are very difficult to reproduce, therefore there wasn't much that they could do.
I have found issues with long filenames in p4 reconcile
from the base direectory
p4 reconcile ./...
never returned.
but if I cd further up the tree
cd components
p4 reconcile ./...
worked.
I was able to reconcile the whole tree eventually by stepping up directories, depending on how much longer your paths are this might work for you.
I had an instance where p4v showed the visual indicator that files had changes, and doing a diff showed the changes appropriately, but resolve on any parent directory didn't show them.
Those files had been changed by downgrading a library using a unity package install, and their "last modified" date was older than the previously submitted files. On OSX running the touch command on all the files in relevant directories updated all their modified times and reconcile worked after that.
I've got a really large project I made for myself and rece3ntly a client asked for their own version of it with some modifications. The project name was rather silly and my client wants the source so I figured it'd be best if I renamed all my files from
sillyname.h
sillyname.cpp
sillyname.dsp
etc..
Unfortunatly after I added everything back together I can't see any way to change the project name itself. Plus now I'm getting this error on compilation.
main.obj : error LNK2001: unresolved external symbol __imp__InitCommonControls#0
Debug/New_Name_Thats_not_so_silly.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
There has to be an easier way to change all this, right?
Here is a Step by Step on Steve Andrews' blog (he works on Visual Studio at Microsoft)
I haven't verified this, but I've done this a number of times and if my memory serves me right, you can actually use the search-and-replace functionality in VS2005 to rename all instances of the string "X" to "Y" in any type of file.
Then you need to close the solution and change the project (and any other file with the same name regardless of extension) file name(s).
You will obviously need to do a full rebuild afterwards.
I find it always annoying too, to do this manually.
So I tried some tools available by googling- two didn't work (VS C++ here), dunno, if they are more useful for C#.
The following tool worked good for me: I have used the trial version, but I will pay 39,- bucks for it. For me it is worth it. It has also a VS add-in. VS 2013 was not supported directly, at least not mentioned, yet, when I looked:
http://www.kinook.com/CopyWiz
In-place rename didn't work (access error), but "rename-while-copying" worked fine.
But I really wonder, if it is so difficult as some programmers claim. For most parts file renaming and a search&replace of all occurences in all text files in the project dir should be a quite easy and working approach. Maybe someone can contibute what shall be so difficult.
The rational part of my brain forbids the dreaming part to program an own tool- I am lucky ! :-)
You can simply rename the .vcproj or .dsp file and then either create a new workspace (sln dsw) and include the renamed project or simply chnage the name inside the sln file (it's just xml) I can't remember the format of the old workspace but it's still text.
You can either manually rename and reinclude all the .cpp of edit the project file and rename them in there.
sorry don't know of refactoring tool that will do all this but there probably is one.
I assume that in addition to the renamed set of files, you also still maintain a complete "parallel" set of the original files in some other directory, am I right?
Assuming you have both versions, what I would do is:
Get a file comparison tool like Beyond Compare or DiffMerge and compare the old SLN file and the new SLN file side-by-side. Also do this for each "proj" file and any other "config" type files.
It is possible to edit these files by hand. Usually looking at what is different between two copies will help illuminate what you should do to get the second one working.
You might as well start tinkering with the renamed project by hand, anyway, given that it already isn't working. You can't make it much worse. And: you might learn some handy tricks about the XML structure of these files.
Even if you do make small mistakes when hand-tweaking this files, I have repeatedly been very impressed by how Visual Studio handles things. Visual Studio will usually tell you exactly where you got it wrong.