Re: [fricas-devel] jupyter notebook

Am 12.10.2016 um 03:48 schrieb Bill Page: > On 11 October 2016 at 20:16, Kurt Pagani wrote: >>> >>> Haven't gone back to look but I seem to remember parseAndEvalToString was >>> important. It was a hack because doing it properly was going to require >>> deeper >>> changes in

Re: [fricas-devel] jupyter notebook

On 11 October 2016 at 20:16, Kurt Pagani wrote: >> >> Haven't gone back to look but I seem to remember parseAndEvalToString was >> important. It was a hack because doing it properly was going to require >> deeper >> changes in Axiom/Fricas/OpenAxiom at the time. >> >> Have you

Re: [fricas-devel] jupyter notebook

Am 12.10.2016 um 01:31 schrieb Waldek Hebisch: > Kurt Pagani wrote: >> >> Am 11.10.2016 um 04:39 schrieb Waldek Hebisch: >>> >>> I am affraid there are dragons here. IIUC you use FriCAS functions >>> in two different threads. Currently FriCAS is not thread safe >>> and doing this may lead to

Re: [fricas-devel] jupyter notebook

Am 11.10.2016 um 20:04 schrieb Arthur Ralfs: > On 10/09/2016 05:24 PM, Kurt Pagani wrote: >> Am 10.10.2016 um 00:03 schrieb Arthur Ralfs: >>> On 10/09/2016 01:07 PM, Waldek Hebisch wrote: >> axserver may be sever due to Martin Rubey, he wrote about it in the mailing list.

Re: [fricas-devel] jupyter notebook

Kurt Pagani wrote: > > Am 11.10.2016 um 04:39 schrieb Waldek Hebisch: > > > > I am affraid there are dragons here. IIUC you use FriCAS functions > > in two different threads. Currently FriCAS is not thread safe > > and doing this may lead to troubles. More precisely, for > > performance

Re: [fricas-devel] jupyter notebook

On 10/09/2016 05:24 PM, Kurt Pagani wrote: Am 10.10.2016 um 00:03 schrieb Arthur Ralfs: On 10/09/2016 01:07 PM, Waldek Hebisch wrote: axserver may be sever due to Martin Rubey, he wrote about it in the mailing list. There was also work by Kai Kaminsky -- some info is in "contributions"

Re: [fricas-devel] jupyter notebook

Kurt Pagani wrote: > > Meanwhile I had another idea that looks very promising to me: the few lines > of lisp code below (webserver.lisp) loads the Hunchentoot > webserver into fricas (with or without sman) > which runs > quietly in the background and listening on a

Re: [fricas-devel] jupyter notebook

Am 10.10.2016 um 00:03 schrieb Arthur Ralfs: > On 10/09/2016 01:07 PM, Waldek Hebisch wrote: >> axserver may be sever due to Martin Rubey, he wrote about it in >> the mailing list. >> >> There was also work by Kai Kaminsky -- some info is in "contributions" >> section on the wiki. >> > >

Re: [fricas-devel] jupyter notebook

On 10/09/2016 01:07 PM, Waldek Hebisch wrote: Kurt Pagani wrote: By accident I landed at http://mathbrane.ca/axiom/index.html a website by A.C. Ralfs, I guess. Apparently he is the one we owe the xhtml version of the 'book'. There's also a link to a "panserver". Can anybody tell me whether

Re: [fricas-devel] jupyter notebook

Thank you, just what I've been looking for. https://groups.google.com/forum/#!searchin/fricas-devel/axserver|sort:relevance/fricas-devel/WiF69URN9Bk/fMhOserfdHsJ http://axiom-wiki.newsynthesis.org/AxiomUI After all it seems to me that the visionary synopsis by Kai Kaminski (2008) still is an

Re: Re: [fricas-devel] jupyter notebook

Kurt Pagani wrote: > > May I ask what's the state of OpenMath? > > (1) -> OMserve(9000, 10)$OpenMathServerPackage > >>> System error: >The function BOOT::OM-MAKECONN is undefined. > > > Where are all the Lisp functions referred to in omdev.spad , omserver.spad > etc.? A "grep" in the

Re: Re: [fricas-devel] jupyter notebook

May I ask what's the state of OpenMath? (1) -> OMserve(9000, 10)$OpenMathServerPackage >> System error: The function BOOT::OM-MAKECONN is undefined. Where are all the Lisp functions referred to in omdev.spad , omserver.spad etc.? A "grep" in the algebra folder doesn't show anything

Fwd: Re: [fricas-devel] jupyter notebook

Correction of correction: the encoding of link in the former post was also wrong, it should read as: http://localhost:4343/eval?code=integrate(sin(x),x) returns the result: - cos(x) Type: Union(Expression(Integer),...) -- The easy-handler is /eval

Re: [fricas-devel] jupyter notebook

Correction: the encoding of link in the former post was wrong, it should be: http://localhost:4343?eval=integrate(sin(x),x) returns the result: - cos(x) Type: Union(Expression(Integer),...) -- The easy-handler is /eval and ?code is the parameter. --

Re: [fricas-devel] jupyter notebook

Thank you for the explanations. On 5 October 2016 at 19:17, Waldek Hebisch wrote: > > > > I think that such changes should be easy, but I do > not know what you need/want. > > I probably don't know myself (yet). But seriously, the goal is to have a connection to the

Re: [fricas-devel] jupyter notebook

> > Am 02.10.2016 um 22:57 schrieb Waldek Hebisch: > > Current FriCAS connection scheme is a mess. Core of this mess is > > that standard Lisp IO have no concept of socket and that original > > You were completely right: it's a mess! > Now, when figured out, I conceive the meaning of the

Re: [fricas-devel] jupyter notebook

Am 02.10.2016 um 22:57 schrieb Waldek Hebisch: > Current FriCAS connection scheme is a mess. Core of this mess is > that standard Lisp IO have no concept of socket and that original You were completely right: it's a mess! Now, when figured out, I conceive the meaning of the "sockets" /tmp/.x

Re: [fricas-devel] jupyter notebook

Am 02.10.2016 um 22:57 schrieb Waldek Hebisch: and one copy of sman > is responsible to demultiplex FriCAS output and send it to proper > destination. Other programs use Unix domain sockets, and use > functions like 'connect_to_local_server' to establish connection. > Graphics only uses sockets,

Re: [fricas-devel] jupyter notebook

Kurt Pagani wrote: > > I've got several complaints that installing > https://github.com/nilqed/fricas_jupyter fails. Indeed, there are a lot of > changes in various prerequisites like pzmq, sbcl and jupyter. It's > difficult to maintain a package if so many dependencies still are under > active

Re: [fricas-devel] jupyter notebook

Hello Kurt, THANK YOU VERY MUCH. With the Dockerfile and the replacement of pzmq I was able to make jupyter_fricas working again on my computer, although my setup works with virtualenv and sbcl in my HOME dir. I'm amazed how fast you could figure out and solve the problem. Ralf -- You

Re: [fricas-devel] jupyter notebook

Am 13.05.2016 um 08:02 schrieb Ralf Hemmecke: >>> It's a pity that with Xenial the installation becomes too >>> complicated. I've set up a docker image from ubuntu:xenial and installed everything from scratch (https://github.com/nilqed/fricas_docker/blob/master/Dockerfile:latest). After having

Re: [fricas-devel] jupyter notebook

> That's OK, but only holds for system administrators not for developers. > Otherwise we would still be sitting on trees and eat bananas. ;-) there are worse things :] > >> Sorry for the inconv-s Kurt > > Not your fault. Still, it would be good if I could test that iSPAD > behaves like AXIOMsys

Re: [fricas-devel] jupyter notebook

On 05/13/2016 12:05 AM, Kurt Pagani wrote: > I suggest to exec ./install.sh in fricas_jupyter again (will build a > new image). I remembered that. But it did not help. > Also, deleting the cache > ~/.cache/common-lisp/sbcl-1.3.0-linux-x64/home/???/fricas_jupyter/ > might be an option (followed

Re: [fricas-devel] jupyter notebook

Am 12.05.2016 um 22:19 schrieb Ralf Hemmecke: > I must be doing something completely wrong. Now I am at the stage that > strting a fricas session in the notebook leads to (see below). Not at all. I suggest to exec ./install.sh in fricas_jupyter again (will build a new image). Also, deleting the

Re: [fricas-devel] jupyter notebook

I must be doing something completely wrong. Now I am at the stage that strting a fricas session in the notebook leads to (see below). It's a pity that with Xenial the installation becomes too complicated. Ralf

Re: [fricas-devel] jupyter notebook

Hello Ralf This time it wasn't SBCL to blame. Reverting to SBCL 1.2.6 showed the same behaviour. I could get the kernel working again by $ sudo pip uninstall jupyter-client $ sudo pip install jupyter-client==4.0 The errors apparently come from jupyter-client 4.2 (4.1 doesn't work as well). I

Re: [fricas-devel] jupyter notebook

I can reproduce the error when using SBCL 1.3 to build the kernel (still had a 1.2.16 version of the kernel). Unfortunately I also updated Jupyter before testing, so it's not yet clear to me which one is causing the issue. However, friend "google" indicates that SBCL might be the troublemaker ...

Re: [fricas-devel] jupyter notebook

On 05/11/2016 10:59 PM, Kurt Pagani wrote: > Another point that's puzzling me is that you have an old kernel spec > called "ispad" (the devel version form bitbuckt). OK. Good point. I must have been sleeping that I haven't seen this. > Perhaps you should remove it ( >

Re: [fricas-devel] jupyter notebook

Another point that's puzzling me is that you have an old kernel spec called "ispad" (the devel version form bitbuckt). Perhaps you should remove it ( /home/hemmecke/.local/share/jupyter/kernels/ispad) as it might interfere with "ifricas" which is the one that you installed. Also note that the

Re: [fricas-devel] jupyter notebook

Hallo Ralf You have to use "jupyter notebook" to start the kernel. The executable "iSPAD" needs the kernel name as an argument (that's why the "NIL" error) and is not supposed to be called directly (unless you want to connect to an existing kernel). Best regards Kurt Am 11.05.2016 um 15:51