print s1 output changes depending on dc number

[GoogleCodeExporter]

Description From Bob Marinier 2005-07-13 09:06:13 (-) [reply]
1) Start the Java debugger
2) Change the state tab's command to "print s1"
3) Step.  Notice the format of the output of the command.
4) Step twice more.  Notice that, even though the contents of the output 
haven't
changed, the formatting has.
5) Step 4 times more.  The formatting has changed again.
6) Step 5 times more.  The formatting has changed again.  The formatting 
seems
to stabilize here.

I've confirmed the issue exists in TestCommandLineInterface as well.

This is probably an issue with how the formatting is generated internally 
in the
kernel.  If that's the case, then the issue should go away when we switch 
over
to using XML output for everything (at least, it'll fix it for the tree 
view). 
Given that, it may not be worth fixing this specific issue (unless it's 
really
easy).
------- Comment #1 From Karen Coulter 2005-07-13 09:15:29 (-) [reply] -----
--
This is not a bug.   The output is changing because the state is changing
and the default --depth for printing objects is --depth 2.  So anything 
added
to any object on S1 will change the printed output for "print s1"
------- Comment #2 From Bob Marinier 2005-07-13 09:29:01 (-) [reply] ------
-
This is a bug; the contents of the output are not changing, just the 
whitespace
(there are no productions loaded).  Also,the default depth does not appear 
to be
2.  For example, if TOH is loaded and run one step, "p s1" and "p s1 -d 2" 
print
different things (and not just whitespace differences).
------- Comment #3 From Karen Coulter 2005-07-15 14:30:03 (-) [reply] -----
--
just adding comments that were in email, but not logged in bugzilla...

I think this formatting bug is very, very minor and transient too.
If I type "print s1" in the debugger commandline, I never see the
indentation bug, and if I hit return in the state tab, the formatting
glitch goes away.

And it's only obvious when doing a "print S1" with no rules loaded.

The indent arg is always 0, so it will take a runtime debug while
watching the screen and the indent value to figure out what's going on.

Karen
------- Comment #4 From Bob Marinier 2007-04-26 11:00:42 (-) [reply] ------
-
Since I'm looking at the print code for bug 988 and bug 989, I took another
look at this bug.

First, the reason Karen didn't see the bug when doing prints in the Java
debugger is because it is using the XML output of the print, which does not
include this whitespace (the debugger generates the whitespace itself).  
The
state tab, on the other hand, apparently uses the text output, and thus the
problem is visible there.  Using TestCLI also shows the problem, since it 
is
using text output.

The issue stems from the printer_output_column field of the kernel's agent
structure.  Whenever something is printed, this integer is incremented for 
each
character (see print_string in print.cpp).  When a newline is printed, it 
is
reset to 1.

The function neatly_print_wme_augmentation_of_id (in gSKI_DoNotTouch.cpp)
checks to see if printer_output_column >= 80, and if it is, prints a 
newline.

The problem is that the printer_output_column is not reset after some 
prints
have been completed.  This probably stems from our decision to make the 
client
responsible for adding newlines (i.e. I think most output does not end in a
newline).  In this particular case, I think that the impasse stuff being
printed to the output from the stepping is causing the 
printer_output_column to
increase, and thus affecting other printed output.

One possible solution is to track down the specific problem with printing
impasse information to the trace, and make sure printer_output_column is 
reset
properly there.  The issue here is that there may be lots of places where
printer_output_column is not properly reset, and it will be difficult to 
track
them all down.

Another possible solution is to always reset printer_output_column before 
doing
a print.  This will catch all cases.  However, I'm not sure that this is 
always
the right thing to do; it may be that there are cases where we can't assume 
a
print is starting in the first column (e.g. possibly when a print is 
embedded
in a RHS function that is constructing a string -- I'm not sure if that's 
even
possible).

Yet another possible solution is to remove this printer_output_column 
tracking
altogether, and make the client responsible for wrapping.  While this is 
more
flexible (columns won't be fixed at 80 characters), it will make developing
usable clients much more difficult (unless we supply the wrapping function 
in
ClientSML, which is another option).
------- Comment #5 From Jonathan Voigt 2008-06-30 16:26:45 (-) [reply] ----

---
verify
------- Comment #6 From Bob Marinier 2008-07-07 12:22:32 (-) [reply] ------
-
verified this is still a problem

Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 4:06

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

• Added labels: Imported-Bugzilla

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 7:39

• Added labels: Milestone-9.3.0

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 10:30

• Removed labels: Milestone-9.3.0