I'd like to try using maxima on jupyter (Windows). I was made aware that there is a maxima kernel for jupyter named maxima-jupyter (https://github.com/robert-dodier/maxima-jupyter).
I installed maxima using chocolatey and tried to follow the steps given on https://github.com/robert-dodier/maxima-jupyter. Regarding the step where I need to install Quicklisp, I tried doing it using command line maxima like this:
Maxima 5.44.0 http://maxima.sourceforge.net
using Lisp SBCL 2.0.0
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) load("quicklisp.lisp");
==== quicklisp quickstart 2015-01-28 loaded ====
To continue with installation, evaluate: (quicklisp-quickstart:install)
For installation options, evaluate: (quicklisp-quickstart:help)
(%o1) quicklisp.lisp
(%i2) (quicklisp-quickstart:install);
(%o2) quicklisp - install
(%i3)
Quicklisp prompts me with "quicklisp - install" and I have no idea what to do next.
Did I do something wrong with my preceding steps or should I install SBCL on my device and install quicklisp using that?
Related
I am using a Windows machine and trying to have Jupyter Notebook kernels for multiple versions of Julia (0.7.0 and 1.1.1) because package AWS does not support the latest version, but does support 0.7.0.
I had Julia 1.1.1 installed on my computer first and got something similar to the following error when I tried to install package AWS: https://github.com/JuliaLang/Pkg.jl/issues/792
Then I installed Julia 0.7.0 and was able to install AWS in the Julia 0.7.0 terminal with Pkg.add("AWS") with no problems.
In the Julia 0.7.0 terminal, I installed IJulia again with Pkg.add("IJulia") and restarted my Jupyter notebook instance. Now I'd like to use AWS via Jupyter notebook but when I create a new one, only Julia 1.1.1 appears.
I ended up having success by showing which kernels I had using jupyter kernelspec list in terminal, which showed where my other Julia kernel was located.
>>> jupyter kernelspec list
Available Kernels:
julia-1.1 C:\Users\{%USERNAME%}\AppData\Roaming\jupyter\kernels\julia-1.1
python3 C:\ProgramData\Anaconda3\share\jupyter\kernels\python3
I navigated to the file path listed after julia-1.1
Created a julia-0.7 folder in that same directory
Copied over contents from the julia-1.1 folder
Edited the kernel.json file by replacing every instance of julia-1.1.1 with julia-0.7.0
What I ended up having success with seems like a very rudimentary way to solve this problem. I'd like a more elegant way to achieve the same result, similar to when adding multiple kernels for different versions of Python. (Using both Python 2.x and Python 3.x in IPython Notebook)
Please help, thank you!
You (probably) just need to Pkg.build("IJulia") on the second Julia version.
Since Julia 0.7 the package manager uses separate directories for each version of a package, meaning that, from the package managers perspective, the package is already installed, and no downloading or building is performed when you install the same version from a different Julia version. The package manager does not know, however, that IJulia needs to be rebuilt for this new Julia version. You can trigger the build manually by Pkg.build("IJulia").
I am facing a particularly vexing problem with R package development. My own package, called ggstatsplot (https://github.com/IndrajeetPatil/ggstatsplot), depends on userfriendlyscience, which depends on another package called MBESS, which itself ultimately depends on another package called gsl. There is no problem at all for installation of ggstatsplot on a Windows machine (as assessed by AppVeyor continuous integration platform: https://ci.appveyor.com/project/IndrajeetPatil/ggstatsplot).
But whenever the package is to be installed on Unix machines, it throws the error that ggstatsplot can't be downloaded because userfriendlyscience and MBESS can't be downloaded because gsl can't be downloaded. The same thing is also revealed on Travis continuous integration platform with virtual Unix machines, where the package build fails (https://travis-ci.org/IndrajeetPatil/ggstatsplot).
Now one way to solve this problem for the user on the Unix machine is to configure GSL (as described here:
installing R gsl package on Mac), but I can't possibly expect every user of ggstatsplot to go through the arduous process of configuring GSL. I want them to just run install.packages("ggstatsplot") and be done with it.
So I would really appreciate if anyone can offer me any helpful advice as to how I can make my package user's life simpler by removing this problem at its source. Is there something I should include in the package itself that will take care of this on behalf of the user?
This may not have a satisfying solution via changes to your R package (I'm not sure either way). If the gsl package authors (which include a former R Core member) didn't configure it to avoid a pre-req installation of a linux package, there's probably a good reason not to.
But it may be some consolation that most R+Linux users understand that some R packages first require installing the underlying Linux libraries (eg, through apt or dnf/yum).
Primary Issue: making it easy for the users to install
Try to be super clear on the GitHub readme and the CRAN INSTALL file. The gsl package has decent CRAN directions. This leads to the following bash code:
sudo apt-get install libgsl0-dev
The best example of clear (linux pre-req package) documentation I've seen is from the curl and sf packages. sf's CRAN page lists only the human names of the 3 libraries, but the GitHub page provides the exact bash commands for three major distribution branches. The curl package does this very well too (eg, CRAN and GitHub). For example, it provides the following explanation and bash code:
Installation from source on Linux requires libcurl. On Debian or Ubuntu use libcurl4-openssl-dev:
sudo apt-get install -y libcurl-dev
Ideally your documentation would describe how do install the gsl linux package on multiple distributions.
Disclaimer: I've never developed a package that directly requires a Linux package, but I use them a lot. In case more examples would help, this doc includes a script I use to install stuff on new Ubuntu machines. Some commands were stated explicitly in the package documentation; some had little or no documentation, and required research.
edit 2018-04-07:
I encountered my new favorite example: the sys package uses a config file to produce the following message in the R console. While installing 100+ packages on a new computer, it was nice to see this direct message, and not have to track down the R package and the documentation about its dependencies.
On Debian/Ubuntu this package requires AppArmor.
Please run: sudo apt-get install libapparmor-dev
Another good one is pdftools, that also uses a config file (and is also developed by Jeroen Ooms).
Secondary Issue: installing on Travis
The userfriendly travis config file apparently installs a lot of binaries directly (including gsl), unlike the current ggstatsplot version.
Alternatively, I'm more familiar with telling travis to install the linux package, as demonstrated by curl's config file. As a bonus, this probably more closely replicates what typical users do on their own machines.
addons:
apt:
packages:
- libcurl4-openssl-dev
Follow up 2018-03-13 Indrajeet and I tweaked the travis file so it's working. Two sections were changed in the yaml file:
The libgsl0-dev entry was added under the packages section (similar to the libcurl4-openssl-dev entry above).
Packages were listed in the r_binary_packages section so they install as binaries. The build was timing out after 50 minutes, and now it's under 10 min. In this particular package, the r_binary_packages section was nested in the Linux part of the Travis matrix so it wouldn't interfere with his two OS X jobs on Travis.
Does anyone have a link to clear instructions on how to install and configure the necessary latex packages to build R packages on a mac?
I have some scripts for building and checking R packages on a mac server. They seemed to work fine, but after upgrading to R 3.1.3, many of the packages started failing with
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'networkVignette.tex' failed.
Messages:
sh: /usr/local/bin/texi2dvi: No such file or directory
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
I found a thread which seemed to suggest I need a more recent version texinfo (5.2) than what is installed by default. And apparently I've I've got the wrong version installed in the wrong location?
which texi2pdf
/sw/bin/texi2pdf
texi2pdf --version
texi2pdf (GNU Texinfo 5.1) 5234
(same version is reported when running system('texi2pdf --version') in R )
This thread gives a link to a texinfo 5.2 source collection:
http://r.789695.n4.nabble.com/R-CMD-build-looking-for-texi2dvi-in-the-wrong-place-R-devel-td4701706.html
But I'm not familiar with installing executable from a tar.gz file on a mac. The R mac help pages I found suggest installing MacTex, which I tried but that didn't seem to help.
** Update: ** additional discussion of related problems on R-SIG-mac mailing list:
https://groups.google.com/forum/#!topic/r-sig-mac/xjyuFdl5Ezk
Update:
Here is where I'm currently at:
I removed my /sw directory to uninstall fink and all of its packages (couldn't figure out how to upgrade it)
installed homebrew
brew install texinfo installs version 5.2 the package,
but generates the message This formula is keg-only, which means it was not symlinked into /usr/local and actually installs in in /usr/local/Cellar/texinfo/5.2/bin which means it is not on the path and R won't find it.
manually symlink each of the texi2pdf, texi2dvi , etc as vincent suggests (this is because R has the /usr/local/bin location as default in the tools::texi2dvi function?
edited the /etc/paths file on the system to add /usr/local/bin so that finds the brew installed 5.2 version before it finds it before the osx system supplied version 4.6 version. This may not be necessary because R has it hardcoded?
All of this gets rid of the "can't find texi* errors", and gives me a bunch of latex errors (which I don't see on unix and windows builds) so I'm still kind of stuck.
This seems very hackish, so there must be a cleaner way? But it sounds like stuff with tex and mac is very sketchy at the moment? https://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
This worked for me on Mavericks and on Yosemite:
ln -s /usr/bin/texi2dvi /usr/local/bin/texi2dvi
ln -s /usr/bin/texi2pdf /usr/local/bin/texi2pdf
On my Lion system both the command which texi2pdf at a Terminal/bash prompt and from a R.app GUI prompt tell me that I have that program in:
system("which texi2pdf")
#/opt/local/bin/texi2pdf
That is a location typical for MacPorts installation. I think the /usr/local/bin/ is what the binary R version "expects". I'm not really that UNIX savvy, but I think the you can modify the PATH environment variable so that R will be able to find your installation. (Whether it will be compatible I cannot say since so much detail is missing from your question.) My Tex installation is MacTex, which I got from https://www.tug.org/mactex/. I admit to having a cobbled-together system:
system("echo $PATH")
# /opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
That gets set at the beginning of an R session because this is the first line in my .Rprofile-(invisible)file:
Sys.setenv(PATH="/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin")
I think /sw/bin/ installations signify a fink install, which I have had very little success with. Simon Urbanek suggests not using any package installers, but then leaves the rest of us UNIX weenies very little in the way of worked examples of how to install that various external packages that underpin the many interesting and oh-so-useful R packages. So I feel your pain, but I'm not running for President.
So I suppose you could try this at your R console before again attempting one of the earlier unsuccessful installs:
Sys.setenv(PATH=paste( Sys.getenv()$PATH, # should be the character string of the $PATH
"/sw/bin/", sep=":")
)
Wish I could offer guarantees, but if it breaks the only guarantee is that you get to keep all the pieces.
I ran into a similar error message using Mavericks 10.9.5 (factory configured) and R 3.1.
It turns out that I didn't have pdfLaTex. I went to this page: http://tug.org/mactex/ and downloaded the MacTex installation package. It's big (>2GB) but after I installed it, my R package build problems went away.
Hope this might be helpful to anyone else who runs into this error message.
When installing GLPK from (from https://www.gnu.org/software/glpk), I get the following error:
libtool: install: /usr/bin/install -c .libs/libglpk.36.dylib /usr/local/lib/libglpk.36.dylib
install: /usr/local/lib/libglpk.36.dylib: Permission denied
I have tried installing to other locations successfully, but python does not find the package. I would like to run. Note: I am using Enghought Canopy to run Python on Mac OS X version 10.9.4.
You don't install a non-python package into Python. You install it on your system (not a python issue, maybe someone else will have a suggestion), and then install a python package which "wraps" it -- provides access to it in python. If you have already successfully installed GLPK, then you should simply be able to open a Canopy Terminal window from the Canopy Tools menu, and type:
pip install glpk
EDIT: It looks like this is the best place for examples of using it: http://www.tfinley.net/software/pyglpk/examples.html
I'm convinced that using Dirk's package is the best way to install and maintain R on an Ubuntu system. But I want to have some fun and get used to installing R from source.
What are the most common configure flags to use when installing?
Also, if I want to install 2.14.1 and I have 2.14.0 currently installed (which was installed from source), should I first uninstall 2.14.0?
There was a recent thread somewhere about having several versions---one from the apt-get repo, one in /usr/local. Try to find that...
Otherwise, I will roll up 2.14.1 on Friday morning, Michael will do his magic and the repo will have .deb packages of 2.14.1 'real soon', sometimes within a day.
Lastly, you can see which flags are used by getting the package sources for which you just do apt-get source r-base (and that works for any Debian/Ubuntu package that way if you have source references in apt's file.
Edit: By the way, regarding the '64-bit' aspect of your question: Nada. We don't do anything differently. It is "merely" the host OS being more generous with resources. But R finds all it needs to know on its own via its configure etc logic.