I believe I correctly deactivated this pyenv virtualenv, but the symbol just doesn't go away. Am I still in this virtualenv or not? This is so confusing. Pls help. Thanks!
(catalog-project) wjz#MacBook-Air ~ % source deactivate
pyenv-virtualenv: deactivate 3.10.0/envs/catalog-project
(catalog-project) wjz#MacBook-Air ~ %
Related
every time I open the console of a Mac (Catalina osx), three lines of code appear:
/Users/xxxxxxxxx/ .zprofile:6: command not found: pyenv
/Users/xxxxxxxxx/ .zprofile:6: command not found: pyenv
/Users/xxxxxxxxx/ .zprofile:6: command not found: pyenv
(base) ➜ ~ git:(python)
Actually, I'm not sure if the problem is a virtual environment problem, a git problem or a pyenv problem. Before I touch anything to solve it, does anyone have any idea how to configure the environment so that those lines with "command not found: pyenv" disappear every time I open the console?
I am really a beginner and don't understand how a lot of this stuff works. I just installed doom emacs, I've never used emacs before. I ran the doom doctor command and it gives me two warnings.
> Checking Doom Emacs...
✓ Initialized Doom Emacs 2.0.9
✓ Detected 30 modules
✓ Detected 118 packages
> Checking Doom core for irregularities...
Found font material-design-icons.ttf
Found font weathericons.ttf
Found font octicons.ttf
Found font fontawesome.ttf
Found font file-icons.ttf
Found font all-the-icons.ttf
> Checking for stale elc files in your DOOMDIR...
> Checking your enabled modules...
> :lang markdown
! Couldn't find a markdown compiler, `markdown-preview' won't work
> :lang sh
! Couldn't find shellcheck. Shell script linting will not work
There are 2 warnings!
✓ Finished in 3.7202s
What does this even mean? Can I just ignore it? Please bear with me I'm just beginning to learn this stuff. Thanks
It means Doom can't access those tools since they aren't installed on your system. They aren't necessary, as the warning suggests. If you want both of these utilities, you will need to install Marked for the markdown-preview and ShellCheck for shell script linting.
npm install -g marked
sudo apt install shellcheck
Note that Shellcheck can also be installed from cabal, dnf, pkg or brew install.
Afterwards, you should find that running doom doctor shows no warnings.
On Fedora 33, the command is
sudo dnf install ShellCheck
Please note the capitalization of the characters S and C
When I open emacs I am getting this warning
external/slc6_amd64_gcc630/lib/libtiff.so.5: no version information available (required by emacs)
I recently changed my system from sl6 to centos7. So, it is a result of this. How do I resolve this issue?
Just a guess, but I think you could get away with a symlink from your libtiff to the location expected by your emacs binary (assuming you don't just want to recompile / get an emacs binary for your distro).
Make a link to your libtiff wherever it may be,
find /usr/lib -name libtiff.so.5 2>/dev/null
or locate libtiff.so.5
from that expected by the emacs binary,
ldd /usr/bin/emacs | awk '/libtiff/ { print $3 }'
replacing the /usr/lib/, /usr/bin/emacs with your actual locations.
I'm showing you the steps I use to create a virtualenv based on miniconda based on pyenv-virtualenv docs. Finally you will see that the virtualenv was created but I can't access to it.
1.0. Check my initial pyenv versions:
$ pyenv versions
* system (set by /home/oscar/.python-version)
2.7.9
3.5.1
1.1 Install miniconda:
$ pyenv install miniconda3-4.0.5
$ pyenv versions
* system (set by /home/oscar/.python-version)
2.7.9
3.5.1
miniconda3-4.0.5
1.2. Create the venvtest virtualenv based on miniconda:
$ pyenv virtualenv miniconda3-4.0.5 venvtest
$ pyenv versions
* system (set by /home/oscar/.python-version)
2.7.9
3.5.1
miniconda3-4.0.5
miniconda3-4.0.5/envs/venvtest
venvtest
When I want to check if the virtualenv was created, It doesn't show it. So I can't no access to it :(
$ pyenv virtualenvs
miniconda3-4.0.5 (created from /home/oscar/.pyenv/versions/miniconda3-4.0.5)
$ pyenv activate ... (autocompleting)
--help miniconda3-4.0.5 --unset
Please, I hope you can help me.
https://github.com/yyuu/pyenv-virtualenv/issues/178
A bit late answer. But a similar thing happened to me.
So I used
source /Users/<user_name>/Applications/anaconda3/bin/activate <env_name>
instead of
source activate <env_name>
My recommendation is to not install Miniconda or Anaconda (herein refereed to as *conda) via pyenv. Instead, download the installer from the applicable site and install it as follows.
Eg. I downloaded the installer from the website to ~/Downloads
% cd ~/Downloads
% ls | grep conda
Miniconda3-latest-Linux-x86_64.sh
Run the installer:
% bash Miniconda3-latest-Linux-x86_64.sh
Now most importantly, at the end of the installer when you are prompted Q) Do you wish the installer to initialize Miniconda3 by running conda init? [yes|no], choose no.
Note: If you choose yes, Miniconda or Anaconda will deploy changes into your ~/.bashrc which will start up the *conda environment every time you open a bash session. This will corrupt pyenv.
After the installer is complete, add the following functions* to your ~/.bashrc:
function aconda {
eval "$(${HOME/miniconda3/bin/conda shell.bash hook)"
}
function dconda {
conda deactivate
}
* change the path to conda executable as required.
To launch the *conda environment, open any terminal and type aconda and to deactivate type dconda and that's it.
These instructions are for Linux but should port to Mac easily, not sure about windows though as I don't use it for my development.
I'm new to using the *conda environments and was surprised with the lack of simple instructions so I had to do a bunch of trial and error to get it so PyEnv, which I adore, working correctly. Hopefully this helps some others.
Now that it's 2022, it's time for a new answer...
It appears that the current method for installs of *conda via pyenv is to manage the conda virtual environment with conda's commands.
From the pyenv-virtualenv README:
"You can manage conda environments by conda create as same manner as standard Anaconda/Miniconda installations. To use those environments, you can use pyenv activate and pyenv deactivate... If conda is available, pyenv virtualenv will use it to create environment by conda create." See the Github repo README.md for a command walk-through.
I have been stuck on this problem for several weeks and been looking around on Internet for solution but so far not so good...
So I have a program written by someone else and I try to compile it in Matlab to make it work. My computer is Red-hat enterprise Linux workstation (64 bits) with gcc 4.4.3 and Matlab 2011b installed. The gcc is compatible with my Matlab (http://www.mathworks.com/support/compilers/R2011b/glnxa64.html).
The compilation works fine (I mean, no error message occurs in Matlab command window). But after compilation, every time when I use a specific function from the compilation (it's call "mexLasso"), it will show up errors like this:
***Invalid MEX-file '/usr/local/matlab_R2011b/toolbox/spams-matlab/build/mexLasso.mexa64':
/usr/local/matlab_R2011b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by
/usr/local/matlab_R2011b/toolbox/spams-matlab/build/mexLasso.mexa64)
Error in test (line 24)
alpha=mexLasso(X,D,param);*
So I type "strings /usr/lib/libstdc++.so.6 | grep GLIBC" in the terminal, and I found the "GLIBCXX_3.4.11" is actually in it.
I've been using Linux and gcc stuff for only several months...so there are still a lot of things I don't understand. It will be of great help if you can explain it in detail. Thanks!!
%% More detail:
I got these programs on machine learning from http://spams-devel.gforge.inria.fr/downloads.html. The wierd thing is, after compilation, other functions in that package works fine (such as "mexTrainDL").
The solution prompted by #whjiang works but have two limits:
You may be required a sudo privilege to change the library symbol
link.
The change is global and can affect all users
So there is another.
As explained by this answer from MATLAB Central, the problem is caused by Matlab:
Matlab internally changes the LD_LIBRARY_PATH to prefer <MatlabPATH >/sys/os/<ARCH>
and the <MatlabPATH>/sys/os/libstdc++.so.6 is out of date.
The solution is set LD_PRELOAD when calling Matlab like this,
env LD_PRELOAD=/usr/lib/libstdc++.so.6 <MatlabPATH>/bin/matlab -desktop
The path of libstdc++.so.6 my be different from os to os. For example, on my LMDE2, the path is /usr/lib/x86_64-linux-gnu/libstdc++.so.6.
This is answered in the libstdc++ FAQ: http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
Here is an solution:
sudo ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 /usr/local/MATLAB/R2011b/bin/glnxa64/libstdc++.so.6
explanation and reference:
http://fantasticzr.wordpress.com/2013/05/29/matlab-error-libstdc-so-version-glibcxx_3-4-15-not-found/
A simple solution from this page ( http://ubuntuforums.org/showthread.php?t=808045 ) that worked for me.
Go to the matlab directory where libstdc++.so.6 and libgcc_s.so.1 are stored. In my case, this was:
cd /usr/local/MATLAB/MATLAB_Production_Server/R2015a/sys/os/glnxa64
Then rename libstdc++.so.6 and libgcc_s.so.1:
sudo mv libstdc++.so.6 libstdc++.so.6.orig
sudo mv libgcc_s.so.1 libgcc_s.so.1.orig
That's it!