Subject: mailing-list for TeXmacs Users
List archive
From : "Andrey G. Grozin" <address@hidden>- To: address@hidden
- Subject: Re: GNU Octave interface
- Date: Tue, 24 Sep 2002 09:53:51 +0700
Hello *,
> > if (length(getenv("TEXMACS_PATH")) > 0)
> > PS1="\\002channel:prompt\\005octave> \\005";
> > endif
> >
> > And launch octave with the following script:
> >
> > #!/bin/bash
> > echo -ne "\002verbatim:"
> > octave -v
> > exec octave -qi
The first "\2verbatim" is produced by the script, OK.
But who produces "\2verbatim:" after each user input?
(I mean \2 whivh is closed by the second \5 in PS1).
By the way, you should redefine PS2, too.
> > How might I allow Octave to utilize Yacas? Anyone have
> > any ideas? If we could provide an Octave symbolic
> > toolboox by connecting to Yacas we'd turn a lot of
> > heads in the Octave crowd, and a --texmacs option to
> > Octave would be taken a lot more seriously.
Why Yacas??? There is a much more powerful and mature free CAS - Maxima.
I'm sure that if we want a symbolic toolkit for Octave, it should be based
on Maxima.
Recently, I've started to hack Octave sources to include TeXmacs support
at the C++ level. The idea is:
There is an object of the class command_editor which is responsible for
interactive input. I add a few string members to it; these strings are
written to stdout at various important moments. Currently, they are
begin_prompt
end_prompt
begin_output
end_output
begin_latex
end_latex
begin_session
end_session
(not all of them are really used at the moment). I added two command-line
options: --texmacs and --color. They initialize these strings. Without
these options, all strings are empty. --color inserts ANSI codes to have
prompts, output and user input of different colors on an xterm or similar
vt??? emulator. --texmacs adds \2 - \5 stuff. This is basically working.
There are many problems, however. When Octave wants to output something
very long, it uses less; this should be forbidden under TeXmacs.
I haven't started to implement LaTeX output yet. The text-mode output
riytines of Octave are rather advanced. E.g., if matrix rows are too long,
they switch to a separate format, etc. etc. We don't want most of this:
let TeXmacs handle huge matrices in the best way it can. But we need, at
least, a reasonable vertical alignment in columns of matrices. I can
generate a reasonable LaTeX for this, but this will be a very advanced
LaTeX, and I'm not sure if TeXmacs will accept it. What is the simplest
way to align numbers at the decimal point in a column, which TeXmacs can
understand?
I can't really understand why anybody would like to run Octave from
TeXmacs (well, I can use this occasion to learn something about huge C++
sources :-). Octave writes only numbers, matrices of numbers, and
polynomials. Matrices are without any surraunding brackets, just nicely
aligned tables of numbers. Any graphical-mode output can only make them
*less* readable, because digits have fixed width in usual fonts anyway (no
difference from the text mode here), and alignment can be easily spoiled,
if we don't emulate all (highly sophisticated) Octave output-formatting
routines. Polynomials look nicer in the graphical mode, but they are
(relatively) rarely used.
Best wishes,
Andrey
- GNU Octave interface, michael graffam, 09/21/2002
- Re: GNU Octave interface, Joris van der Hoeven, 09/21/2002
- Re: GNU Octave interface, michael graffam, 09/21/2002
- Re: GNU Octave interface, Joris van der Hoeven, 09/23/2002
- Re: GNU Octave interface, Andrey G. Grozin, 09/24/2002
- Re: GNU Octave interface, michael graffam, 09/24/2002
- Re: GNU Octave interface, Joris van der Hoeven, 09/24/2002
- Re: GNU Octave interface, Andrey G. Grozin, 09/24/2002
- Re: GNU Octave interface, michael graffam, 09/25/2002
- Re: GNU Octave interface, Andrey G. Grozin, 09/24/2002
- Re: GNU Octave interface, Andrey G. Grozin, 09/24/2002
- Re: GNU Octave interface, Joris van der Hoeven, 09/23/2002
- Re: GNU Octave interface, michael graffam, 09/21/2002
- Re: GNU Octave interface, Joris van der Hoeven, 09/21/2002
Archive powered by MHonArc 2.6.19.