#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.

Discussion

  • Robert Cartwright

    The parser for the boolean simplier in jsr14 (not jsr14p) form

     
  • Brian Stoler

    Brian Stoler - 2002-01-22

    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

     
  • Eric E. Allen

    Eric E. Allen - 2002-01-22

    Logged In: YES
    user_id=429660

    I was able to reproduce this bug on Solaris, but not
    Windows.

    -- Eric

     
  • Robert Cartwright

    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.

     
  • Robert Cartwright

    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.

     
  • Robert Cartwright

    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.

     
  • Eric E. Allen

    Eric E. Allen - 2002-01-22

    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.

     
  • Eric E. Allen

    Eric E. Allen - 2002-01-22

    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_.

     
  • Robert Cartwright

    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.

     
  • Brian Stoler

    Brian Stoler - 2002-01-22
    • milestone: 174447 --> 7: Could cause data loss
     
  • Brian Stoler

    Brian Stoler - 2002-01-22

    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.

     
  • Brian Stoler

    Brian Stoler - 2002-01-22

    Version of alt-parser.java with tabs removed, showing bug not there

     
  • Brian Stoler

    Brian Stoler - 2002-01-23

    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 ... .

     
  • Brian Stoler

    Brian Stoler - 2002-01-23
    • labels: 389806 --> Definitions (source editor)
     
  • Brian Stoler

    Brian Stoler - 2002-01-23

    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.

     
  • Brian Stoler

    Brian Stoler - 2002-01-23

    Logged In: YES
    user_id=343403

    Fixed in drjava-20020122-2256.

     
  • Brian Stoler

    Brian Stoler - 2002-01-23
    • assigned_to: nobody --> brianstoler
    • status: open --> closed-fixed
     
  • Brian Stoler

    Brian Stoler - 2002-01-24

    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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks