drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Feature Requests-544491 ] Better GUI Strings

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

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

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Better GUI Strings

Initial Comment:
A pet peeve of mine with the current DrJava GUI is the set of strings displayed on GUI elements.  None of the menu options use the standard notation of an elipse (...) to indicate that a menu item will present the user with a dialog.  Also, the "Compiler output" and "Test output" tab labels are not capitalized.

Unless I hear complaints from the crowd, I will commit these changes as soon as I can commit anything at all.  (Unrelated problem on my machine.)

Perhaps this should be classified as an "Ease of Use" issue, but this seemed more like a personal request, so I put it here.

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

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

[DrJava] Mac OS X Hardware Acceleration

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

To those of you who use DrJava on Mac OS X, it may help to 
enable hardware acceleration.  I've noticed an improvement in 
scrolling performance on my 500 MHz iBook.  There are two 
methods of enabling acceleration, depending on whether you have 
the latest 1.3.1 update from Apple or not.  I won't bother 
explaining the old way, since you should all get the new version 
anyway.  The new method is described here:

http://developer.apple.com/techpubs/java/ReleaseNotes/java131update1/NewFeatures/
index.html

Sadly, the heuristic used to determine if acceleration should be 
enabled apparently doesn't show enough of a performance increase 
to actually use it on my iBook.  I know that several of you have 
this machine also, so here's the workaround.  Use the special 
debug keys to force hardware acceleration on each time you run 
DrJava.  This is the key that needs to be added to your 
Info.plist or MRJApp.properties file.  Once this is on, use 
Command-F8 while running DrJava to force your machine to run 
Swing a bit less painfully:

com.apple.usedebugkeys=true

Sadly, this doesn't appear to fix the horrendous slowness in 
actual editing, but I'll be working on that later tonight.

--
Peter

[DrJava] [ drjava-Feature Requests-544387 ] Save a blank file

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

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

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: John Garvin (johngarvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save a blank file

Initial Comment:
You should be able to save a new, blank file using
"Save As...".  I think it's pretty common for users to
say something like "I want to create a new file named
'Foo.java'."  Currently, the fastest way to do it in
DrJava is to create a new file, make some trivial
modification to turn off the "unmodified" flag, then
save it with a filename.  The trivial modification step
should be unnecessary; you should just be able to make
a new file and save it with a name.

Programs I know of that already do this: MS Word,
Excel, pico, emacs, Appleworks, etc.  DrJava's current
"new files are unmodified" thing is pretty weird, all
things considered.

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

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

[DrJava] Update util again

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

Sorry, you need to update/compile the util package again. (If you do an
update of drjava and try to compile and run DependenciesTest, it'll tell
you so. Try it, it's fun! :))

I fixed that silly race condition that Peter discovered in the shiny new
newjvm code. Silly me. I implemented a regression test to document what
the bug was.

I've noticed a bunch of times that the automated tests tend to find race
conditions well because they tend to issue multiple operations in quicker
succession than normal programs (due to the lack of user input). (Peter
found the bug running GlobalModelQuitTest.)

-brian

----------------------------------------------------------------
Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
Graduate student, Rice University Department of Computer Science

[DrJava] [ drjava-Bugs-543895 ] newjvm: Race condition in invoke/quit

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

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

Category: util package
Group: Crashes
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: newjvm: Race condition in invoke/quit

Initial Comment:
In AbstractMasterJVM, there is a potential race
condition that can occur if .quitSlave is called in
between the time the slave is invoked and the time the
slave registers itself. In other words, this happens if
the quit is issued quickly after the invoke, so quickly
that the slave hasn't yet finished starting up.

This manifests itself as an IllegalStateException,
complaining that quit was called when there was nothing
to quit. The stack trace, produced by GlobalModelQuitTest:

     [junit] Testcase: testQuitNoDocuments took 1.606 sec
     [junit]     Caused an ERROR
     [junit] tried to quit when no slave running
     [junit] java.lang.IllegalStateException: tried to
quit when 
no slave running
     [junit]     at 
edu.rice.cs.util.newjvm.AbstractMasterJVM.quitSlave(AbstractMasterJVM.java:
190)
     [junit]     at 
edu.rice.cs.drjava.model.repl.newjvm.MainJVM.killInterpreter(MainJVM.java:
203)
     [junit]     at 
edu.rice.cs.drjava.model.DefaultGlobalModel.quit(DefaultGlobalModel.java:383)
     [junit]     at 
edu.rice.cs.drjava.model.GlobalModelQuitTest.testQuitNoDocuments
(GlobalModelQuitTest.java:161)
     [junit]     at
java.lang.reflect.Method.invoke(Native Method)
     [junit]     at
junit.framework.TestCase.runTest(TestCase.java:166)
     [junit]     at
junit.framework.TestCase.runBare(TestCase.java:140)
     [junit]     at 
junit.framework.TestResult$1.protect(TestResult.java:106)
     [junit]     at 
junit.framework.TestResult.runProtected(TestResult.java:124)
     [junit]     at
junit.framework.TestResult.run(TestResult.java:109)
     [junit]     at
junit.framework.TestCase.run(TestCase.java:131)
     [junit]     at
junit.framework.TestSuite.runTest(TestSuite.java:173)
     [junit]     at
junit.framework.TestSuite.run(TestSuite.java:168)
     [junit]     at 
junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
     [junit]     at 
junit.extensions.TestSetup$1.protect(TestSetup.java:19)
     [junit]     at 
junit.framework.TestResult.runProtected(TestResult.java:124)
     [junit]     at
junit.extensions.TestSetup.run(TestSetup.java:23)
     [junit]     at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
(JUnitTestRunner.java:231)
     [junit]     at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM


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

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

[DrJava] friendlier (and more correct) Test functionality

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

I just committed a whole slew of bug fixes that should make the Test
button functionality much more user friendly. In particular, I'm pretty
sure that I've caught all the ways in which the Test button code could
cause DrJava to hang.

BTW, Let me reiterate my message from Friday: If an UnexpectedException is
thrown, it should mean that a bug was found in DrJava. Don't throw them in
any other case. If you do, you may cause DrJava to freeze completely, as
if it were some sort of crappy C++ application.

-- Eric

[DrJava] [ drjava-Bugs-543881 ] JSR14 v1.2 fails to integrate

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

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

Category: Compiler integration
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: JSR14 v1.2 fails to integrate

Initial Comment:
I have a suspicion that the new version of JSR-14 will
not work with DrJava without some changes. The reason
is that (based on a cursory glance) it appears that
they have once again changed the programmatic way to
deflect the error output to a different place. (javac
1.3 is already different from javac 1.4/jsr14 1.0, and
it appears that jsr14 1.2 and probably javac > 1.4 do
it a third way!)

They've actually changed a number of aspects of the
internals of the compiler that break the way we
integrate. I fear we'll need to make an entirely new
compiler adapter for Javac 1.5+.


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

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

Re: [DrJava] FYI, on jsr-14 v1.2 and DrJava (fwd)

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

I'm almost finished fixing many of the problems mentioned concerning the
new Test functionality. I'll let you know when it's committed.

-- Eric



On Sun, 14 Apr 2002, Brian Stoler wrote:

> I bet this is the reason for the jsr14 problems with DrJava: You're using
> that new 1.2 version, right? (I don't know why I didn't send this message
> to the entire list.)
>
> See below for details. I'm going to give this a quick look now.
>
> -brian
>
> ---------- Forwarded message ----------
> Date: Fri, 5 Apr 2002 16:10:42 -0600 (CST)
> From: Brian Stoler <bs...@bs...>
> To: ja...@ri...
> Subject: FYI, on jsr-14 v1.2 and DrJava
>
> I have a suspicion that the new version of JSR-14 will not work with
> DrJava without some changes. The reason is that (based on a cursory
> glance) it appears that they have once again changed the programmatic way
> to deflect the error output to a different place. (javac 1.3 is already
> different from javac 1.4/jsr14 1.0, and it appears that jsr14 1.2 and
> probably javac > 1.4 do it a third way!)
>
> I can explain this in more detail to someone if you're interested.
>
> -brian
>
> ----------------------------------------------------------------
> Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
> Graduate student, Rice University Department of Computer Science
>
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] FYI, on jsr-14 v1.2 and DrJava (fwd)

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

I bet this is the reason for the jsr14 problems with DrJava: You're using
that new 1.2 version, right? (I don't know why I didn't send this message
to the entire list.)

See below for details. I'm going to give this a quick look now.

-brian

---------- Forwarded message ----------
Date: Fri, 5 Apr 2002 16:10:42 -0600 (CST)
From: Brian Stoler <bs...@bs...>
To: ja...@ri...
Subject: FYI, on jsr-14 v1.2 and DrJava

I have a suspicion that the new version of JSR-14 will not work with
DrJava without some changes. The reason is that (based on a cursory
glance) it appears that they have once again changed the programmatic way
to deflect the error output to a different place. (javac 1.3 is already
different from javac 1.4/jsr14 1.0, and it appears that jsr14 1.2 and
probably javac > 1.4 do it a third way!)

I can explain this in more detail to someone if you're interested.

-brian

----------------------------------------------------------------
Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
Graduate student, Rice University Department of Computer Science

[DrJava] Problems with the current release

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

Executive Summary:

The current cvs build of DrJava is definitely not 
release-quality, particularly on OS X.

Full Narative:

First of all, ant test seems to hang while running 
GlobalModelOtherTest.  I've tried this several times, with full 
updates of util and the main packages between attempts.  The 
first attempt showed no progress after 3.5 hours.  The second 
and third took half an hour and an hour respectively, with 
similar lack of results.

When I opened GlobalModelOtherTest.java in DrJava to try out the 
new Test button, I got no love.  First, JSR14 compilation failed 
with an IllegalAccessError.  This occurs for several different 
files I have attempted to compile.  GJ and the standard javac 
work fine.

Next, I switched to the standard javac and clicked Test again.  
Now I get a NoClassDefFoundError for GlobalModelTestCase and 
DrJava is completely locked up with a busy cursor.  No click 
events seem to be registering, although the menus still 
respond.  I think this error was caused by a dependency in the 
test case in this specific class, but it should certainly be 
handled more gracefully.

Running the tests through junitgui reveals that the jsr14 error 
is what's causing the ant test hang.  For some reason the 
problem is not getting reported back to ant.  Maybe this is 
because an Error is generated, not an Exception.  The Error 
actually happens quite quickly.

Here's an exception trace, to help in fixing this:

java.lang.IllegalAccessError: try to access field 
com.sun.tools.javac.v8.JavaCompiler.syms from class 
edu.rice.cs.drjava.model.compiler.JSR14Compiler
	at 
edu.rice.cs.drjava.model.compiler.JSR14Compiler.initCompiler
(JSR14Compiler.java:88)
	at 
edu.rice.cs.drjava.model.compiler.JavacGJCompiler.compile
(JavacGJCompiler.java:139)
	at 
edu.rice.cs.drjava.model.compiler.CompilerProxy.compile(CompilerProxy.java:
120)
	at 
edu.rice.cs.drjava.model.DefaultGlobalModel$DefinitionsDocumentHandler.startCompile(
DefaultGlobalModel.java:935)
	at 
edu.rice.cs.drjava.model.GlobalModelOtherTest._doCompile
(GlobalModelOtherTest.java:261)
	at 
edu.rice.cs.drjava.model.GlobalModelOtherTest.testInteractionsCanSeeChangedClass(
GlobalModelOtherTest.java:301)

--
Peter

[DrJava] [ drjava-Feature Requests-543860 ] Better Docs for Test Feature

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

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

Category: User interface
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Docs for Test Feature

Initial Comment:
The current cvs build (as of 20020414-1821) has no documentation for what the behavior of the Test button or menu item does.  It seems reasonable that most casual Java programmers will not be familiar with JUnit, so I think this feature needs some explanation, especially since there can be detrimental effects if there are issues with the classpath, etc.  Ideally this documentation would be within DrJava itself, perhaps in the vestigial Help menu, but an explanation in a readme of some kind would probably be sufficient.  Please include stories for error conditions and required setup, if any.

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

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

[DrJava] Second JVM quits immediately now

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

Fixed bug #529125, making the interactions JVM quit immediately when
DrJava quits. See bug report or commit logs for details.

I still want to release tonight, so please tell me if there are any
reasons not to!

-brian

----------------------------------------------------------------
Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
Graduate student, Rice University Department of Computer Science

[DrJava] release?

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

Is everyone satisfied that the current release is not broken in any way?
Speak now, as I plan to do a release tonight if I don't hear otherwise.
One thing: Could someone (Peter?) ensure that the new RMI code works fine
on Mac and email me?

Also, please don't commit anything right now if it shouldn't be released
yet.

Thanks,
-brian

----------------------------------------------------------------
Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
Graduate student, Rice University Department of Computer Science

[DrJava] [ drjava-Ease of use Issues-543765 ] Non-existant Command Line Files

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Non-existant Command Line Files

Initial Comment:
Story:

The user runs DrJava from the command line with several filename arguments.  The files specified do not exist.

Current Behavior:

Nothing happens.  DrJava opens in exactly the same way as if none of the non-existant filenames had been entered at all.

Desired Behavior:

New, empty DefinitionsDocuments are created for each of the specified files.  The documents are given the same title as specified.  The files are marked modified by default, and when the user attempts to save them, the appropriate filename is automatically populated into the dialog.


There is no precedent on Mac OS X or (as far as I know) on Windows for opening files via a command line.  There is a precedent in UNIX, however.  The behavior specified above is taken from emacs.  Pico behaves in the same way, though it only supports one file at a time.  I would appreciate comments from users of other UNIX editors.

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

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

[DrJava] [ drjava-Bugs-543750 ] Null File From OS X JFileChooser

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

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

Category: UI: MacOS X-specific
Group: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Null File From OS X JFileChooser

Initial Comment:
Story:

A user opens a file.  The user forgets the file is open, and uses the open command.  The last openned file is already selected.  The user double-clicks on the file, wishing to open it again.  An exception is generated because the JFileChooser says the selected file is null.

Problem:

Mac OS X's implementation of JFileChooser isn't properly updating it's visual state when setSelectedFile(null) is called.  When the user double-clicks the already-selected file, the JFileChooser fails to update it's internal state to reflect the selection, leaving a null value where a File should be.

Fix:

setSelectedFile to any other File, then set it back to the old selection, then set it to null.  I used the File.getParentFile() for this purpose, but any old File should cause the JFileChooser to update.

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

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

Re: [DrJava] Please test newest DrJava!

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

Well, it turns out that I just wasn't being patient enough. NewJVMTest
doesn't hang anymore on my machine, whether I'm running DrJava or not. But
some runs take much longer than others. So, I guess that Brian's new RMI
code was all that was needed to fix the NewJVMTest hanging problem.

-- Eric

Re: [DrJava] Please test newest DrJava!

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

The new commit works fine on my Windows XP box. All test cases pass, and
it looks fine by inspection. NewJVMTest still hangs, but I guess that's
what to expect until Brian puts in the code to automatically kill the
second JVM on quit.

That leads to a question: How did I get the test cases to pass if
NewJVMTest was hanging? The answer is that I've found a workaround to the
problem: keep DrJava up and running while running the test cases. It works
consistently, at least on Windows XP (I haven't tried it on other
platforms). With the workaround, NewJVMTest completes on my machine in ~2
seconds.

-- Eric

Re: [DrJava] util.newjvm doesn't update

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

Hi Peter,

Actually, things aren't so bad as they seem. To get DrJava running, all
you have to do is first go to:

 edu/rice/cs/util

and run "ant update compile". After that, you can go back to the drjava
directory and update without any problems. So, I wouldn't say that Brian's
changes broke update; it's just that some of his changes were in the util
project instead of drjava. Admittedly, it would be nice to have util
updated automatically whenever updating drjava. But changes to util are
infrequent enough that this isn't a high priority.

-- Eric



On Sun, 14 Apr 2002, Peter Centgraf wrote:

> Brian,
>
> Your recent changes, moving parts of the model.repl.newjvm
> package to util.newjvm, has broken the ant update target.  More
> specifically, once you update, compile no longer works.  CVS is
> not automatically grabbing the new directory.  Could you please
> tweak the build file so that CVS grabs the directory (and any
> other new directories) for us?  I don't believe it is being
> updated, even after manually grabbing the directory from CVS.
> (While you're at it, could you add variations on the compile
> target that add the -deprecated and/or -warnunchecked flags?)
>
> In the meantime, people can get DrJava building again by running
> the following command while inside their top-level cvs root,
> i.e. "~/comp312/sf/" or wherever you originally set things up.
> This will grab all new files and directories from CVS.  This is
> the same command that you run when initially configuring your
> DrJava hacking environment.
>
> cvs -d $CVSROOT checkout src
>
> --
> Peter
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] [ drjava-Ease of use Issues-543709 ] OS X Drag and Drop Support

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: OS X Drag and Drop Support

Initial Comment:
From Apple's latest JRE release notes:

Description:

Without minor configuration changes, Swing text components are not able to implement drag and drop functionality. 

Resolution:

To provide drag and drop text for a Swing text component, the developer must install the MacDnDCaret into the JTextComponent (or any text class which extends from JTextComponent). This is done as follows:
JTextComponent myTextComponent=...myTextComponent.setCaret(new  com.apple.mrj.swing.MacDnDCaret());



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

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

[DrJava] [ drjava-Ease of use Issues-543708 ] OS X Quit Handler

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: OS X Quit Handler

Initial Comment:
Story:

A Mac OS X user launches DrJava and has a productive editing session.  When done, he/she selects "Quit DrJava" from the standard OS X application menu.

Current Behavior:

Nothing happens.

Desired Behavior:

This menu item should behave just like File:Quit, i.e. prompting to save open documents and exiting the program.

Fix:

We need to install a handler for the Quit AppleEvent.  There is documentation for how to do this on Apple's site.

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

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

[DrJava] [ drjava-Ease of use Issues-543703 ] Reopening a File

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Reopening a File

Initial Comment:
Story:

A user opens a file.  At some time in the future, the user forgets that the file is open and chooses the file again in another open dialog.

Current Behavior:

On Mac OS X, nothing at all happens.  This is because someone forgot to throw an UnexpectedException in DefaultGlobalModel._getOpenDocument().  I added this throw and am currently attempting to avoid ever making it.  I will post a bug tracker item momentarily.  I won't commit this change until I make a complete fix, since it prevents opening any file whatsoever on Mac OS X.

On Solaris (and probably all other platforms), the user is presented with a dialog with a choice to either "OK" - switch to the already open file, or "Cancel" do nothing and return to the currently active file.  Note that in the case that the active file is the one that was just selected, both of these options are the same, and neither of them actually does anything at all.  In all cases, the dialog is totally unnecessary.  Switching to an already open file is always non-destructive and is exactly the behavior a person would expect, since they just asked to see the file.

Desired Behavior:

Default to the current "OK" behavior in all cases.  If the requested file is already active, do nothing.  If the requested file is open but not active, make it active.  This is standard behavior for several applications tested on Mac OS X and Windows, and even emacs. (If emacs abides by the standard, you know it's really a standard!)

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

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

[DrJava] util.newjvm doesn't update

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

Brian,

Your recent changes, moving parts of the model.repl.newjvm 
package to util.newjvm, has broken the ant update target.  More 
specifically, once you update, compile no longer works.  CVS is 
not automatically grabbing the new directory.  Could you please 
tweak the build file so that CVS grabs the directory (and any 
other new directories) for us?  I don't believe it is being 
updated, even after manually grabbing the directory from CVS.  
(While you're at it, could you add variations on the compile 
target that add the -deprecated and/or -warnunchecked flags?)

In the meantime, people can get DrJava building again by running 
the following command while inside their top-level cvs root, 
i.e. "~/comp312/sf/" or wherever you originally set things up.  
This will grab all new files and directories from CVS.  This is 
the same command that you run when initially configuring your 
DrJava hacking environment.

cvs -d $CVSROOT checkout src

--
Peter

[DrJava] Please test newest DrJava!

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

Quick note: You will need to update and compile util before you can update
and compile drjava.

I've just committed a somewhat radical change to DrJava's implementation
(which has no user-visible change, I hope). I've created a new framework
for invoking the interactions JVM that is simpler and does not use an RMI
registry. (This was causing us various problems and was just clunky. If
you're curious, the new system simply serializes the RMI stub to a file
and then lets the second JVM deserialize the file to establish the
connection.)

Anyway, this change involved my created a generic invoke-JVM package in
util (util.newjvm) and then porting DrJava to use this new framework.
(See util.newjvm's package docs for details.)

Anyhow, since this is a moderate architectural change, I would like to be
sure that it is happy on all platforms before we release anything based on
it. Could someone test it (by running the test cases and also by manually
ensuring the REPL works normally) on Windows and Mac and get back to me?
I've tried it on my home Linux machine and on Solaris with no problems.
I don't anticipate any problems but I'd rather find out from one of you
than from a user. :)

This change does not change the user-visible behavior at all, but it sets
the stage for a change to make DrJava actually close the interpreter JVM
before exiting. (Right now, it simply lets the interpreter kill itself
after the main DrJava process has been dead for a minute or so.)
I hope to implement this soon, possibly tomorrow.

-brian

PS: Good test suites rule. I had some initial problems with my adaptation
to the new framework, and these problems were caught by the existing
GlobalModelOtherTest case and it's tests relating to the REPL. If not for
the test cases, I would have had to do a lot more manual testing to check
the various behaviors, and even then I'd be less confident that I'd
covered it all. Test cases really do pay off a lot when you re-implement
existing functionality in a new way.

----------------------------------------------------------------
Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
Graduate student, Rice University Department of Computer Science

[DrJava] [ drjava-Feature Requests-543321 ] Improve Find/Replace Focus

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

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

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 3
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: Improve Find/Replace Focus

Initial Comment:
When using find/replace multiple times, the "find" field
doesn't always get the focus.  It would be nice to
not only consistently get the focus in the right place,
but have the text automatically highlighted (so that
typing a new term overwrites the old one, but hitting
enter searches for the old one again).


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

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

[DrJava] Line numbers finalized.

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

The basic idea is that we now use safer helper methods and massively
streamlined the code.  It runs slightly slower in two border cases,
jumping over large blocks of text and deleting blocks at the end of a
large file.

For most use, it is responsive, and it is always accurate.

We may work on some potential performance improvements; it is possible to
eliminate the second border condition, at least.

Enjoy!

Jim and Charlie