Your message dated Wed, 13 Aug 2014 15:00:07 +0200
with message-id <[email protected]>
and subject line Re: Bug#737198: maxima doesn't honour *prompt-prefix* and
*prompt-suffix* as used by cantor-backend-maxima
has caused the Debian Bug report #737198,
regarding maxima doesn't honour *prompt-prefix* and *prompt-suffix* as used by
cantor-backend-maxima
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
737198: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737198
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: maxima
Version: 5.32.1-1
Severity: normal
Tags: upstream
Hi,
Running the unittests in cantor I found that maxima is not honouring the
*prompt-prefix* and *prompt-suffix* as are set by cantor (and documented in
maxima's doc/implementation/external-interface.txt).
cantor uses /usr/share/kde4/apps/cantor/maximabackend/cantor-initmaxima.lisp
to initialize it, and expects them to notice requests of additional
information, such as when evaluating: integrate(x^n,x)
Running cantor, a "sort of" nice way to read the dialog between them is to
use:
strace -vfo /tmp/cantor_maxima.strace -s 1024 -e write cantor --backend maxima
I've noticed that the git version of maxima has a number of changes around
format-prompt and such, but I could not get it to compile to test it.
Thanks,
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages maxima depends on:
ii gnuplot-x11 4.6.4-1
ii libc6 2.17-97
ii libgmp10 2:5.1.3+dfsg-1
ii libreadline6 6.2+dfsg-0.1
ii libx11-6 2:1.6.2-1
Versions of packages maxima recommends:
ii maxima-share 5.32.1-1
Versions of packages maxima suggests:
pn maxima-doc <none>
pn maxima-emacs <none>
pn texmacs <none>
ii tk8.5 [wish] 8.5.14-2
pn xmaxima <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 5.33.0-15
¡Hola Camm!
El 2014-08-11 a las 14:10 -0400, Camm Maguire escribió:
> tags 737198 unreproducible
> thanks
> Greetings, and thanks so much for looking into this. To the OP, please
> let me know if anything has been overlooked. If not, I plan on closing
> this in a week's time.
Indeed, the issue seems to be unreproducible, and most probably fixed in the
current unstable version. Sadly, I haven't noticed about the bug activity as the
older post weren't cced to -submitter, please, consider adding whenever you
interact with a bug, so the submitter can provide you further information,
tests, etc.
In a related note, the behavior of multiple inputs seem to have changed,
something like: 2+2; 3+3; produce:
(%o1) 4
(%i2) (%o2) 6
(%i3)
while cantor is expecting:
(%o1) 4
(%o2) 6
(%i3)
The difference is small, but makes the processing of the multiple results
unreliable, as reading the input is likely to end in (%i2) making it
undistinguishable form a single result.
After some trial and error I noticed that there is a '\r' being sent by maxima
after a prompt if there is no other pending result, something like:
(%i2) \r2+2; 3+3;
(%o1) 4
(%i2) (%o2) 6
(%i3) \r
And I patched cantor to use this \r to detect the end of result.
Do you know if this is some actually supported behavior, or if the \r is
configurable to something else?
Happy hacking,
--
"Inside every large problem is a small problem struggling to get out."
-- Hoare's Law of Large Problems
Saludos /\/\ /\ >< `/
signature.asc
Description: Digital signature
--- End Message ---
