I am using Enthought's Canopy environment on a 64 bit Linux OS. Everything works fine in the Ipython console which is attached with the editor. But when I ipython in the terminal and try to use magic functions, I get the following error.
---------------------------------------------------------------------------
error Traceback (most recent call last)
<ipython-input-3-29a4050aa687> in <module>()
----> 1 get_ipython().show_usage()
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/site-packages/IPython/core/interactiveshell.pyc in show_usage(self)
2931 def show_usage(self):
2932 """Show a usage message"""
-> 2933 page.page(IPython.core.usage.interactive_usage)
2934
2935 def extract_input_lines(self, range_str, raw=False):
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/site-packages/IPython/core/page.pyc in page(strng, start, screen_lines, pager_cmd)
188 if screen_lines <= 0:
189 try:
--> 190 screen_lines += _detect_screen_size(screen_lines_def)
191 except (TypeError, UnsupportedOperation):
192 print(str_toprint, file=io.stdout)
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/site-packages/IPython/core/page.pyc in _detect_screen_size(screen_lines_def)
112 # Proceed with curses initialization
113 try:
--> 114 scr = curses.initscr()
115 except AttributeError:
116 # Curses on Solaris may not be complete, so we can't use it there
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/curses/__init__.pyc in initscr()
31 # instead of calling exit() in error cases.
32 setupterm(term=_os.environ.get("TERM", "unknown"),
---> 33 fd=_sys.__stdout__.fileno())
34 stdscr = _curses.initscr()
35 for key, value in _curses.__dict__.items():
error: setupterm: could not find terminfo database
So, I installed a bare bones iPython shell which is not the one provided by Canopy and tried the same magic functions in there and it works fine.
Have I done something wrong with the installation? Please help
Thanks a lot
shahensha
This is not a solution, but just an observation. My desktop is MacOS-X and I connect to a Centos machine to run Enthought Canopy both 64 bit. I get the same error message as OP if I ssh from iterm2, but not if I use the Terminal app.
I am not sure what the underlying reason is, but may be someone can verify if a similar situation is true for linux. Interestingly I can use either iterm2 or Terminal on the local canopy without any issues.
Update:
I just noticed that the TERM environment variable in iterm2 was set to "xterm" while the Terminal app was showing "xterm-256color". Issuing the command export TERM="xterm-256color" before running the Canopy ipython in terminal solves the issue for me in iterm2.
Problem reproduction:
$ python -c 'import curses; curses.setupterm()'
Traceback (most recent call last):
File "<string>", line 1, in <module>
_curses.error: setupterm: could not find terminfo database
This irc log gave me the idea that this error was to do with libncursesw.
My Canopy version is 1.0.3.1262.rh5-x86_64. I have installed it to ~/src/canopy.
In ~/src/canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib we can see that my canopy install has libncursesw.so.5.7.
My machine (Debian Wheezy 64bit) has libncursesw.so.5.9 (in /lib/x86_64-linux-gnu/libncursesw.so.5.9). I made canopy use this. You can toggle the problem on / off by using LD_PRELOAD and pointing at the .so file.
Solution
Replace libncurses.so.5.7 with libncurses.so.5.9:
CANOPYDIR=$HOME/src/canopy
CANOPYLIBS=$CANOPYDIR/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/
SYSTEMLIBS=/lib/x86_64-linux-gnu
cp $SYSTEMLIBS/libncurses.so.5.9 $CANOPYLIBS
ln -sf $CANOPYLIBS/libncurses.so.5.9 $CANOPYLIBS/libncurses.so.5
It appears that Canopy User Python is not your default. See this article:
https://support.enthought.com/entries/23646538-Make-Canopy-s-Python-be-your-default-Python-i-e-on-the-PATH-
Update: Not true here -- instead, see batu's workaround answer.
Related
there
On Net::SSH2::Simple,
It has been no longer connected by ssh after update Windows7 to Windows10.
With following error.
Net::SSH2::net_ss_timeout: invalid object Net::SSH2::Simple=SCALAR(0x3f5c218) at C:/Strawberry/perl/vendor/lib/Net/SSH2.pm line 111.
at C:/Strawberry/perl/vendor/lib/Net/SSH2.pm line 111.
Net::SSH2::connect(Net::SSH2::Simple=SCALAR(0x3f5c218), "xxxx.com", 22) called at C:/tool/eclipse_classic/workspace/test/work14.pl line 98
(in cleanup) Net::SSH2::net_ss_DESTROY: invalid object Net::SSH2::Simple=SCALAR(0x3f5c218) at C:/tool/eclipse_oxygen/eclipse/workspace/.metadata/.plugins/org.epic.debug/perl5db.pl line 4211.
My code are
use Net::SSH2::Simple;
$ssh2 = Net::SSH2::Simple->new();
$ssh2->connect( 'xxxx.com', 22 ) ;
$ssh2->auth_password( 'username', 'passwd' );
Error comes up at "$ssh2->connect" line.
But
This code works fine by using Net::SSH2.
Only Net::SSH2::Simple doesn't work.
To xxxx.com connection is fine. and no username,password mistakes found.
How can I fix that.
Windows10 64bit
Strawberry Perl 5.30.1.1 (64bit)
Eclipse Oxygen
EPIC 0.77
Thanks
Net::SSH2::Simple 0.01 was released Dec 13 2009. At that time Net::SSH2 was at 0.28 (2009-10-24), it is now at 0.70 (2019-3-17).
I got Net::SSH2::Simple to work on Windows10 64bit / Strawberry Perl 5.30.0.1 (64bit) by installing the earlier version 0.58 (2015-12-20) of Net::SSH2 using
cpan install SALVA/Net-SSH2-0.58.tar.gz
Version 0.59_20 (2016-05-11) gives the 'net_ss_timeout: invalid object' error . The change log for version 0.59_01 has this warning
** WARNING: this release includes lots of changes, some
visible, most internal. Regressions are expected. Also,
it introduces some minor backward incompatible changes -
but in those cases, the old behavior was broken or insane
anyway.
I am trying to install Jedi for emacs26 using MELPA package by following instructions here --http://tkf.github.io/emacs-jedi/released/.I used pip3 to install 'jedi flake8 autopep8' and I also use M-x package-listto intstall jedi.But When I use M-x jedi:install-server ,It only shows:
Running: pip install --upgrade /home/lzzz/.emacs.d/elpa/jedi-core-20181207.1/...
Runing
After a long time, it didn't reply anything.I don't know what should I do.Is my configure's or network's wrong? I need help.
the jedi error
`Error (jedi):
Failed to start Jedi EPC server.
* EPC Error *
Server may raise an error. Use "M-x epc:pop-to-last-server-process-buffer RET" to see full traceback:
Traceback (most recent call last):
File "/home/lzzz/.emacs.d/elpa/jedi-core-20181207.1/jediepcserver.py", line 39, in
import jedi
ImportError: No module named jedi
* EPC Server Output (last 10 lines) *
Traceback (most recent call last):
File "/home/lzzz/.emacs.d/elpa/jedi-core-20181207.1/jediepcserver.py", line 39, in
import jedi
ImportError: No module named jedi
* EPC Server Config *
Server arguments: ("python" "/home/lzzz/.emacs.d/elpa/jedi-core-20181207.1/jediepcserver.py")
Actual command: /usr/bin/python
VIRTUAL_ENV envvar: nil
* jedi-mode is disabled in # *
Fix the problem and re-enable it.
* You may need to run "M-x jedi:install-server". *
This could solve the problem especially if you haven't run the command yet
since Jedi.el installation or update and if the server complains about
Python module imports.
`
I think the problem may be that Jedi is not starting the server with the same Python environment as the one in which you installed the dependencies.
I would suggest that you first find out which Python executable corresponds to the pip3 you used to install dependencies. Let's say it is /usr/local/bin/python3. Then add the following to your .emacs:
(setq 'jedi:server-command
'("/usr/local/bin/python3" "/home/lzzz/.emacs.d/elpa/jedi-core-20181207.1/jediepcserver.py"))
Then, try to run M-x jedi:ac-setup in a python buffer (you shouldn't need the M-x installe-server since you went for the manual installation).
Hope this helps!
PsychoPy looks like just what I need. But I want to use my own development environment (a straightforward IPython prompt combined with the editor of my choice) instead of the provided IDE.
The trouble is that you seem to have to quit Python and relaunch after every PsychoPy run. If for example I cd to the ...../demos/coder/stimuli directory and type run gabor.py it runs fine, but if I then type run gabor.py again I get this exception from pyglet:
C:\snap\PsychoPy2\lib\site-packages\pyglet\window\win32\__init__.pyc in _create(self)
259 if not self._wgl_context:
260 self.canvas = Win32Canvas(self.display, self._view_hwnd, self._dc)
--> 261 self.context.attach(self.canvas)
262 self._wgl_context = self.context._context
263
C:\snap\PsychoPy2\lib\site-packages\pyglet\gl\win32.pyc in attach(self, canvas)
261 self._context = wglext_arb.wglCreateContextAttribsARB(canvas.hdc,
262 share, attribs)
--> 263 super(Win32ARBContext, self).attach(canvas)
C:\snap\PsychoPy2\lib\site-packages\pyglet\gl\win32.pyc in attach(self, canvas)
206 raise RuntimeError('Share context has no canvas.')
207 if not wgl.wglShareLists(share._context, self._context):
--> 208 raise gl.ContextException('Unable to share contexts')
209
210 def set_current(self):
ContextException: Unable to share contexts
Is there some sort of pyglet.cleanup() I can call (analogous to pygame.quit()) to allow PsychoPy scripts to run more than once in the same session? Or other way of avoiding this problem?
I'm using the Standalone PsychoPy distro version 1.81.02, untouched. The problem is not specific to IPython---it also can also be demonstrated from the plain Python prompt if you disable sys.exit and type execfile('gabor.py') twice:
C:\snap\PsychoPy2\Lib\site-packages\PsychoPy-1.81.02-py2.7.egg\psychopy\demos\coder\stimuli>python
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import sys; sys.exit = lambda x:x
>>> execfile('gabor.py')
0.6560 WARNING Movie2 stim could not be imported and won't be available
1.6719 WARNING Monitor specification not found. Creating a temporary one...
>>>
>>> execfile('gabor.py')
Traceback (most recent call last):
[snip]
File "C:\snap\PsychoPy2\lib\site-packages\pyglet\gl\win32.py", line 208, in attach
raise gl.ContextException('Unable to share contexts')
pyglet.gl.ContextException: Unable to share contexts
I don't know how to undo all the pyglet/psychopy initialisation - neither are really designed for you to do this, so there would be some work here. But I'm not sure it's a good idea anyway to run scripts the way you are doing.
The PsychoPy app itself gets around the by launching each script in a new process. It means that you know the namespace is clean on each run. Running your script on top of the previous one can lead to some really hard-to-find bugs because you don't know in what state the previous script left the memory, graphics card and namespace.
cheers
Jon
I am currently working with Gurobi solver using python. Previously, I have just been using a mix of a text editor and the terminal to write and run my models but I am currently experimenting with using Enthought Canopy Editor. I have a model that is works when I run in in the terminal using python model.py but when I try doing%run model.py in Canopy's iPython shell I get:
%run /home/cdhagmann/Copy/Code_Env/Farmer/model.py
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/home/cdhagmann/Canopy/appdata/canopy-1.0.1.1189.rh5-x86_64/lib/python2.7/site-packages/IPython/utils/py3compat.pyc in execfile(fname, *where)
181 else:
182 filename = fname
--> 183 __builtin__.execfile(filename, *where)
/home/cdhagmann/Copy/Code_Env/Farmer/model.py in <module>()
----> 1 from gurobipy import *
2 from data_IO import read_data,currency
3 import time
4
5 # Import model data
ImportError: No module named gurobipy
My guess is that the terminal and Canopy look for modules in different places but I don't know how to rectify it. I found this reference on the Gurobi group site about Enthought Canopy and Gurobi on OS X 10.8 but didn't know how much those instruction would differ from doing it on Linux and even what he meant about installing Gurobi in Canopy's site-packages.
UPDATE: Based on information found the first link I clicked on, I did in fact leave the boxed clicked making Canopy my default directory. You have to manually prepend the PATH variable, which I missed them saying that I had to do. So I did that. I now have Canopy's version of iPython running in my terminal (check by using sys.path); however, I get a huge list of errors when I try run python.
cdhagmann#Crispin ~ $ python
Traceback (most recent call last):
File "/usr/lib/python2.7/site.py", line 563, in <module>
main()
File "/usr/lib/python2.7/site.py", line 545, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib/python2.7/site.py", line 272, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib/python2.7/site.py", line 247, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib/python2.7/site.py", line 237, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib/python2.7/sysconfig.py", line 578, in get_config_var
return get_config_vars().get(name)
File "/usr/lib/python2.7/sysconfig.py", line 505, in get_config_vars
import re
File "/usr/lib/python2.7/re.py", line 105, in <module>
import sre_compile
File "/usr/lib/python2.7/sre_compile.py", line 14, in <module>
import sre_parse
File "/usr/lib/python2.7/sre_parse.py", line 17, in <module>
from sre_constants import *
File "/usr/lib/python2.7/sre_constants.py", line 18, in <module>
from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT
Suggestions?
And to answer #Jonathan questions:
sys.prefix = '/usr'
sys.path:
/usr/lib/python2.7
/usr/lib/python2.7/plat-x86_64-linux-gnu
/usr/lib/python2.7/lib-tk
/usr/lib/python2.7/lib-old
/usr/lib/python2.7/lib-dynload
/usr/local/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages/PILcompat
/usr/lib/python2.7/dist-packages/gtk-2.0
/usr/lib/pymodules/python2.7
/usr/lib/python2.7/dist-packages/ubuntu-sso-client
gurobipy.__file__ = '/usr/local/lib/python2.7/dist-packages/gurobipy/gurobipy.so'
If the terminal is correctly configured for Canopy Python, then python in terminal and Canopy Python should be looking for modules in the same places. If during installation, you disabled "make Canopy be default Python", or if you have not restarted terminal since installation, then it won't automatically be configured correctly.
These articles should help you understand and configure:
http://docs.enthought.com/canopy/configure/faq.html#where-are-all-of-the-python-packages-in-my-user-python-environment
https://support.enthought.com/entries/23646538-Make-Canopy-s-Python-be-your-default-Python-i-e-on-the-PATH-
https://support.enthought.com/entries/23389761-Installing-packages-into-Canopy-Python-from-the-command-line
If these articles do not suffice for you to solve this, then please report -- when you run python from terminal, what are these?
sys.prefix
sys.path
gurobipy.__file__
I'm using the execnet package to allow communication between Python scripts interpreted by different Python interpreters.
The following code (test_execnet.py):
import execnet
for python_version in ('python', 'python3'):
try:
gw = execnet.makegateway("popen//python="+python_version)
ch = gw.remote_exec('channel.send(1/3)')
res = ch.receive()
print(python_version, ': ', res, sep ="")
except:
print('problems with ', python_version)
Runs perfectly in the command-line Terminal, showing the following output:
$ python3 test_execnet.py
python: 0
python3: 0.333333333333
However, if I try to run the same code from within the Eclipse IDE, I get the following error:
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "<string>", line 4, in <module>
File "<string>", line 2, in <module>
File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/site-packages/execnet/gateway_base.py", line 8, in <module>
import sys, os, weakref
File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/os.py", line 380, in <module>
from _abcoll import MutableMapping # Can't use collections (bootstrap)
File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_abcoll.py", line 54
class Hashable(metaclass=ABCMeta):
^
SyntaxError: invalid syntax
problems with python
problems with python3
NOTE:
Eclipse Version: 3.6.0
PyDev Interpreter configured for the project: python3
"Preferences/Interpreter - Python"'s Python Interpreters:
python (/usr/bin/python)
python3 (/Library/Frameworks/Python.Framework/Versions/3.1/Resources/Python.app/Contents/MacOS/Python
EDIT:
I write a code to show the os.environ like this:
for python_version in ('python', 'python3'):
try:
import os
for item in os.environ:
print(item, '= ', os.environ[item])
except:
print('problems with ', python_version)
I got the following outputs:
eclipse_output.txt
terminal_output.txt
A FileMerge comparison of the files can be found at eclipse_output.txt vs. terminal_output.pdf.
Any hints?
Thanks
seems like pydev does site-customizations and particularly modifies things for interactive/console usage (judging from a very quick skim of http://github.com/aptana/Pydev/blob/master/plugins/org.python.pydev/pysrc/pydev_sitecustomize/sitecustomize.py ). This is not useful or fitting for execnet-mediated processes.
You could try to "del os.environ['PYTHONPATH']" before you invoke execnet.makegateway, or, to be more careful, just delete the sitecustomize part of it.
hth,
holger
'import site' failed; use -v for traceback
I have seen that when python was unable to find its landmark. Which that indicates there is a PYTHONHOME problem.
Check out http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME maybe eclipse is screwing your environment up.
Edit:
Looked at your env dumps, looks like eclipse is definitely messing with PYTHONPATH, which will cause your child python processes to not work correctly.
Basically what you have going on here is eclipse starts a python v2 instance with a PYTHONPATH pointing to the python v2 directories. Then you spawn a python v3 process which tries to load its landmark from the python v2 directories...
You need to find a way to have eclipse not mess with the PYTHONPATH. I am not sure what eclipse is trying to do by doing that, but it is certainly no friend when you want to spawn new python processes.