How do I completely wipe (remove) Julia from my system?
Unless you've made changes to the code in packages, you can delete the whole .julia directory when you get into trouble. Either via a file manager, or (on a Unix system) via the command line,
rm -rf ~/.julia
Tim's answer is good, however you can also be a bit more specific.
I usually do the following (since I'm using v0.5, the path has v0.5, however, that will depend on what version you are using):
rm -rf ~/.julia/lib/v0.5 ~/.julia/v0.5/<packagename>
Deleting the lib subdirectory gets rid of any precompiled code, which might be also in a bad state.
Related
On Debian, I had a bunch of cruft installed in /usr/lib/sbcl/site-systems that wouldn't load because the FASLs didn't match the version of SBCL that is actually installed.
For some reason, none of these files were associated with any Debian package (this is an old computer that has been running the same Debian install for over a decade– it's on Debian Sid).
I deleted the bad systems one at a time, and for most of them, Quicklisp did the right thing and downloaded the Quicklisp version. Sometimes, ASDF would insist that the system should exist at its previous path, but restarting SBCL got past that problem.
But for one system, ASDF has persistently cached the location of its .asd file as being in the /usr/lib/sbcl/site-systems/ directory. Loading this system is impossible because ASDF will not look anywhere else, even after restarting SBCL.
I tried looking in all the paths specified in various config files under /etc/common-lisp. None of those files contain a reference to the now-missing library.
I've resorted to doing a grep -rli across all the files under /usr. I don't expect that to complete in less than a day, and it might not find anything, in which case I'll be forced to grep the whole hard drive, which might take a whole week. Hopefully, the cache isn't compressed, because then I'll never find it.
Does anyone happen to know how ASDF persists the paths of files?
After a lot of excruciating debugging, I discovered that the files in /usr/lib/sbcl/site-systems/ actually do exist. They're broken symlinks.
The files I deleted were in the similar-looking path /usr/lib/sbcl/site/, to which the symlinks pointed.
Removing the symlinks fixed all the loading errors.
A couple of ideas about troubleshooting Quicklisp, particularly if your getting bizarre behavior.:
If you use Quicklisp for any length of time you'll probably eventually use local packages, found here by default, ~/quicklisp/local-projects It's valid to symlink you're projects into that directory. If you ever rename one of your projects, of course, don't forget to create a new symlink and delete the old one
Likewise, if you rename a local project, also delete the system index which Quicklisp will then recreate the next time it runs: ~/quicklisp/local-projects/system-index.txt Doesn't hurt to delete it from time to time just to keep your system fresh.
your *.fasl files can become stale too, deleting the system cache forces quicklisp to recompile everything. On an Ubuntu system running SBCL that would mean deleting the contents of:
rm -rf ~/.cache/common-lisp
Try updating the Quicklisp client
(ql:update-client)
Potentially deleting and reinstalling Quicklisp itself at ~/quicklisp can be necessary. (It's possible to inadvertently edit source files when your debugging and using Swanks lookup definition feature, breaking installed packages that used to work. Not that I would ever have done something as careless as that.)
Also, don't forget that ASDF decends into directories looking for *.asd files. If you have a stray one that's improperly structured that can cause havoc on you build system. (See my comment above about registering local projects to Quicklisp)
Finally, don't forget to check your lisp init file, e.g. .sbclrc for any debugging or quick and dirty hacks you might have left there and forgot about.
These are all things that have worked for me at one time or another, hopefully I'm not perpetuating legend and cant on things have have long since been fixed!
I am working on ubuntu 18.10. want to recompile several of my libraries:
zlib, jasper, libpng, hdf5, netcdf
Even with
make distclean
I see that the old lib and include files still remain. Can I assume that a recompilation replaces these files, or can I remove them with sudo apt-get purge/remove ?
I am not sure whether removing them manually is safe, or will remove all of them and.or may remove other unrelated files.
I will appreciate some guidance
Calling make distclean will clean up enough that you will get a fresh compile when doing make afterwards.
The additional target maintainer-clean is available which may remove even more files, but you really shouldn't need to use it.
I assume if you have kept all the source folders and built your libraries within those source folders, then make distclean, if really properly enabled, will clean all the compiled stuff and you can re-build everything.
It is highly possible that make distclean does not clean the installed stuff, meaning if make install was executed and all the built executables/libraries/header were also linked/copied to the system path e.g. /usr/bin, /usr/local/ ... or whatever directories are used by the system.
Nevertheless, if you re-build everything and if again (after successful re-compile/re-build) execute make install, new version of the binaries/libraries/ will overwrite the old ones.
After switching to a new Mac (macOS Sierra) and re-cloning all of my GitHub repositories, I began to encounter a new problem. Whenever I make changes and save an R script, and run:
git status
## Untracked files:
## (use "git add <file>..." to include in what will be committed)
## .DS_Store
## .Rhistory
.DS_Store and .Rhistory appear.
Question: Is there a way to stop and/or ignore (e.g. via .gitignore, see below) these files when committing R scripts to GitHub?
I understand similar questions may have been asked, I decided to still raise this question because I really want to make sure that I get the setting right at the first place, especially if others have encountered similar problems before. If you have a way and/or references of how to solve this highly specific problem--which may require a combination of bash Terminal, R, as well as the operating system
The fastest and simplest way is to add .DS_Store and .Rhistory to your global gitignore file.
Here is how to do it, in a nutshell: open or create (if doesn't exist yet) ~/.gitignore_global and add .DS_Store and .Rhistory on two new lines.
If your repository already includes any unwanted files, use git rm to get rid of them (link).
I have found several relevant references that can lead to a potential solution:
Mac OS X v10.4 and later: How to prevent .DS_Store file creation over network connections, which simply asks user to run the line below in Terminal to stop generating .DS_Store files:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
r - Disabling saving history. This earlier post provides instruction on how to disable creation of .Rhistory files on Windows.
Remove .DS_Store files from a Git repository using .gitignore. I suppose the same could be done to .Rhistory
Still, if you have a better solution, please share with the community!
I wrote a .spec file on RHEL and I am building RPM using rpmbuild. I need ideas on how to handle the situation below.
My RPM creates an empty logs directory when it installs first time within the installation folder like below
/opt/MyInstallation-1.0.0-1/some executables
/opt/MyInstallation-1.0.0-1/lib/carries shared objects(.so files)
/opt/MyInstallation-1.0.0-1/config/carries some XML and custom configuration files(.xml, etc)
/opt/MyInstallation-1.0.0-1/log--->This is where application writes logs
When my RPM upgrades MyInstallation-1.0.0-1, to MyInstallation-1.0.0-2 for example, I get everything right as I wanted.
But, my question is how to preserve log files written in MyInstallation-1.0.0-1? Or to precisely copy the log directory to MyInstallation-1.0.0-2.
I believe if you tag the directory as %config, it is expected that the user will have files in there, so it will leave it alone.
I found a solution or workaround to this by hit and trial method :)
I am using rpmbuild version 4.8.0 on RHEL 6.3 x86_64. I believe it will work on other distros as well.
If you install with one name only like "MyInstallation" rather than "MyInstallation-version number-RPM Build Number" and create "logs directory as a standard directory(no additional flags on it)[See Original Question for scenario] Whenever you upgrade, you normally don't touch logs directory. RPM will leave its contents as it is. All you have to do is to ensure that you keep the line below in the install section.
%install
install --directory $RPM_BUILD_ROOT%{_prefix}/%{name}/log
Here, prefix and name are macros. That has to do nothing with underlying concept.
Regarding config files, the following is a very precise table that will help you guarding your config files. Again, this rule can't be applied on logs our applications create.
http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html
Thanks & Regards.
On windows after running the grunt build command for creating brackets shell it gives done without errors but i dont see any .exe file generated..
What might be the problem???
Here are some possible solutions:
Are you following the full brackets-shell build instructions, including all prerequisites?
Make sure Brackets isn't running at the same time. The build will fail silently if the .exe file is currently in use (see bug).
Try with a fresh git clone of the repo. If your brackets-shell local copy has been around for a while, sometimes the build & deps folders can get in a bad state. (I'm assuming you haven't modified the source at all. If you have, try with an unmodified copy of the source first to make sure it builds correctly without any of your changes).
Check that python --version shows 2.7.x
Verbose build output would also be helpful in diagnosing issues like this, but unfortunately there's not yet an easy way to get that...
If you follow the instructions on bracket-shell's wiki page, the Windows executable should be created in the Release directory.