IntelliJ has a "safe write" option (quotes theirs, for some reason) which, on save, instead of simply updating the file, writes to a temporary file, then deletes the original, then renames the temporary file to the original's name. I hear that vim also does this.
I know this causes problems with programs that are watching the file. Sometimes such programs see the delete, but never see the update, for example.
But what advantages are there? IntelliJ's docs say that there are advantages that would be lost if you turned it off. There must be some reason this option is the default.
It took me a looong time to figure out this was how intellij operated and that it was causing some chronic issues I was facing, and took me even longer to figure out it was an option I could turn off. Now that I have that option, I'd like to know if the cure is worse than the disease, so to speak.
The safe write prevents you from data loss in case something goes wrong during the update. Just think of your computer or Intellij crashing while you are saving the file. You might lose the file completely then. But with safe write you would lose your recent changes only. After the updated version of your file is written to disk without errors, the old version can be replaced. This way you have a valid file version at any point of time during the update process, so no crash or whatever could make you lose all your work on that file. The worst thing which could happen is the loss of your recent changes.
Related
When I save a method and get back to it later, all of my variable names become temp and all of my parameters becomes arg and the code indentation get changed.
Any thoughts on how I can fix this?
The behaviour that you are experiencing is not code formatting at all. You immage is experiencing an issue where it can't access original source code. Thus it uses a backup solution and decomples method bytecode. During the compilation process the variable names are erased, so they can't be re-created during the decompilation, and generic substitudes are used instead.
Now, why you are missing sources is another question. First of all it's important to check if you get some exceptions. Often these happen when you open or save your image, but also thaty may occur when you save methods.
Depending on the Pharo version you may be missing .changes or .sources files. This often happens when you more an image without moving other supporting files.
Unfortunately after swearing to never use the hunk of garbage that is Dreamweaver again, after 7 years - I found a need for some WYSIWYG editing and installed the complete hunk of garbage software on my machine.
I simply knew there would be some disaster awaiting, so I was being really meticulous about backing up.
But I got caught not backing up for about 4 hours, and lost those 4 hours of work to yet another of the endless array of bugs that will completely destroy your work when using Dreamweaver.
I was using CTRLZ multiple times when suddenly the code went all weird and blocks of code went missing, and it looks like sections were just cut in mid line - and it just went from ugly to uglier. I recognized this nightmare form 7 years ago - the exact same reason why I stopped using this garbage software to begin with and swore to never use again. Right now I am wishing I kept my promise to myself.
So I was really careful not to save the document, but the fun thing is - every time I hit CTRLZ - Dreamweaver is "conveniently" saving the file to the server.
I do want live updates as I hit "Save" or CTRLS, but I DO NOT want anything saved when I hit CTRLZ!
So knowing that I want to use CTRLZ, and knowing Dreamweaver is complete garbage and will crash and kill my code.
How do I turn off automatic saving when I hit CTRLZ?
As a secondary question - how about how do I prevent losing my code again with this hunk of garbage software?
You probably have auto-save AND auto-sync turned on together, and auto-save might have ran shortly after you undid changes, following which the file was uploaded to the server by auto-sync.
Simply switch off auto-save so that only a manual save will trigger an upload.
Also another option that may accidentally revert your changes is the Auto Recovery feature, that reverts your file to an incorrect state when Dreamweaver crashes (or encounters a bug). If auto-sync is switched on as well, that may cause a corrupt file to be uploaded.
Simply switch off Auto Recovery so that no corrupt files will be uploaded.
I have a two broken VIs with front panels that open fine, but I can't edit or run them, or open theis block diagrams.
One of these was made as a replacement for the first when it started to have this problem. I need to at least find out how to avoid this problem in future, so I don't lose work on bigger VIs.
I'm not sure if it makes any difference, but I very recently upgraded to LabVIEW 2013.
Thank you in advance.
This is the error I get when I try to run them:
"
VI has a bad connection to or cannot find a subVI or external routine.
This VI has a bad connection to or cannot find a subVI or external routine but
it has no block diagram to show or fix the error. You must find or correct the
subVI or external routine. Check for more information in the Explain dialog box
in Get Info.
"
Before reverting to a previous version (using dropbox) I got a different error with one of them:
"
LabVIEW: Generic error.
An error occurred loading VI 'sweep harmonics first test.vi', LabVIEW load
error code 6: Could not load the block diagram.
"
One situation how this happened.
Sometime LabVIEW crashes, and it restart. After restart, LabVIEW will ask you to recover the autosaved code.
I personally always discard those autosaved code. If you do choose to recover autosaved code, there is a chance the recovered code is corrupted. Once you save corrupted code to disk, you are probably going to lose the ability to open/save the block diagram ever again.
Having a version control system is usually a way to avoid minimize the damage when LabVIEW crashes. At worst, you loose maybe an hour worth of work.
If you can't open Block Diagram of your VI, first check the suggestion by #Rodrigo - it is most likely just a "compiled" VI, which has Block Diagram removed.
If you think there is Block Diagram inside and it is just corruped - you may contact NI support. And if you want to look deeper by yourself, extract the VI to XML using pyLabview, and look into the XML - there you can modify every single part of the VI. For example, you may start removing parts until it starts working.
I wouldn't go into manual VI editing unless you have at least a dozen of affected files though. For a single file, it will be faster to re-create it in LabVIEW instead of trying to understand the internals. If many files are affected - may be worth finding the issue in one, as other files probably have the same glitch, so you can make a script which extracts, modifies and re-creates VIs automatically.
From the sound of it, I believe what happens is that you are trying to run the VI's created as "DATA" for an executable, instead of the actual source VI's.
When you build an executable LabVIEW creates a copy of all the Top Level VI's dependencies into the support (DATA) folder which should be in the same directory as your executable.
Try opening the VI's that are marked as not having a block diagram and navigate to File>>VI Properties to check the path from which the VI is being loaded. If it's not the original VI, you can just replace it.
On both Xcode 4.4 and 4.4.1 I'm experiencing the same issue in that with the specific project I'm working on, I don't seem to be able to rename any classes or variables from the Refactor menu option.
Each time I try and do a rename, I type in the new name for the class/variable and click Preview at which point the bottom left begins a spinner with Finding files.... However, I then get a message saying:
The selection is not a type that can be renamed.
Make a different selection and try again.
I'm pretty sure that this is not an issue with my specific install of Xcode, because I can refactor other projects fine, it's just that I can't seem to be able to refactor this specific project.
Anyone with any ideas? I don't have any particularly exotic configuration for this project, it just seems to be a random affliction. I've deleted all of my derived data and re-indexed, but that doesn't seem to help.
Since it works OK in other projects, I'm thinking one thing I could try to do is re-generate the actual project file(s) itself. I don't know if there is a way to do this automatically?
If they're in dropbox get them out of there. It mangles project files. I've had it happen numerous times and at times it makes refactoring > renaming not work.
I have managed to solve this issue after trying many different things (tweaking project settings, pch, etc.) and it turns out there was a very simple (and totally counter-intuitive) method of fixing this issue.
All I have done is:-
Copy my entire project folder (so from Project to Project Copy).
Move Project (the original folder) to trash.
Rename Project Copy to Project.
Mysteriously, everything now works fine.
I really cannot figure out why this works. As mentioned previously, I had already deleted all derived data, etc. so I don't know why this should make things spontaneously work, but it does.
Would appreciate anyone who is able to shed some light on this as it does expose just how fiddly Xcode can be, and any understanding of what goes on under the hood is always beneficial.
Sounds like a buggered index.
I usually use the nuke from space option to delete everything in the derived data directory.
Unless you have changed it (I change mine to /tmp/bbum-derived), it'll be at:
~/Library/Developer/Xcode/DerivedData
Thus, I'll quit Xcode and do:
rm -rf ~/Library/Developer/Xcode/DerivedData
Yes, it is a bit brute force, but it works. You can likely force Xcode to rebuild the index from the UI, but I never bother. Of course, I'm also installing quite a few "odd" builds of this and that as a part of my day job...
(that is an rm -rf. It means "nuke everything and don't ask" in unix parlance. It is dangerous. Do not mistype that command.)
It seems you have an active selection somewhere in the gui, perhaps some of your files or classes are selected ? Try unselect in every sub window and retry refactoring.
I'm a bit late to this thread, but I ran into the same problem today and I was able to get it to finally refactor correctly, thought I share it.
So in large part I did what bbum said, I closed xCode, nuked the Derived data for the project the class files were in and re opened the project. Doing just that, it didn't work; the key, I found (at least for me), is that I had to do a clean (command shift k) after xCode restarts. After that I was able to rename the class files again :)
Also as a side note, my project is divided into the main project, and a static library. When I had to rename classes in the static library, I had to quit the main project and do what I described in the static library itself. Somehow I got the same error described in the question when I tried to do the refactor/rename from the main project.
Good luck!
This thread was very helpful for me in determining the problem.
It turned out that I had to Repair Disk with Disk Utility. I had visited a site earlier that had hijacked Safari and was telling me to call a number for emergency repairs, an obvious scam.
I followed the Disk Utility instructions to repair disk (including restarting with CMD-R pressed). Another clue was that I tried to commit to git and Xcode said No Way, Jose.
Afterwards I was able to refactor and commit changes as if nothing ever happened. I hope this helps someone else as a possible cause to investigate.
I've been looking for an IDE or Text Editor that can save "snapshots" of my code. I have been coding in a lot of new languages lately using a lot of trial and error. I often find myself wanting to revert a file or multiple files because of a coding/design decisions made in the last couple of hours or even days. It would be nice if I could take a snapshot of my code periodically and reverting to a past snapshot rather than manually making copies of my files on intervals.
I'd imagine that there has to be atleast an editor that shows version-history of a file. ( I realize I could use git or svn or any other versioning solution, but I'd like a more automated process.)
(if not an IDE, does anyone know how to configure Windows-ShadowCopy, OSX-TimeMachine, to make backups of my development folder on 45min intervals... or even a third-party program.)
Eclipse takes a local history on a per file basis... but personally I would strongly suggest using source control for this. If you use something like git or Mercurial, your commits are all local anyway - and it means you'll have a consistent snapshot at moments where you believe you've reached a useful point.
With a bit of experience it only takes a few seconds to commit your current work, and I think it's likely to prove more useful over time than automatically snapshotting either every save or at random intervals.
(It's hard to know whether Eclipse will actually be useful to you, as you haven't specified which language you'll be programming in. Admittedly there are plugins for a fair number of languages in Eclipse...)