drjava-hackers — DrJava developers mailing list

[DrJava] UnexpectedException

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

Oops; here's another thing we never told you about:

Sometimes, the Java static type system will force you to deal with "ghost
exceptions", i.e., checked exceptions that you _know_ will never happen.
And I mean that they will never occur unless there is a bug in your
program. It's wordy and tedious to add these these exceptions to the
throws clauses of the transitive closure of all callers. Originally we
handled such cases by simply catching them and doing nothing in the catch
clause. But we stopped that after the first time we had to debug a case
where such an exception was actually thrown. So now, we catch such
exceptions and throw an instance of a special class, called
UnexpectedException. Whenever we see an UnexpectedException thrown, we
know there's a bug in the program. So please don't use this
UnexceptedException class for any purpose other than to deal with these
ghost exceptions.

On the other hand, if you really do have a ghost exception to deal with,
please _do_ throw an UnexpectedException in the corresponding catch
clause.

Thanks,

-- Eric

[DrJava] Coding standards stuff

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

BTW, I'm not sure whether we talked about this at the beginning of the
class or whether I stupidly assumed you'd pick it up via osmosis, but
please try to adhere to the coding standards posted at
http://www.cs.rice.edu/~javaplt/code.html. Most notably, don't use tab
characters, and indentation should be two spaces.

All coding standards are fairly arbitrary, so if you are used to other
ones, we're sorry. We'd like to keep the code as uniform as possible, and
these are the rules we cooked up.

Thanks,
-brian

[DrJava] DrJava is still alive ? (fwd)

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

Further motiviation to do a release sooner rather than later: We do, in
fact, have real users. :)

(This is the guy in France who is using DrJava for a class!)

-brian

---------- Forwarded message ----------
Date: Fri, 12 Apr 2002 17:02:29 +0200
From: Jean-Paul Roy <Jea...@un...>
To: Brian Stoler <bs...@bs...>
Subject: DrJava is still alive ?

Hi Brian,
I was addicted to downloading at least a new release every
night, and nothing for a month ! What's happening :-)
The main problem - already referenced is about the scrolling
of the editor pane with the mouse (to get it back, use "open-cancel")...

     -jpr

Re: [DrJava] Re: I'm a liar

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

Peter,

If Brian is right (he usually is), then the first step in fixing this bug
should be to write a test that trips it. That way, you won't be able to
commit until it's fixed, and we'll never trip over that same bug again.

-- Eric



On Thu, 11 Apr 2002, Brian Stoler wrote:

> > Seems like we really do need that GUI testing framework. :-)
> > Maybe this should be made a high priority for the summer. . . .
>
> Perhaps so, but that bug does not justify it. It's actually a bug in the
> model, I think, which should be perfectly reproducible in a
> DefinitionsDocumentTest case.
>
> -brian
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

Re: [DrJava] Re: I'm a liar

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

> Seems like we really do need that GUI testing framework. :-)
> Maybe this should be made a high priority for the summer. . . .

Perhaps so, but that bug does not justify it. It's actually a bug in the
model, I think, which should be perfectly reproducible in a
DefinitionsDocumentTest case.

-brian

[DrJava] Re: I'm a liar

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

Seems like we really do need that GUI testing framework. :-)  
Maybe this should be made a high priority for the summer. . . .

--
Peter

[DrJava] [ drjava-Bugs-542747 ] Files open via command line problem

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

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

Category: Other
Group: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Files open via command line problem

Initial Comment:
If you open a file by putting it on the command line
when launching DrJava, and if the path you gave was
relative, DrJava chokes when trying to compile the
file. (More precisely, when trying to get its source root.)

Here's the exception you get:
java.lang.RuntimeException: parent dir is null?!
	at
edu.rice.cs.drjava.model.DefaultGlobalModel$DefinitionsDocumentHandler._getSourceRoot(DefaultGlobalModel.java:1118)
	at
edu.rice.cs.drjava.model.DefaultGlobalModel$DefinitionsDocumentHandler.getSourceRoot(DefaultGlobalModel.java:1070)
	at
edu.rice.cs.drjava.model.DefaultGlobalModel.getSourceRootSet(DefaultGlobalModel.java:668)
	at
edu.rice.cs.drjava.model.DefaultGlobalModel._resetInteractionsClasspath(DefaultGlobalModel.java:1284)
	at
edu.rice.cs.drjava.model.DefaultGlobalModel._restoreInteractionsState(DefaultGlobalModel.java:1302)
	at
edu.rice.cs.drjava.model.DefaultGlobalModel.resetInteractions(DefaultGlobalModel.java:418)
	at
edu.rice.cs.drjava.model.DefaultGlobalModel$DefinitionsDocumentHandler.startCompile(DefaultGlobalModel.java:932)
	at
edu.rice.cs.drjava.ui.MainFrame._compile(MainFrame.java:643)
	at
edu.rice.cs.drjava.ui.MainFrame.access$1000(MainFrame.java:67)
	at
edu.rice.cs.drjava.ui.MainFrame$13.actionPerformed(MainFrame.java:250)
	at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1767)
	at
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1820)
	at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419)
	at
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257)
	at
javax.swing.AbstractButton.doClick(AbstractButton.java:289)
	at
javax.swing.AbstractButton.doClick(AbstractButton.java:269)
	at
javax.swing.plaf.basic.BasicMenuItemUI$ClickAction.actionPerformed(BasicMenuItemUI.java:1052)
	at
javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1502)
	at
javax.swing.JComponent.processKeyBinding(JComponent.java:2422)
	at
javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:658)
	at
javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:666)
	at
javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:666)
	at javax.swing.JMenuBar.processKeyBinding(JMenuBar.java:642)
	at
javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:253)
	at
javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:240)
	at
javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2499)
	at
javax.swing.JComponent.processKeyBindings(JComponent.java:2491)
	at
javax.swing.JComponent.processKeyEvent(JComponent.java:2385)
	at java.awt.Component.processEvent(Component.java:4830)
	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.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1700)
	at
java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:568)
	at
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:739)
	at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:673)
	at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:534)
	at java.awt.Component.dispatchEventImpl(Component.java:3396)
	at java.awt.Container.dispatchEventImpl(Container.java:1437)
	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.pumpOneEventForHierarchy(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)


The problem, I believe, is that the File needs to be
made absolute. I'll make DefaultGlobalModel convert the
file to absolute form before proceeding on an open
operation.

I'll make a test case for this before fixing it.

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

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

Re: [DrJava] Committed version; ready for release?

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

I'm going to have to recommend putting out the release before the 
debugger stuff gets in.  There's no reason to put in the extra code if 
it won't get used, and there's enough issues with it that I don't feel 
comfortable having it in this release.

I think we have enough to go on, though.  The new indent system, new 
config framework, and lots of little bug fixes and feature requests 
(like opening files from the command line) already make it a better program.

If you want to wait for line numbering, I'm working with Jim on it 
tomorrow at 1:00, and expect to have it finished that afternoon.  I 
don't mind waiting for the next release, though, which will also include 
a usable debugger (and whatever else is ready).

Charlie


Christian Anderson Westbrook wrote:
> While I wouldn't want to commit to this without discussing it with the
> rest of the group, I might suggest that we could have the advanced mode
> (jswat console) or even a preliminary GUI in for the debugger by the end
> of the week.
> 
> We had talked about only displaying the debug menu if the jswat jar were
> present, and even then perhaps adding the configuration flag for it to
> ensure it doesn't pop up to random users.
> 
> Then again, since this doesn't affect random users, I guess it doesn't
> really matter whether or not its in the actual release...
> 
> Cw
> 

Re: [DrJava] Committed version; ready for release?

[Christian A. W. <cw...@ow...>]

While I wouldn't want to commit to this without discussing it with the
rest of the group, I might suggest that we could have the advanced mode
(jswat console) or even a preliminary GUI in for the debugger by the end
of the week.

We had talked about only displaying the debug menu if the jswat jar were
present, and even then perhaps adding the configuration flag for it to
ensure it doesn't pop up to random users.

Then again, since this doesn't affect random users, I guess it doesn't
really matter whether or not its in the actual release...

Cw

On Thu, 11 Apr 2002, Brian Stoler wrote:

> With this out of the way, does anyone know of any impediments to doing a
> release soon? If the line enumeration is going to be stable soon enough,
> we can wait for that. Anything else?
>
> -brian

[DrJava] Committed version; ready for release?

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

I just tested that the new configuration framework preserves the ability
to let the user pick a compiler at startup if none is found. It works
fine, but there was a problem that caused the UI to not be correctly
updated with the list of compilers. (This was caused by reordering the
construction of MainFrame in DrJava.java, which I fixed and put in a
comment explaining.) I committed these changes.

With this out of the way, does anyone know of any impediments to doing a
release soon? If the line enumeration is going to be stable soon enough,
we can wait for that. Anything else?

-brian

[DrJava] I'm a liar.

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

If you run an update, you may notice--- no line numbers.

This time, the fix introduced an even worse bug than just all over the 
place reporting of line number.    Starting a new document and typing into 
it completely breaks DrJava!  Completely.  That's just a *little* nasty.

There is some subtle stuff I'm missing still, so it's back to the coal 
mines to try to pull out this gem over the next couple of days.  But, as 
always it seems, be on the lookout for it.

Jim

[DrJava] [ drjava-Bugs-542221 ] Column fails to update on switching of active document.

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

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

Category: User interface
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 3
Submitted By: Jim Van Fleet (bigfleet)
Assigned to: Jim Van Fleet (bigfleet)
Summary: Column fails to update on switching of active document.

Initial Comment:
The title says it all.  The cursor appears in one positions, but it must be reporting that it's in another somehow.  I'll take a look under the hood at the column code and see if I can get a handle on what's going on here.  I consider this a low priority, as any cursor movement or mouse click corrects the display, and the line number reporting is accurate in all circumstances.

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

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

[DrJava] Line enumeration is back.

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

And better than ever.

We've added some caching information (position, line number, previous
newline, and next newline) to DefinitionsDocument, and we're guaranteed
never to do more work than we have to.  If it's cheaper to calculate the
documents position from "scratch" i.e. the top of the document, then it
does that.  Otherwise, it calculates how much earlier or later in the
document the current location is than the cached location, and merges it
with the cached line number.  It's pretty slick;  I've never written
anything quite like it.

There's still an outstanding issue concerning switching documents, you can
read the feature request if you're interested.  But check out the code,
laddies, you can see the line numbers!  (I even threw in some spacing in
the status bar display, so the Mac OS X users can see it.  ;-)

Jim

[DrJava] [ drjava-Feature Requests-540323 ] Make capitalized tokens hypertext links

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

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

Category: User interface
Group: Unknown size
Status: Open
Priority: 3
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make capitalized tokens hypertext links

Initial Comment:
A long-range goal could be to make capitalized  
tokens into hypertext links to other source files (or 
perhaps doc comment files for the library classes). 
Resolving the appropriate source file for a token 
could be done whenever the user modifies that token. 
If the source file can't be resolved, the token could 
be colored differently.

Because this strategy works without contextual 
analysis (well, except for keeping track of the 
import and package statements), it should be easy to 
use it for the various tabbed panes. Hypertext links 
would be especially useful with the compiler and 
testing errors.

We could even include "back" and "forward" buttons in 
the toolbar, but I don't want to get too far ahead of 
things yet.

Story: The user clicks on a capitalized token 
referring to a resolvable class. The corresponding 
source file (or the hypertext doc comment file for a 
library class) is brought into the definitions pane.
The user clicks on a link in the newly opened 
document to bring that file into the definitions pane.

The user then modifies a capitalized token so that it 
no longer refers to a valid class. The token is 
immediately colored differently, to alert the user. 
The user tries to click on the modified token, but 
nothing happens.

-- Eric


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

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

[DrJava] [ drjava-Feature Requests-540319 ] Color capitalized tokens

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

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

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 2
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Color capitalized tokens

Initial Comment:
It would be nice to color types differently than 
other tokens. One way to approximately this very 
closely (with zero contextual analysis) would be to 
just color all capitalized tokens. In fact, this 
strategy has the advantage of alerting users when 
they mistakenly capitalize a token.

Story: The user types in a token starting with a 
capitalized letter. As soon as the first letter is 
capitalized, the token is colored differently. As 
soon as the token no longer has a capital letter in 
front, the token color reverts to black.

-- Eric




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

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

[DrJava] [ drjava-Feature Requests-540293 ] Modify compiler errors interface

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

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

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 3
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Modify compiler errors interface

Initial Comment:
The ScrollPane interface to the compiler errors is 
slow and a bit awkward. There's never any need in 
scrolling half way between two errors. Perhaps a 
cleaner interface would be up and down arrow buttons 
(with their own keyboard shortcuts) that allow for 
atomic scrolling between errors.

Story: The user compiles a program with errors. The 
compiler errors tabbed pane pops up and displays the 
first of these errors. A count of the total number of 
errors appears off to the side. The user fixes this 
error and then quickly pops to the next by clicking 
on the down arrow button in the compiler errors 
tabbed pane. He then clicks on the up arrow button, 
and the first error reappears, with the fixed text 
highlighted. He clicks the up and down arrow buttons 
repeatedly, scrolling through and fixing the compiler 
errors in the program.

The user then learns the keyboard shortcuts and 
quickly pops from error to error without switching 
focus from the definitions pane.

-- Eric


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

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

[DrJava] [ drjava-Bugs-539571 ] Unsaved files highlighted with errors

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

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

Category: Compiler integration
Group: Ugly
Status: Open
Resolution: None
Priority: 7
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unsaved files highlighted with errors

Initial Comment:
Although it's impossible to compile without saving 
the currently open file, it's not necessary to save 
all the other files. This is actually a bug, because 
the compiler error highlighter will then highlight 
regions in the unsaved file. We need to either (1) 
ensure all files are saved before compiling, or (2) 
revert buffers when popping up compiler errors. I 
think that (1) is much simpler and less dangerous for 
the user.

-- Eric


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

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

Re: [DrJava] Line Enumeration

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

Finally...  After two more tries (one of them hanging on NewJVMTest), my 
earlier changes are in.  As I said, I'll look at the underlying logic 
more after dinner to see if I can figure out what's going wrong.

Charlie


Eric E. Allen wrote:
> Hi Charlie,
> 
> I'm having trouble committing too! NewJVMTest is hanging again...
> 
> Anyway, I filed a bug report with my discoveries so far. Let's post all
> new discoveries to the bug report; interested parties can monitor it.
> 
> -- Eric
> 
> 
> 
> On Thu, 4 Apr 2002, Charles Reis wrote:
> 
> 
>>Argh!  I've made some changes to line numbering, but I'm having trouble
>>committing them at the moment (memory problems, editor issues).  I'm
>>already late to practice, so I need to run.  I'll get them checked in
>>once I get back...
>>
>>
>>Here's the email I was going to send out:
>>
>>   I've started making some updates to the line numbering code, but
>>mainly just in the UI for now-- I haven't gotten much into the code in
>>DefDoc yet.  The creation and management of the field and listener is a
>>little cleaner now, but it still doesn't work correctly, so I've
>>commented out the code that displays it on the most recent commit.
>>
>>To test the line numbering stuff, there's three lines you need to
>>uncomment, all in MainFrame.  One is in the constructor, where it
>>instantiates PositionListener.  The other two are in
>>_createDefScrollPane, where it adds the caret listener and updates the
>>display.
>>
>>   I'm off to practice now, but I'll look more at the inner workings
>>when I get back.
>>
>>Charlie
>>
>>
>>_______________________________________________
>>drjava-hackers mailing list
>>drj...@li...
>>https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>>
> 
> 
> 
> .
> 

Re: [DrJava] Line Enumeration

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

Hi Charlie,

I'm having trouble committing too! NewJVMTest is hanging again...

Anyway, I filed a bug report with my discoveries so far. Let's post all
new discoveries to the bug report; interested parties can monitor it.

-- Eric



On Thu, 4 Apr 2002, Charles Reis wrote:

> Argh!  I've made some changes to line numbering, but I'm having trouble
> committing them at the moment (memory problems, editor issues).  I'm
> already late to practice, so I need to run.  I'll get them checked in
> once I get back...
>
>
> Here's the email I was going to send out:
>
>    I've started making some updates to the line numbering code, but
> mainly just in the UI for now-- I haven't gotten much into the code in
> DefDoc yet.  The creation and management of the field and listener is a
> little cleaner now, but it still doesn't work correctly, so I've
> commented out the code that displays it on the most recent commit.
>
> To test the line numbering stuff, there's three lines you need to
> uncomment, all in MainFrame.  One is in the constructor, where it
> instantiates PositionListener.  The other two are in
> _createDefScrollPane, where it adds the caret listener and updates the
> display.
>
>    I'm off to practice now, but I'll look more at the inner workings
> when I get back.
>
> Charlie
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

Re: [DrJava] Line Enumeration

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

Argh!  I've made some changes to line numbering, but I'm having trouble 
committing them at the moment (memory problems, editor issues).  I'm 
already late to practice, so I need to run.  I'll get them checked in 
once I get back...


Here's the email I was going to send out:

   I've started making some updates to the line numbering code, but 
mainly just in the UI for now-- I haven't gotten much into the code in 
DefDoc yet.  The creation and management of the field and listener is a 
little cleaner now, but it still doesn't work correctly, so I've 
commented out the code that displays it on the most recent commit.

To test the line numbering stuff, there's three lines you need to 
uncomment, all in MainFrame.  One is in the constructor, where it 
instantiates PositionListener.  The other two are in 
_createDefScrollPane, where it adds the caret listener and updates the 
display.

   I'm off to practice now, but I'll look more at the inner workings 
when I get back.

Charlie

[DrJava] [ drjava-Bugs-539435 ] Inaccurate reporting of line and column

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

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

Category: Definitions (source editor)
Group: Annoying
Status: Open
Resolution: None
Priority: 8
Submitted By: Eric E. Allen (eallen)
Assigned to: Jim Van Fleet (bigfleet)
Summary: Inaccurate reporting of line and column

Initial Comment:
This bug applies only to the (thus far) unreleased 
drjava20020404-* and up.

I spent some time looking at, and playing with, the 
new line number code. It's pretty clear that the 
problem is what I call a Liar View: the model seems 
to be correct, but the view isn't displaying it 
properly. In particular, when moving the caret with 
the arrow keys, the line reporting is consistently 
reporting the position_before_ the last line change. 
Also, the current column is reported as 1 at every 
key movement after the first (yet test cases on the 
model side show that the current column is computed 
properly).

Here is my hypothesis: 

The listener for updating the position display is 
registered with the DefinitionsPane. Perhaps the 
DefinitionsPane is notifying the listener of a 
mouse/key movement before the model is updated? This 
would at least explain the lag in the update of line 
positions. The other problems are potentially due to 
race conditions between the model and the listener.

I think that what we really want is for the listener 
to be notified by the GlobalModel directly. But, 
currently, there is no method for notifying 
GlobalModelListeners of position changes (and I'm not 
sure that we really want to notify all listeners of 
every position change).

Unfortunately, I don't have any more time to help 
with this right now. But I suggest commenting out the 
line that sets the text in MainFrame.PositionField 
until this problem is fixed.

BTW, even if the listener is notified by 
DefinitionsPane, shouldn't it be a CaretListener 
instead of a Key- and MouseListener? However, I made 
that change on my copy and it had no effect on the 
problem.

-- Eric




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

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

[DrJava] a clarification

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

To all DrJava hackers:

We fully understand that we are asking a lot from you. On the one hand, we
ask you to continuously integrate your code with the repository. On the
other hand, we ask that you interleave writing your code with writing
tests over it, and to never commit code until all of your tests pass.

Satisfying these two requirements is _hard_. It requires a lot of thinking
about the problem, and, in many cases, it requires you to write the code
in a very different way than you would otherwise. Sometimes, you may not
succeed in fully satisfying the requirements. As long as you are trying
your best, that's okay; the purpose of this course is to give you
experience with programming in this fashion. But when you must err, err on
the side of less frequent commits. As always, we are much more concerned
with soundness than completeness.

-- Eric

Re: [DrJava] Line numbers committed.

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

Hi Jim,

I appreciate your work on this problem, and I don't want to single your
team out, but _please_ don't commit buggy code intentionally. If you're
having problems working with existing code, ask one of the project
managers to pair program with you to fix the problem. We'd like to
maintain the invariant that we can form a release out of any committed
copy of the code. I am cc'ing drjava-hackers so that other teams
understand this point as well.

BTW, where are the unit tests for the new code located?

Thanks,

-- Eric



On Wed, 3 Apr 2002, Jim Van Fleet wrote:

> The mist cleared, the debugger group needed a certain implementation, and
> lo, it became.
>
> getCurrentLine() and getCurrentCol() have been added to
> DefinitionsDocument, and a PositionField inner class has been created in
> MainFrame to store the results of calls to those methods.
>
> Right now, the results are EXTREMELY buggy.  Many times, DrJ seems to
> assume that you're on the first column in a line until you type a
> character or delete one.
>
> But something is there, and I'll be ironing out the bugs in the underlying
> calls before the end of the week.  I'd also be interested in finding out
> whether the resize block covers up the numbers on other platforms besides
> Mac OS X (what I'm running.)
>
> Let me know, group!
>
> Jim
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] Line Enumeration

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

What a long, strange trip it's been.  After Charlie helped pull my head out 
of my rear, I got *an* implementation of getting a line number and column 
number out of a DefinitionsDocument fairly quickly.

I finished up some work that Erik and I were doing, and committed some code 
this afternoon that adds a DrScheme like listing of the line number and 
column number.

Apparently, the underlying calls are still very buggy.  Column is just all 
messed up, which means I will probably not rely on the helper methods 
already present to determine that info.

The line number, however, only seems to be wrong when using the up and down 
arrow keys, sometimes by as many as 20 lines on large files.

It would be easy to keep this out of a release, but if any of you have 
fifteen spare minutes, check out the code and see what I'm doing wrong.  I 
know you've wanted this feature in there, and we're very close.

Thanks all!

Jim

[DrJava] Line numbers committed.

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

The mist cleared, the debugger group needed a certain implementation, and
lo, it became.

getCurrentLine() and getCurrentCol() have been added to
DefinitionsDocument, and a PositionField inner class has been created in
MainFrame to store the results of calls to those methods.

Right now, the results are EXTREMELY buggy.  Many times, DrJ seems to
assume that you're on the first column in a line until you type a
character or delete one.

But something is there, and I'll be ironing out the bugs in the underlying
calls before the end of the week.  I'd also be interested in finding out
whether the resize block covers up the numbers on other platforms besides
Mac OS X (what I'm running.)

Let me know, group!

Jim