On 18 January 2016 at 21:43, Kurt Pagani <[email protected]> wrote: > > Am 18.01.2016 um 18:41 schrieb Bill Page: > >> As I understanding it, docker assigns ip addresses to containers in >> the range 172.17.0.x with the host having address 172.17.0.1. These >> are used to set up the port mappings, e.g. 443:8888. localhost in the >> container is (usually) assigned 127.0.0.1 by the operating system. So >> it is important that jupyter notebook be able to listen on ports other >> than localhost. > > Meanwhile there is a "jungle" of possibilities mapping ports: see e.g. > https://www.ctl.io/developers/blog/post/docker-networking-rules/ >
Actually it seems pretty clear but unfortunately ip is mentioned but not explained anywhere in this article. > The simplest one still is the "-p" option, however, everything is > perfectly configurable. > Perfect. ;) >> >> A couple of other comments about the docker image: >> >> 1) It seems that the Jupyter root is set to /. This seems unnatural in >> general since that exposes the usual linux root directories - although >> I can understand that it is convenient for now. How should this be >> handled in the future? Can the Jupyter root be set via the command >> line when the docker image is started? >> > > No, because this is wired in the Docker file: > > https://github.com/nilqed/fricas_jupyter/blob/master/Dockerfile > > You'll see the lines: > > ... > RUN cd /root && \ > git clone https://github.com/nilqed/fricas_jupyter.git && \ > cd ./fricas_jupyter && \ > ./install.sh > > Simply change the "cd /root" to "cd /whatever/you/like". What I actually see when I start notebook is the system directory '/', not '/root'. The same thing when I start Terminal in Jupyter. Perhaps the root or home folder if the notebook is set somewhere else? > > If you are going to use the image for other purposes than the notebook > it would certainly be better not using the "root" folder ;) I use docker > for testing purposes only, so it's convenient as you noticed. > > Also the base dockerfile > https://github.com/nilqed/fricas_docker/blob/master/Dockerfile suffers > from the same sloppiness. For production use there are many > pre-configured templates around (SSL, password, multi-user). > OK. I have a lot to learn about docker. At first blush not all of it seems pleasant or straight forward so maybe I should decide first just what I want to do with this docker image thing. Should perhaps the FriCAS project be offering this as a potential way to install FriCAS with the Jupyter interface? Are any other FriCAS users interest in this? > >> 2) Apparently the default command shell is /bin/sh when a Jupyter >> Terminal windows is opened. This seems to cause trouble with the >> usual history mechanism one expects from bash. It is possible of >> course to start a bash shell and things then work as usual but I >> wonder it bash should not be the default? Again, perhaps this can be >> set from the Jupyter command line? > > Indeed, there has been some controvery about that: > https://github.com/docker/docker/issues/8100 > > ... because /bin/sh is available on every linux distro, whereas > /bin/bash is not. > Well um, I am not sure this is exactly about what I was talking about - maybe. What I did expect was for the Jupyter Terminal window to be using bash. this could be set by /etc/passwd but I was not even able to determine exactly what the user id is when I open Terminal. All of this is still mysterious to me. > >> I don't think SMC can use docker images. William Stein needs to be >> able to globally install a Jupyter kernel for FriCAS on SMC. The >> easier we can make it for him to do that the better - just one command >> would be ideal. I haven't checked your documentation yet, but is it >> still necessary to recompile FriCAS to install part of the interface? >> If this is the case, then perhaps it would be better first to resolve >> how to get this interface included in the FriCAS distribution. >> >> Regards, >> Bill Page. >> > > Let me summarize the current situation: > > The recommended installation is here: > https://github.com/nilqed/fricas_jupyter > > In principle a ".\install.sh" is enough, provided that: > > - FriCAS, SBCL and Jupyter have been installed. > - AxiomSYS is a SBCL core of the same version (i.e. a binary Fricas > version may be used if you have the corresponding SBCL version ;) > > The install script loads AxiomSYS as a core into SBCL, then compiles the > kernel and saves a new image "iSPAD" to ".local/bin", thus working > without "sudo". > > -rwxr-xr-x 1 root root 73596976 Okt 25 22:10 AXIOMsys > -rwxr-xr-x 1 kfp kfp 95125552 Dez 17 17:54 iSPAD > > The resulting image is more than 20MB bigger, so it's probably better to > keep it outside the distribution. Provided that in all other respects iSPAD behaves like AXIOMsys, i.e that the interpret and hyperdoc work the same way, then I do not see any reason not to just include this as a make file step controlled by a configure option. On SMC we could just ask William Stein (make it easy as part of the FriCAS installation) to replace AXIOMsys with the iSPAD image globally. The easiest for Stein would be if this could be done with just an ubuntu apt-get. > When loading SNARK and KENZO we even get 160MB. > What's that? > To get it on SMC we also could use: > https://github.com/nilqed/fricas_smc/releases > which I've completely forgotten. This provides a pre-configured > FriCAS/SBCL environment and ought to go with ease. > Yes, that looks very promising. But on SMC however Jupyter is already installed globally (with some SMC specific extensions). In my limited understanding this means that as a minimum the locations of files change and the script needs to be run by an SMC administrator. Bill. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
