Menu
▾
▴
drjava-hackers — DrJava developers mailing list
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: SourceForge.net <no...@so...> - 2004-04-28 06:21:26
|
Bugs item #943514, was opened at 2004-04-27 23:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943514&group_id=44253 Category: Eclipse Plug-in Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: Trouble launching eclipse plugin on OS X Initial Comment: I ran into some odd behavior with the latest DrJava Eclipse plugin on OS X. Configuration: OS X 10.3.3 latest software updates, but no developer previews (i.e., the released Java 1.4.2) Eclipse 3.0M8 - clean installation with no prior workspace or options DrJava plugins 0.9.4 and 0.9.0 With the 0.9.0 plugin, all works well if I launch Eclipse, select the java perspective, then select the DrJava perspective. If I launch eclipse and select the DrJava perspective first, the windows change around, but the DrJava interactions window does not appear. With the 0.9.4 plugin, selecting the DrJava perspective results in the dreaded beachball of death. Looking at the Activity Monitor display, it appears that something is trying to launch every few seconds, but it's failing. This happens regardless of whether the java perspective has been opened first or not. In all cases, there are no open Java projects or source files. I'm sticking with the 0.9.0 plugin for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943514&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-28 06:21:26
|
Bugs item #943508, was opened at 2004-04-27 23:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943508&group_id=44253 Category: Eclipse Plug-in Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: Trouble launching eclipse plugin on OS X Initial Comment: I ran into some odd behavior with the latest DrJava Eclipse plugin on OS X. Configuration: OS X 10.3.3 latest software updates, but no developer previews (i.e., the released Java 1.4.2) Eclipse 3.0M8 - clean installation with no prior workspace or options DrJava plugins 0.9.4 and 0.9.0 With the 0.9.0 plugin, all works well if I launch Eclipse, select the java perspective, then select the DrJava perspective. If I launch eclipse and select the DrJava perspective first, the windows change around, but the DrJava interactions window does not appear. With the 0.9.4 plugin, selecting the DrJava perspective results in the dreaded beachball of death. Looking at the Activity Monitor display, it appears that something is trying to launch every few seconds, but it's failing. This happens regardless of whether the java perspective has been opened first or not. In all cases, there are no open Java projects or source files. I'm sticking with the 0.9.0 plugin for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943508&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-28 06:21:26
|
Bugs item #943510, was opened at 2004-04-27 23:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943510&group_id=44253 Category: Eclipse Plug-in Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: Trouble launching eclipse plugin on OS X Initial Comment: I ran into some odd behavior with the latest DrJava Eclipse plugin on OS X. Configuration: OS X 10.3.3 latest software updates, but no developer previews (i.e., the released Java 1.4.2) Eclipse 3.0M8 - clean installation with no prior workspace or options DrJava plugins 0.9.4 and 0.9.0 With the 0.9.0 plugin, all works well if I launch Eclipse, select the java perspective, then select the DrJava perspective. If I launch eclipse and select the DrJava perspective first, the windows change around, but the DrJava interactions window does not appear. With the 0.9.4 plugin, selecting the DrJava perspective results in the dreaded beachball of death. Looking at the Activity Monitor display, it appears that something is trying to launch every few seconds, but it's failing. This happens regardless of whether the java perspective has been opened first or not. In all cases, there are no open Java projects or source files. I'm sticking with the 0.9.0 plugin for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943510&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-28 06:21:24
|
Bugs item #943507, was opened at 2004-04-27 23:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943507&group_id=44253 Category: Eclipse Plug-in Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: Trouble launching eclipse plugin on OS X Initial Comment: I ran into some odd behavior with the latest DrJava Eclipse plugin on OS X. Configuration: OS X 10.3.3 latest software updates, but no developer previews (i.e., the released Java 1.4.2) Eclipse 3.0M8 - clean installation with no prior workspace or options DrJava plugins 0.9.4 and 0.9.0 With the 0.9.0 plugin, all works well if I launch Eclipse, select the java perspective, then select the DrJava perspective. If I launch eclipse and select the DrJava perspective first, the windows change around, but the DrJava interactions window does not appear. With the 0.9.4 plugin, selecting the DrJava perspective results in the dreaded beachball of death. Looking at the Activity Monitor display, it appears that something is trying to launch every few seconds, but it's failing. This happens regardless of whether the java perspective has been opened first or not. In all cases, there are no open Java projects or source files. I'm sticking with the 0.9.0 plugin for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=943507&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-23 00:20:27
|
Bugs item #940420, was opened at 2004-04-23 00:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=940420&group_id=44253 Category: Other Group: Crashes Status: Open Resolution: None Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Command Line Indenter broken Initial Comment: It used to be possible to apply DrJava's indenting algorithm to a series of files from the command line, with: java -classpath drjava.jar edu.rice.cs.drjava.IndentFiles *.java That gives a java.awt.HeadlessException now, apparently caused by some LookAndFeel related options in OptionConstants. Full exception text below, for Java 1.4.2 and the most recent stable. Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at edu.rice.cs.drjava.config.OptionMapLoader.class$(OptionMapLoader.java:51) at edu.rice.cs.drjava.config.OptionMapLoader.<clinit>(OptionMapLoader.java:59) at edu.rice.cs.drjava.config.SavableConfiguration.loadConfiguration(SavableConfiguration.java:78) at edu.rice.cs.drjava.config.FileConfiguration.loadConfiguration(FileConfiguration.java:73) at edu.rice.cs.drjava.DrJava.initConfig(DrJava.java:296) at edu.rice.cs.drjava.DrJava.getConfig(DrJava.java:122) at edu.rice.cs.drjava.model.definitions.indent.Indenter.buildTree(Indenter.java:98) at edu.rice.cs.drjava.model.definitions.indent.Indenter.<init>(Indenter.java:64) at edu.rice.cs.drjava.IndentFiles.indentFiles(IndentFiles.java:130) at edu.rice.cs.drjava.IndentFiles.main(IndentFiles.java:102) Caused by: java.awt.HeadlessException at sun.awt.HeadlessToolkit.getMenuShortcutKeyMask(HeadlessToolkit.java:194) at edu.rice.cs.drjava.config.OptionConstants.<clinit>(OptionConstants.java:297) ... 12 more ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=940420&group_id=44253 |
|
From: Charles R. <creis@u.washington.edu> - 2004-04-21 15:25:37
|
That's fantastic! That sounds like it could be hugely beneficial to DrJava (especially from a UI standpoint, since we haven't had much real intro-user observation outside TeachJava), and just a fun project on its own. I think one related topic is putting together a good "Quick Start" or "What is DrJava" link on our home page, to help people understand what sets DrJava apart (and how to use some of the features). I've been meaning to do this in my free time, but, well, you know... I do have a possible outline that I've attached, though, if anyone's interested in working on it or simply has suggestions. Good luck with it-- I'm looking forward to hearing how it goes! Charlie Peter Centgraf wrote: > I have some good news for the DrJava team. Yesterday I met with three > lecturers from the introductory programming group here at CMU. They > have been using CodeWarrior for their courses and are becoming > increasingly dissatisfied with it, so they gave me the chance to sell > them on using DrJava instead. After an hour of demos and discussion, > they agreed to begin experimenting with DrJava this summer. > > More importantly for you, they agreed to sponsor me in an independent > study course to work with them. My goals will be to 1: investigate how > teachers can leverage DrJava for pedagogic purposes in their courses, > and 2: improve DrJava to better support student needs. Working on #2 > will involve changes to the code that I will feed back to the group. > More importantly, I will be collecting data from both of our user groups > to guide future development. I plan to publish my incremental results > on the web, and I will keep the list(s) informed about important findings. > > For those of you working to support TeachJava, one of the courses I will > be assisting is an AP level course for high school students. The > teachers have already been looking at the materials for past workshops, > and this summer will provide a good opportunity to field test some of > your methods. In the past, CMU's introductory courses have started with > a procedural-style emphasis on mechanics. It will be interesting to see > how pushing design patterns down into this level changes the style of > their courses. > > If any of you have suggestions or questions for me, I would appreciate > the feedback as I develop specific plans for my work. It's because of > your past innovations in teaching that I have so much to contribute to > CMU in the first place. Thanks for the great work -- I hope to be part > of that process again soon. > > -- > Peter > > |
|
From: Peter C. <pe...@ce...> - 2004-04-21 15:13:16
|
I have some good news for the DrJava team. Yesterday I met with three lecturers from the introductory programming group here at CMU. They have been using CodeWarrior for their courses and are becoming increasingly dissatisfied with it, so they gave me the chance to sell them on using DrJava instead. After an hour of demos and discussion, they agreed to begin experimenting with DrJava this summer. More importantly for you, they agreed to sponsor me in an independent study course to work with them. My goals will be to 1: investigate how teachers can leverage DrJava for pedagogic purposes in their courses, and 2: improve DrJava to better support student needs. Working on #2 will involve changes to the code that I will feed back to the group. More importantly, I will be collecting data from both of our user groups to guide future development. I plan to publish my incremental results on the web, and I will keep the list(s) informed about important findings. For those of you working to support TeachJava, one of the courses I will be assisting is an AP level course for high school students. The teachers have already been looking at the materials for past workshops, and this summer will provide a good opportunity to field test some of your methods. In the past, CMU's introductory courses have started with a procedural-style emphasis on mechanics. It will be interesting to see how pushing design patterns down into this level changes the style of their courses. If any of you have suggestions or questions for me, I would appreciate the feedback as I develop specific plans for my work. It's because of your past innovations in teaching that I have so much to contribute to CMU in the first place. Thanks for the great work -- I hope to be part of that process again soon. -- Peter |
|
From: Peter C. <pe...@ce...> - 2004-04-20 11:54:24
|
Hi Gang, I've recently discovered the Quaqua Look And Feel -- an open-source (LGPL or BSD) implementation of an improved Aqua LaF. Essentially, it makes Swing more Aqua-like than Apple's Aqua LaF is by default. It includes a pure-Java implementation of a column-view style JFileChooser (Happy day!), and fixes a number of misc rendering problems. <http://www.randelshofer.ch/quaqua/download.html> In my attempts to get this LaF working with DrJava, I discovered a quirk of the current LaF config option: it only allows built-in LaFs to be used. The offending code is in config/OptionConstants.java. The LOOK_AND_FEEL constant is set to a ForcedChoiceOption populated by "UIManager.getInstalledLookAndFeels();". Since this is performed statically at class load-time, there's no way to install an alternative LaF before the classname is rejected as an unsupported option. You can make another LaF work by calling "UIManager.installLookAndFeel()" manually in OptionConstants, but this is obviously a dirty, dirty hack. Using a ForcedChoiceOption gives us a nicely rendered combo box in Preferences, but the behavior we want is more like a silent-failing StringOption. Maybe we should have a "PromptedChoiceOption" or somesuch that renders like a ForcedChoiceOptionComponent but allows a user to specify an arbitrary String in the config file. If someone feels ambitious, this shouldn't be hard to implement. As for the Quaqua LaF, I'm going to spend some time with it. If it seems solid, are there any objections on principle to including it as our default LaF? That JFileChooser is very slick. . . . -- Peter |
|
From: SourceForge.net <no...@so...> - 2004-04-16 20:28:21
|
Feature Requests item #936578, was opened at 2004-04-16 13:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=936578&group_id=44253 Category: User interface Group: None Status: Open Priority: 5 Submitted By: Neal Horowitz (nrhorowitz) Assigned to: Nobody/Anonymous (nobody) Summary: More "Find" Options Initial Comment: I have two stories in mind. They're not exactly related, but they have good synergy. Story one: A user wants to find the usages of a certain method. After selecting the method name, the user types ctrl+F to search. The search tab is automatically brought up with the selected text in the search field. The user is then able to repeatedly type <Enter or <F3> to search for the method without having to type the name in the search field. Story two: A user has just searched for one bit of text, but realizes that a previous search is needed again. The user types <down arrow> in the search field, and the last search the user looked for is shown. Additionally, the search field might become a combo box so that the search history can be displayed all at once. The first option could be annoying if the user actually wanted to search for the last thing again or make a slight modification to it; however, with the search history, it would be easy to get that back if something were highlighted upon hitting find. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=936578&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-15 20:10:37
|
Bugs item #935208, was opened at 2004-04-14 14:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=935208&group_id=44253 Category: Other Group: Could cause data loss Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: runtime exception occured Initial Comment: edu.rice.cs.util.UnexpectedException: javax.swing.text.BadLocationException: Invalid location at edu.rice.cs.drjava.model.compiler.CompilerErrorModel.get ErrorAtOffset(CompilerErrorModel.java:287) at edu.rice.cs.drjava.ui.ErrorCaretListener.updateHighlight (ErrorCaretListener.java:121) at edu.rice.cs.drjava.ui.MainFrame$107.run (MainFrame.java:4335) at edu.rice.cs.drjava.ui.MainFrame$ModelListener.activeDoc umentChanged(MainFrame.java:4386) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel$1.noti fyListener(DefaultSingleDisplayModel.java:450) at edu.rice.cs.drjava.model.GlobalEventNotifier.notifyListene rs(GlobalEventNotifier.java:102) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel._setA ctiveDoc(DefaultSingleDisplayModel.java:444) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel.acces s$300(DefaultSingleDisplayModel.java:95) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel$Selec tionModelListener.valueChanged (DefaultSingleDisplayModel.java:472) at javax.swing.DefaultListSelectionModel.fireValueChanged (Unknown Source) at javax.swing.DefaultListSelectionModel.fireValueChanged (Unknown Source) at javax.swing.DefaultListSelectionModel.fireValueChanged (Unknown Source) at javax.swing.DefaultListSelectionModel.removeIndexInterv al(Unknown Source) at javax.swing.plaf.basic.BasicListUI$ListDataHandler.interva lRemoved(Unknown Source) at javax.swing.AbstractListModel.fireIntervalRemoved (Unknown Source) at javax.swing.DefaultListModel.removeElement (Unknown Source) at edu.rice.cs.drjava.model.DefaultGlobalModel.closeFile (DefaultGlobalModel.java:608) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel.close File(DefaultSingleDisplayModel.java:355) at edu.rice.cs.drjava.model.DefaultGlobalModel.closeAllFiles (DefaultGlobalModel.java:625) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel.close AllFiles(DefaultSingleDisplayModel.java:385) at edu.rice.cs.drjava.model.DefaultGlobalModel.quit (DefaultGlobalModel.java:650) at edu.rice.cs.drjava.ui.MainFrame._quit (MainFrame.java:2055) at edu.rice.cs.drjava.ui.MainFrame.access$2700 (MainFrame.java:103) at edu.rice.cs.drjava.ui.MainFrame$67.windowClosing (MainFrame.java:1208) at java.awt.AWTEventMulticaster.windowClosing(Unknown Source) at java.awt.Window.processWindowEvent (Unknown Source) at javax.swing.JFrame.processWindowEvent (Unknown Source) at java.awt.Window.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl (Unknown Source) at java.awt.Container.dispatchEventImpl (Unknown Source) at java.awt.Window.dispatchEventImpl (Unknown Source) at java.awt.Component.dispatchEvent (Unknown Source) at java.awt.EventQueue.dispatchEvent (Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarch y(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy (Unknown Source) at java.awt.EventDispatchThread.pumpEvents (Unknown Source) at java.awt.EventDispatchThread.pumpEvents (Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Caused by: javax.swing.text.BadLocationException: Invalid location at javax.swing.text.GapContent.getChars (Unknown Source) at javax.swing.text.GapContent.getString (Unknown Source) at javax.swing.text.AbstractDocument.getText (Unknown Source) at edu.rice.cs.drjava.model.compiler.CompilerErrorModel.get ErrorAtOffset(CompilerErrorModel.java:280) at edu.rice.cs.drjava.ui.ErrorCaretListener.updateHighlight (ErrorCaretListener.java:121) at edu.rice.cs.drjava.ui.MainFrame$107.run (MainFrame.java:4335) at edu.rice.cs.drjava.ui.MainFrame$ModelListener.activeDoc umentChanged(MainFrame.java:4386) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel$1.noti fyListener(DefaultSingleDisplayModel.java:450) at edu.rice.cs.drjava.model.GlobalEventNotifier.notifyListene rs(GlobalEventNotifier.java:102) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel._setA ctiveDoc(DefaultSingleDisplayModel.java:444) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel.acces s$300(DefaultSingleDisplayModel.java:95) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel$Selec tionModelListener.valueChanged (DefaultSingleDisplayModel.java:472) at javax.swing.DefaultListSelectionModel.fireValueChanged (Unknown Source) at javax.swing.DefaultListSelectionModel.fireValueChanged (Unknown Source) at javax.swing.DefaultListSelectionModel.fireValueChanged (Unknown Source) at javax.swing.DefaultListSelectionModel.removeIndexInterv al(Unknown Source) at javax.swing.plaf.basic.BasicListUI$ListDataHandler.interva lRemoved(Unknown Source) at javax.swing.AbstractListModel.fireIntervalRemoved (Unknown Source) at javax.swing.DefaultListModel.removeElement (Unknown Source) at edu.rice.cs.drjava.model.DefaultGlobalModel.closeFile (DefaultGlobalModel.java:608) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel.close File(DefaultSingleDisplayModel.java:355) at edu.rice.cs.drjava.model.DefaultGlobalModel.closeAllFiles (DefaultGlobalModel.java:625) at edu.rice.cs.drjava.model.DefaultSingleDisplayModel.close AllFiles(DefaultSingleDisplayModel.java:385) at edu.rice.cs.drjava.model.DefaultGlobalModel.quit (DefaultGlobalModel.java:650) at edu.rice.cs.drjava.ui.MainFrame._quit (MainFrame.java:2055) at edu.rice.cs.drjava.ui.MainFrame.access$2700 (MainFrame.java:103) at edu.rice.cs.drjava.ui.MainFrame$67.windowClosing (MainFrame.java:1208) at java.awt.AWTEventMulticaster.windowClosing(Unknown Source) at java.awt.Window.processWindowEvent (Unknown Source) at javax.swing.JFrame.processWindowEvent (Unknown Source) at java.awt.Window.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl (Unknown Source) at java.awt.Container.dispatchEventImpl (Unknown Source) at java.awt.Window.dispatchEventImpl (Unknown Source) at java.awt.Component.dispatchEvent (Unknown Source) at java.awt.EventQueue.dispatchEvent (Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarch y(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy (Unknown Source) at java.awt.EventDispatchThread.pumpEvents (Unknown Source) at java.awt.EventDispatchThread.pumpEvents (Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=935208&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-15 19:23:18
|
Bugs item #935163, was opened at 2004-04-14 14:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=935163&group_id=44253 Category: User interface Group: Would be nice if fixed ... Status: Open Resolution: None Priority: 5 Submitted By: Moez A. Abdel-Gawad (moez) Assigned to: Nobody/Anonymous (nobody) Summary: Find's found text output in console panel Initial Comment: When searching for some text in DrJava, the found text, if found, gets output in the console panel preceded by the message "I see word as:". Would be nice if this is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=935163&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-15 05:19:55
|
Feature Requests item #935412, was opened at 2004-04-14 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=935412&group_id=44253 Category: User interface Group: None Status: Open Priority: 5 Submitted By: Neal Horowitz (nrhorowitz) Assigned to: Nobody/Anonymous (nobody) Summary: Accelerator keys Initial Comment: Story: A user wants to quit DrJava. After choosing File->Quit, the user is prompted with a dialog, "Are you sure you want to quit DrJava?" Beneath the message, there are _Y_es and _N_o buttons (with the first letter underlined), indicating that typing Y or N will have the same effect as clicking Yes or No, respectively. The user is sure, presses the Y key, and DrJava exits. The dialog appears as stated, but the current behavior requires the user to type alt-Y or alt-N to use the accelerator keys. This is fairly unintuitive outside the context of the accelerator keys for the pulldown menus in the main windows. For dialogs, it makes more sense not to require the alt press. Clearly, this would involve some mucking with swing/awt primitives. A good place to start might be looking at the key processing done by a JOptionPane. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=935412&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-12 21:42:07
|
Feature Requests item #933919, was opened at 2004-04-12 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=933919&group_id=44253 Category: Interactions Group: None Status: Open Priority: 3 Submitted By: Neal Horowitz (nrhorowitz) Assigned to: Nobody/Anonymous (nobody) Summary: interactions pane keystrokes Initial Comment: Story: An impatient programmer wishes to type several interactions into the interactions pane in sequence. The user knows what they are without being concerned with the results of the first few (perhaps they are import statements, declarations, or other statements using a semicolon to suppress output). The programmer, being impatiant, does not want to have to wait until each one finishes before typing the next one; instead, once an interaction has been typed, the user hits enter and begins typing the next interaction. When the first interaction finishes, the second line of typing appears at the new prompt in the interactions pane and is immediately executed. The idea here would be to emulate the way a Unix terminal handles input, minus the extra echoing. If your prompt is busy, characters typed in are basically queued until the next time the prompt is available. As a result, several sequqential commands can be entered all at once without waiting for the result of the first. This isn't a big deal, and I'm not even sure we *want* this behavior, but I think it would be nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=933919&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-12 04:02:54
|
Bugs item #933507, was opened at 2004-04-11 21:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=933507&group_id=44253 Category: UI: MacOS X-specific Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Pool (reganto) Assigned to: Nobody/Anonymous (nobody) Summary: Interactions importing & execution flakiness Initial Comment: Under OS X 10.3.3 with Jave version 1.4.2_03 and Java VM 1.4.2-34, DrJava (stable release of 2004/03/26) is doing these things in the Interactions pane: 1. If all classes of javax.swing or of java.awt are imported, DrJava resumes OK from the import command, but, if only one class is imported, specifically JColorChooser or Color, then DrJava goes into the background and edu.rice.cs.util.newjvm.SlaveJVMRunner comes into the foreground and stays there, until the user manually brings DrJava back into the foreground; until then any typing in the Interactions pane is impossible. 2. Each invocation of JColorChooser.showDialog results in edu.rice.cs.util.newjvm.SlaveJVMRunner remaining in the foreground, as above. 3. The first invocation of JColorChooser.showDialog may display the color dialog window in front, but all subsequent invocations bring it to the front only for a split second, after which it recedes into the background until the user manually brings it into the foreground to use it. 4. Erratically, some invocations of JColorChooser.showDialog also yield null, rather than a Color. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=933507&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-11 22:00:02
|
Bugs item #933423, was opened at 2004-04-11 15:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=933423&group_id=44253 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: running a Tester class, runtime error terminated program Initial Comment: not sure if this is a real bug, I got a Dr java error message when running a Tester to report to this site Here is the copy of stack trace: com.sun.jdi.VMDisconnectedException at com.sun.tools.jdi.TargetVM.waitForReply (TargetVM.java:273) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply (VirtualMachineImpl.java:883) at com.sun.tools.jdi.PacketStream.waitForReply (PacketStream.java:51) at com.sun.tools.jdi.JDWP$ThreadReference$Status.waitFor Reply(JDWP.java:4132) at com.sun.tools.jdi.JDWP$ThreadReference$Status.process (JDWP.java:4113) at com.sun.tools.jdi.ThreadReferenceImpl.jdwpStatus (ThreadReferenceImpl.java:184) at com.sun.tools.jdi.ThreadReferenceImpl.status (ThreadReferenceImpl.java:196) at edu.rice.cs.drjava.model.debug.DebugThreadData.<init> (DebugThreadData.java:69) at edu.rice.cs.drjava.model.debug.JPDADebugger.getCurrent ThreadData(JPDADebugger.java:1143) at edu.rice.cs.drjava.ui.DebugPanel.updateData (DebugPanel.java:178) at edu.rice.cs.drjava.ui.DebugPanel$21.run (DebugPanel.java:964) at java.awt.event.InvocationEvent.dispatch (Unknown Source) at java.awt.EventQueue.dispatchEvent (Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarch y(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy (Unknown Source) at java.awt.EventDispatchThread.pumpEvents (Unknown Source) at java.awt.EventDispatchThread.pumpEvents (Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=933423&group_id=44253 |
|
From: Peter C. <cen...@cm...> - 2004-04-11 05:50:37
|
Hi fellow hackers,
There appears to be an inconsistency in the current CVS. After a CVS
update and clean recompile of the whole project, I get this:
do-compile:
[javac] Compiling 357 source files to
/Users/centgraf/Documents/Rice/Comp312/cvs/built
[javac]
/Users/centgraf/Documents/Rice/Comp312/cvs/src/edu/rice/cs/drjava/
model/repl/IdentityVisitor.java:63:
edu.rice.cs.drjava.model.repl.IdentityVisitor is not abstract and does
not override abstract method
visit(koala.dynamicjava.tree.ForEachStatement) in
koala.dynamicjava.tree.visitor.Visitor
[javac] public class IdentityVisitor implements Visitor<Node> {
[javac] ^
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
If I build a new jar from our DynamicJava CVS and use that, I get
different errors:
do-compile:
[javac] Compiling 357 source files to
/Users/centgraf/Documents/Rice/Comp312/cvs/built
[javac]
/Users/centgraf/Documents/Rice/Comp312/cvs/src/edu/rice/cs/drjava/
model/repl/TypeCheckerExtension.java:217: cannot find symbol
[javac] symbol : method
visitNumericExpression(koala.dynamicjava.tree.DivideExpression,java.lang
.String)
[javac] location: class
edu.rice.cs.drjava.model.repl.TypeCheckerExtension
[javac] Class c = visitNumericExpression(node, "division.type");
[javac] ^
[javac]
/Users/centgraf/Documents/Rice/Comp312/cvs/src/edu/rice/cs/drjava/
model/repl/TypeCheckerExtension.java:230: cannot find symbol
[javac] symbol : method
visitNumericExpression(koala.dynamicjava.tree.RemainderExpression,java.l
ang.String)
[javac] location: class
edu.rice.cs.drjava.model.repl.TypeCheckerExtension
[javac] Class c = visitNumericExpression(node,
"remainder.type");
[javac] ^
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
Could whoever has been modifying these classes please fix this? I
would like to add nice default toString behavior for the interactions
pane based on Jakarta Commons Lang ReflectionToString, but can't build.
:-(
--
Peter
|
|
From: Peter C. <pe...@ce...> - 2004-04-10 08:43:44
|
Hi gang, On a lark, I ran a Google search for "DrJava" tonight, and I'm impressed by how widely our tools are being used. I found installation guides or help documents published in France, Italy, Spain, Austria, Brazil, Japan, and a handful of US and Canadian universities. Of course, these are only the places that have invested in DrJava so much that they have custom help pages for it -- who knows how many more universities are silently installing it on their workstations. Keep up the good work, everyone! -- Peter |
|
From: Robert C. <co...@cs...> - 2004-04-09 05:35:00
|
Neal Horowitz wrote: > although it is an easy problem to make (and has been made in the=20 > past), the problem this time is that it is not in the drjava part of=20 > the cvs tree, it's in the util directory (specifically=20 > edu/rice/cs/util/swing), and so will not be gotten by an ant update=20 > from within drjava. The solution is either to run "cvs update" from=20 > src/edu/rice/cs (or any parent directory), or to do an "ant update"=20 > from within the util package of drjava. (This is also a really common=20 > problem. I don't even remember how many times I've wondered who=20 > managed to commit broken code before finally remembering to update util= !) > Neal > > *From:* drj...@li...=20 > [mailto:drj...@li...] *On Behalf Of=20 > *Jonathan Lugo > *Sent:* Thursday, April 08, 2004 11:55 PM > *To:* drj...@li... > *Subject:* [DrJava] Please Add Any New Dependent Classes to CVS > > There have been some resent problems with the CVS tree due to missing=20 > classes. Specifically, the ui.MainFrame class now depends on a small=20 > class named UnfocusableButton. This class, however is no where on the=20 > CVS tree. It=92s probably easy to create the new class and forget to do= =20 > the appropriate CVS add. While the code will compile and test on the=20 > committers machine (since the class is there), not all the code gets=20 > sent. So, whoever created the UnfocusableButton class, please commit=20 > it so we can compile. > > This seems like an easy problem to make. Is there some feasible=20 > automation we can implement? Is it possible have ant ignore anything=20 > that=92s not a .java file but still do some check or prompt for java=20 > files that would be prefixed with a =93?=94 in the CVS output? > > - jonathan > Why can't we define an ant update update command for the parent cs=20 directory (above util, drjava and lib) that updates the entire subtree. We could make this the standard update=20 command to synchronize a local copy of the source with sourceforge. -- Corky |
|
From: Neal H. <nr...@ri...> - 2004-04-09 05:22:47
|
although it is an easy problem to make (and has been made in the past), the problem this time is that it is not in the drjava part of the cvs tree, it's in the util directory (specifically edu/rice/cs/util/swing), and so will not be gotten by an ant update from within drjava. The solution is either to run "cvs update" from src/edu/rice/cs (or any parent directory), or to do an "ant update" from within the util package of drjava. (This is also a really common problem. I don't even remember how many times I've wondered who managed to commit broken code before finally remembering to update util!) Neal _____ From: drj...@li... [mailto:drj...@li...] On Behalf Of Jonathan Lugo Sent: Thursday, April 08, 2004 11:55 PM To: drj...@li... Subject: [DrJava] Please Add Any New Dependent Classes to CVS There have been some resent problems with the CVS tree due to missing classes. Specifically, the ui.MainFrame class now depends on a small class named UnfocusableButton. This class, however is no where on the CVS tree. It's probably easy to create the new class and forget to do the appropriate CVS add. While the code will compile and test on the committers machine (since the class is there), not all the code gets sent. So, whoever created the UnfocusableButton class, please commit it so we can compile. This seems like an easy problem to make. Is there some feasible automation we can implement? Is it possible have ant ignore anything that's not a .java file but still do some check or prompt for java files that would be prefixed with a "?" in the CVS output? - jonathan |
|
From: Jonathan L. <jl...@ri...> - 2004-04-09 04:55:02
|
There have been some resent problems with the CVS tree due to missing classes. Specifically, the ui.MainFrame class now depends on a small class named UnfocusableButton. This class, however is no where on the CVS tree. It's probably easy to create the new class and forget to do the appropriate CVS add. While the code will compile and test on the committers machine (since the class is there), not all the code gets sent. So, whoever created the UnfocusableButton class, please commit it so we can compile. This seems like an easy problem to make. Is there some feasible automation we can implement? Is it possible have ant ignore anything that's not a java file but still do some check or prompt for java files that would be prefixed with a "?" in the CVS output? - jonathan |
|
From: SourceForge.net <no...@so...> - 2004-04-07 19:03:11
|
Bugs item #931088, was opened at 2004-04-07 07:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=931088&group_id=44253 Category: UI: MacOS X-specific Group: Ugly Status: Open Resolution: None Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: resize thumb covers corner of OS X window Initial Comment: In OS X, the resize thumb in the lower-right corner hides something like a 15x15 rectangle of whatever is drawn in that corner. It can be seen in DrJava itself, where the editor's column number is partially hidden. Here's a simple test case that also shows it: import java.awt.*; import javax.swing.*; public class TestPanel extends JPanel { public void paintComponent(Graphics g) { super.paintComponent(g); g.setColor(Color.green); g.fillOval(0,0,50,50); g.fillOval(getWidth()-30, getHeight()-30, 30, 30); } } Do the following in the interactions window to demonstrate: import java.awt.*; import javax.swing.*; JFrame f = new JFrame(); TestPanel t = new TestPanel(); t.setPreferredSize(new Dimension(200,200)); f.getContentPane().add(t); f.pack(); f.setVisible(true); I'm not sure if there's an easy fix, since this might be a "feature" of OS X's implementation of JFrame. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=931088&group_id=44253 |
|
From: Neal H. <nr...@ri...> - 2004-04-02 23:11:15
|
A new version of the DrJava Plug-In for Eclipse has been released! This version increases ease of typing long interactions into the interactions pane. Upon pressing enter, the interactions pane automatically detects if the user has not finished typing and gives the user a newline rather than attempting to interpret the incomplete interaction. This version also allows reverse searching through the interactions pane by typing partial text and pressing tab. You can go to <http://drjava.sf.net/eclipse.shtml> http://drjava.sf.net/eclipse.shtml to download the new plug-in. Please send us any comments you have! Neal |
|
From: SourceForge.net <no...@so...> - 2004-04-02 01:09:52
|
Feature Requests item #927955, was opened at 2004-04-01 17:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=927955&group_id=44253 Category: User interface Group: None Status: Open Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: alt-F4 doesn't quit in windows, etc. Initial Comment: A couple of minor user interface glitches in the current production DrJava on WinXP. 1) alt-F4 doesn't do anything. For consistency with other windows apps, it should cause the application to quit (as cntrl-q does now). 2) When the "do you really want to quit" dialog pops up, typing y or n doesn't do anything. One has to type alt- y or alt-n. It'd be nice if y and n worked by themselves. Hal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=927955&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-04-02 01:01:38
|
Feature Requests item #927952, was opened at 2004-04-01 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=927952&group_id=44253 Category: Other Group: None Status: Open Priority: 5 Submitted By: Hal Perkins (hperkins) Assigned to: Nobody/Anonymous (nobody) Summary: Remember last directory in file commands Initial Comment: It would be nice if DrJava would remember from session to session the folder used last time as the starting place for open, save, and similar file commands. Right now it starts in the folder containing DrJava each time DrJava starts up, but most of the time the files I want are in the folder I used last time, or are nearby (the project I'm working on, the demo I want to show, etc.). It shouldn't be too hard to store the directory location in the .drjava file. If that folder information is no longer valid when accessed (the directory was deleted, etc.), it can just be ignored, or some parent folder could be selected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=927952&group_id=44253 |
|
From: Peter C. <cen...@cm...> - 2004-04-01 05:13:47
|
My test problems with DynamicJava went away -- I suspect it was some
oddity with using the official jsr14 v2.5 and JDK 1.4. My changes are
now committed to CVS. It was a very simple fix to add the argument
types to the error message when a method lookup fails. For example,
this call:
System.exit("blah");
now provides this error message:
Error: No 'exit' method in 'java.lang.System' with arguments:
(java.lang.String)
Instead of the old, misleading message:
Error: No 'exit' method in 'java.lang.System'
The new message still isn't perfect, since Java method lookup doesn't
require an exact match. Something like "No '%0' method in '%1' matches
arguments: (%2)" would be more precise, if we could trust the user to
understand "matches" in the context of the Java type system. I went
with the more general wording because I think Java novices would be
less likely to misinterpret it. You can play with your own message
strings by changing the
dynamicjava/interpreter/resources/messages.properties file. The old
"no.such.method" string is still in use by some special cases, and my
new message is called "no.such.method.with.args".
P.S. It appears that the ant script also committed my build.xml and
build-common.xml. I modified them so that the "jar" target works
correctly, building a "dynamicjava.jar" instead of "drjava.jar", and to
print only deprecation and unchecked operation warnings (and not all
the serialization stuff).
--
Peter
On Mar 31, 2004, at 11:46 PM, Neal Horowitz wrote:
> Peter -- what changes exactly did you make and what problems are you
> having?
> There shouldn't be any trouble with the unit tests... Maybe James can
> tell you
> more?
|
25 messages has been excluded from this view by a project administrator.
