How do I fix a blank white screen for Visual Studio Code run remotely through X11? - visual-studio-code

Visual Studio Code displays perfectly from a local display on a Ubuntu 20 installation, but just produces a blank white window when run from a remote Ubuntu machine through X-windows. Running code --disable-gpu doesn't help. Other applications such as Firefox, Nautilus, and Eclipse display remotely with no problem.
Any suggestions?

There is an issue for this upstream: https://github.com/microsoft/vscode/issues/110119
Running code --verbose --log debug --disable-gpu prints, among others:
[3440:1116/110926.098706:WARNING:x11_util.cc(1520)] X error received: serial 169, error_code 1 (BadRequest (invalid request code or no such operation)), request_code 130, minor_code 1 (X_ShmAttach)
[3440:1116/110926.129228:WARNING:x11_util.cc(1520)] X error received: serial 170, error_code 1 (BadRequest (invalid request code or no such operation)), request_code 130, minor_code 1 (X_ShmAttach)
[3440:1116/110926.170878:WARNING:x11_util.cc(1520)] X error received: serial 171, error_code 1 (BadRequest (invalid request code or no such operation)), request_code 130, minor_code 3 (X_ShmPutImage)
[3440:1116/110926.204224:WARNING:x11_util.cc(1520)] X error received: serial 172, error_code 1 (BadRequest (invalid request code or no such operation)), request_code 130, minor_code 3 (X_ShmPutImage)
I don't know much about X, but I would expect X shared memory (shm) to not work via X forwarding, and maybe it's something that vscode currently needs?

It looks like it started in rev 1.66 on my Linux systems.
I uninstalled and installed 1.65 from here:
https://code.visualstudio.com/updates/v1_65

For me the "--disable-extensions --disable-gpu" options worked.

Just install an old version of VS Code.
I use version 1.59.1 and I don't have a white screen anymore when I use sudo.

Related

Anaconda 3 throwing error when installed in Linux Mint 19

I had a previous version of Anaconda 2 (working with Python 2.7), which I uninstalled to newly install Anaconda 3 (to work with Python 3.x).
While the previous Anaconda 2 was working fine, the newly installed Anaconda 3 throws the following error:
Traceback (most recent call last):
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/widgets/main_window.py", line 541, in setup
self.post_setup(conda_data=conda_data)
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/widgets/main_window.py", line 578, in post_setup
self.tab_home.setup(conda_data)
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/widgets/tabs/home.py", line 169, in setup
self.set_applications(applications, packages)
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/widgets/tabs/home.py", line 204, in set_applications
apps = self.api.process_apps(applications, prefix=self.current_prefix)
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/api/anaconda_api.py", line 848, in process_apps
app = app(config=self.config, process_api=self._process_api, conda_api=self._conda_api)
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/api/external_apps/vscode.py", line 48, in __init__
**kwargs
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/api/external_apps/base.py", line 43, in __init__
self.init()
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/api/external_apps/base.py", line 60, in init
SUBDIR, INST_EXT, INST_DIR = self._find_linux_install_dir()
File "/home/partha/anaconda3/lib/python3.7/site-packages/anaconda_navigator/api/external_apps/vscode.py", line 168, in _find_linux_install_dir
if DISTRO_NAME in ['ubuntu', 'debian']:
UnboundLocalError: local variable 'DISTRO_NAME' referenced before assignment
Any help to get started with the new installation will be much appreciated.
I am using Linux Mint 19 with the following info:
...$ cat /etc/linuxmint/info
RELEASE=19
CODENAME=tara
EDITION="Xfce"
DESCRIPTION="Linux Mint 19 Tara"
DESKTOP=Gnome
TOOLKIT=GTK
NEW_FEATURES_URL=http://www.linuxmint.com/rel_tara_xfce_whatsnew.php
RELEASE_NOTES_URL=http://www.linuxmint.com/rel_tara_xfce.php
USER_GUIDE_URL=help:linuxmint
GRUB_TITLE=Linux Mint 19 Xfce
...$
A quick google search showed that an issue was open about your problems few days ago in github
Fortunately a workaround was posted:
Editing the file: ".../anaconda3//lib/python3.7/site-packages/anaconda_navigator/api/external_apps/vscode.py"
By declaring the variable outside the loop.
Just add the line:
DISTRO_NAME = None
on Line 159 and indent it in line with the if above it (Outside it)
I got a similar experience this morning. But I was able to resolve mine by typing this into my command-line interface(CLI).
conda update anaconda-navigator
I hope this work for you.

Net::SSH2::Simple failed after update to Windows10

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.

Octave imread bmp file

I need to read a file myFile.bmp in Octave but it doesn't work.
I have:
Ubuntu 15.04
Ocatve 3.8.2
ImageMagick 8:6.8.9.9-5
When I run imread('myFile.bmp'), I get this:
octave:10> imread ("myFile.bmp")
error: imread: invalid image file: /usr/lib/x86_64-linux-gnu/octave/3.8.2/oct/x86_64-pc-linux-gnu/__magick_read__.oct: failed to load: /usr/lib/x86_64-linux-gnu/octave/3.8.2/oct/x86_64-pc-linux-gnu/__magick_read__.oct: undefined symbol: _ZN6Magick5ColorC1Ehhh
error: called from:
error: /usr/share/octave/3.8.2/m/image/private/__imread__.m at line 181, column 7
error: /usr/share/octave/3.8.2/m/image/private/imageIO.m at line 66, column 26
error: /usr/share/octave/3.8.2/m/image/imread.m at line 107, column 30
When I run imread('myFile.bmp', 'Format', 'bmp'), I get the same error.
If you installed everything from the Ubuntu repositories, then you are probably affected by an Ubuntu packaging issue. It was described in comment #6 of Ubuntu bug #1372202.
Since Ubuntu 15.04 has already reached end of life, they probably won't fix it. You can:
upgrade Ubuntu
build Octave from source yourself

Enthought Canopy - "IOError: [Errno 10038]" when install or update packages in Package Manager

I have installed Canopy 1.7.4.3348 (64 bit). My OS is Windows 10 (64 bit). I have the most updated Canopy and Windows 10.
When I tried to update and install any packages in Package Manager, the "Status" would turn out to be "Error", and I got the message:
IOError: [Errno 10038] An operation was attempted on something that is not a socket.
I looked up the Error code on microsoft.com (https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx) and found Microsoft's definition of socket error 10038:
WSAENOTSOCK 10038
Socket operation on nonsocket.
An operation was attempted on something that is not a socket.
Either the socket handle parameter did not reference a valid socket,
or for select, a member of an fd_set was not valid.
I think this error from Canopy may only exist in Windows but not in other OS like Linux. Could anyone please kindly help with this issue? Really appreciate it!!
The detailed messages are as below:
Warming up...
Traceback (most recent call last):
File "build\bdist.win-amd64\egg\canopy_dashboard\packman\package_action_worker.py", line 54, in run
File "build\bdist.win-amd64\egg\canopy_dashboard\packman\package_action.py", line 193, in execute
File "build\bdist.win-amd64\egg\canopy_dashboard\packman\packman.py", line 346, in <lambda>
File "build\bdist.win-amd64\egg\canopy_dashboard\packman\packman.py", line 893, in _install
File "build\bdist.win-amd64\egg\canopy_platform\cpython_packages_manager.py", line 98, in install_package
File "build\bdist.win-amd64\egg\canopy_platform\enpkg_api.py", line 102, in install_package
File "build\bdist.win-amd64\egg\canopy_platform\enpkg_api.py", line 177, in _execute_in_subprocess
File "build\bdist.win-amd64\egg\canopy_platform\enpkg_api.py", line 212, in _propagate_progress_events
IOError: [Errno 10038] An operation was attempted on something that is not a socket
Please file a bug report from the Canopy help menu for Enthought tech support records (and please refer to this SO question in your report).
I don't know what causes this rare error, but it should disappear in Canopy 2.0, which uses a different package manager backend, based on the Enthought Deployment Manager (EDM).
Meanwhile, you can avoid the error by using the command-line package installer, enpkg, from a Canopy Command Prompt. Please see this Knowledge Base article for details: https://support.enthought.com/entries/22415022-Using-enpkg-to-update-Canopy-EPD-packages.

Cannot run magic functions in ipython terminal

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.