You can subscribe to this list here.
2002 |
Jan
(17) |
Feb
(80) |
Mar
(56) |
Apr
(79) |
May
(9) |
Jun
(60) |
Jul
(29) |
Aug
(40) |
Sep
(23) |
Oct
(6) |
Nov
(25) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(17) |
Feb
(85) |
Mar
(22) |
Apr
(3) |
May
(18) |
Jun
(27) |
Jul
(38) |
Aug
(19) |
Sep
(15) |
Oct
(6) |
Nov
(2) |
Dec
(5) |
2004 |
Jan
(19) |
Feb
(26) |
Mar
(30) |
Apr
(29) |
May
(8) |
Jun
(28) |
Jul
(39) |
Aug
(17) |
Sep
(19) |
Oct
(12) |
Nov
(18) |
Dec
(9) |
2005 |
Jan
(5) |
Feb
(18) |
Mar
(4) |
Apr
(5) |
May
(9) |
Jun
(10) |
Jul
(15) |
Aug
(11) |
Sep
(6) |
Oct
(6) |
Nov
(11) |
Dec
(6) |
2006 |
Jan
(10) |
Feb
(27) |
Mar
(24) |
Apr
(39) |
May
(14) |
Jun
(14) |
Jul
(5) |
Aug
(15) |
Sep
(21) |
Oct
(25) |
Nov
(10) |
Dec
(6) |
2007 |
Jan
(19) |
Feb
(23) |
Mar
(10) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(8) |
Aug
(6) |
Sep
(10) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
2008 |
Jan
(23) |
Feb
(13) |
Mar
(19) |
Apr
(11) |
May
(11) |
Jun
(10) |
Jul
(12) |
Aug
(19) |
Sep
(11) |
Oct
(4) |
Nov
(6) |
Dec
|
2009 |
Jan
(8) |
Feb
(15) |
Mar
(21) |
Apr
(12) |
May
(14) |
Jun
(9) |
Jul
(2) |
Aug
(17) |
Sep
(36) |
Oct
(31) |
Nov
(13) |
Dec
(13) |
2010 |
Jan
(24) |
Feb
(17) |
Mar
(32) |
Apr
(18) |
May
(9) |
Jun
(6) |
Jul
(11) |
Aug
(18) |
Sep
(7) |
Oct
(20) |
Nov
(5) |
Dec
(4) |
2011 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
2012 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
|
2013 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Charles R. <cr...@ri...> - 2002-07-03 16:16:37
|
The first stable release of DrJava, drjava-stable-20020703-1520, has been released! This serves as a milestone that can be used by all users as we continue to add features to the development releases. This release also contains the first round of user documentation, which will be improved as the summer continues. Feel free to email me with any suggestions. Charlie |
From: <no...@so...> - 2002-07-02 20:31:08
|
Bugs item #576587, was opened at 2002-07-02 15:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576587&group_id=44253 Category: JUnit integration Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: Infinit loop in Junit test Initial Comment: An infinite loop in a Junit test causes DrJava (6/19 release) to freeze. There should be a way of killing a JUnit test and all its threads ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576587&group_id=44253 |
From: <no...@so...> - 2002-07-02 20:28:55
|
Bugs item #576585, was opened at 2002-07-02 15:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576585&group_id=44253 Category: User interface Group: Would be nice if fixed ... Status: Open Resolution: None Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: stack trace on dialog frame close Initial Comment: When I try to compile a dirty buffer, and get the save dialog, and click the close frame button rather than a dialog button, I get the appended stack trace (DrJava 6/19 release). The response should be the same as clicking no. ------------------------------------------- Stack Trace: java.lang.RuntimeException: Invalid rc from showConfirmDialog: -1 at edu.rice.cs.drjava.ui.MainFrame$ModelListener.saveAllB eforeProceeding(MainFrame.java:2083) at edu.rice.cs.drjava.model.DefaultGlobalModel$8.notifyList ener(DefaultGlobalModel.java:821) at edu.rice.cs.drjava.model.DefaultGlobalModel.notifyListen ers(DefaultGlobalModel.java:1807) at edu.rice.cs.drjava.model.DefaultGlobalModel.saveAllBefo reProceeding(DefaultGlobalModel.java:819) at edu.rice.cs.drjava.model.DefaultGlobalModel$Definitions DocumentHandler.startCompile (DefaultGlobalModel.java:1035) at edu.rice.cs.drjava.ui.MainFrame._compile (MainFrame.java:916) at edu.rice.cs.drjava.ui.MainFrame.access$1300 (MainFrame.java:76) at edu.rice.cs.drjava.ui.MainFrame$14.actionPerformed (MainFrame.java:303) at javax.swing.AbstractButton.fireActionPerformed (AbstractButton.java:1767) at javax.swing.AbstractButton$ForwardActionEvents.action Performed(AbstractButton.java:1820) at javax.swing.DefaultButtonModel.fireActionPerformed (DefaultButtonModel.java:419) at javax.swing.DefaultButtonModel.setPressed (DefaultButtonModel.java:257) at javax.swing.plaf.basic.BasicButtonListener.mouseRelea sed(BasicButtonListener.java:258) at java.awt.AWTEventMulticaster.mouseReleased (AWTEventMulticaster.java:227) at java.awt.Component.processMouseEvent (Component.java:5021) at java.awt.Component.processEvent (Component.java:4818) at java.awt.Container.processEvent (Container.java:1380) at java.awt.Component.dispatchEventImpl (Component.java:3526) at java.awt.Container.dispatchEventImpl (Container.java:1437) at java.awt.Component.dispatchEvent (Component.java:3367) at java.awt.LightweightDispatcher.retargetMouseEvent (Container.java:3214) at java.awt.LightweightDispatcher.processMouseEvent (Container.java:2929) at java.awt.LightweightDispatcher.dispatchEvent (Container.java:2859) at java.awt.Container.dispatchEventImpl (Container.java:1423) at java.awt.Window.dispatchEventImpl (Window.java:1566) at java.awt.Component.dispatchEvent (Component.java:3367) at java.awt.EventQueue.dispatchEvent (EventQueue.java:445) at java.awt.EventDispatchThread.pumpOneEventForHierarc hy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:130) at java.awt.EventDispatchThread.run (EventDispatchThread.java:98) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576585&group_id=44253 |
From: <no...@so...> - 2002-07-02 15:54:09
|
Bugs item #576457, was opened at 2002-07-02 10:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576457&group_id=44253 Category: User interface Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: save dialog box closing Initial Comment: I tried to compile a file w/o having saved it. When the save dialog popped up, I decided I didn't want to compile, and I tried to close the dialog via the upper- right close box (instead of the cancel button). I got grey stack error box, but wasn't in a position to save it. This and my last two reports were all using the 6/17 version of DrJava in Windows 2000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576457&group_id=44253 |
From: <no...@so...> - 2002-07-02 15:50:44
|
Bugs item #576454, was opened at 2002-07-02 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576454&group_id=44253 Category: Interactions Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: thread priority Initial Comment: Threads run in the interactions window (or via the test button), should have lower priority than DrJava. At present, if a program run in the interations window goes into an infinite loop (or at least an infinite recursion), DrJava is inoperative. It should be possible to kill the interaction (or test thread(s)) by resetting the interactions window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576454&group_id=44253 |
From: <no...@so...> - 2002-07-02 15:48:08
|
Bugs item #576448, was opened at 2002-07-02 10:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576448&group_id=44253 Category: Interactions Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: interactions with threads Initial Comment: A compile or any other operation that resets the interactions window should kill all threads that were created earlier via the interactions window (or test button). When students start using threads this is very important, or DrJava's performance degrades from background threads w/o any clue what is happening. I suppose old threads might also be contributing output to the console and interactions windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576448&group_id=44253 |
From: <no...@so...> - 2002-07-01 23:30:24
|
Bugs item #576179, was opened at 2002-07-01 18:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576179&group_id=44253 Category: Interactions Group: Makes DrJ unstable Status: Open Resolution: None Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: stack trace error Initial Comment: Entering the interaction TestApplet.test(new MagnetGame(), 400, 400) and playing with the applet resulted in a null pointer exception (obvious errors by beginners). The exception shows up in the console window, but not the interactions window, which is quite unfortunate for the student. And when I click in the interactions window after clicking in the applet, I get the following using the 6/17 version of drjava (in Windows XP). This is still an improvement on the earlier version of drjava the students are using, which hung in a similar situation. Does the reset interactions command kill all threads from privious interactions? It should. Stack Trace: java.lang.ArrayIndexOutOfBoundsException at javax.swing.text.CompositeView.getView (CompositeView.java:143) at javax.swing.text.FlowView$FlowStrategy.createView (FlowView.java:567) at javax.swing.text.FlowView$FlowStrategy.layoutRow (FlowView.java:441) at javax.swing.text.FlowView$FlowStrategy.layout (FlowView.java:397) at javax.swing.text.FlowView.layout (FlowView.java:182) at javax.swing.text.BoxView.setSize (BoxView.java:379) at javax.swing.text.BoxView.viewToModel (BoxView.java:475) at javax.swing.text.CompositeView.viewToModel (CompositeView.java:408) at javax.swing.text.BoxView.viewToModel (BoxView.java:477) at javax.swing.plaf.basic.BasicTextUI$RootView.viewToMod el(BasicTextUI.java:1366) at javax.swing.plaf.basic.BasicTextUI.viewToModel (BasicTextUI.java:919) at javax.swing.text.DefaultCaret.positionCaret (DefaultCaret.java:219) at javax.swing.text.DefaultCaret.adjustCaret (DefaultCaret.java:367) at javax.swing.text.DefaultCaret.adjustCaretAndFocus (DefaultCaret.java:355) at javax.swing.text.DefaultCaret.mouseClicked (DefaultCaret.java:294) at java.awt.AWTEventMulticaster.mouseClicked (AWTEventMulticaster.java:208) at java.awt.AWTEventMulticaster.mouseClicked (AWTEventMulticaster.java:207) at java.awt.Component.processMouseEvent (Component.java:5024) at java.awt.Component.processEvent (Component.java:4818) at java.awt.Container.processEvent (Container.java:1380) at java.awt.Component.dispatchEventImpl (Component.java:3526) at java.awt.Container.dispatchEventImpl (Container.java:1437) at java.awt.Component.dispatchEvent (Component.java:3367) at java.awt.LightweightDispatcher.retargetMouseEvent (Container.java:3214) at java.awt.LightweightDispatcher.processMouseEvent (Container.java:2938) at java.awt.LightweightDispatcher.dispatchEvent (Container.java:2859) at java.awt.Container.dispatchEventImpl (Container.java:1423) at java.awt.Window.dispatchEventImpl (Window.java:1566) at java.awt.Component.dispatchEvent (Component.java:3367) at java.awt.EventQueue.dispatchEvent (EventQueue.java:445) at java.awt.EventDispatchThread.pumpOneEventForHierarc hy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:130) at java.awt.EventDispatchThread.run (EventDispatchThread.java:98) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576179&group_id=44253 |
From: <no...@so...> - 2002-07-01 18:26:46
|
Bugs item #576081, was opened at 2002-07-01 18:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576081&group_id=44253 Category: Compiler integration Group: Crashes Status: Open Resolution: None Priority: 7 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: NullPointer if CompilerErrors in 2 files Initial Comment: If two files have errors in them and one depends on the other, compiling the first will show a list of errors in both files. Switching to the second file (or putting the cursor at the end of the second file) causes a NullPointerException in CompilerErrorPanel. Sample code: // Class 1 ---- public class Foo2 { Foo f = new Foo(); // End Class 1 ---- // Class 2 ---- public class Foo { public int x = 3; public static void main(String[] args) { System.out.println("Running program with arg: " + args[0]); } } } // End Class 2 ---- (It may be something specific about this type of error...) Compile Foo2, then switch to Foo and put the cursor at the end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=576081&group_id=44253 |
From: Eric E. A. <eri...@ma...> - 2002-06-29 12:54:10
|
> Anyway, the initial framework has now been committed. The docs > directory is within edu/rice/cs/drjava, which isn't ideal, but works > well enough. (Ideally it would be parallel to the src directory, but > we can't easily change the CVS root, which currently starts at the src > directory.) Of course, there is one really big advantage to putting the documentation in the DrJava directory: you'll always have the up-to-date docs just by doing a single ant update (unlike, e,g., the util classes. They were originally in a subpackage of drjava, and it was probably a mistake to lift them). > There is now a "docs" target to call from ant, which will generate the > HTML files for the documentation if you have "docbook2html" on your > path. I know this is installed on at least the Linux CS machines (eg. > nunavut), though I haven't found it on the Solaris ones. The HTML > files will be written to a "docs" directory next to your "built" > directory. Would it make sense to install it into the javaplt bin directory? Charlie, let me know if you want to do this, and I'll give you the password. We should both have write access to those directories anyway. -- Eric |
From: Charles R. <cr...@ri...> - 2002-06-28 05:58:05
|
After experimenting with a few different options, I've decided that DocBook is a good way to go for writing the user and developer documentation for DrJava. It's a very simple XML format, and is widely used for project documentation. If you want more information on it, follow some of the links at the DocBook Wiki (http://docbook.org/wiki/). Anyway, the initial framework has now been committed. The docs directory is within edu/rice/cs/drjava, which isn't ideal, but works well enough. (Ideally it would be parallel to the src directory, but we can't easily change the CVS root, which currently starts at the src directory.) There is now a "docs" target to call from ant, which will generate the HTML files for the documentation if you have "docbook2html" on your path. I know this is installed on at least the Linux CS machines (eg. nunavut), though I haven't found it on the Solaris ones. The HTML files will be written to a "docs" directory next to your "built" directory. There is also a "commit-docs" ant target, so that changes to the documentation can be committed without having to run all the tests. At the moment, only the user documentation has been started (not any of the developer docs). It has chapters on getting started and editing programs, as well as an appendix on how to configure DrJava. As soon as I get simple chapters written for the Interactions, Compiler, and JUnit integration, I'll start posting it on the main web site for users. (It should be a useful companion to the upcoming stable release.) I can post a private copy on my own page if people are interested in seeing what's there so far (without compiling it themselves). Anyway, there will be lots of changes to it over the next few days, but feel free to send me any feedback. Charlie |
From: <cen...@ri...> - 2002-06-27 22:42:17
|
Where are the French help files that have been written for DrJava? I want to attempt a translation via BabbleFish and/or other automatic translation services. Hopefully the transliteration will be good enough that a quick revision will be all that's necessary for satisfactory English. I would prefer that the original authors of the docs upload them to SourceForge and release them under the DrJava license. If someone could contact our French friends and ask them for this, I would appreciate it greatly. I don't want to violate international copyrights. :-) -- Peter |
From: <no...@so...> - 2002-06-27 20:00:12
|
Bugs item #574761, was opened at 2002-06-27 20:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=574761&group_id=44253 Category: Global model Group: Crashes Status: Open Resolution: None Priority: 7 Submitted By: Charles Reis (csreis) Assigned to: James Sasitorn (camus546) Summary: Open non-existant file crashes on 1.3 Initial Comment: If the user types in a filename that doesn't exist into the Open Files dialog on JDK 1.3, an ArrayIndexOutOfBoundsException is thrown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=574761&group_id=44253 |
From: <cen...@ri...> - 2002-06-27 18:36:05
|
Where are the French help files that have been written for DrJava? I want to attempt a translation via BabbleFish and/or other automatic translation services. Hopefully the transliteration will be good enough that a quick revision will be all that's necessary for satisfactory English. I would prefer that the original authors of the docs upload them to SourceForge and release them under the DrJava license. If someone could contact our French friends and ask them for this, I would appreciate it greatly. I don't want to violate international copyrights. :-) -- Peter |
From: Charles R. <cr...@ri...> - 2002-06-27 16:51:02
|
Ack-- it appears that the order of the updates matters here. Here's what I suggest: In the cs directory: cvs update build-common.xml util/build.xml drjava/build.xml Then run "ant update" in util, then "ant update" in drjava. Sorry about that... Charlie Charles Reis wrote: > The latest commit includes changes to both the util package and the > build-common.xml, so you'll need to run "ant update" in util and "cvs > update build-common.xml" in the cs directory. > > (The commit converts all System.out and System.err output to go to the > DrJava console, rather than the system console. This includes JUnit > tests, internal debugging statements, and anywhere else in the main JVM > that calls System.out and System.err.) > > Charlie > > > > ------------------------------------------------------- > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > drjava-hackers mailing list > drj...@li... > https://lists.sourceforge.net/lists/listinfo/drjava-hackers |
From: Charles R. <cr...@ri...> - 2002-06-27 16:45:18
|
The latest commit includes changes to both the util package and the build-common.xml, so you'll need to run "ant update" in util and "cvs update build-common.xml" in the cs directory. (The commit converts all System.out and System.err output to go to the DrJava console, rather than the system console. This includes JUnit tests, internal debugging statements, and anywhere else in the main JVM that calls System.out and System.err.) Charlie |
From: Charles R. <cr...@ri...> - 2002-06-26 23:09:12
|
Actually, I believe Dr. Nguyen has been working on this some already. He just reported yesterday that those docs are fairly interspersed with lecture material, so even a direct translation would still need some work. Anyway, I've been getting the documentation framework together, and it's almost ready to commit-- rather than LyX/LaTeX, I'm leaning towards Docbook (an XML standard that is widely used for documentation). It should all be available this week to start working on. Charlie cen...@ri... wrote: > Where are the French help files that have been written for DrJava? > I want to attempt a translation via BabbleFish and/or other > automatic translation services. Hopefully the transliteration will > be good enough that a quick revision will be all that's necessary > for satisfactory English. > > I would prefer that the original authors of the docs upload them to > SourceForge and release them under the DrJava license. If someone > could contact our French friends and ask them for this, I would > appreciate it greatly. I don't want to violate international > copyrights. :-) > > -- Peter > > > ------------------------------------------------------- This sf.net > email is sponsored by: Jabber Inc. Don't miss the IM event of the > season | Special offer for OSDN members! JabberConf 2002, Aug. > 20-22, Keystone, CO http://www.jabberconf.com/osdn > _______________________________________________ drjava-hackers > mailing list drj...@li... > https://lists.sourceforge.net/lists/listinfo/drjava-hackers > |
From: <cen...@ri...> - 2002-06-26 22:59:47
|
Where are the French help files that have been written for DrJava? I want to attempt a translation via BabbleFish and/or other automatic translation services. Hopefully the transliteration will be good enough that a quick revision will be all that's necessary for satisfactory English. I would prefer that the original authors of the docs upload them to SourceForge and release them under the DrJava license. If someone could contact our French friends and ask them for this, I would appreciate it greatly. I don't want to violate international copyrights. :-) -- Peter |
From: <cen...@ri...> - 2002-06-26 22:46:09
|
I'm posting this here, since I was denied rights to update the tracker item directly. . . . I was the one who changed the keyboard shortcut to ESC originally. I didn't realize that ESC was already bound to an action because there is no documentation for that feature and no visual indication in the app that it exists. It is now possible to clear the current line by pressing the down key, so we wouldn't be losing a significant amount of functionality if that feature was removed or changed to a different shortcut. ESC is also generally used to escape actions in progress, not to edit state. Therefore, I think it would make more sense to change the key command for clearing the line, rather than changing the menu shortcut. Command-B is sometimes used for Clear on Mac OS (it's right next to the clipboard shortcuts) - perhaps we could also use that shortcut. Command-Escape on the Mac is dangerously close to Command-Option-Escape (the option key is next to the Command key), which is a reserved shortcut for the Force Quit dialog. Considering the functionality of Abort Current Interaction, it could be very confusing if the shortcut was incorrectly typed. -- Peter |
From: <no...@so...> - 2002-06-26 16:43:54
|
Bugs item #574167, was opened at 2002-06-26 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=574167&group_id=44253 Category: Other Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: Javadoc won't build in some setups Initial Comment: In some environments, the "ant javadoc" target will generate four errors and quit without writing any of the javadoc files. Eric and I finally traced this down to a classpath issue: if the jars in the edu/rice/cs/lib directory are on your classpath, it won't work, but if the /home/javaplt/classes directory is on your classpath, it will. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=574167&group_id=44253 |
From: <no...@so...> - 2002-06-26 03:44:51
|
Bugs item #573933, was opened at 2002-06-26 03:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573933&group_id=44253 Category: User interface Group: Ugly Status: Open Resolution: None Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: ESC doesn't actually abort interactions Initial Comment: The shortcut key for Abort Current Interactions is currently ESC, but hitting ESC while the focus is in the InteractionsPane is bound instead to clearing the current line. (Hitting ESC with the focus in the DefinitionsPane actually does abort the interaction, but this isn't the usual case.) Easy solution is to change the default key for Abort Current Interaction. It used to be CTRL+C, which obviously wasn't any better (conflicts with copy). I'll set it to CTRL+ESC for now. I know that that conflicts with many window managers and might not work in all cases, but this isn't a very high priority keyboard shortcut anyway-- it's just as easy to choose the menu item. I'm open to suggestions for a better shortcut, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573933&group_id=44253 |
From: <no...@so...> - 2002-06-26 03:40:50
|
Bugs item #573932, was opened at 2002-06-26 03:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573932&group_id=44253 Category: User interface Group: Annoying Status: Open Resolution: None Priority: 3 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: No key binding for end of document Initial Comment: In the new configurable key bindings, a config option exists for "key.end.document", but there's no code in MainFrame for actually binding this to an action. Looks like it was just accidentally left out-- I'll put it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573932&group_id=44253 |
From: <no...@so...> - 2002-06-26 03:38:56
|
Bugs item #573931, was opened at 2002-06-26 03:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573931&group_id=44253 Category: User interface Group: Crashes Status: Open Resolution: None Priority: 6 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: Closing some dialogs crashes DrJava Initial Comment: Some of the dialogs, such as the prompt to save all documents before compiling, check to see that a valid code is returned from the JOptionPane. If not, they throw a RuntimeException. Many of them don't check if CLOSED_OPTION or CANCEL_OPTION is returned, though, so closing the dialog window (or hitting escape) will cause a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573931&group_id=44253 |
From: <no...@so...> - 2002-06-25 19:38:20
|
Feature Requests item #573782, was opened at 2002-06-25 14:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=573782&group_id=44253 Category: Definitions (source editor) Group: None Status: Open Priority: 5 Submitted By: Christopher Haynes (chaynes) Assigned to: Nobody/Anonymous (nobody) Summary: case sensitive file name changes Initial Comment: With Windows 2000/xp, if a file is saved with an all- lower case name, and then one saves it as a name that is the same but with some chars upcased, the name is not changed, either on disk, in the open file list, or in the titlebar. This is particularly unfortunate since beginners may fail to start a class name with an uppercase letter. The (unpleasant) workaround is to delete the file on disk and then do the saveAs. This really needs to be fixed. Also, a minor feature request: it would be nice if saveAs made the files public class name the default value of the name field. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=573782&group_id=44253 |
From: <no...@so...> - 2002-06-25 19:34:53
|
Feature Requests item #573780, was opened at 2002-06-25 19:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=573780&group_id=44253 Category: User interface Group: Small (< 1 pair-week) Status: Open Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Make JUnit Stack Trace Accessible Initial Comment: From Chris Haynes: If non-JUnit exceptions are thrown during a test button run, they show up in an abbreviated form. It would be nice if the whole stack trace showed up somewhere, say on the console. (Perhaps a button or menu item could display the whole stack trace for a given JUnit error. This would also be useful for Compiler errors.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=573780&group_id=44253 |
From: <no...@so...> - 2002-06-25 19:13:44
|
Bugs item #573769, was opened at 2002-06-25 19:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573769&group_id=44253 Category: Compiler integration Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Christopher McGraw (cmcgraw) Summary: Loaded compilers use different Config Initial Comment: After much debugging, we've discovered that the compilers loaded with our custom classloader are not using the same Configuration object as the rest of DrJava, but are instead creating a new instance of FileConfiguration when they're loaded. This is a problem if config values are changed on the fly, because the classloaded compilers won't ever see the changes. This can be fixed by removing all references to the Configuration object from the loaded compilers. Instead, the values of the config options can be set as fields directly on the compiler from CompilerProxy, which has a reference to the correct instance of the Configuration object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=573769&group_id=44253 |