drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Feature Requests-681488 ] Configurable line number font

[SourceForge.net <no...@so...>]

Feature Requests item #681488, was opened at 2003-02-06 06:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=681488&group_id=44253

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configurable line number font

Initial Comment:
Story:
User turns on "Line Number Enumeration" in the Display
Options section of the Preferences Window, and line
numbers are displayed in the left margin.  However, the
user finds the font to be difficult to read, so he
changes "Line Number Font" in the Fonts section of the
Preferences Window to specify a larger font size.

Implementation notes:
Be careful of the hard-coded widths in the LineEnumRule
class...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=681488&group_id=44253

[DrJava] [ drjava-Bugs-681397 ] Console output garbled initially

[SourceForge.net <no...@so...>]

Bugs item #681397, was opened at 2003-02-05 19:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681397&group_id=44253

Category: User interface
Group: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: James Hsia (jhsia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console output garbled initially

Initial Comment:
If the console tab has not yet been displayed, then when 
multiple println's statements are made in the 
interactions pane, the console output will display the 
earlier results too many times. 

For example, before clicking on the console tab, if the 
user types:
> x = 5
> System.out.println("x = " + x)
> System.out.println("x = " + x)

the console will display:
x = 5x = 5
x = 5

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681397&group_id=44253

[DrJava] [ drjava-Bugs-681203 ] Comment Indenting

[SourceForge.net <no...@so...>]

Bugs item #681203, was opened at 2003-02-05 14:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681203&group_id=44253

Category: Definitions (source editor)
Group: Annoying
Status: Open
Resolution: None
Priority: 3
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Comment Indenting

Initial Comment:
Story:

User is editing a document with multiline comments.  She decides to break up a single line of comments into multiple lines.  Rather than getting this:

/**
  * Here is my comment,
  * nicely formatted on multiple lines.
  */

... she instead gets this:

/**
  * Here is my comment,
  indented, but missing the asterisk.
  */

This is inconsistent with the behavior of the indenter when creating a new line within a block of comments, which does this:

/**
  * Here is my comment,
  * 
  */

Two test cases for this problem are here:

drjava.model.definitions.indent.ActionMultilineCommentNewlineMidlineTest

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681203&group_id=44253

[DrJava] IMPORTANT: Use JDK 1.3 Javadocs!

[Charles R. <cr...@ri...>]

   Since the minimum requirement for running DrJava is JDK 1.3, we must use 
the 1.3 Javadocs when developing code.  There was recently a commit which 
used Color.BLACK, which only exists in Java 1.4.  (In 1.3, it's 
Color.black.)  As a result, people using Java 1.3 won't be able to compile. 
  (And that includes me, since I have to compile releases with 1.3.)  We 
won't require you to use JDK 1.3 when developing, but just work from the 
1.3 Javadocs when you can to avoid problems like this.

Thanks,
Charlie

[DrJava] DrJava Stable Release

[Charles R. <cr...@ri...>]

  A new stable release of DrJava is now available from http://drjava.org.
This release should resolve most of the recent problems users have
experienced with resetting the Interactions Pane.  If you have any trouble
with it, let us know!

Charlie Reis

[DrJava] [ drjava-Feature Requests-680533 ] "Clear Line" instead of "Cut Line"

[SourceForge.net <no...@so...>]

Feature Requests item #680533, was opened at 2003-02-04 17:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=680533&group_id=44253

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: "Clear Line" instead of "Cut Line"

Initial Comment:
Story:

A user is refactoring code from part of a method into another method.  He copies the body text, then uses the "Clear Line" method to clean up the remaining brackets, method sig., etc.  The clipboard contents remain unchanged, so that he can paste the copied body text to its new location.

Note: This is the same behavior as emacs, on which the existing "Cut Line" action was modeled.  Right now this behavior destructively updates the clipboard, forcing the user to undo his cut line actions to restore the body text.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=680533&group_id=44253

[DrJava] [ drjava-Feature Requests-680479 ] Dancing UI

[SourceForge.net <no...@so...>]

Feature Requests item #680479, was opened at 2003-02-04 15:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=680479&group_id=44253

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Moez A. Abdel-Gawad (moez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dancing UI

Initial Comment:
When compiling a file that depends on other files, these 
files are opened in DrJava. That's OK, but while loading 
these files and compiling the main file the UI keeps 
changing the size of the open files tab, which causes it 
to look like it's dancing.

The tab should retain its original size, without moving or 
being resized.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=680479&group_id=44253

[DrJava] ideas for unit tests

[Eric A. <eri...@ma...>]

If anyone is still having difficulty coming up with new unit tests, you 
might want to check out the SourceForge bug report list. If you can 
come up with a unit test that succinctly exposes an open bug, it'll be 
invaluable. Once the bug is fixed, we can use your unit test to ensure 
that it never resurfaces.

Fixed bugs _should_ have unit tests in place to guard against their 
reappearance, but I wouldn't be surprised if there are some fixed bugs 
without adequate unit tests in place.

-- Eric

[DrJava] [ drjava-Bugs-680038 ] compile exception when deleting

[SourceForge.net <no...@so...>]

Bugs item #680038, was opened at 2003-02-03 21:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=680038&group_id=44253

Category: Compiler integration
Group: Annoying
Status: Open
Resolution: None
Priority: 3
Submitted By: Neal Horowitz (nrhorowitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile exception when deleting

Initial Comment:
A user clicks compile, then notices a misspelling in
the line he just typed.  Just after pressing compile,
he hits the backspace key to nab that typo.  The typo
disappears; however, he is confronted with an
exception:

java.lang.IllegalArgumentException: Couldn't find index
for error
CompilerError(file=/net/barred/nrh/drjava/stuff.java,
line=2, col=28, msg='(' or '[' expected)

We surmise that the exception is a result of the ui
trying to highlight a position that no longer exists.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=680038&group_id=44253

[DrJava] Feature Requests / Bugs

[Charles R. <cr...@ri...>]

  I'm glad to see that people in 312 are starting to submit feature
requests and bugs on SourceForge.  We encourage you to submit things that
you notice and want to see in DrJava, and the ones I've seen recently have
been good examples of how to write a user story.

  However, there have also been a few duplicate submissions, which you
should really try to avoid.  Please take the time to look through the list
of existing bugs and feature requests (and yes, there is more than one
page of feature requests) to see if what you are going to post is already
there.  There might even be a partial discussion on the report already,
which you should always feel free to join.  You should look through the
lists anyway, to find out what other people are requesting and possibly to
get more ideas.

  Anyway, one other note for those of you not familiar with SourceForge--
you will always receive the first submission of any feature request or bug
by email.  However, you will not receive any updates to it unless you post
to it yourself (or click the "Monitor" button on the report page).  So if
you see something of interest, be sure to monitor it to keep up to date.

That's it for now,
Charlie

[DrJava] [ drjava-Feature Requests-679999 ] allow searches in reverse

[SourceForge.net <no...@so...>]

Feature Requests item #679999, was opened at 2003-02-04 03:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=679999&group_id=44253

Category: Interactions
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Tim Oberg (alphacoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow searches in reverse

Initial Comment:
The user hits the hotkey for a search, types in her
search string, checks the search backwards box, and
when the search is executed, the search moves backwards
through the document.

New story but closely related: the user binds a hotkey
in the preferences menu to represent searching in
reverse.  Now when that key, perhaps C-r, is pressed
the search dialog comes up with the search in reverse
box already checked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=679999&group_id=44253

[DrJava] Update lib / classpath

[Charles R. <cr...@ri...>]

    In yesterday's email, I forgot to mention that you will need to update
your classpath for the new platform specific framework.  I've just finished
making that a little eaiser, though, by consolidating a few of the jar
files in the lib directory.

    You will need to do two things to get your build environment updated.
First, go to your src/edu/rice/cs/lib directory and run "cvs update".  This
should remove several jar files and add "compilers.jar" and "platform.jar".

   Second, change your ~/.bashrc (or the equivalent for your platform) and
update your classpath.  You should remove "compilers-jsr14v1_0.jar" and
"compilers-jsr14v1_2.jar" and add "compilers.jar" and "platform.jar" (all
in the lib directory).  After that, you should be set!  Report any problems
to me...

Charlie

[DrJava] Update your entire source tree...

[Charles R. <cr...@ri...>]

  There have been a few commits in the last two days that will require you
to update your entire DrJava source tree.  These commits include a new
framework for writing platform specific code (such as specifying the menus
properly on Mac OS X), which was added by Peter Centgraf.  They also
include a subtle bug fix to the RMI code in the util package (my quest to
fix all the RMI stuff continues), and also an improvement to
build-common.xml for committing.

  To update, change to your ~/drjava/src directory, and run the following
command:

cvs update -Pd

  (The P argument will prune deleted directories, and the d argument will
retrieve any new directories that have been added.)


  A note on the new commit process:  the Ant script will now ask you if
you want to enter the comments for a commit manually (on one line only) or
from an existing file.  If you will be writing a long comment (I usually
do), I suggest saving it to a file with several lines and passing in by
name, since it will be easier to read in the CVS logs.  (The line you
enter won't wrap if you enter it manually.)

  For example, save your multi-line message to a file called
"comments.txt" in your drjava/src/edu/rice/cs/drjava directory.  When
prompted during the commit, type "r" to read the comments from a file, and
then specify "comments.txt" as the filename.

Let me know if you have any questions about it..

Charlie

[DrJava] [ drjava-Feature Requests-678778 ] color changes in panes

[SourceForge.net <no...@so...>]

Feature Requests item #678778, was opened at 2003-02-01 12:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=678778&group_id=44253

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: color changes in panes

Initial Comment:
An option to change the backround color and font color 
in the interaction and definition panes would be greatly 
appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=678778&group_id=44253

[DrJava] [ drjava-Bugs-678760 ] Non-bracketed nesting indentation snafu

[SourceForge.net <no...@so...>]

Bugs item #678760, was opened at 2003-02-01 13:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=678760&group_id=44253

Category: Other
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 2
Submitted By: Jim Van Fleet (bigfleet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Non-bracketed nesting indentation snafu

Initial Comment:
Let's say a user is doing a nested for loop with one
line of main action, looking like so

for ( blah ) 
  for ( bleh )
  ...

The action line shows up where the dots are, instead of
being indented.  This can be avoided with use of
brackets, but coders can vary in their preference of
extra crud.





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=678760&group_id=44253

[DrJava] Unit Testing Multithreaded Code

[Charles R. <cr...@ri...>]

Note:  This email is primarily for students in 312, but it should be of 
interest to all DrJava developers.

Eliot brought up a good question in today's lab session, while looking at a 
test case that involved multithreaded code.  (Actually, it was testing 
calls between two different JVMs, which is an extreme case of multithreaded 
code, but which happens often in DrJava.)  It made me realize I should 
explain the technique we use to test such behavior, as you guys are 
starting to write your unit tests.

(Note:  if you have never worked with multithreaded code before, you'll 
want to see me for a crash course, because it shows up a *lot* in DrJava!)


The Situation -----

Suppose you have the following classes that you're testing:

class Foo {
   Bar b = ...
   void foo() {  b.bar();  }
}
interface FooListener {
   void done();
}
class Bar {
   FooListener fl = ...
   void bar() {  ...; fl.done();  }
}

These classes run in different threads or JVMs.  Essentially, Foo tells Bar 
to do some work (perhaps over RMI), and Bar lets FooListener know when it's 
done.


How To Test -----

We use a synchronization block in our test to help us wait for Bar to call 
done(), since we don't know exactly when it's going to happen.  We will 
create a special FooListener for this purpose.

public class FooBarTest extends TestCase {
   Foo f = ...;  Bar b = ...;
   public void testFooBar() {
     // Create a listener for our test
     FooListener fl = new FooListener() {
       void done() {
         synchronized(this) {
           ...
           this.notify();
         }
       }
     };

     b.addListener(fl);
     synchronized(fl) {
       f.foo();
       fl.wait();
     }
     b.removeListener(fl);
   }
}



Things To Notice:

In our test case, we create a FooListener that synchronizes on itself in 
the done() method.  We add that listener to our Bar, and then call f.foo() 
in a block of code that is also synchronized on the listener.  This means 
that we've acquired the lock on the listener, so *nothing* can be executed 
in our listener's done() method until we release that lock.

Note that we have *no idea* when done() will be called.  The OS might 
schedule the Bar code to run before we can call fl.wait(), so done() might 
get called immediately.  Or the OS might not schedule it for several 
seconds, in which case we've already called wait().

That's why we need to have the lock.  Even if done() gets called first, it 
*can't do anything* until we release the lock by calling fl.wait().  Then 
done() can finish at its own convenience, and notify the waiting test 
method when it is finished.



This construct is used everywhere in DrJava's unit tests, so it is very 
important that you understand it, to avoid creating timing bugs and 
synchronization problems.  If you haven't had any experience with 
multithreaded code before, please make an appointment to come talk to me 
and I can help walk you through it.

If you want to look at some of this code in practice, here are a few good 
tests to browse:

edu.rice.cs.util.NewJVMTest
   (uses a TestJVMExtension class rather than a listener)
edu.rice.cs.drjava.model.GlobalModelOtherTest
   (waits/notifies on certain events on a GlobalModelListener)


Let me know if you have any questions, or if this isn't clear!  I'll be 
adding some of this to the developer documentation...

Charlie

[DrJava] DrJava Development Release

[Charles R. <cr...@ri...>]

I've just released a new development release of DrJava which includes a 
few fixes in the RMI code.  Specifically, laptop users should now be 
able to move between different networks (or put the laptop to sleep) 
without encountering any problems with the Interactions pane.  Please 
test this if you can.

For those interested, the problem was that Java's RMI was including the 
current IP address in exported objects, so MainJVM and InterpreterJVM 
couldn't find each other if the IP address changed.  We were able to get 
around this by setting the "java.rmi.server.hostname" System property to 
"127.0.0.1", which is always a valid IP address for the local machine.

Charlie


ps-- Note to Comp 312:

Development releases are generally intended as a preview of new features 
and a chance to test new features and bug fixes on different platforms. 
  After a few of these releases have been shown to behave well, we 
release a "beta" release with the new features and then a stable release 
for the home page.  In general, development releases are the most 
frequent, while stable releases come out about once a month.

[DrJava] [ drjava-Feature Requests-678355 ] No Compiler Error message should be more specific

[SourceForge.net <no...@so...>]

Feature Requests item #678355, was opened at 2003-01-31 13:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=678355&group_id=44253

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Eliot Flannery (leafly)
Assigned to: Nobody/Anonymous (nobody)
Summary: No Compiler Error message should be more specific

Initial Comment:
Having successfully figured out the source of my 
mysterious "No Compiler Found" problem with DrJava, I 
think DrJava should make this error message more 
specific.  Particilarly, DrJava should think something 
fishy is going on if it cannot find a compiler in a user 
specified file called tools.jar.  DrJava ought to display an 
error message along the lines of "Could not find compiler 
in tools.jar" if it cannot find a compiler in tools.jar, 
instead of simply displaying "No Compiler found."


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=678355&group_id=44253

[DrJava] New Website Layout

[Charles R. <cr...@ri...>]

   After a bit of feedback on the DrJava website, I added a small right 
margin without an extra frame.  The new site is live now.

Charlie

[DrJava] DrJava Website

[Charles R. <cr...@ri...>]

  I just made some updates to the DrJava website, mainly including a new
button to download the OS X App off the home page.  (I was surprised how
many OS X users didn't know we had an OS X App.)

  I'm also experimenting with the layout.  I didn't really care for the
blank white frame on the right, which made it difficult to read the
documentation, etc.  I put together a temporary page removing it, but I
wanted to make sure it didn't do anything strange on other people's
browsers/displays before making it live.  When you get a second, go to the
address below and let me know if you have any problems with it or
suggestions.

http://drjava.org/index2.html

Thanks!
Charlie

[DrJava] [ drjava-Bugs-676588 ] non-default key bindings don't work except in editor window

[SourceForge.net <no...@so...>]

Bugs item #676588, was opened at 2003-01-29 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=676588&group_id=44253

Category: User interface
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Oberg (alphacoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: non-default key bindings don't work except in editor window

Initial Comment:
If you change your key bindings, it is only valid for
the text editor part of the screen, not interactions or
find/replace or any other text box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=676588&group_id=44253

[DrJava] [ drjava-Bugs-676586 ] meta key bindings don't work on sun

[SourceForge.net <no...@so...>]

Bugs item #676586, was opened at 2003-01-29 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=676586&group_id=44253

Category: UI: UNIX-specific
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Oberg (alphacoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: meta key bindings don't work on sun

Initial Comment:
in the 20030115 build, if you bind an action to, for
example Meta-C, when pressing Meta-C the action will be
executed and a C will be printed.  I do not have this
problem on my Linux box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=676586&group_id=44253

[DrJava] [ drjava-Bugs-676558 ] Interactions JVM hangs if user leaves network

[SourceForge.net <no...@so...>]

Bugs item #676558, was opened at 2003-01-29 04:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=676558&group_id=44253

Category: Interactions
Group: Makes DrJ unstable
Status: Open
Resolution: None
Priority: 6
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: Interactions JVM hangs if user leaves network

Initial Comment:
If the user starts DrJava while on a network and then leaves the network (or changes his IP address), the Interactions Pane will stop responding, displaying an Exception.  It will attempt to reset but never finish.

This is a problem with RMI that I am currently investigating.  RMI embeds the user's IP address in exported objects so that they can be located.  However, once UnicastRemoteObject gets the current IP address once, it will never use a different one for the life of the JVM.  This seems to prevent the user from changing or leaving networks, which is a real problem for laptop users.

I'm hoping to find a way to use a custom RMISocketFactory with UnicastRemoteObject so that it uses 127.0.0.1 for the IP address, which should always be valid.  Haven't had any luck yet...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=676558&group_id=44253

[DrJava] Update your build-common.xml

[Charles R. <cr...@ri...>]

   I just committed a change to build-common.xml to improve the commit 
process.  Instead of requiring a new Emacs window to enter the commit 
comments, the Ant script will now prompt you for the comments at the 
command line.  This is a huge win for setting up new build environments, 
since we no longer require graphical Emacs on Windows or Mac OS X.

   To get the new change, run "cvs update build-common.xml" in your 
src/edu/rice/cs/ directory.

Charlie

[DrJava] [ drjava-Refactorings-674893 ] JMenuBar Factory Method

[SourceForge.net <no...@so...>]

Refactorings item #674893, was opened at 2003-01-26 03:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=451586&aid=674893&group_id=44253

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: JMenuBar Factory Method

Initial Comment:
The current menu bar setup code is integrated with the general setup code in ui/MainFrame.  This makes it difficult to make platform-specific modifications, e.g. reordering the File menu, removing the redundant File->Quit item under Mac OS X, etc.  It's also difficult to produce new copies of the menubar for use in secondary JFrames.  (This is also important for consistency with Mac OS X system behavior.)  Ideally, the menu bar would be setup through a factory method, and this method would interact with the new platform framework to tailor the menus to platform conventions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=451586&aid=674893&group_id=44253