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 |