[Maxima-bugs] [ maxima-Bugs-1046653 ] input prompt appearing when it should not

[SourceForge.net <no...@so...>]

Bugs item #1046653, was opened at 2004-10-14 00:36
Message generated for change (Comment added) made by crategus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Lisp Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Abdulhaq Lynch (abdulhaq)
Assigned to: Nobody/Anonymous (nobody)
Summary: input prompt appearing when it should not

Initial Comment:
on entering e.g.  
 
integrate(,x);  
 
the input prompt appears 3 times instead of once. This is a problem 
for external interfaces. 
 
Thanks. 

----------------------------------------------------------------------

>Comment By: Dieter Kaiser (crategus)
Date: 2010-07-10 17:40

Message:
Fixed in nparese.lisp revision 1.59. As suggested we do the test (eql
*parse-stream* *standard-input*).
Closing this bug report as fixed.
Dieter Kaiser

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-05-23 17:53

Message:
In mread-synerr in the file nparse.lisp we have the following check

   (output-stream-p *standard-input*)

If T Maxima prints the *parse-window*, marks the place where the input
error had occurred and flushes the rest of the input line.

I think this test is not correct at this place, because it only checks the
Lisp specific implementation of the stream *standard-input*. For GCL we get
always T and for SBCL we get always NIL for this test. Because of this
mread-synerr does not print the *parse-window* and does not flush the input
line. We get the following:

(%i1) integrate(,x);
incorrect syntax: , is not a prefix operator
(%i1) incorrect syntax: Too many )'s
(%i1) incorrect syntax: Premature termination of input at ;.
(%i1) sin a+b);
incorrect syntax: A is not an infix operator
(%i1) incorrect syntax: Too many )'s
(%i1) incorrect syntax: Premature termination of input at ;.
(%i1) sin(a+b;
incorrect syntax: Missing )

I think we have to ask if we are reading from the *standard-input*. For
this case we print out the *parse-window* on the *standard-output*. This
could be the test

   (eql *parse-stream* *standard-input*)

With this change we get for SBCL the expected behavior too:

(%i2) integrate(,x);
incorrect syntax: , is not a prefix operator
integrate(,
         ^
(%i2) sin a+b);
incorrect syntax: A is not an infix operator
sin a+
    ^
(%i2) sin(a+b;
incorrect syntax: Missing )
sin(a+b;
      ^

Dieter Kaiser

----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2006-09-09 07:21

Message:
Logged In: YES 
user_id=501686

(1) I've succeeded in reproducing the bug. It appears in
SBCL and CMUCL but not GCL or Clisp (all Linux) so far as I
can tell. Apparently parsing and/or error handling works
differently depending on the Lisp implementation. Rats.

(2) I'm entirely in agreement with the comments about the
need for a programmatic interface. If the original poster
has further comments on this topic, I would be interested to
hear about it.


Maxima sessions:

Maxima 5.9.3cvs / SBCL 0.9.9:

(%i1) integrate(,x);
Incorrect syntax: , is not a prefix operator
(%i1) Incorrect syntax: Too many )'s
(%i1) Incorrect syntax: Premature termination of input at ;.
(%i1) 

Maxima 5.9.1 / CMUCL 19a:

(%i1) integrate(,x);
Incorrect syntax: , is not a prefix operator
integrate(,
         ^
(%i1) Incorrect syntax: Too many )'s
x)
^
(%i1) Incorrect syntax: Premature termination of input at ;.
;
^
(%i1) 

Maxima 5.9.3cvs / Clisp 2.38 (exact same result for Maxima
5.9.3cvs / GCL 2.6.7):

(%i1) integrate(,x);
Incorrect syntax: , is not a prefix operator
integrate(,
         ^
(%i1)


----------------------------------------------------------------------

Comment By: aalynch (aalynch)
Date: 2006-07-31 12:02

Message:
Logged In: YES 
user_id=1289744

it seems that it has been fixed.

I'm working on a front endfor maxima (Kayali) and the
underlying problem is that the interface is not suitable for
machine-machine communication (it was after all designed for
human-machine interation).

We (xmaxima, wxMaxima, whatever) really need an interface
tailored for being used programmatically e.g.(in pythonesque
p-code)

result, errorcode, extrainfo = submit(equation)

without needing to parse input/output prompts etc.




----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2006-07-31 06:18

Message:
Logged In: YES 
user_id=501686

Not sure what the problem is here. It would help to report
the build_info() output and also to show a session log (just
cut-n-paste whatever Maxima prints out).



----------------------------------------------------------------------

Comment By: Abdulhaq Lynch (abdulhaq)
Date: 2004-10-15 18:03

Message:
Logged In: YES 
user_id=182792

unfortunately no as the problem is: when do I stop listening to Maxima
i.e. 
when do I stop waiting for more output? To verify that the prompts are 
the same you have to wait to see if the second or third prompt does 
actually come - i.e. the problem is knowing when to wait. 
 
If we set the timeout large then it's annoying for the user and if it's
too 
small then the communication gets messed up entirely. 

----------------------------------------------------------------------

Comment By: Stavros Macrakis (macrakis)
Date: 2004-10-14 16:05

Message:
Logged In: YES 
user_id=588346

Note that the input-line number (e.g. %i34) is the same each
time.  Does that help in parsing Maxima's output?

Of course, it would be better if there were a clean socket
API where all these things were made explicit.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&group_id=4933