Allow use of noninteractive maxima with run-string or batch-string command line args

[kasperpeulen]

Maxima pool seems to work great, if the users provides maxima code without errors, but when the user provides bad maxima code, we have some struggles.

Either, because the error message is not clear from maximapool, or the user has to wait for the timeout, until it receives the error.

For example:
input:

a: 1

output:

(%i1) 
incorrect syntax: concat is not an infix operator
concat(
     ^
(%i1) 

We have a couple of other cases, where maxima expects more input, and therefore the process will only be killed after the timeout time.

I feel like Maximapool would be in general a more clean process, if it would use the run-string and batch-string command line arguments. That is kind of the noninteractive way. While now Maximapool uses the interactive command line tool.

Would that be possible?

[aharjula]

Hi,

I have now been thinking about this through the weekend and have to say that command line arguments are not an option due to conflicting with the primary purpose of MaximaPool i.e., being able to maintain ready started up Maxima instances with plenty of libraries loaded in and thus speeding the processing of whatever input is given in the future as the loading phase has been handled before hand. Thus we cannot give the commands to run during the loading step (as command line argument) as we do not know the commands at that moment, and if we were to start the (Maxima-) processes at the time of receiving commands we would essentially lose the whole point of the pool idea as we could not keep a pool of running processes.

As to your example, may I ask in what kind of an context are you using MaximaPool? Surely, you are not allowing people to send raw commands without any limitations directly to MaximaPool? As the pool itself does no validation (and never will) of the inputs it pushes to Maxima, you can indeed send in invalid or even dangerous commands and processing will therefore fail. The primary user of the pool STACK overcomes syntactical, security and interaction issues by validating and even correcting the user input extensively and wrapping it in various error catching functions of Maximas before sending anything to Maxima.

Should it interest you the "concat is not an infix operator" issue in your example is due to the input statement not ending, with either ; or $, and remaining open when the pool tries to build the string it uses to identify the completion of the processing and that concatenation command then appears in an inconvenient place. To avoid this you should ensure that whatever you send to the pool has an input terminator at the end.

However it might be that at some point the pool could receive more than just the command in the evaluation process, maybe even files that it would then place in the work directory and allow the command to execute them and if there were an command inside Maxima that would do a non interactive batch evaluation starting from already running Maxima that might provide what you wished for, but I don't think that any of the current developers of the pool have any intention of building such extension in the near future if ever, but naturally should such one appear as a pull request we would explore it as long as it is backwards compatible.

Same pull request statement applies to someone sending in a MaximaNonPool-mode type of an extension that would switch the operation of the system from pooling to just execution. But I have to say that a thing that is a pool project would have some philosophical issues with being something that is not a pool. Therefore I have to say that instead of trying to merge such an feature to MaximaPool it might be simpler to just write some simple script that does that execution directly.

[kasperpeulen]

Thanks for your relpy 👍

As to your example, may I ask in what kind of an context are you using MaximaPool?

We have a platform for letting teacher create mathematical exercises, then students solve those exercises in this way:

Should it interest you the "concat is not an infix operator" issue in your example is due to the input statement not ending, with either ; or $, and remaining open when the pool tries to build the string it uses to identify the completion of the processing and that concatenation command then appears in an inconvenient place. To avoid this you should ensure that whatever you send to the pool has an input terminator at the end.

We actually do that. But there are many examples where we get a long timeout. We do some other checks, but for example the following code:

diff(x,);

When the teacher is making the exercise in our platform, it will sometimes make syntax error like this. And we want to provide a very quick and helpful error, but now with maximapool the teacher has to wait 10 seconds, before we can help him.

Sometimes we use the result of a maxima call, somewhere in the platform, somewhere else in the platform. For example, this is one that I found in our log, which also causes a long timeout.

load("sm_texlist.mac")$texlist(solve: dependent equations eliminated: (4 3)\n[x0,2,2,-4,-1,1,-t,t,-%e^-t*((sin(t)-cos(t))*B+(sin(t)+cos(t))*A),\n -%e^-t*((sin(t)-cos(t))*D+(sin(t)+cos(t))*C),\n -%e^-t*(2*sin(t)*D+2*cos(t)*C-2*sin(t)*B-2*cos(t)*A),\n -%e^-t*(4*sin(t)*D+4*cos(t)*C-5*sin(t)*B-5*cos(t)*A),\n (-(sin(t)-cos(t))*B)-(sin(t)+cos(t))*A = (-2*sin(t)*D)-2*cos(t)*C+2*sin(t)*B\n                                                       +2*cos(t)*A,\n (-(sin(t)-cos(t))*D)-(sin(t)+cos(t))*C = (-4*sin(t)*D)-4*cos(t)*C+5*sin(t)*B\n                                                       +5*cos(t)*A,\n (-B)-A = 2*B-2*D,B-A = 2*A-2*C,(-D)-C = 5*B-4*D,D-C = 5*A-4*C,A = (D+3*C)/5,\n B = (3*D-C)/5,x = (%e^-t*((3*sin(t)+cos(t))*D+(3*cos(t)-sin(t))*C))/5,\n y = %e^-t*(sin(t)*D+cos(t)*C),false], "true")

So basically, using run-string would cause a performance issue? We have now tried to solve this issue in other way. What do you think of this solution?

https://github.com/sowiso/stack_util_maximapool/commit/8c7abff33b79bf3287bdacca8fbc7ec8e61e35b0

Basically, we scan if maxima is hanging somewhere because incorrect syntax, or because of interactivity etc, and then we kill the process.

[aharjula]

So you do check the values send to be evaluated in the case a "student" writes things but not in the case an author writes things and you are probably building some sort of an AJAX thing that checks syntax by trying to run it while writing, sounds scary. Maybe the simplest way here (if you think that is not scary that is) is to tune your MaximaPools timeout when calling from a source like that, assuming you are not pushing in inputs that do take long to evaluate.

Personally, I would recommend not sending anything to Maxima before you know it is at the very least syntactically correct and preferably does not contain gems like system("rm -rf /"). As I have been working on something that would probably solve your problem better, faster and completely on the client side I would recommend defining a Maxima-grammar in something like pegjs and checking for syntax validity with it before sending anything to Maxima. I can say that it is not even hard and that the core features of Maxima syntax fit well into 200 lines of grammar definition, however I am not yet ready to publish my version which will tie to a type inference based checker that does a bit more.

As to the long example. Assuming texlist is a function eating strings it would probably want a string to be given and this is just a syntax error. Like those others.

So basically, using run-string would cause a performance issue?

Very much so, it would eliminate all the performance benefits that people gain from using MaximaPool thus making MaximaPool pointless. At the very minimum it would require all inputs to start up a Maxima process from scratch bringing back the ~200-300ms start up time that has been stripped down to around ~1ms by using pooling of pre-emptively started processes and it would cause serious variability in that start up time during peak loads when people are reaching the I/O limits of simultaneously starting Maxima-processes on their servers and the time starts to grow to seconds.

We have now tried to solve this issue in other way. What do you think of this solution?

It would not pass were it a pull request. The reason being that many users of Maxima, especially me, tend to want to send strings to it and the strings that you are checking from within the output are such that they are pretty likely to exist in strings that might be there in in the cases of generating feedback related to student input. The only place where MaximaPool relies on the contents of the actual output (after loading) is the "killString", and I want to keep it that way, even that is configurable if the current silly value were to conflict with some users inputs.