Menu
▾
▴
#8 Mangled display of file
closed-fixed
9
2002-01-23
2002-01-21
No
This bug may be the same as 506082. The
reduced model seems to be broken. I
have included a file that compiles perfectly
under jsr14 (without parametric container
class signatures) yet the display produced
by DrJava is garbled. Simply jump to the end
of the file inside DrJava to see the worst
example of garbled text.
The parser for the boolean simplier in jsr14 (not jsr14p) form
Logged In: YES
user_id=343403
I started trying successively older version of DrJava to find a
version that could handle the boolsimp parser. I got all the
way back to the release version (Aug 14 2001) without finding
one that worked on this program. I suspect that the glitch
in the model is generic Java specific since it has not shown
up until now.
-- Corky
Logged In: YES
user_id=429660
I was able to reproduce this bug on Solaris, but not
Windows.
-- Eric
Logged In: YES
user_id=430590
I reproduced the bug in the release version of DrJava
using the IBM Linux 1.3.10 JVM on my home machine
(Linux 7.1). I haven't tried the bug test on any Windows
JVM's yet, but I would be very surprised not to see the same
behavior.
Logged In: YES
user_id=430590
I reproduced the bug in the release version of DrJava
using the IBM Linux 1.3.10 JVM on my home machine
(Linux 7.1). I haven't tried the bug test on any Windows
JVM's yet, but I would be very surprised not to see the same
behavior.
Logged In: YES
user_id=430590
I reproduced the bug on Windows 98 both with the
current release and the latest build using the Sun
JDK 1.3 JVM.
Logged In: YES
user_id=429660
Okay, originally when checking on Windows (XP), using IE
6.0 for downloading, Corky's file popped up in the browser
window instead of being saved to disk. So, I copy-and-
pasted it into DrJava. I was unable to reproduce the bug
this way.
Since Corky had no problem reproducing it, I tried again,
this time right clicking in IE and saving the file
directly. This time, I was able to reproduce the bug.
Interestingly, when I copy-and-pasted the text into a new
file, the garbled text at the bottom of the file went
away. I also tried deleting the text at the bottom of the
file, saving, closing, and opening again. And again, the
garbled text went away.
Logged In: YES
user_id=429660
>Interestingly, when I copy-and-pasted the text into a new
>file, the garbled text at the bottom of the file went
>away.
I mean, when I copy-and-pasted _everything but the garbled
text_.
Logged In: YES
user_id=430590
The bug is not GJ specific! I loaded the raw
Java version of the same program (the parser
for the boolean simplifier) and the result was
a garbled display. In this case, I ran both the
current release and the latest build
(drjava-20020120-1343.jar) using
Sun JDK 1.3.0 on Linux 6.2 (my office machine).
Both versions produced exactly the same garbled
result. I am attaching the raw Java source file that
exhibits the bug.
Logged In: YES
user_id=343403
I found what I believe to be the culprit! It's TAB
characters in the input! Somehow the stripping of tab
characters is broken and messing up the file. Notice that
the file Corky submitted has tab characters. Now try loading
the version of the file I'm attaching, which has tabs
removed. No problem there!
This should help us write a unit test to find the problem
and then fix it. Phew! And this explains why no one has seen
it -- since it only comes up if you are bringing in source
that was not created with DrJava and uses tabs.
Version of alt-parser.java with tabs removed, showing bug not there
Logged In: YES
user_id=343403
I'm having trouble reproducing the problem in a smaller test
case, but I have proven it's the removeTabs function in
DefinitionsDocument that is at fault. I commented out the
tab removal, and sure enough the weird text at the end never
happened. Still invetigating ... .
Logged In: YES
user_id=343403
OK, so I've narrowed down the problem even further.
Presently, when we remove tabs, we turn each tab into 2
spaces (the number of spaces per indent leve). We do this
work inside DefinitionsDocument.insertString(). This means
that if there were tabs in the text, the resulting inserted
text is actually longer than the argument of input text.
I think the standard Swing code that handles reading from a
file into a Document (in DefaultEditorKit.read()) assumes
that each chunk it inserts will have the effect of changing
the length exactly the same amount as its argument. I proved
this by changing the tab remover to replace it with only one
space; that got rid of the problem! (Though, by the way, I
still can't reproduce the problem in any reasonable-sized
test case, even one that generates a long string with a loop!)
So, I see two possible solutions to this problem:
1) Simply change the rules for auto-tab replacement, and
replace tabs with one space each.
or
2) Convert tabs to spaces somewhere else. The way we do it
now is weird (since we don't actually insertString the exact
string they requested!), and it appears to violate an
invariant that DefaultEditorKit.read() expects. So, what we
could do is, in DefinitionsEditorKit, override the two
read() methods. There, we could either wrap the
InputStream/Reader arguments with ones that filtered out tab
characters, or we could just do the insertString calls
ourselves. Either way, we'd have to have a way for the
editor kit to insert the proper number of spaces into the
document, a value currently known only to the document
(though it might have an accessor).
For now, I am implementing #1 because it's very simple.
Anyhow, I don't think it's too bad, since if the file had
tabs before, you probably want to re-tabify it after loading
it in.
Logged In: YES
user_id=343403
Fixed in drjava-20020122-2256.
Logged In: YES
user_id=343403
Aren't I a moron? I was playing with various ways to fix
this, and it turns out the one I committed in
drjava-20020122-2256 was the wrong one! I have no idea how I
got it so messed up.
Fixed for *real* in drjava-20020124-1139.