Bug - Not A Bug Tables in the gCLI mutliplying

As another (weird) datapoint, the CLI command "modref" spits out a list of modifiers, in what looks like an HTML table. This modref table does NOT have this strange multiplying display issue.
 
That table bug... it's BACK?

See attached image. I am running Java 7u60 on OS X 10.10 (developer preview 3).

Note: I experienced this bug with Java 8 too. I wonder what changed between now and then.
 
And as a note, ckb reported that 7u60 had that problem a month ago. :) So what changed is that the version that didn't work a month ago still doesn't work.
 
yes, this is terribly annoying. My solution is to stop using print_html() and use print() with multiple colors or make everything a relay script.
 
Is it possible that they are unaware of the problem? Maybe there's a newer function everyone is supposed to be using for this... So this bug isn't appearing when java is used the way they want?
 
Last edited:
Does this happen when printing the entire table in a single print_html(), or only when printing in chunks/parts? I remember rewriting my scripts to compose large strings and use a single print_html (and then rewriting them to spit out several tables, because one long table was TOO long), because just printing parts of the html as I got to them never worked right.
 
xKiv said:
Does this happen when printing the entire table in a single print_html()
Click to expand...

Yes, since it apparently happens with the "bounty" CLI command, and it doesn't take much looking at that command to see that a single table is sent all at once to RequestLogger.printLine().
 
ckb said:
As another (weird) datapoint, the CLI command "modref" spits out a list of modifiers, in what looks like an HTML table. This modref table does NOT have this strange multiplying display issue.
Click to expand...
So, I looked at the two, and noticed that modref uses StringBuffer rather than the recommended StringBuilder. So I changed "banishes" to use this, and banishes still had the issue. Weirdly, having done so, "modref" also now has the issue for me, even though I didn't touch that function! And this issue continues even having reverted my changes and recompiled!!!!

Well, maybe not exactly the same problem, the table formatting is all over the place, and only the first 10 lines are duplicated.

Edit - Use of "mirror filename" to write the output to the pane to a file as well shows that the output is correct, so it's a html display issue not a stringbuilder one. As we convert both StringBuffer and StringBuilder to a String before passing to RequestLogger, that shouldn't matter.

So I guess the bug is with the parser used in later java for displaying HTMLDocument when content is test/html ?
 
Last edited:
I just started seeing this but since the owner of the machine recently required an update to Java 7, 60 now I know why :-)
 
modtrace screwed up

e.g.

modtrace adv
or
modtrace item drop

seems to repeat information, not list totals, and in some cases the graphics for the columns are not wide enough for the text.
Looks really bad...
 
This is a bug, as I am only running java 1.7.0_65.

Not only do I see duplicate items, but also columns that aren't wide enough for the text in them. It's really difficult to read.
 
Things used to work well.
Java changed.
Things don't work well any more.

What do you want us to do?
 
Sorry I didn't see that it was known to happen after a certain version of java 1.7 .. I thought it was a java 8 only issue.

I will downgrade my java back to 1.6
 
I'm running 1.7.0_51 and have no HTML rendering issues.
Frono says he upgraded to version 60 and started seeing bad HTML rendering.

I expect that Java 8 is based on the latest Java 7 - or, at least, one which has the HTML bug in it.

Now, I'm on a Mac, and Safara kept bugging me to upgrade to version 60, so I did it. I figured I'd at least get to share the pain - but since I build KoLmafia myself and did not upgrade the JDK - just the JRE - apparently I don't have to use it. I suppose I should update my JDK to version 55, at least.
 
Last edited:
You must log in or register to reply here.
Back
Top