bugGNU TeXmacs - Bugs: bug #36233, incorrect output from a for loop...


You are not allowed to post comments on this tracker with your current authentication level.

bug #36233: incorrect output from a for loop in maxima session

Submitted by:  Kamaraju Kusumanchi <kamaraju>
Submitted on:  Wed 18 Apr 2012 01:33:45 AM UTC  
Category:  Plugins Priority:  3 - Low
Item Group:  Error Status:  In Progress
Privacy:  Public Assigned to:  Andrey Grozin <grozin>
Originator Name:  Open/Closed:  Open
Release: Release:  None
Fixed Release:  None Fixed Release: 

( Jump to the original submission)

Mon 25 Nov 2013 02:27:02 PM UTC, comment #6:

I cannot reproduce this bug.
However, printing 1000 numbers is extremely slow...

Joris van der Hoeven <vdhoeven>
Project Administrator
Thu 15 Nov 2012 03:30:25 PM UTC, comment #5:

> And it also seems that this behaviour is relatively new.

I tested the bug, and I reproduced it on older versions of TeXmacs (one year ago).

So, it may be not so new.

Francois Poulain <fpoulain>
Project Member
Sat 13 Oct 2012 05:43:32 AM UTC, comment #4:

Another example of the same bug: at the maxima prompt in TeXmacs, say


The bytes sent by maxima to TeXmacs are (I use p_out from the pnambic plugin)

[02]latex:$\displaystyle \mbox{\tt\red(\mathrm{\%o1}) \black}1$[05][0a]
[02]latex:$\displaystyle \mbox{\tt\red(\mathrm{\%o2}) \black}2$[05][0a]
[02]latex:\red (\mathrm{\%i}3) \black[05][05]

However, in the TeXmacs window I only see

(%o1) 1

The line (%o2) 2 is completely missing. What's even more strange, the next prompt is (%i1), in spite of the fact that maxima has sent the code instructing TeXmacs to write (%i3) !
It seems that when output pieces are sent to TeXmacs too quickly, it handles the first of them (or first few of them), and just ignors the rest. And it also seems that this behaviour is relatively new.

Andrey Grozin <grozin>
Project MemberIn charge of this item.
Fri 21 Sep 2012 11:46:34 AM UTC, comment #3:

This is a bug in TeXmacs. maxima produces the correct output and sends it to stdout (very quickly). TeXmacs receives it via a pipe; it seems that when it cannot handle input via this pipe, it simply throes it away.
I modified tm_maxima to say
exec maxima ... | tee /path/to/out
where out is a fifo, and said
cat out | p_out
where p_out is from the pnambic plugin. Then I started maxima-5.28.0 (sbcl) from TeXmacs-, and defined
f(n):=for i:1 thru n do display(i);
f(10) produces the expected result. f(100) produces the expected result in the window which traces the fifo out, this proves that all the right bytes are sent to TeXmacs via the pipe. However, TeXmacs displays only the beginning of the output. The length varies (and seems to depend on the current load level of the computer). Sometimes, lines up to i=52 are displayed; sometimes, up to i=11; etc. Never up to the end, i=100.
Sorry, I cannot fix this. Somebody who knows TeXmacs internals is needed here.

Andrey Grozin <grozin>
Project MemberIn charge of this item.
Sun 09 Sep 2012 06:53:12 PM UTC, comment #2:

Sorry, my fault. The "Need info" was meant for Andrey Grozin, the maintainer of the plugin, asking for his input on the matter. But I guess it's supposed to mean that the submitter has to provide more info. I'm setting it back to none. Cannot confirm myself though.

Miguel de Benito <mdbenito>
Project Member
Sun 09 Sep 2012 04:27:10 PM UTC, comment #1:

Why is the status set to "Need Info"? What more information do you need?


Kamaraju Kusumanchi <kamaraju>
Wed 18 Apr 2012 01:33:45 AM UTC, original submission:

Using texmacs, maxima 5.27.0, GCL 2.6.7 on a Debian Wheezy, kernel 3.0.0-1-686-pae, 32 bit machine

To reproduce the bug
1) start texmacs
2) Insert -> Session -> Maxima

Inside the maxima session, enter

for i : 0 thru 1000 do display( i );

The output is displayed only for a few values of i. The exact number of displayed values varies from run to run (suggesting that this is a memory related issue) but never 1000.

A native maxima session (without using texmacs), displays the values of i all the way up to 1000.

This bug is originally reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434768 by Miguel Aguado.

Kamaraju S Kusumanchi

Kamaraju Kusumanchi <kamaraju>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by vdhoeven (Posted a comment)
  • -email is unavailable- added by agraef
  • -email is unavailable- added by grozin (Posted a comment)
  • -email is unavailable- added by mdbenito (Updated the item)
  • -email is unavailable- added by kamaraju (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-27 vdhoeven StatusNone => In Progress
    2013-11-25 vdhoeven Priority7 - High => 3 - Low
        Assigned tovdhoeven => grozin
    2012-10-27 agraef Carbon-Copy- => Added agraef
    2012-09-21 mdbenito Assigned togrozin => vdhoeven
    2012-09-09 mdbenito StatusNeed Info => None
    2012-09-09 mdbenito Priority5 - Normal => 7 - High
        Item GroupNone => Error
        StatusNone => Need Info
        Assigned toNone => grozin

    Back to the top

    Powered by Savane 3.3