This is on a new bleeding edge ubuntu installed laptop where I also installed all the latest packages and tools.
The jupyter notebook also doesn't display the asterisk * when busy and execution index.
This might seem trite but I'm very used to the way notebooks work and without the order of execution and the busy asterisk I'm slowly losing my grip on reality.
Especially strange is the fact that I googled the hell out of this but it seems no one has encountered or reported it, hope its not an option I'm missing or something.
output of python --version :
Python 3.7.5
output of pip freeze :
absl-py==0.9.0
astor==0.8.1
attrs==19.3.0
backcall==0.1.0
bleach==3.1.0
boto3==1.12.38
botocore==1.15.38
Bottleneck==1.3.1
cachetools==4.0.0
certifi==2020.4.5.1
chardet==3.0.4
cycler==0.10.0
decorator==4.4.1
defusedxml==0.6.0
docutils==0.15.2
entrypoints==0.3
fasttext==0.9.1
gast==0.3.3
gensim==3.8.1
google-api-core==1.16.0
google-auth==1.13.1
google-cloud-core==1.3.0
google-cloud-storage==1.27.0
google-pasta==0.1.8
google-resumable-media==0.5.0
googleapis-common-protos==1.51.0
grpcio==1.27.1
h5py==2.10.0
idna==2.9
importlib-metadata==1.5.0
ipykernel==5.1.4
ipython==7.12.0
ipython-genutils==0.2.0
ipywidgets==7.5.1
jedi==0.16.0
Jinja2==2.11.1
jmespath==0.9.5
jsonschema==3.2.0
jupyter==1.0.0
jupyter-client==5.3.4
jupyter-console==6.1.0
jupyter-contrib-core==0.3.3
jupyter-contrib-nbextensions==0.5.1
jupyter-core==4.6.1
jupyter-highlight-selected-word==0.2.0
jupyter-latex-envs==1.4.6
jupyter-nbextensions-configurator==0.4.1
Keras==2.3.1
Keras-Applications==1.0.8
Keras-Preprocessing==1.1.0
kiwisolver==1.1.0
lxml==4.5.0
Markdown==3.2
MarkupSafe==1.1.1
matplotlib==3.1.3
mistune==0.8.4
more-itertools==8.2.0
nbconvert==5.6.1
nbextensions==0.1.0
nbformat==5.0.4
notebook==6.0.3
numexpr==2.7.1
numpy==1.16.4
pandas==1.0.1
pandocfilters==1.4.2
parso==0.6.1
pexpect==4.8.0
pickleshare==0.7.5
pkg-resources==0.0.0
prometheus-client==0.7.1
prompt-toolkit==3.0.3
protobuf==3.11.3
ptyprocess==0.6.0
pyasn1==0.4.8
pyasn1-modules==0.2.8
pybind11==2.4.3
Pygments==2.5.2
pyparsing==2.4.6
pyrsistent==0.15.7
python-dateutil==2.8.1
pytz==2019.3
PyYAML==5.3
pyzmq==18.1.1
qtconsole==4.6.0
requests==2.23.0
rsa==4.0
s3transfer==0.3.3
scipy==1.4.1
Send2Trash==1.5.0
six==1.14.0
smart-open==1.10.0
tensorboard==1.14.0
tensorflow==1.14.0
tensorflow-estimator==1.14.0
tensorflow-gpu==1.14.0
termcolor==1.1.0
terminado==0.8.3
testpath==0.4.4
torch==1.4.0
tornado==6.0.3
traitlets==4.3.3
urllib3==1.25.8
wcwidth==0.1.8
webencodings==0.5.1
Werkzeug==1.0.0
widgetsnbextension==3.5.1
wrapt==1.11.2
zipp==2.2.0
I've fixed the problem by:
deleting all my venvs
uninstalling all the packages from the main linux python installation (things I accidently didn't install via dpkg)
creating a new venv with all the GPU stuff and checking that it works
removing all the leftovers from the notebook stuff (mostly broken binaries)
adding the notebook stuff (mainly jupyter) to the packages
deleting the .jupyter config, recreating it and changing stuff like desktop/ initial folder/ etc...
running jupyter and seeing that it works fine
adding nbextensions and other packages the rest of my code needs
Related
Anyone got an idea why
system2("bash", "ls")
would result in (both in R-Gui and RStudio Console)
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
while other shells work w/o issues (see example below) and the "bash" in the RStudio Terminal also works w/o problems. AND if there is a remedy for that?
Working system2 example:
system2("powershell", "dir")
Running R-3.6.3 on Windows 10 here ... with "Git bash" executing as "bash".
PS: just in case someone wonders - I also tried the full path ie /usr/bin/ls -> same result
Ok - this does the trick
system2("bash", input = "ls")
so instead of args = ... as with the powershell command one needs (or more interestingly sometimes 'can') use the input = ... parameter with bash
OR as mentioned in the comments by #oguzismail this will also work
system2("bash", "-c ls")
as well as pointed out by #Christoph
system2("ls")
also works sometimes (ie in some RStudio[?] setups it will not return results in some it will).
But I have come to notice that different combinations of R-versions with different RStudio versions [or more probably Locales] will not always behave consistently of course also depending on the availability of bash commands like ls (more generally /usr/bin) being on the PATH or not.
So choose what suits u best!
Whenever I start Atom it opens two files, one called:
ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false
And the other one:
/usr/bin/atom
It's really annoying and I don't understand how to fix it. From what I understand it is some sort of environment configuration bug, but I can't find what's causing it.
I am going to make several assumptions. You are running on Ubuntu and you've installed Atom via Snap.
If these assumptions are correct the cause of the issue is a misconfigured application menu item from the Snap package author.
To fix it you just need to run this command:
sudo sed -i 's/Exec=env BAMF_DESKTOP_FILE_HINT=\/var\/lib\/snapd\/desktop\/applications\/atom_atom.desktop \/snap\/bin\/atom ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false \/usr\/bin\/atom %F/Exec=env BAMF_DESKTOP_FILE_HINT=\/var\/lib\/snapd\/desktop\/applications\/atom_atom.desktop ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false \/snap\/bin\/atom %F/' /var/lib/snapd/desktop/applications/atom_atom.desktop
TL;DR {
Here is a detailed explanation of what's causing the issue and what the command above does. It may be useful if the file has been changed since the answer was written.
The actual cause for the bug is that this menu item file:
/var/lib/snapd/desktop/applications/atom_atom.desktop
It has a typo in it and what should be environment variables are set after calling
the atom executable, resulting in Atom treating it as arguments in the form of
files that it should open.
# ▼ Executable ▼ Not an environment variable ▼ Not an executable
Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/atom_atom.desktop /snap/bin/atom ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false /usr/bin/atom %F
It should instead be:
# ▼ Environment variable ▼ Environment variable ▼ Executable
Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/atom_atom.desktop ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false /snap/bin/atom %F
The solution above uses sed to search and replace the file and fix the issue.
}
NOTE: The command will work until the Snap author updates the menu item file (.desktop) when hopefully the issue would have been resolved.
(ql:quickload "aserve") fails
I'm trying to install AllegroServe. According to http://quickdocs.org/portableaserve/ and to this SO thread the simplest way to get aserve would be to get it with quicklisp: (ql:quickload "aserve")
But (ql:quickload "aserve") fails yielding the following error in the debugger buffer:
COMPILE-FILE-ERROR while compiling
#<IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "digest">
[Condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR]
Whereas in the REPL it says:
; Loading "aserve"
; caught ERROR: READ error during COMPILE-FILE: Symbol "BIGNUM-TYPE"
; not found in the SB-BIGNUM package. Line: 53, Column: 52,
; File-Position: 2151 Stream: #<SB-INT:FORM-TRACKING-STREAM for
; "file
; C:\\Users\\user\\AppData\\Roaming\\quicklisp\\dists\\quicklisp\\software\\ironclad_0.33.0\\src\\digests\\digest.lisp"
; {25AFCD91}>
What I've tried so far
Apparently ironclad is another package, a "cryptographic toolkit written in pure Common Lisp". I downloaded ironclad-v0.34 from http://quickdocs.org/ironclad/ and even found digest.lisp and digests.lisp in the ironclad folder which made me think that I am on the right track.
My problem is I don't no where to go from here. How and where do I "install" ironclad?
Quickdocs says
[ironclad] comes with an ASDF system definition, so (asdf:oos 'asdf:load-op
:ironclad) should be all that you need to get started. The testsuite
can be run by substituting asdf:test-op for asdf:load-op in the form
above.
but since I'm not familiar with asdf I don't know what to make of it.
Am I even on the right track? Is installing the ironclad package the right way to make the error COMPILE-FILE-ERROR while compiling #<IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "digest">go away? If so what do I do with the ironclad-v0.34 folder?
(I'm using sbcl on a windows 10 machine.)
Thanks to #jkiiski leading me down the right path I was able to install aserve. The problem was indeed an old version of ironclad which, as #jkiiski pointed out, was using SB-BIGNUM:BIGNUM-TYPE which had been removed from SBCL.
However, the way I updated ironclad is probably NOT(!) a good way because I did it all manually (error prone).
Not knowing how quicklisp works exactly I searched for every occurence of ironclad-0.33.0 and replaced it with ironclad-v0.34, which meant replacing
the .../dists/quicklisp/software/ironclad-0.33.0 folder with .../dists/quicklisp/software/ironclad-v0.34
the irconcladd-0.33.0 tgz in .../dists/quicklisp/archives/ with ironclad-v0.34.tgz
the entry dists/quicklisp/software/ironclad-0.33.0/ in .../dists/quicklisp/installed/releases/ironclad.txt with dists/quicklisp/software/ironclad-v0.34/.
I also updated ironclad.txt and ironclad-text.txt in .../dists/quicklisp/installed/systems/
Well, it worked, but I only did it this way because I don't know any better (but am sure there has to be a better way).
I want to have highlights for multiple words. i normally do this in .vimrc-
:highlight HLONE ctermbg=grey ctermfg=white
:highlight HLTWO ctermbg=blue ctermfg=white
:highlight HLTHREE ctermbg=green ctermfg=white
nnoremap 1 :mat HLONE "<C-R><C-W>"<CR>
nnoremap 2 :2mat HLTWO "<C-R><C-W>"<CR>
nnoremap 3 :3mat HLTHREE "<C-R><C-W>"<CR>
But its not working for me at my current workplace for some reason. Presessing one highlights the way it should. but pressing 2 (2mat) gives error -
E481: No range allowed
its seems 2mat, 3mat, matchadd are not available. vim version is 6.3.
is there any workaround or alternative?
Vim 6.3 is from 2004; the :2match commands were only introduced in Vim 7.0. If you're stuck with that version, you can only use :match, or alternatively try :syn keyword (but that will interfere with the regular syntax highlighting).
Even without root / administrative rights, you can usually compile / install a local version of Vim.
Advertisement: If you find the multi-word highlighting indispensable and use it often, try out my Mark plugin; it automates the process of :2match, offers many colors, and highlights in all windows (but requires Vim 7.2). On that page are also links to other such plugins, some of which still use syntax highlighting and may work even with Vim 6.
I am looking for a working distribution of SQLite for OpenVMS. I tried building SQLite 3.7.9 from the amalgamation file, using patches I found in a mailing list, but it does not quite work.
I am using HP C V7.1-015 on OpenVMS Alpha 7.3-2.
Since I cannot install python, which seems to include SQLite3, I have to build from sources.
I compile using the following commands:
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
sqlite3.c
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
shell.c
I copied the defines from the mailing list, and added /FLOAT=IEEE_FLOAT to get rid of most warnings regarding floating points (related to overflows due to exponent 308).
During compilation I got some informationals and warnings.
I get the following messages while linking:
$ LINK shell.obj,sqlite3.obj
...
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, __STD_FSTAT
%LINK-I-UDFSYM, __STD_STAT
...
Since I am a little bit lost here, I rather have SQLite3 sources which compile on OpenVMS.
The specific problem you're getting from the linker arises from the fact that you've requested capability at compile time that your system doesn't have. I believe the _USE_STD_STAT option first became available in OpenVMS v8.2, yet you're on 7.3-2. Your compiler and your headers know what to do when _USE_STD_STAT is defined, but the functions to process the X/Open-compliant stat structure do not exist in the C run-time (CRTL in VMS parlance) on your system, and your linker is telling you, "ain't got those functions."
Ideally you would be able to upgrade your operating system. Current as of this writing is v8.4. v7.3-2 was released eight and a half years ago and v8.2 over seven years ago. I understand that there are technical, budgetary, and even political reason that upgrades aren't always possible. If it were me, and I were stuck on OpenVMS Alpha v7.3-2, I would try removing the _USE_STD_STAT=ENABLE from the compilation and see what blows up.
One of the side effects of enabling _USE_STD_STAT is that you also get _LARGEFILE along with it. If that's the only reason SQLite needs the option, you may be fine but limited to 4GB databases. I suspect there's more to it than that, i.e., SQLite very likely makes use of elements in the stat structure that do actually require the newer structure.
You can read up on the differences in the traditional and standards-compliant stat structures at http://h71000.www7.hp.com/doc/84final/5763/5763profile_062.html#index_x_1699.
I've recently improved my VMSish patch for SQLite and made it available for SQLite version 3.7.14.1: http://www.mail-archive.com/sqlite-users#sqlite.org/msg73570.html (or http://sqlite.1065341.n5.nabble.com/Building-SQLite-3-7-14-1-for-OpenVMS-td65277.html).
POSIX locking still doesn't work though, and I was unable to find out why.
Well, there was a message on the sqlite-users mailing list on getting SQLite 3.7.9 working on OpenVMS. I don't know how relevant that is to the version you've got (or if the patch was adopted by the SQLite developers; they're a bit picky for legal reasons IIRC) but it looks likely to be useful. Good luck.