Menu
▾
▴
maxima-discuss
|
From: Jeronimo P. <j_...@al...> - 2016-08-30 17:04:06
|
Hello, I would like to integrate Maxima in some other software I've been working on, but I couldn't find in the manual how to do this. I suppose that since Maxima is written in Common Lisp, it would be difficult to call it directly via FFI, but I was wondering if it's possible to have a Maxima server listening over some TCP port, and speaking some protocol. Is this possible? I would guess so, since Slime seems to do that. If it is possible, where is it documented? Thank you! Jeronimo |
|
From: Michel T. <ta...@lp...> - 2016-08-30 17:15:34
|
Jeronimo Pellegrini wrote: > Hello, > > I would like to integrate Maxima in some other software I've been > working on, but I couldn't find in the manual how to do this. I > suppose that since Maxima is written in Common Lisp, it would be > difficult to call it directly via FFI, but I was wondering if > it's possible to have a Maxima server listening over some TCP > port, and speaking some protocol. > > Is this possible? I would guess so, since Slime seems to do > that. If it is possible, where is it documented? > > Thank you! > Jeronimo > > ------------------------------------------------------------------------------ It is possible and this is the way wxmaxima and so on communicate with maxima. You can start with maxima -s and then play communicating with the socket using netcat. Probably you need to strip the prompts (%i1) (%o1) etc. There are numerous posts on the mailing list on this subject. -- Michel Talon |
|
From: Richard <fa...@gm...> - 2016-08-30 17:45:18
|
FFI means that Maxima/Lisp can possibly call your program which can be loaded in the same core image. This has some advantages over using sockets etc. Like you can pass pointers to data structures like arrays. On 8/30/16 10:15 AM, Michel Talon wrote: > Jeronimo Pellegrini wrote: >> Hello, >> >> I would like to integrate Maxima in some other software I've been >> working on, but I couldn't find in the manual how to do this. I >> suppose that since Maxima is written in Common Lisp, it would be >> difficult to call it directly via FFI, but I was wondering if >> it's possible to have a Maxima server listening over some TCP >> port, and speaking some protocol. >> >> Is this possible? I would guess so, since Slime seems to do >> that. If it is possible, where is it documented? >> >> Thank you! >> Jeronimo >> >> > ------------------------------------------------------------------------------ > It is possible and this is the way wxmaxima and so on communicate with maxima. > You can start with > maxima -s > and then play communicating with the socket using netcat. Probably you need to > strip the prompts (%i1) (%o1) etc. > There are numerous posts on the mailing list on this subject. > > |
|
From: Wolfgang D. <wol...@da...> - 2016-08-30 18:07:52
|
On 2016-08-30 19:15, Michel Talon wrote: > Jeronimo Pellegrini wrote: >> I was wondering if it's possible to have a Maxima server listening >> over some TCP port, and speaking some protocol. >> >> Is this possible? I would guess so, since Slime seems to do that. >> If it is possible, where is it documented? > > --------------------------------------------------------------------- > It is possible and this is the way wxmaxima and so on communicate > with maxima. > You can start with maxima -s and then play communicating with the > socket using netcat. It's the other way round: Maxima is the *client*, not the server. So *first* start netcat in server mode on port 1234: nc -l 1234 (or your program, which must be a server). *Then* start Maxima as client, with the option -s 1234 to connect to the Server on port 1234: maxima -s 1234 And then the server can submit maxima commands (for example you in your terminal Window using netcat as server) and the Maxima client will compute them and return the results. (Can a Maxima client connect to a port on another computer? It does not seem so...) > Probably you need to strip the prompts (%i1) (%o1) etc. Yes, it would be nice, if Maxima would have the possibility to communicate in a more computer parseable way. Best regards, Wolfgang |
|
From: Richard <fa...@gm...> - 2016-08-30 18:20:54
|
On 8/30/16 11:07 AM, Wolfgang Dautermann wrote: > It's the other way round: Maxima is the*client*, not the server. That's the way people think because they wrote the other program and they want it to be in charge. That doesn't mean it should be that way. Here's why: Maxima sets up a large infrastructure for memory management, symbolic computation, and perhaps other libraries for numerical, statistical, etc work. Say you have your own program P that (for example) tests students on algebra problems. And say your program is 1/100 the size of Maxima. Here's a way to run it. Have a Maxima system that loads your program as a foreign function library. One binary. When you start up this system, it executes a Maxima command that calls P. P can call back into Maxima by calling any lisp program, or can access any data in Maxima. It has full access to the system, including evaluating command lines, but also everything else. It is perhaps a question as to how to best handle some issues -- like a keyboard interrupt, or a system error condition -- in such a system. But my experience with programs connected by sockets suggests this is often a problem in that setting as well. Stopping a runaway Maxima loop? Anyway, the point used to be that program P was much smaller and less sophisticated than Maxima.. Now I suppose that P can be larger and hairier than Maxima, given the huge bloat and complexity of programs that are produced by common interactive development environments. RJF |
|
From: Wolfgang D. <wol...@da...> - 2016-08-30 18:50:53
|
On 2016-08-30 20:20, Richard wrote: > On 8/30/16 11:07 AM, Wolfgang Dautermann wrote: >> It's the other way round: Maxima is the *client*, not the server. > That's the way people think because they wrote the other program and > they want it to be in charge. No, it's just a networking thing. The *server* is the program, that starts first and listens *actively* on a port for clients who may connect. And probably use multithreading or multiple processes to handle connections from different client at the same time, ... Maxima does (currently) have no 'server'-infrastructure, but the possibility to connect as a client to a TCP/IP port on the same machine and get the input from there. > That doesn't mean it should be that way. Here's why: > > Maxima sets up a large infrastructure for memory management, > symbolic computation, and perhaps other libraries for numerical, > statistical, etc work. > > Say you have your own program P that (for example) tests students on > algebra problems. And say your program is 1/100 the size of Maxima. Size does not matter, often the client is much larger than the server. Compare the size of the Apache web*server* binary with the Firefox browser (a HTTP *client*): du -sh /usr/sbin/apache2 /usr/lib/firefox 632K /usr/sbin/apache2 107M /usr/lib/firefox (/usr/bin/firefox is a shellscript which calls the binary /usr/lib/firefox) Best regards, Wolfgang |
|
From: Richard F. <fa...@be...> - 2016-08-30 21:06:27
|
I was not thinking in terms of a web server, but in terms of a single-user single-computer combination of two (or more) programs which happen to be initially written independently. Maybe in some view Maxima does have an infrastructure though -- it can run a "pseudo-teletype" input-output stream. I suppose if you open it in a window, the window is a server... RJF On 8/30/2016 11:50 AM, Wolfgang Dautermann wrote: > On 2016-08-30 20:20, Richard wrote: >> On 8/30/16 11:07 AM, Wolfgang Dautermann wrote: >>> It's the other way round: Maxima is the *client*, not the server. >> That's the way people think because they wrote the other program and >> they want it to be in charge. > No, it's just a networking thing. > The *server* is the program, that starts first and listens *actively* on > a port for clients who may connect. And probably use multithreading or > multiple processes to handle connections from different client at the > same time, ... > > Maxima does (currently) have no 'server'-infrastructure, but the > possibility to connect as a client to a TCP/IP port on the same machine > and get the input from there. > >> That doesn't mean it should be that way. Here's why: >> >> Maxima sets up a large infrastructure for memory management, >> symbolic computation, and perhaps other libraries for numerical, >> statistical, etc work. >> >> Say you have your own program P that (for example) tests students on >> algebra problems. And say your program is 1/100 the size of Maxima. > Size does not matter, often the client is much larger than the server. > Compare the size of the Apache web*server* binary > with the Firefox browser (a HTTP *client*): > du -sh /usr/sbin/apache2 /usr/lib/firefox > 632K /usr/sbin/apache2 > 107M /usr/lib/firefox > > (/usr/bin/firefox is a shellscript which calls the binary /usr/lib/firefox) > > Best regards, Wolfgang > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
|
From: Robert D. <rob...@gm...> - 2016-08-31 05:45:22
|
On 2016-08-30, Jeronimo Pellegrini <j_...@al...> wrote: > I would like to integrate Maxima in some other software I've been > working on, What language is the other software written in? If Python -- there is an implementation of Python in Common Lisp named CLPython. If Java -- there is an implementation of Common Lisp in Java named ABCL. In either case, it might be possible to call directly from the other program into a Maxima function. best Robert Dodier |
|
From: Leo B. <l_b...@us...> - 2016-08-31 17:20:30
|
Wolfgang Dautermann <wol...@da...> writes: >> Probably you need to strip the prompts (%i1) (%o1) etc. > > Yes, it would be nice, if Maxima would have the possibility to > communicate in a more computer parseable way. The alt-display package is what you want, I think. See the examples in the info documentation. -- Leo Butler <l_b...@us...> SDF Public Access UNIX System - http://sdf.lonestar.org |
|
From: Richard F. <fa...@be...> - 2016-08-31 17:34:46
|
On 8/31/2016 10:20 AM, Leo Butler wrote: >> Yes, it would be nice, if Maxima would have the possibility to >> >communicate in a more computer parseable way. > The alt-display package is what you want, I think. > See the examples in the info documentation. The alt-display package does something useful, but is it really what is needed? If Maxima is being used to produce actual symbolic expressions rather than (say) numbers, then the recipient R of such information is faced with expressions like A+B. Which means that R probably needs to know how to parse pretty-much arbitrary "algebraic" notation expressions, following the rules of Maxima syntax. The expressions inside Maxima are already "parsed" into an "intermediate language" that explicitly represents the symbolic data. This language is trivially printed and read back in as strings, or could be passed as pointers to trees. Thus A+B*C internally is [*see note] (+ A (* B C)) and (A+B)*C is (* (+ A B) C)) note: it is an easy transformation to get to the forms above, but actually for various reasons Maxima uses something more elaborate. ((mplus simp) $a ((mtimes simp) $b $c)) is the first one, for example. This is a stumbling block for programs calling CAS over a socket ... if they are accessing anything "symbolic" they either have to duplicate the parsing mechanism already in Lisp/Maxima to obtain information from strings, or find another way of passing more sophisticated data in streams. Or perhaps they are linking to a CAS for some trivial response, like the one from nroots() guaranteed to be an integer. |
|
From: Leo B. <l_b...@us...> - 2016-09-01 04:00:16
|
Richard Fateman <fa...@be...> writes: > On 8/31/2016 10:20 AM, Leo Butler wrote: >>> Yes, it would be nice, if Maxima would have the possibility to >>> >communicate in a more computer parseable way. >> The alt-display package is what you want, I think. >> See the examples in the info documentation. > The alt-display package does something useful, but is it really what > is needed? As I wrote, it satisfies his *wants*. > If Maxima is being used to produce actual symbolic expressions rather > than (say) numbers, > then the recipient R of such information is faced with expressions > like A+B. > Which means that R probably needs to know how to parse pretty-much arbitrary > "algebraic" notation expressions, following the rules of Maxima syntax. > > The expressions inside Maxima are already "parsed" into an > "intermediate language" > that explicitly represents the symbolic data. This language is > trivially printed and > read back in as strings, or could be passed as pointers to trees. > > Thus A+B*C internally is [*see note] (+ A (* B C)) > and (A+B)*C is (* (+ A B) C)) > > note: it is an easy transformation to get to the forms above, but > actually for various > reasons Maxima uses something more elaborate. > > ((mplus simp) $a ((mtimes simp) $b $c)) is the first one, for example. > > This is a stumbling block for programs calling CAS over a socket ... > if they are accessing anything "symbolic" they either have to duplicate > the parsing mechanism already in Lisp/Maxima > to obtain information from strings, or find another > way of passing more sophisticated data in streams. Or perhaps they > are linking to a CAS for some trivial response, like the one from nroots() > guaranteed to be an integer. I agree with what you have written. But curiously no frontend to Maxima takes this approach, as far as I am aware. -- Leo Butler <l_b...@us...> SDF Public Access UNIX System - http://sdf.lonestar.org |
|
From: Gunter K. <gu...@pe...> - 2016-09-01 05:09:06
|
>> if they are accessing anything "symbolic" they either have to >duplicate >> the parsing mechanism already in Lisp/Maxima >> to obtain information from strings, or find another >> way of passing more sophisticated data in streams. Or perhaps they >> are linking to a CAS for some trivial response, like the one from >nroots() >> guaranteed to be an integer. > >I agree with what you have written. But curiously no frontend to Maxima >takes this approach, as far as I am aware. wxMaxima does do so, in a way. It only doesn't parse the lisp expressions in the programming language it was written in (C++) but comes with a lisp function instead that reverses the parsing process.I don't know if altdisplay was advanced enough 10 years ago when wxMaxima was written that it could have been used instead. It's MathML output looks like it could serve as an intermediate language. But MathML feels like it is being rather new so that might have required both altdisplay and a time machine. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. |
|
From: Fernando P. <fbp...@ho...> - 2016-09-01 11:52:39
|
Dear Prof. Butler, may I sugest a view to EulerMathToolbox ? It's in the Maxima pages and I used it in my classes for years. Best regards. Fernando Pacheco ________________________________ De: Leo Butler <l_b...@us...> Enviado: 1 de setembro de 2016 04:54 Para: max...@li... Assunto: Re: [Maxima-discuss] How can I call Maxima functions from a language different from Common Lisp? (FFI or server/client, doesn't matter) Richard Fateman <fa...@be...> writes: > On 8/31/2016 10:20 AM, Leo Butler wrote: >>> Yes, it would be nice, if Maxima would have the possibility to >>> >communicate in a more computer parseable way. >> The alt-display package is what you want, I think. >> See the examples in the info documentation. > The alt-display package does something useful, but is it really what > is needed? As I wrote, it satisfies his *wants*. > If Maxima is being used to produce actual symbolic expressions rather > than (say) numbers, > then the recipient R of such information is faced with expressions > like A+B. > Which means that R probably needs to know how to parse pretty-much arbitrary > "algebraic" notation expressions, following the rules of Maxima syntax. > > The expressions inside Maxima are already "parsed" into an > "intermediate language" > that explicitly represents the symbolic data. This language is > trivially printed and > read back in as strings, or could be passed as pointers to trees. > > Thus A+B*C internally is [*see note] (+ A (* B C)) > and (A+B)*C is (* (+ A B) C)) > > note: it is an easy transformation to get to the forms above, but > actually for various > reasons Maxima uses something more elaborate. > > ((mplus simp) $a ((mtimes simp) $b $c)) is the first one, for example. > > This is a stumbling block for programs calling CAS over a socket ... > if they are accessing anything "symbolic" they either have to duplicate > the parsing mechanism already in Lisp/Maxima > to obtain information from strings, or find another > way of passing more sophisticated data in streams. Or perhaps they > are linking to a CAS for some trivial response, like the one from nroots() > guaranteed to be an integer. I agree with what you have written. But curiously no frontend to Maxima takes this approach, as far as I am aware. -- Leo Butler <l_b...@us...> SDF Public Access UNIX System - http://sdf.lonestar.org SDF Public Access UNIX System - Free Shell Account and ...<http://sdf.lonestar.org/> sdf.lonestar.org ©1987-2065 SDF Public Access UNIX System, Inc. 501(c)(7) (this page was generated using ksh, sed and awk) ------------------------------------------------------------------------------ _______________________________________________ Maxima-discuss mailing list Max...@li... https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
|
From: Richard F. <fa...@be...> - 2016-09-01 04:45:34
|
On 8/31/2016 8:54 PM, Leo Butler wrote: > I agree with what you have written. But curiously no frontend to Maxima > takes this approach, as far as I am aware. The pseudo-tty interface IS a front end, and it essentially takes this approach. On Lisp machines, Macsyma including the whole front end (as well as the operating system!) and plotting were all written in Lisp, and (while I cannot say I've looked at the implementation of these pieces) I would assume that 2-d variable-size font etc display was all keyed to lisp internal form -- probably something like the version that comes out of the nformat program. ... this changes ((mtimes) -1 x) to ((mminus) x) etc. Why don't other programs use this? I suspect that for at least some programs, it was a matter of matching some API other than Lisp, e.g. MathML, a choice that looks more "standard" and only requires a few thousand extra lines of code. It is certainly possible now for many Lisp implementations to do graphics and typesetting and web access etc etc entirely within the Lisp ecosystem. But probably the front-end authors wanted to be more implementation-independent. |
|
From: Gunter K. <gu...@pe...> - 2016-09-01 05:15:23
|
Am 1. September 2016 06:45:26 MESZ, schrieb Richard Fateman <fa...@be...>: >On 8/31/2016 8:54 PM, Leo Butler wrote: >> I agree with what you have written. But curiously no frontend to >Maxima >> takes this approach, as far as I am aware. >The pseudo-tty interface IS a front end, and it essentially takes this >approach. On Lisp machines, Macsyma >including the whole front end (as well as the operating system!) and >plotting were all written in Lisp, and >(while I cannot say I've looked at the implementation of these pieces) > >I would assume that 2-d variable-size >font etc display was all keyed to lisp internal form -- probably >something like the version that comes out of >the nformat program. ... this changes ((mtimes) -1 x) to >((mminus) >x) etc. > >Why don't other programs use this? I suspect that for at least some >programs, it was a matter >of matching some API other than Lisp, e.g. MathML, a choice that looks > >more "standard" and >only requires a few thousand extra lines of code. > > It is certainly possible now for many >Lisp implementations to do graphics and typesetting and web access etc >etc entirely within >the Lisp ecosystem. But probably the front-end authors wanted to be >more implementation-independent. > > > > > > >------------------------------------------------------------------------------ >_______________________________________________ >Maxima-discuss mailing list >Max...@li... >https://lists.sourceforge.net/lists/listinfo/maxima-discuss The disadvantage of using a human-readable format directly is that it can be mimicked by other human-readable things. If an user uses a variable named \%1 or does similar things this might part of the output look like an input prompt or something else that involuntarily tricks the fromtend into the wrong state. XML escapes all offending characters or allows to replace them by tags. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. |
|
From: Jeronimo P. <j_...@al...> - 2016-09-02 16:28:27
|
On Wed, Aug 31, 2016 at 05:39:28AM +0000, Robert Dodier wrote: > On 2016-08-30, Jeronimo Pellegrini <j_...@al...> wrote: > > > I would like to integrate Maxima in some other software I've been > > working on, > > What language is the other software written in? If Python -- there is an > implementation of Python in Common Lisp named CLPython. If Java -- there > is an implementation of Common Lisp in Java named ABCL. In either case, > it might be possible to call directly from the other program into a > Maxima function. It's a program written in Scheme. Thanks to everyone who answered. Using "maxima -s" seems to be useful, as I can then parse the output from Maxima in Scheme. J. |
|
From: Richard F. <fa...@be...> - 2016-09-02 16:50:44
|
Scheme !!
It is rather likely that any particular Scheme program can be translated
into Common Lisp
without too much trouble. If you rely on piles of Scheme programs in
libraries and such,
maybe this is not a solution. But.. there is a Scheme interpreter
written in Common Lisp
in Norvig's "Paradigms of AI Programming".
If your program P were in CL, then you could load and run it inside
Maxima by
having an initialization command that was equivalent to (load("P.lisp"),
?P() )
RJF
|
|
From: Jeronimo P. <j_...@al...> - 2016-09-02 19:23:46
|
On Fri, Sep 02, 2016 at 09:50:39AM -0700, Richard Fateman wrote:
> Scheme !!
Yes...
> It is rather likely that any particular Scheme program can be translated
> into Common Lisp
> without too much trouble. If you rely on piles of Scheme programs in
> libraries and such,
> maybe this is not a solution. But.. there is a Scheme interpreter
> written in Common Lisp
> in Norvig's "Paradigms of AI Programming".
>
> If your program P were in CL, then you could load and run it inside
> Maxima by
> having an initialization command that was equivalent to (load("P.lisp"),
> ?P() )
Well, I'm using implementation-specific libraries, so translating would
be difficult. But I've found that I can call Maxima directly with
maxima --very-quiet < whatever-file
and things will work if I tell Maxima to answer in Lisp form (not in
pre-formatted output).
Thank you for your help!
J.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X