I was trying to set up the Eclipse on a new computer, and thought I might as well try Juno instead of Indigo as I was using before.
However, attempting to import my PyDev/Django files was troublesome, and I ended up creating a new Django project and copying my source files in.
However, when I hit Refresh, Eclipse deletes a bunch of files including urls.py!
I've given up for now - back to Notepad++ - but does anyone have any ideas as to what might be causing this?
I must say that'd be the first time I heard that PyDev was deleting .py files... (it does have an option to remove orphaned .pyc files which you can disable on window > preferences > pydev > builders > how to handle .pyc/$py.class deletion).
Are you sure that it's really deleting those files in the filesystem? Can you reproduce that? (if so, please provide the steps to do so, because I've tried many things here and haven't been able to duplicate that behavior). It'd be nice if you check if it really removes the files in the filesystem (i.e.: it's possible that for some reason it's only filtering those in the PyDev package explorer?)
I just lost 3 hours of work using pydev and eclipse, without using django. So this is not django specific.
Related
We have a team of several members using Eclipse for a C & C++ application that we commit the make files it generates as part of the package build. I have added and committed a library to the project then we decide against using it. So I remove it from my project and commit the change to git for the rest of the team. When anyone else pulls the change their Eclipse reverts the removal to the .cproject file preventing the removal of the unwanted library, include paths, and toolchain paths. The only thing that seems to work is to blow away the project metadata and re-import the project, which is a hassle.
How do I easily get everyone else's Eclipse to accept the removal and stop adding it back in?
Thanks.
The issue comes from not committing the .metadata folder. Eclipse keeps a backup of the project somewhere in there and continually changes these file making it unreasonable to commit to source control.
The only thing I've found to always work is to delete the project from the workspace, but do not remove the files, and import the updated project after pulling the updates from source control.
You and your team may not be able or willing to do this, but it is easier to not check in IDE specific files at all and allow a build tool plugin like Maven or Gradle to handle the project structure and classpath. This is how I've worked with team members for years without experiencing this problem.
There is quite a bit of a paradigm shift doing this, and depending on the flexibility of your project it may not be feasible.
Edit:
I noticed you are of the C persuasion. I don't recommend Maven, but consider Gradle.
https://docs.gradle.org/3.5/userguide/native_software.html
I'm new to ember and after following a few guides, I've been playing around with ember apps. I'm using ember-cli to create an app, so I use
$ ember new 'app-name'
which creates the app as expected with the 'app' and 'dist' folder. But it also creates a lot of other files. I only discovered this while deleting the folder when the windows delete dialog box showed deleting more than 30000 files.
Is it that I'm doing something wrong that's causing unnecessary files to be created? Is there a way to avoid this?
You aren't doing anything wrong, a big portion of it is the dependencies and then the build process keeps a lot of temporary files around for reuse.
By the way, if you are developing in Windows, make sure you are running your command prompt as administrator, and that you've excluded the ember app from the virus scan, it really improves the build times.
It's not an issue with ember-cli itself, but how npm handles dependencies, since it has a hierarchical dependency system. You could try npm 3 (be warned, it's still beta - changelog), which tries to flatten out the dependencies better.
Another thing is checking if bower packages are adding any unneeded dependencies, like tests or raw source files (if they have pre built files). You could submit a PR to those projects by adding the ignore property in the bower.json file. See the spec here. Same with npm packages, which has a .npmignore file.
This is probably not what you wanted to hear, but in open source, we must all help each other. These are the bread crumbs of open source, and a great place to get started.
I have searched a net for some nice code and suddenly I have bumped on a one, however it's been worked in Eclipse, and since I don't have an Eclipse( and I am not planning to instal it anyway ) I can't properly compile it on my VS10. The thing is that all linker references are mapped in .cproject and if I create an app in my VS10 and paste all the headers and cpp files to it, I still can't build it, 'cause it freezes once it gets up. The main issue may lay in .cproject, so my Q. is can I somehow transform .cproject to .vcproj without much fuss so that this can work on my VS10 as well? :)
You can avoid the fuss partially by using CMake (http://www.cmake.org/)
You need to extract the source files' list from the .cproject and run the CMake to get the .vcproj/.vcxproj (basically, you create the "metaproject" for "all of the IDEs")
If you require some extra compiler setup then the fuss is unavoidable.
I experienced this problem in VS2010 before, and solved it looking at this SO question. However, now that I upgraded my VS to SP1, it appeared again. I tried to solve it the same way, enabling C++ projects logging and using DebugView. But I can't get to see any output in DebugView, no matter what I do. I also tried raising the Build output verbosity (Tools->Options->Projects and Solutions->Build And Run), but couldn't find any clue.
As in the original problem, the projects reported as out of date are always unmanaged C++ projects. The solution has C#, VB.NET, C++/CLI and C++ projects. What I'm trying to run is a VB.NET exe which uses some C++ projects through C++/CLI wrappers.
Any hint on how to troubleshoot this?
UPDATE: Solved it with a clean checkout. However, it's a shame that there is no longer a way to troubleshoot this kind of errors...
Is it possible you were testing with the date in the future and saved a source file in the future? While clean/rebuild all should fix this, VS seems to go batty and stay there until I resave the file in the present.
Another last-ditch thing that sometimes solves these problems that works 'like a reboot' if you have just the source-code in version control: Check everything in, close VS and anything using files in your project, move all your project folders to a backup folder, and do a force-get latest version of each. Sometimes 'clean project' doesn't cut it.
If that doesn't work and you can't find a missing .h ... You can always fire up Process Monitor, set a filter, and dig in there.
Admittely all just stabs in the dark. Hope one hits the burgler! ;-)
After a compiler upgrade you should do a rebuild-all, if you haven't done that already.
For native C++ projects you can get "project out of date", but still nothing to build, if you have some include files in your project that doesn't actually exits. Like if you have deleted some unused .h files, but they are still part of the project.
This popup comes up as soon as the app is started:
The program can't start because MSVCP90.dll is missing from your computer.
Before anyone says "install the VC++ runtimes", wait! If I rename the folder containing my .EXE then the app runs. If I rename it back, it breaks. The app has been running for weeks without any changes to my system/VS installation (2008 SP1), we suddenly spotted this error a few days ago.
Lost as to why the name of the dir is causing issues... again this has not changed in months and all our resource paths are relative anyway, e.g "../someOtherDir/...."
It doesn't just do this on my PC, we have the /bin dir (the one containing EXE) in SVN and suddenly everyone started seeing the same issue, even though the binaries themselves seem just fine. Is it possible some additional data got put into SVN and that's the cause? Since it's not just one PC, there must be something either in SVN or the EXE itself...
Note this popup comes before our code even gets to run.
It seems that there is a .exe.manifest file lying around, specifying some other version of MSVCP90.dll. Removing this file should do the trick (In theory the manifest is the solution against dll hell, but in reality it is just a new PITA).
Try rolling back to some earlier SVN revisions and see if you can identify a change which made it stop working. A binary search will be most efficient for this. PATH settings might also be an issue?