drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Ease of use Issues-552664 ] Bracket Highlight Color

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

Ease of use Issues item #552664, was opened at 2002-05-05 16:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=552664&group_id=44253

Category: Platform Independent
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bracket Highlight Color

Initial Comment:
As of 5-5-2002, DrJava's bracket-matching highlight is exactly the same color as the selection highlight.  The only way to tell that a block of text is highlighted and not selected is to notice that highlighted text loses its syntax-based coloring, while selected text retains it.  Obviously, this is not helpful for a chunk of text which does not normally have syntax coloring.  Also, if the edge of a selection falls in a location which causes highlighting, the bounds of the selection can be ambiguous.  It may appear to a new user that her selection had been extended to the far end of the bracket-enclosed region, which is incorrect.  This problem would be resolved if the bracket-matching highlight was drawn in a different color than a normal selection highlight.  DrScheme uses this technique, drawing bracket matching in a lighter grey than a normal selection.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=552664&group_id=44253

[DrJava] Brian undoes his stupidity, for now

[Brian S. <bs...@bs...>]

I finally realized that the best answer to the RMI-newjvm-thing problem I
created was to simply back out of the changes I've made, for now, and then
to re-apply them (with the problems fixed) when I can. So I've done that,
and I am in the process of running "ant commit" now to commit them.

Commit process is done. Now committed is drjava-20020503-0535, which is
exactly like what was committed before except that my RMI changes were
undone. So any other changes you guys made are still there. CVS is cool
like this.

For the gory details (if you're curious), read below. But once again, CVS
is cool.

Now, this means that (once you ensure this version really works, like by
testing it on Windows and Mac, which I don't have time to do right now)
you can feel free to release a new version publicly (provided everything
else is stable and happy). Cool? Make sure to get info from everyone if
needed on release notes.

FYI, I'll be away but checking email Friday-Thursday, then in town
Thursday the 11th through Wednesday the 17th. I will, however, have the
iBook with me this next week and hope to work on the damned problem we
were having!

-brian

---------- Forwarded message ----------
Date: Fri, 3 May 2002 00:20:09 -0500 (CDT)
From: Brian Stoler <bs...@bs...>
To: co...@ri..., ea...@ri..., cr...@ri...
Cc: bs...@ri...
Subject: CVS trickery

BTW, thought you might be interested in the trickery I'm using to roll
back the changes I made to the RMI thing. I'm using CVS's ability to
apply the difference between two arbitrary revisions of a file to the
current file to selectively undo just my changes. (The relevant docs are
at http://www.cvshome.org/docs/manual/cvs_5.html#SEC62)

So, both so I can remember what I've done and to tell you what I've done,
here's the steps I've taken.

1) Undo changes to drjava.model.repl.newjvm.
First, I used the CVS log info (from the CVS web interface) to find out
the version of DrJava where I first changed over to the RMI thing. Then I
found the current version number (the version I want to be the other
endpoint of the delta). Using these, I did this (inside newjvm):

cvs update -j drjava-20020502-2032 -j drjava-20020413-2208 *.java

This undid all changes made between those two revisions to those files. (I
had to fix one small thing besides this to make it still compile, to
reflect that I repackaged util during that time as well.

2) Undo DefaultGlobalModel changes.
Then I had to undo the changes to DGM, which is the client of the newjvm
stuff. I checked out the log for DGM.java and found the numerical
revisions of the file before and after I made my changes and used them to
make CVS un-apply only those changes by doing this:

cvs update -j 1.26 -j 1.24 DefaultGlobalModel.java

Note that many other revisions occurred after my changes (the current rev
is 1.35), but CVS only un-applies the changes made between 1.26 and 1.24.
Pretty cool. Note as well that because there were later changes, I
encountered a few conflicts when doing this update (just like normal
conflicts when two people edit the same file). They were due to debug
stuff. Anyway, they were easy to resolve.

3) Remove GlobalModelQuitTest.
This test is specific to the new framework and so is not needed (or
wanted) in the version I am going to commit now. So:

cvs remove -f GlobalModelQuitTest.java

4) ant clean test, and make everything pass.


Now I've got a happy version reverted to the old newjvm code. BTW, the
new code in util.newjvm is still there, but unused at present.

After this commit, I will fix my working copy (but not the committed
version!) to un-undo these changes so I can go back to fixing this. This
will be precisely doing steps 1-3 in reverse:


cvs update -j drjava-20020413-2208 -j drjava-20020502-2032 model/repl/newjvm/*.java
cvs update -j 1.24 -j 1.26 model/DefaultGlobalModel.java
cvs update -j 1.3 -j 1.2 model/GlobalModelQuitTest.java

BTW, the third one un-does the removal of QuitTest! Pretty cool!

Then, I will have a personal copy that is once again ready to resolve the
problems, but the committed version will be back to how it was before.
Sorry I didn't realize to do this earlier, and sorry I screwed the
codebase up in the first place! I shouldn't have made such a risky change
like that.

-brian

----------------------------------------------------------------
Brian Stoler                                cell: (713) 725-3374

[DrJava] configuration intro (fwd)

[Brian S. <bs...@bs...>]

PS: This should move to either the sourceforge page's "documents manager"
or to the web site itself.

---------- Forwarded message ----------
Date: Mon, 29 Apr 2002 01:29:50 -0500 (CDT)
From: Stephan Jorg Ellner <be...@cs...>

A bit later than announced, I finally uploaded a page
that hopefully explains how to work with our new DrJava
configuration framework. It can be found at

   www.owlnet.rice.edu/~besan/config.html

[DrJava] OS X Tests

[Peter C. <pce...@ma...>]

I did the same research on OS X commits and found the same 
conclusion.  I sent some more specific info to Brian about this 
issue, but I should have sent it to the entire list.  Here are 
some excerpts:

I just ran GlobalModelOtherTest in the textui.TestRunner, and I 
got some very interesting results.  If I run it as it stands in 
CVS, I get a hang in testInteractionAbort.  If I uncomment the 
println calls, the test passes.  It seems to me that this would 
indicate an extremely narrow race condition.

-----
Later
-----

After a bunch of commenting and uncommenting, I've discovered 
some more specific trends.  The call that hangs is near the end 
of the test:

     // now make sure it still works!
     assertEquals("5", interpret("5"));

If the code looks like this, I get consistent hangs from that call:

       public void interactionsExited(int status) {
         //System.err.println("exit notice");
         assertInteractionStartCount(1);
         interactionsExitedCount++;
       }

If I uncomment that particular println, I only get hangs about 
half of the times that I run the tests directly in junit.  It 
doesn't appear to matter if the call is made before or after the 
meaningful contents of that method.  I also tried adding a sleep 
call inside the method and commenting out the println.  Sleeping 
for 300ms and 1s didn't guarantee success, but it worked about 
as well as with the println enabled.

Also, running under the GUI TestRunner seems to slow things down 
enough that I haven't seen a hang yet.

--
Peter

[DrJava] [ drjava-Bugs-547798 ] problem with interactions window

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

Bugs item #547798, was opened at 2002-04-23 14:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=547798&group_id=44253

Category: None
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with interactions window

Initial Comment:
The following source code compiles OK with version 1.4 
of JDK (and also the latest version of DrJava), 
However, it will not work correctly in the 
interactions window of DrJava, but does work correctly 
using the command line prompt in DOS.  The error 
message I receive is:  
edu.rice.cs.drjava.model.repl.InteractionsException: 

Also, when you run the program, the cursor is at the 
beginning, not at the end of the prompt:  
 
Enter your name: 

====================================================


// From the errata of the book "Beginning Java
// Objects" by Jacquie Barker

// KeyboardInput.java

// I discovered that you can only read one character 
from the keyboard
// at a time, so I created this little class to hide 
the "ugliness".
//
// To use it, in your main program, do the following:
//
// KeyboardInput k = new KeyboardInput();
// k.readLine();
//
// then, k.getKeyboardInput(), which returns a full 
line's worth
// of keyboard input, as follows:
//
// String name = new String(k.getKeyboardInput());

import java.io.*;

public class KeyboardInput {
// Whatever the user last typed gets saved in this 
String.
private static String keyboardInput;

public String readLine() {
char in;

// Clear out previous input.
keyboardInput = "";

try {
// Read one integer, and cast it into a character.
in = (char) System.in.read();

// Keep going until we reach a newline character (\n).
while (in != '\n') {
keyboardInput = keyboardInput + in;
in = (char) System.in.read();
}
}
catch (IOException e) { 
// Optional error reporting goes here.

// Reset the input.
keyboardInput = "";
}

// Strip off any leading/training white space.
keyboardInput = keyboardInput.trim();
return keyboardInput;
}

public String getKeyboardInput() {
return keyboardInput;
}
}



//KeyboardInputTest.java

import java.util.*;
import java.io.*;

public class KeyboardInputTest {
public static void main(String args[]) {
KeyboardInput k = new KeyboardInput();

// Gather input from the keyboard.

System.out.print("Enter your name: ");
k.readLine();
System.out.println("You typed: |" + k.getKeyboardInput
() + "|");
}
}

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

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

[DrJava] [ drjava-Bugs-547754 ] Problem with saving file...

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

Bugs item #547754, was opened at 2002-04-23 13:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=547754&group_id=44253

Category: None
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with saving file...

Initial Comment:
If you type in the file name of the file you want to 
save and then switch folders, the name you picked does 
not persist and you have to type it in again.

Windows 98
JDK 1.4

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

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

[DrJava] [ drjava-Bugs-547752 ] can't copy highlited text with mouse

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

Bugs item #547752, was opened at 2002-04-23 13:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=547752&group_id=44253

Category: None
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't copy highlited text with mouse

Initial Comment:
Right clicking on highlited text does not bring up any 
options

Windows 98

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

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

[DrJava] Update lib for Debugger!

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

Hey everyone--
   We've committed an early version of the integrated JSwat debugger, 
though it's still commented out for now (just so our group can share our 
work on it).  In order to compile, you'll need to also update your lib 
directory to get the jswat.jar, and then put it on your classpath.  Note 
that you do not need JSwat on your classpath to _run_ DrJava, so users 
won't need it (and we won't include it in drjava.jar yet).

Note that you'll need to use "cvs update" in the lib directory, since 
there is no ant build.xml file there.

Charlie

[DrJava] Tidbit from CHI

[Peter C. <cen...@ri...>]

http://www-2.cs.cmu.edu/~rcm/lapis/

This Java-based editor uses structure information inferred from 
user examples to perform multiple edits on multiple regions of 
Java source, HTML, or raw text at the same time.  The source is 
available under the GPL.  We might be able to use this as an 
example of potential implementation options for DrJava.  I plan 
to attend their demonstration at CHI tomorrow, and if anyone 
would like to see the extended abstract, I can loan them my 
conference proceedings book after I get back in town on Friday.

While this would be rather lame compared to their system, we 
might be able to use the same Jakarta-regexp library that they 
use for some of their internal search processing.  I don't 
recommend actually porting anything resembling their full 
selection system to DrJava, as this would massively increase the 
complexity of our code and UI.  Some of the pattern-matching 
logic may be useful in redesigning the reduced model, but I 
suspect that its fuzzy-logic matching system will not be 
rigorous enough for our needs.

In any case, this thing looks really cool.  :-)

--
Peter

[DrJava] GlobalModelOtherTest on OS X

[Jim V. F. <big...@ow...>]

I have researched the test case, as requested, and found that the only
test which hangs OS X is testInteractionAbort().  If you need to commit on
OS X, you need only comment out this test method.

I was not asked to reason why it would fail on this, but I'm 100% certain
that if you comment out only this test case, it will once again pass on
OS X.  I don't want to commit my version, because it has nasty println
statements in it.  But I thought the masses should know.

Jim

[DrJava] [ drjava-Bugs-547229 ] REPL JVM dies after system sleeps

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

Bugs item #547229, was opened at 2002-04-22 14:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=547229&group_id=44253

Category: UI: MacOS X-specific
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Nobody/Anonymous (nobody)
Summary: REPL JVM dies after system sleeps

Initial Comment:
As of drjava-20020415-2112:

At least on my iBook/10.1.4/jdk1.3.1, if I close the
lid and let it go to sleep for a while, when it wakes
up the REPL JVM has died. I think the culprit is the
"check if the master JVM is alive every minute" thing.
(This is in util.newjvm.AbstractSlaveJVM.) Somehow,
after waking up it thinks that it lost contact, while
it was really just asleep.

Here's a guess on how to work around the problem:

Every minute, poll the master JVM to see if it's alive.
If it's not, set a flag (masterPossiblyDead), and wait
another minute (or maybe less time?) and check again.
If it's still dead, then proceed with the exit. Else,
abandon the exit.

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

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

Re: [DrJava] Indent Bug?

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

The "int result" line does appear to be a bug that I thought was fixed, 
so we'll have to look into it.

The indenting of the string within the array is simply not handled by 
our system-- we're not looking for the "=".  Fixing this is another 
iteration to the tree, since it will involve additional rules.

As for indenting comments, we discussed that many times and went back 
and forth.  It was a conscious decision to make it act this way (I think 
because of how the rule affects another rule), but it might be possible 
to leave commented lines with text and without a leading star alone.

And yes, the whole thing is documented at the package level (see 
package.html) in the Javadoc.

Charlie


Peter Centgraf wrote:
> Indent Group:
> 
> I think I may have found a bug in the indent decision tree.  Take a look 
> at this example from DrJava.java:
> 
>   private static void _setupCompilerIfNeeded() {
>     if (CompilerRegistry.ONLY.isNoCompilerAvailable()) {
>       // no compiler available; let's try to let the user pick one.
>       final String[] text = {
>         "DrJava can not find any Java compiler. Would you ",
>           "like to configure the location of the compiler? ",
>           "The compiler is generally located in 'tools.jar', ",
>           "in the 'lib' subdirectory under your JDK ",
>           "installation directory. (If you say 'No', DrJava ",
>           "will be unable to compile programs.)"
>       };
> 
>         int result = JOptionPane.showConfirmDialog(null,
>                                                    text,
>                                                    "Compiler not found",
>                                                    
> JOptionPane.YES_NO_OPTION);
> 
> Notice that the declaration of "result" is indented an extra level, as 
> are the non-first elements of the declaration of "text".  I'm mildly 
> surprised that the closing bracket is matched properly, since it is 
> backing up an extra level of indentation.  Is the code correctly 
> handling this type of array initialization?
> 
> Another detail, which I'm not sure is a bug or a feature request:  If 
> you comment out code with /* */ and then reindent it as part of a block 
> selection, all lines are aligned left, losing the original indentation.  
> I imagine that this would also destroy any manual ASCII table alignment 
> within comments.  Is it possible to ignore lines within comments when 
> doing a block re-indent?  This issue is especially troublesome because 
> an indent operation is not easy to undo with the current implementation.
> 
> Is there any central documentation (maybe a flow chart) for the decision 
> tree as it is currently implemented?  I think it would be helpful to be 
> able to debug the logic separately from the implementation, since there 
> is a significant amount of code to scan.
> 
> -- 
> Peter
> 
> 
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> 
> .
> 

[DrJava] OS X Quirk

[Peter C. <cen...@ri...>]

Under OS X, if you use tab in a dialog to move the focus 
indicator to a non-default button, you must use the space bar to 
activate that button.  Pressing return will always activate the 
default button, regardless of the focus indicator.  This is 
theoretically correct, since users can always rely on a mapping 
from the return key to the default button.  Unfortunately, this 
conflicts with a certain Redmond-produced family of operating 
systems, so dual-platform users need to be wary.

Just a helpful hint from your friendly neighborhood interface 
nazi. . . .

--
Peter

[DrJava] [ drjava-Ease of use Issues-546093 ] Find Via Keyboard

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

Ease of use Issues item #546093, was opened at 2002-04-19 07:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=546093&group_id=44253

Category: Platform Independent
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Find Via Keyboard

Initial Comment:
Currently, the Find/Replace dialog does not have a default button.  If the user presses return while focused on the find field, the "find next" action is performed, but if they press return while focused anywhere else in the dialog, nothing happens.  If "find next" is going to be the default action in the dialog, it should be consistent and visually obvious.  Therefore, it should be implemented as a standard default button, rather than a special-purpose handler for that text field.  It is generally a poor usability choice to have a completely different behavior for the same user action based only on the current focus.  I would strongly discourage implenting a separate handler for the replace field to trigger the "replace" or "replace/find next" actions, since this only increases the number of actions that can be triggered by the same keystroke.  This is particularly important because replacement is a destructive action, although the effect is mitigated by undo.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=546093&group_id=44253

[DrJava] [ drjava-Ease of use Issues-546062 ] Indent Warning->Progress Bar

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

Ease of use Issues item #546062, was opened at 2002-04-19 05:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=546062&group_id=44253

Category: Platform Independent
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Indent Warning->Progress Bar

Initial Comment:
If a user selects a significant amount of text and hits tab, they are presented with a Yes/No confirmation dialog warning them that the indent operation may take a long time, defaulting to No.  This should be changed to a progress dialog with a cancel button or removed completely, IMHO.

The current behavior is difficult to predict.  It is unclear to me what heuristic is used to determine how long an indent operation will take and how much time is considered "long".  This heuristic may or may not be accurate or reasonable depending on the complexity of the text and the speed of the user's machine.  In my experience, this message is sometimes presented even when the indent operation takes less than 10 seconds to complete.  For comparison, it can take a similar amount of time to open a file and much more time to launch DrJava in the first place.  With the threshold set this low, it could be very annoying for users with fast machines.

The current behavior is also modal and therefore wasteful.  During the time it takes to display the dialog, read it, and respond, no useful computation is being performed.  This problem is exacerbated by the default button selection of No, which requires the user to use the mouse to force DrJava to perform the requested action.  (Using tab to select a different button does not work reliably.)  This interruption time is often a significant fraction of the time it takes to perform the actual computation.

Incidentally, if the user selects Yes, no busy cursor is presented to indicate that the system is performing an action and will be unresponsive.

Using a progress bar will not solve the threshold issue, but it will make it less costly to the user when it is activated.  The progress bar gives all of the benefit of a confirmation dialog, namely the ability to cancel a long-running operation, plus it provides the necessary information to make that decision intelligently.  More importantly, it does not waste the user's time in the most common case that they want DrJava to perform as requested.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=546062&group_id=44253

[DrJava] [ drjava-Feature Requests-546056 ] Select All

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

Feature Requests item #546056, was opened at 2002-04-19 05:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=546056&group_id=44253

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

Initial Comment:
It would be nice to implement the common editor command to select all text in the current document.  It is debatable whether this action should be undoable.

Story:

User wants to reindent an entire ugly file.  User chooses "Select All" from the Edit menu, or uses the keyboard shortcut "Control-A".  All text in the active document is selected.  The user then hits tab to reindent the entire file.

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

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

[DrJava] Indent Bug?

[Peter C. <cen...@ri...>]

Indent Group:

I think I may have found a bug in the indent decision tree.  
Take a look at this example from DrJava.java:

   private static void _setupCompilerIfNeeded() {
     if (CompilerRegistry.ONLY.isNoCompilerAvailable()) {
       // no compiler available; let's try to let the user pick one.
       final String[] text = {
         "DrJava can not find any Java compiler. Would you ",
           "like to configure the location of the compiler? ",
           "The compiler is generally located in 'tools.jar', ",
           "in the 'lib' subdirectory under your JDK ",
           "installation directory. (If you say 'No', DrJava ",
           "will be unable to compile programs.)"
       };

         int result = JOptionPane.showConfirmDialog(null,
                                                    text,
                                                    "Compiler not found",
                                                    
JOptionPane.YES_NO_OPTION);

Notice that the declaration of "result" is indented an extra 
level, as are the non-first elements of the declaration of 
"text".  I'm mildly surprised that the closing bracket is 
matched properly, since it is backing up an extra level of 
indentation.  Is the code correctly handling this type of array 
initialization?

Another detail, which I'm not sure is a bug or a feature 
request:  If you comment out code with /* */ and then reindent 
it as part of a block selection, all lines are aligned left, 
losing the original indentation.  I imagine that this would also 
destroy any manual ASCII table alignment within comments.  Is it 
possible to ignore lines within comments when doing a block 
re-indent?  This issue is especially troublesome because an 
indent operation is not easy to undo with the current 
implementation.

Is there any central documentation (maybe a flow chart) for the 
decision tree as it is currently implemented?  I think it would 
be helpful to be able to debug the logic separately from the 
implementation, since there is a significant amount of code to 
scan.

--
Peter

[DrJava] Source of the test problems

[Brian S. <bs...@bs...>]

I'm pretty sure I've found the source of the test problems. First, the 
reason the Quit tests fail (sometimes, perhaps) on Owlnet/CSnet is a 
timing issue. We're starting up those JVMs (to test what happens when we 
quit), but in some cases the JVM has not yet connected by the time we 
check whether it has exited or not. To resolve this problem, I just put 
in a call to interpret(0) after each new JVM is invoked, since the 
interpret call will block until the REPL JVM connects.

But this brings us to the other problem, which explains the fact that 
OtherTest sometimes hangs (on MacOS, as well as on CS net!). I'm now 
pretty sure this is caused by GlobalModelTestCase.interpret(), which is 
hanging. I will dig into this further when I get a chance, but if anyone 
else has a second feel free to check it out. That method does have to do 
wacky synchronization stuff (because it is using the asynchronous REPL 
but wants to block until it returns), so I'm not surprised to see a 
timing-type problem here.

-brian

PS: My ibook is back, after all that time. And they finally did get it 
to take the 512MB RAM chip.

Re: [DrJava] failing tests

[Eric E. A. <ea...@cs...>]

FYI, I just updated and tested 20020415-2112 and all tests still pass on
Windows XP.

-- Eric



On Wed, 17 Apr 2002, John Garvin wrote:

> The problem with testing on Owlnet has spread like a virus to CSNet, or it
> could be it never worked and I just had an old build.  We tried commenting
> tests out (without committing, of course), and there seem to be two tests
> that are failing:
>
> testQuitUnsavedDocumentDisallowAbandon
>
> and
>
> testQuitMultipleDocumentsDisallowAbandon.
>
> John
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] failing tests

[John G. <ga...@cs...>]

The problem with testing on Owlnet has spread like a virus to CSNet, or it
could be it never worked and I just had an old build.  We tried commenting
tests out (without committing, of course), and there seem to be two tests
that are failing:

testQuitUnsavedDocumentDisallowAbandon

and

testQuitMultipleDocumentsDisallowAbandon.

John

[DrJava] OS X Testers

[Peter C. <cen...@ri...>]

I've just committed a proposed solution for packaging DrJava 
into an OS X double-clickable application.  I would like any of 
our developers with OS X machines to test this out to see if it 
is functional on machines other than mine.  Directions for 
setting up the app are as follows.

Update from cvs to grab the new packaging directory under 
drjava.  Inside this directory is a DrJava.app directory 
containing everything necessary to run DrJava, except for DrJava 
itself.  Right-click or control-click on the directory in the 
Finder and Show Package Contents, or use a terminal to dive into 
the hierarchy.  
DrJava.app/Contents/Resources/Java/DrJava.jar-goes-here should 
be replaced with a jar file containing your favorite version of 
DrJava.  I've tested with my latest uncommitted classes and with 
the most recent public release.  Please let me know if this 
works on your machines.

In particular, I would like to verify that this works on a 1.3 
JVM without the recent 1.3.1 update.  I have reason to suspect 
that it will not work, in which case I will need to rebuild from 
a 1.3 machine and try this again.  Any feedback would be 
appreciated.  Thanks.

--
Peter

[DrJava] [ drjava-Bugs-544595 ] Config Object toString

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

Bugs item #544595, was opened at 2002-04-16 05:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=544595&group_id=44253

Category: Other
Group: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Config Object toString

Initial Comment:
The current about box calls toString() on the Configuration object to get a list of user-specified properties useful for configuration support.  However, the new config framework does not support a clean Properties-style toString(), so an ugly Object-default hash string is generated.  Since this output is rather nice to have, I suggest that the new Config object be modified to add a friendly toString, rather than removing the info from the about box.

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

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

[DrJava] [ drjava-Feature Requests-544505 ] Revert From Disk

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

Feature Requests item #544505, was opened at 2002-04-15 23:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=544505&group_id=44253

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Revert From Disk

Initial Comment:
Story:

User opens a file and modifies it.  User wishes to discard all changes he/she made in this session and start over from scratch.  Selecting File-Revert... presents the user with a confirmation dialog.  If confirmed, the file is reloaded from disk and displayed it in the currently active scrollpane.  The viewport is reset to display the start of the file and the scrollbar reflects the new (old?) size and position of the view.  The file list is unchanged, except to reflect that this document is no longer modified.

Optional:

We may or may not want this action to be undoable.  Since the revert operation would ordinarily discard state information from memory, supporting undo for actions performed previous to the revert would require a significant amount of work.  If the undo history is cleared, we should notify the user of this side-effect in the confirmation dialog.

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

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

[DrJava] Debate on opening an open file behavior

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

Hey everyone--
   Peter and I have been having a debate on how DrJava should behave if 
you try to open a file that is already open.  (Specifically, whether or 
not it should give you a message in any case.)  We have not been able to 
agree, so we'd welcome your input...  :)  Take a look at Ease of use 
Issue 543703 (Reopening a File) when you get a chance and add any 
feedback that you have...

Thanks,
Charlie

[DrJava] [ drjava-Refactorings-544503 ] Differentiate By Platform

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

Refactorings item #544503, was opened at 2002-04-15 23:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=451586&aid=544503&group_id=44253

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differentiate By Platform

Initial Comment:
It would be nice to have a separate module to contain all platform-specific code for DrJava.  This would work a lot like the Swing L&F support, with a common interface and platform-specific implementations.  Of course, in order to include non-trivial platform-specific features, we would need to build DrJava separately for each platform, possibly on each of the host platforms (or at least the ones with specific modifications).  This would allow us to support standard Macintosh behaviors on OS X and possibly differentiate some of our configuration defaults (keybindings, etc.) based on platform.

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

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