headers
James Amundson | 3 Sep 2003 04:50
Picon

Requesting input on some possible low-level changes

While I was at the Metz meeting I had a conversation with Joris van der
Hoeven about the interface between TeXmacs and Maxima. The
maxima-texmacs interface is fragile -- there are many ways to get the
interface to hang. I am sorry to say that the problem really is Maxima's
fault. I am interested in solving the problem from the Maxima side
because I think it is a good way to start on developing a robust
interface between Maxima and other applications.

The maxima-texmacs interface currently works by running a filter on the
Maxima output that looks for prompts. When a prompt is found, TeXmacs
knows that Maxima is ready for input. It would be preferable to have
Maxima emit an appropriate string when it is ready for input. (In
general, I would like to see an external interface that does not require
scanning through output streams, but that can come later.) Adding the
appropriate output strings to Maxima is not as simple as it sounds,
because Maxima waits for input in many different situations, not all of
which are currently under our control.

Here are the type of input I have identified:

1) The ordinary command input at the (C1) prompt. This one is obvious.

2) Questions encountered during a calculation, e.g., "Is  a  positive,
negative, or zero?" This one is pretty obvious, too.

3) Input from the info routines, e.g.,

--------------------------------------------------
(C3) ? ask
(Continue reading)

Permalink | Reply | 48 comments |
headers
Richard Fateman | 3 Sep 2003 05:53
Picon
Favicon

Re: Requesting input on some possible low-level changes

I suggest that you disable the escape-to-lisp entirely if you want
a more robust interface.  That is, remove to_lisp(). Replace it
with  ??xyzzy_secret_escape_to_lisp().

Later you can consider your approach, but I suspect you will not
be able to do it in all lisps.

There is also a command that allows the user to request input, as well
as commands that allow the user to write some spoof of the synchronization
sequence. These will have to be considered.

There is a model for such communication; actually several.
(1) The interface between the commercial Macsyma front-end and
its kernel. Advantage: it was designed by someone who had the
time and the smarts to do this well. Disadvantage: it was designed
to run in a particular lisp (CLOE). Also possible disadvantage
is the interface spec may not be public.  (Though I think it might
be..)
(2) The Mathematica front-end/kernel communication.  I don't know
if this is the same as the stuff they push for inter-program
communication, but maybe it is.
(3) The Maple version of the same. I think this was called Irena
at one time.
(4) MathML's attempt to do the same. I disrecommend this approach
since it is probably not thought through for this purpose and is
extremely verbose.

There are, at a minimum, needs for the front-end to interrupt
the kernel, synchronizing notebook modes for input, editing
of output,  and also perhaps other things (e.g. now the mouse
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexander | 2 Sep 2003 20:02
Picon

What is assumed in the integrate?

Hi,

I'ev observed some strange behavior with integrate.
Maybe this could be considered as a bug.

(C1) assume(a<b, b<c, c<d)$
(C2) integrate(max(x, a), x, b, c);
                                 c
                                /
                                [
(D2)                            I  MAX(x, a) dx
                                ]
                                /
                                 b
(C3) assume(x > b)$  
(C4) integrate(max(x, a), x, b, c);
                                     2    2
                                    c    b
(D4)                                -- - --
                                    2    2
(C5) integrate(max(y, a), y, b, c);
                                 c
                                /
                                [
(D5)                            I  MAX(y, a) dy
                                ]
                                /
                                 b
(C6) assume(y > b)$  integrate(max(y, a), y, b, c);
(C7)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey G. Grozin | 3 Sep 2003 10:34
Picon
Favicon

Re: Requesting input on some possible low-level changes

Hello *,

On Tue, 2 Sep 2003, James Amundson wrote:
> 1) The ordinary command input at the (C1) prompt. This one is obvious.
1a) When the user writes a part of a statement after (C1) prompt
(no ; or $), Maxima waits for more input without any prompt at all.
It should issue some "continuation" prompt (I think this would be good 
even for the text-mode Maxima).

> 2) Questions encountered during a calculation, e.g., "Is  a  positive,
> negative, or zero?" This one is pretty obvious, too.
> 
> 3) Input from the info routines, e.g.,
> 
> --------------------------------------------------
> (C3) ? ask
> 
>  0: ASKEXP :(maxima.info)Definitions for Simplification.
>  1: ASKINTEGER :Definitions for Simplification.
>  2: ASKSIGN :Definitions for Simplification.
> Enter n, all, none, or multiple choices eg 1 3 :
> --------------------------------------------------
> 
> 4) Other inputs under Maxima control, including the Maxima debugger. I'm
> not sure how many such routines there are. Anyone?
When writing the TeXmacs-Maxima interface, I tried to identify such 
places. (C1) prompts, pos/neg/zero questions, entermatrix, and Maxima 
debugger work. I could not find how to redefine the string printed by 
info.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Reimpell | 3 Sep 2003 11:28
Picon
Picon

Re: Requesting input on some possible low-level changes


> There are, at a minimum, needs for the front-end to interrupt
> the kernel, synchronizing notebook modes for input, editing
> of output,  and also perhaps other things (e.g. now the mouse
> is pointing to a section of the notebook with a plot in it, now
> it is in a text portion).
Please clearly separate tasks of the kernel (interrupt current calculation) 
and tasks of an interface (mouse pointing to something).

My personal wishlist to a maxima kernel is:

Input request with "line"-number or reference to another input request.

Output with reference to the input number and intermediate step termination 
and termination symbol. The output should have an identifier what sort of 
data it is (picture, text, ...).

There is a need for communication with the maxima kernel without producing 
input or output lines nor increasing the counter for it. (think of a 
plot-view with the possiblitiy to change the plot settings in its context 
menu.)

Possibilities to interrupt and abort calculations.

The output should have the same syntax as the expected input, particularly 
"pretty printing" is task of the view.

Good api documentation.

	Michael
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Stanger | 3 Sep 2003 16:40
Picon

Re: Requesting input on some possible low-level changes


Richard Fateman wrote:

> There is a model for such communication; actually several.
> (1) The interface between the commercial Macsyma front-end and
> its kernel. Advantage: it was designed by someone who had the
> time and the smarts to do this well. Disadvantage: it was designed
> to run in a particular lisp (CLOE). Also possible disadvantage
> is the interface spec may not be public.  (Though I think it might
> be..)

Where would documentation of this interface be?
Permalink | Reply | 1 comment |
headers
C Y | 3 Sep 2003 17:22
Picon
Favicon

Re: Requesting input on some possible low-level changes


--- James Amundson <amundson <at> users.sourceforge.net> wrote:
> I am interested in solving the problem from the Maxima side
> because I think it is a good way to start on developing a robust
> interface between Maxima and other applications.

Yes, I think this is a very good first step.

> The maxima-texmacs interface currently works by running 
> a filter on the Maxima output that looks for prompts.
> When a prompt is found, TeXmacs knows that Maxima is ready 
> for input. It would be preferable to have Maxima emit an 
> appropriate string when it is ready for input. (In
> general, I would like to see an external interface that does not
> require scanning through output streams, but that can come later.) 

Just so we have general idea, how hard would an interface be that
doesn't require the output scanning?  It seems to me that scanning
output would always be fragile way to handle things.  I suppose
something different would have to be done at the lisp level?

> Adding the appropriate output strings to Maxima is not as simple 
> as it sounds, because Maxima waits for input in many different 
> situations, not all of which are currently under our control.
> 
> Here are the type of input I have identified:
> 
> 1) The ordinary command input at the (C1) prompt. This one is
> obvious.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard Fateman | 3 Sep 2003 17:46
Picon
Favicon

Re: Requesting input on some possible low-level changes

The on-line version of the macsyma documentation is
where I would expect this to appear. (I copied
this from the commercial Macsyma CD). If it is not
there, I have no other source.
RJF

Dan Stanger wrote:

>Richard Fateman wrote:
>
>  
>
>>There is a model for such communication; actually several.
>>(1) The interface between the commercial Macsyma front-end and
>>its kernel. Advantage: it was designed by someone who had the
>>time and the smarts to do this well. Disadvantage: it was designed
>>to run in a particular lisp (CLOE). Also possible disadvantage
>>is the interface spec may not be public.  (Though I think it might
>>be..)
>>    
>>
>
>Where would documentation of this interface be?
>
>
>_______________________________________________
>Maxima mailing list
>Maxima <at> www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Toy | 3 Sep 2003 18:19
Picon
Picon

Re: Requesting input on some possible low-level changes

>>>>> "James" == James Amundson <amundson <at> users.sourceforge.net> writes:

    James> A) We create a generic Lisp read-eval-print loop for Maxima to use
    James> instead of allowing access to the same loop in the underlying Lisp.
    James> Doing so is pretty simple. I do not see any problems with this change so
    James> far.

Will we access to the real REPL still be possible?  How would this be
different from your generic Lisp REPL?

Ray
Permalink | Reply | 5 comments |
headers
James Amundson | 3 Sep 2003 19:31
Picon

Re: Requesting input on some possible low-level changes

On Wed, 2003-09-03 at 11:19, Raymond Toy wrote:
> >>>>> "James" == James Amundson <amundson <at> users.sourceforge.net> writes:
> 
>     James> A) We create a generic Lisp read-eval-print loop for Maxima to use
>     James> instead of allowing access to the same loop in the underlying Lisp.
>     James> Doing so is pretty simple. I do not see any problems with this change so
>     James> far.
> 
> Will we access to the real REPL still be possible?  How would this be
> different from your generic Lisp REPL?

I'm glad you are asking these questions. It seems to me that replacing
the real REPL wouldn't be any loss. If I am missing something, I would
like to hear about it.

The standard ways of getting to the REPL are to_lisp() and ctrl-c. Both
would be modified to take you to the maxima REPL. Here is the simple
prototype REPL I've been using:

(defun maxima-read-eval-print-loop ()
  (loop
   (with-simple-restart
    (exit-to-maxima-repl "Exit to Maxima read-eval-print loop" ())
    (format t "~%~a> " (package-name *package*))
    (let ((form (read)))
      (prin1 (eval form))))))

As you can see, it isn't very complicated. According to (my reading of)
the ANSI spec, all the above is missing is the variables *, **, ***, +,
++, +++, /, //, /// and -. I intend to implement them, but have not yet
(Continue reading)

Permalink | Reply | 4 comments |

Gmane