drjava-hackers — DrJava developers mailing list

[DrJava] the cool stuff you can do in the interactions pane

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

feature tip of the day #1: did you know you can make anonymous inner class
instances in the repl?

> final JFrame copy = frame;

[...]

> ActionListener listener = new ActionListener() { public void
actionPerformed(ActionEvent ae) { copy.hide(); } };
> button.addActionListener(listener);

related tip #2: In said anonymous inner class instances, you can reference
final variables that are declared at top-level in the interactions pane.

Pretty cool.

-brian

Re: [DrJava] (debugger)

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

JBuilder Professional allows you to create standing expressions that are
evaluated at every breakpoint (I'm not sure about the free version). This
is sloppy and stupid, because many of those expressions will be
non-sensical inside most scopes! In those cases, JBuilder just says the
expressions are undefined. Also, it's cumbersome to add in new
expressions. They are dancing around the right answer, which is clear to
us because we have a repl built into the IDE.

-- Eric



On Tue, 26 Feb 2002, Brian Stoler wrote:

> If we can integrate a debugger, and then if we can make it so that you can
> pop to the REPL at a breakpoint (in the scope you stopped in), we will
> rule the world.
>
> Imagine that: The ability to stop the program during execution and then to
> be able to enter arbitrary statements/expressions! I don't think any
> mainstream language has a debugger with such support. (I think some allow
> interpretation of expressions w/o side effects.)
>
> -brian
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] (debugger)

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

If we can integrate a debugger, and then if we can make it so that you can
pop to the REPL at a breakpoint (in the scope you stopped in), we will
rule the world.

Imagine that: The ability to stop the program during execution and then to
be able to enter arbitrary statements/expressions! I don't think any
mainstream language has a debugger with such support. (I think some allow
interpretation of expressions w/o side effects.)

-brian

[DrJava] DrJava for software developers? forwarded message from Arnaud Lucas (perso)

[Corky C. <co...@ri...>]

The following inquiry was posted to the HJUG (Houston Java Users
Group) mailing list.  The poster is a developer but sounds like a
potential DrJava user once we have added the debugger.  I wonder if
his viewpoint is shared by a significant fraction of Java developers.

-- Corky

[DrJava] DrJava activity, and new MacOS JVM

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

It's the Java 1.3.1 Update 1. You need 10.1.3.

http://kbase.info.apple.com/cgi-bin/WebObjects/kbase.woa/5/wa/query?type=id&val=122000

Also, Eric says:

BTW, do you realize we are the 44th most active project on SourceForge
right now? Jedit is the 33rd.

If we can push into the top 20, we'll be on the front page of SourceForge.
That should definitely up our user base.

-- Eric

[DrJava] [ drjava-Feature Requests-522975 ] Clean up toolbar/menus

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

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

Category: User interface
Group: None
Status: Open
Priority: 9
Submitted By: Brian Stoler (brianstoler)
Assigned to: Charles Reis (csreis)
Summary: Clean up toolbar/menus

Initial Comment:
We've added lots of cool functionality, but the UI is a
bit bloated and disorganized. Here are the changes I
propose (feel free to follow up with modifications):

* Remove "Save all" from toolbar.
* Put clipboard toolbar items before undo/redo
* Remove "close" toolbar item. I think it's too easy to
hit accidently and not needed often enough. (debate?)
* Get rid of next/prev document toolbar buttons/

File menu:
New
Open...
-------------
Save
Save as...
Save all
-------------
Close
Close all
-------------
Page setup...
Print preview...
Print...
-------------
Quit

Edit menu:
Undo
Redo
-------------
Cut
Copy
Paste
-------------
Find/replace...
Goto line...

Actions menu (not sure of proper order here, or name of
the menu):

Compile
-------------
Abort interaction
Reset interactions
Clear console
-------------
Previous document
Next document

Then, of course, Help..About.

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

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

Re: [DrJava] Menu / Toolbar organization

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

Also: "Edit" needs to be reorganized and some of its contents split off
into another menu. I'm not sure what exactly to put there or what to call
it, though.

-brian

[DrJava] Menu / Toolbar organization

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

   I definitely like the new features that are being added to the menus 
and toolbar, but it's starting to get a bit cluttered.  First, going 
back to an earlier discussion, I can see the argument for removing the 
toolbar buttons for prev and next document.  (I still think we should 
keep the menu items so people can learn the keyboard shortcut, at least 
for now.)
   I'm not sure that Save All belongs on the toolbar.  It's a useful 
action, but I think it's probably used rarely enough that it can reside 
just in the File menu.  That cuts the first section of buttons down to 
New, Open, Save, and Close, which is fairly intuitive.
   As far as the File menu itself goes, I'd expect all the Save commands 
to be together and then all the Close commands to be together.  How 
about: New, Open, Save, Save As, Save All, Close, Close All?  (Keeping 
the other stuff at the bottom the same...)

   Any thoughts on this?  Usability input is welcome...

Charlie

[DrJava] Printing now available

[Alan M. <ami...@ri...>]

The latest code up on SourceForge contains printing/print previewing =
support for DrJava.  Please update your code and tell me of any problems =
you have.

Thanks,
Alan

P.S. - The classpath is the root of all evil.

[DrJava] [ drjava-Feature Requests-522803 ] Close and Close All Icons

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

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

Category: User interface
Group: None
Status: Open
Priority: 5
Submitted By: Alan Mislove (amislove)
Assigned to: Alan Mislove (amislove)
Summary: Close and Close All Icons

Initial Comment:
We should add icons for Close and Close All actions.

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

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

[DrJava] [ drjava-Bugs-522691 ] DrJava window starts partly off screen

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

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

Category: User interface
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Garvin (johngarvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: DrJava window starts partly off screen

Initial Comment:
On startup, the DrJava window starts up with the title
bar off the top border of the screen.  I've confirmed
this on Mac OS X, Windows XP, Solaris, and Linux.

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

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

[DrJava] [ drjava-Bugs-522331 ] Massive memory leakage (fwd)

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

Thought you might find this interesting. (The problem was entirely my
fault, of course.)

---------- Forwarded message ----------
Date: Mon, 25 Feb 2002 08:32:50 -0800
From: no...@so...
To: no...@so...
Subject: [ drjava-Bugs-522331 ] Massive memory leakage

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

Category: Performance
Group: Serious
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Massive memory leakage

Initial Comment:
I think DrJava is leaking memory. I just started
getting some OutOfMemoryErrors when compiling something
in a long-running DrJava process. That process was
using 105 MB of memory.

I then started a new DrJava process, and it's using
32MB of RAM.

(Note that all of this only is concerning the main JVM;
the interactions JVM is a whole other game.)

I think it's leaking memory. Let's see how process RAM
use changes as I compile, to see if that's what is
leaking memory:

OK, loaded one file, and memory use went up less than a
megabyte.

Now I compiled it once, and memory use went up to 48MB.

Compiled the same file again, and memory use is now 52MB.

Further compiles of the same file: 55, 58, 61, 64, 66,
70, 73, 76, 80, 84, 87, 89, 92, 96, 99, 100, 103, 106,
108, and the next one causes an OutOfMemoryError.

I think this is a memory leak cause by compiling. :)

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

>Comment By: Brian Stoler (brianstoler)
Date: 2002-02-25 08:32

Message:
Logged In: YES
user_id=343403

Fix committed in drjava-20020225-1623.

On my last "ant commit", the java process never used more
than 95MB of RAM. While that's a lot, the commit process
does a LOT, all inside on JVM, and it doesn't necessarily
try to hard to clean up garbage. So I think it's a lot
better. :)

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

Comment By: Brian Stoler (brianstoler)
Date: 2002-02-25 08:22

Message:
Logged In: YES
user_id=343403

OK, with this fix, I just ran 50 straight compiles on
jdk1.4, and the memory use of the drjava process on my
machine reached and then stayed fixed at 60MB. I call this
bug fixed.

Note that this bug demonstrates the perils of designing code
that expects one runtime environment and then using it in
another. The compiler was not designed to be run over and
over again in the same JVM, and so it leaks memory like
crazy (I presume via some statics). In this case, the way
around it is to always load the compiler via a custom
classloader.

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

Comment By: Brian Stoler (brianstoler)
Date: 2002-02-25 07:59

Message:
Logged In: YES
user_id=343403

Just made standard javac go through a proxy, and here are
the results:

1803k / 3588k
2172k / 5693k
4601k / 8990k
2455k / 10027k
8450k / 15245k
3864k / 15245k
9434k / 15245k
5537k / 15507k
9295k / 16646k
5255k / 16646k
8793k / 16646k
1754k / 16646k
1754k / 11964k
1754k / 6438k

I think this solved the problem. :) Now I just need to make
GJv6 use a proxy (not that anyone uses GJ).

I think this fix should speed up the test cases that use
compilation and also keep them from using so much memory
(which required -Xmx256M before!).

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

Comment By: Brian Stoler (brianstoler)
Date: 2002-02-25 07:49

Message:
Logged In: YES
user_id=343403

I think that second part of my last comment is actually
wrong. I instrumented DrJava.java with a thread to print the
heap usage every 10 seconds (and call System.gc too), and it
appears that, although memory use can grow with each
compile, it's not permanent. Here are some (used / total)
measurements of the Java heap over time (duplicates deleted)
when I compiled over and over again using JSR-14 (user):

1779k / 5746k
2115k / 8941k
1761k / 8699k
5008k / 8998k
2777k / 9502k
5324k / 10448k
4910k / 13103k
2327k / 10964k
1744k / 6402k
5679k / 10141k
4820k / 13160k
8433k / 14716k
9285k / 16613k
16302k / 16613k
8033k / 16613k
1752k / 15654k
1753k / 11935k
1753k / 6418k


I attribute the weird, wild fluctuations to the vaguaries of
GC. (This was on Linux/Sun-1.4final.) Also, after like 30
compiles, the memory image of the process seemed fixed at 50 MB.

Now let's try the same test using javac (no proxy):

1748k / 3706k
5792k / 10055k
18204k / 32411k
32490k / 57712k
48988k / 66650k
57293k / 66650k

(I loaded a file and then hit F5 in rapid succession.)

Oh my, this is the problem! So we need to make the standard
javac compiler option use a proxy, so that the compiler
classes can be fully unloaded/reloaded.



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

Comment By: Brian Stoler (brianstoler)
Date: 2002-02-25 07:17

Message:
Logged In: YES
user_id=343403

OK, done some more testing. First, this general trend is
reproducable on my Linux machine on both sun-1.4 and ibm-1.3.

Now. My first guess was that this would only show up when I
compiled using a CompilerProxy extension, so I tried
compiling with vanilla javac-from-classpath; but the same
problem persisted.

Then I thought that, if I made sure that the CompilerProxy
threw away its classloader after each compile, I could
ensure the compiler classes would be unloaded and thus all
resources would for sure be cleaned up. So I changed
CompilerProxy to re-create the classloader on every compile,
and it does definately allow the compiler classes to be
unloaded (as seen via java -verbose) -- but the memory use
still keeps growing, although possibly at a slower rate.

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

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

[DrJava] [ drjava-Bugs-522331 ] Massive memory leakage

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

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

Category: Performance
Group: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Massive memory leakage

Initial Comment:
I think DrJava is leaking memory. I just started
getting some OutOfMemoryErrors when compiling something
in a long-running DrJava process. That process was
using 105 MB of memory.

I then started a new DrJava process, and it's using
32MB of RAM.

(Note that all of this only is concerning the main JVM;
the interactions JVM is a whole other game.)

I think it's leaking memory. Let's see how process RAM
use changes as I compile, to see if that's what is
leaking memory:

OK, loaded one file, and memory use went up less than a
megabyte.

Now I compiled it once, and memory use went up to 48MB.

Compiled the same file again, and memory use is now 52MB.

Further compiles of the same file: 55, 58, 61, 64, 66,
70, 73, 76, 80, 84, 87, 89, 92, 96, 99, 100, 103, 106,
108, and the next one causes an OutOfMemoryError.

I think this is a memory leak cause by compiling. :)

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

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

[DrJava] [ drjava-Feature Requests-522213 ] Don't store duplicate entries to history

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

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

Category: Interactions
Group: None
Status: Open
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Don't store duplicate entries to history

Initial Comment:
Don't add an entry to the history if it is exactly the
same as the entry at the end of the history already.

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

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

Re: [DrJava] I don't read French ...

[Christian W. <cw...@ri...>]

> ... but I found interesting the class notes from the intro Java class at
> the University of Nice, where they're using DrJava:
> 
> http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/lecture/mp1_java2002/MP1Feuille_01.pdf
 

I do.  The third paragraph, wherein DrJ is mentioned, is roughly to the 
effect of...,

"DrJava is--like RealJ--a programming environment (in English, IDE, or 
Integrated Development Environment).  It allows you to program in Java 
freely and in a very simple manner.  We refer you now to the document 
concerning DrJava that has also been given to you.  It will acquaint you 
with the IDE."

And yes, I'd expect they'd be glad to help us translate.

Cw

[DrJava] I don't read French ...

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

... but I found interesting the class notes from the intro Java class at
the University of Nice, where they're using DrJava:

http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/lecture/mp1_java2002/MP1Feuille_01.pdf

Perhaps at some point we should internationalize DrJava? I bet these guys
would be happy to translate the text for us.

-brian

[DrJava] [ drjava-Feature Requests-522127 ] Nicer key bindings in interactions

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

Feature Requests item #522127, was opened at 2002-02-24 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=522127&group_id=44253

Category: Interactions
Group: None
Status: Open
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Nicer key bindings in interactions

Initial Comment:
1) Escape key should clear text of the current interaction.

2) Home key should go to the frozen point, not to the 
beginning of the current line.

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

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

[DrJava] [ drjava-Bugs-522123 ] Blank lines are saved to history

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

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

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Blank lines are saved to history

Initial Comment:
If you enter a blank line in interactions (as of
20020220-2337), it's saved to the history. This is
really annoying.

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

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

[DrJava] [ drjava-Feature Requests-521619 ] add SaveAll to file menu

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

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

Category: Definitions (source editor)
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: add SaveAll to file menu

Initial Comment:
It would be nice to have a single menu item that
allowed you to save all open files.

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

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

[DrJava] web page

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

Anyone interested in doing some work on the DrJava web page? I'd like to
have something better by next Wednesday. I can do it myself, but I'm no
great designer. (I've also got a bunch o' crap to do. :))

If you're interested, please e-mail me.

-brian

[DrJava] RE: Having problem compiling (fwd)

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

FYI: Expect that we're going to get a new flood of users of DrJava, since
I submitted DrJava to freshmeat.net. :)

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

---------- Forwarded message ----------
Date: Fri, 22 Feb 2002 10:44:37 -0500
From: Saeid Banaei <sb...@co...>
To: Brian Stoler <bs...@bs...>
Subject: RE: Having problem compiling

Brian,

Thanks for getting back to me so quickly, You are right, I am running NT 4.0
server, and I learned about DrJava from www.freshmeat.net website.

Thanks again,
Sam

-----Original Message-----
From: Brian Stoler [mailto:bs...@bs...]
Sent: Friday, February 22, 2002 10:34 AM
To: Saeid Banaei
Cc: ja...@ri...
Subject: Re: Having problem compiling


First, let me say that we're trying to move everything to SourceForge, so
in the future, please file support requests at
http://sourceforge.net/tracker/?group_id=44253&atid=438936

(We have not publicized this yet, however. :))

On your problem: I bet you're running some flavor of Windows. Due to the
way the JDK is installed on Windows (it puts an extra copy of java.exe in
the JRE directory), you probably need to tell DrJava where your
compiler is. (It's in a jar called tools.jar.)

See:
http://sourceforge.net/docman/display_doc.php?docid=9158&group_id=44253

for details on how to configure DrJava.

This configuration framework is temporary, and we will have a more
user-friendly one in the next few months.

We're glad you like DrJava, and please feel free to contact us again if
you have any problems or questions.

-brian

PS: Another answer to this problem is to change the association for .jar
files to point to the copy of javaw.exe inside the JDK directory
structure, as opposed to the JRE structure.

PS2: Just curious, where did you hear about DrJava?

Re: [DrJava] Time zone, etc

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

Have you ever successfully compiled DrJava? It sounds like you have a
class path problem...

-- Eric



On 21 Feb 2002, Gaurav Oberoi wrote:

> No dice.
>
> I did the compile as you suggested leaving me with one compiled class
> file: TstampGMT, in the appropriate place in 'built'.
>
> When I run 'ant compile' i get the same error message.
>
> Gaurav.
>
>
> On Thu, 2002-02-21 at 20:46, Charles Reis wrote:
> >    The problem isn't on an update of the code, but on a clean install.
> > If you've just checked out the code cleanly, you won't have TstampGMT
> > compiled, so you can't compile anything with Ant.  You have to pull off
> > this trick of compiling that one class to get anywhere...
> >
> >    Note that this isn't a problem if you say "ant clean compile" when
> > you already have the code, because the class is there when ant starts
> > and isn't deleted until the "clean" task runs.  But if you run "ant
> > clean" and then "ant compile", you're hosed.
> >
> >    Should we put some kind of conditional in the ant script to check for
> > the presence of the TstampGMT class and try to compile it on its own if
> > it doesn't exist?
> >
> > Charlie
> >
> >
> > Eric E. Allen wrote:
> > >>java -classpath $ANT_HOME/lib/ant.jar:$CLASSPATH -d ~/school/comp312/sf/built ant/TstampGMT.java
> > >>
> > >
> > > Here, you mean "javac", of course.
> > >
> > > FYI, I had no problems with this update, so I don't think anything is
> > > broken.
> > >
> > > -- Eric
> > >
> > >
> > >
> > > _______________________________________________
> > > drjava-hackers mailing list
> > > drj...@li...
> > > https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> > >
> > > .
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > drjava-hackers mailing list
> > drj...@li...
> > https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> >
>
>
>
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

Re: [DrJava] Time zone, etc

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

Just worked through that with Gaurav-- he was just having classpath 
issues.  Compiling the TstampGMT class on its own works, but we still 
need to figure out a good way to do that on a clean install.

Charlie

Gaurav Oberoi wrote:
> No dice. 
> 
> I did the compile as you suggested leaving me with one compiled class
> file: TstampGMT, in the appropriate place in 'built'.
> 
> When I run 'ant compile' i get the same error message.
> 
> Gaurav.
> 
> 
> On Thu, 2002-02-21 at 20:46, Charles Reis wrote:
> 
>>   The problem isn't on an update of the code, but on a clean install. 
>>If you've just checked out the code cleanly, you won't have TstampGMT 
>>compiled, so you can't compile anything with Ant.  You have to pull off 
>>this trick of compiling that one class to get anywhere...
>>
>>   Note that this isn't a problem if you say "ant clean compile" when 
>>you already have the code, because the class is there when ant starts 
>>and isn't deleted until the "clean" task runs.  But if you run "ant 
>>clean" and then "ant compile", you're hosed.
>>
>>   Should we put some kind of conditional in the ant script to check for 
>>the presence of the TstampGMT class and try to compile it on its own if 
>>it doesn't exist?
>>
>>Charlie
>>
>>
>>Eric E. Allen wrote:
>>
>>>>java -classpath $ANT_HOME/lib/ant.jar:$CLASSPATH -d ~/school/comp312/sf/built ant/TstampGMT.java
>>>>
>>>>
>>>Here, you mean "javac", of course.
>>>
>>>FYI, I had no problems with this update, so I don't think anything is
>>>broken.
>>>
>>>-- Eric
>>>
>>>
>>>
>>>_______________________________________________
>>>drjava-hackers mailing list
>>>drj...@li...
>>>https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>>>
>>>.
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>drjava-hackers mailing list
>>drj...@li...
>>https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>>
>>
> 
> 
> 
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> 
> .
> 
> 

Re: [DrJava] weird exceptions

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

It sounds like you might have an earlier version of drjava-- I think 
that might be a bug that has been fixed since then.  Try updating your 
source on Owlnet.  Also, you can run "ant jar" from within the 
src/edu/rice/cs/drjava directory and just copy over the jar file to save 
some time.  Let me know if that helps...

(I'm not sure on the rmic error, I'll check into that.)

Charlie


Christian Westbrook wrote:
> I'm trying to run DrJava on my redhat 7.2 box; I still can't get it to 
> compile (get: BUILD FAILED, ~/sf/src/edu/rice/cs/drjava/build.xml:61: 
> Couldn't guess rmic implementationcompile here.
> 
> But I compiled on Owlnet then downloaded the classes...only things don't 
> seem quite right.  When I open a file after DrJava starts, I get a 
> NullPointerException.  (trace below).  On the other hand, if I don't do 
> that, and go ahead and type out a basic class definition and save and 
> compile it, everythings fine.  But, doing something as simple as 
> changing the c in "class Foo {" to an uppercase C causes a 
> NullPointerException too (similar trace), even though the compiler error 
> comes up and DrJava even highlights everything correctly.
> 
> Are these NPEs normal and just to be disregarded, or is something funky 
> with my setup somehow?  I get similar behavior with both j2sdk1.4.0 and 
> jdk1.3.1_02
> 
> the exception:
> 
> java.lang.NullPointerException
>     at 
> javax.swing.AbstractButton$ButtonActionPropertyChangeListener.propertyChange(AbstractButton.java:1160) 
> 
>     at 
> edu.rice.cs.util.swing.DelegatingAction.setDelegatee(DelegatingAction.java:145) 
> 
>     at 
> edu.rice.cs.drjava.ui.MainFrame._switchDefScrollPane(MainFrame.java:946)
>     at edu.rice.cs.drjava.ui.MainFrame.access$2000(MainFrame.java:63)
>     at 
> edu.rice.cs.drjava.ui.MainFrame$ModelListener.activeDocumentChanged(MainFrame.java:1011) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel$1.notifyListener(SingleDisplayModel.java:461) 
> 
>     at 
> edu.rice.cs.drjava.model.DefaultGlobalModel.notifyListeners(DefaultGlobalModel.java:1213) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel._setActiveDoc(SingleDisplayModel.java:458) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel.access$300(SingleDisplayModel.java:90) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel$SelectionModelListener.valueChanged(SingleDisplayModel.java:482) 
> 
>     at 
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:187) 
> 
>     at 
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:167) 
> 
>     at 
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:214) 
> 
>     at 
> javax.swing.DefaultListSelectionModel.changeSelection(DefaultListSelectionModel.java:402) 
> 
>     at 
> javax.swing.DefaultListSelectionModel.changeSelection(DefaultListSelectionModel.java:411) 
> 
>     at 
> javax.swing.DefaultListSelectionModel.setSelectionInterval(DefaultListSelectionModel.java:435) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel.setActiveDocument(SingleDisplayModel.java:196) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel.setActiveDocument(SingleDisplayModel.java:180) 
> 
>     at 
> edu.rice.cs.drjava.ui.SingleDisplayModel.openFile(SingleDisplayModel.java:356) 
> 
>     at edu.rice.cs.drjava.ui.MainFrame._open(MainFrame.java:433)
>     at edu.rice.cs.drjava.ui.MainFrame.access$100(MainFrame.java:63)
>     at 
> edu.rice.cs.drjava.ui.MainFrame$4.actionPerformed(MainFrame.java:140)
>     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.plaf.basic.BasicButtonListener.mouseReleased(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.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)
> 
> 
> 
> ... Christian
> 
> 
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> 
> .
> 

[DrJava] [ drjava-Feature Requests-521298 ] Speed Issues under OS X

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

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

Category: Definitions (source editor)
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Speed Issues under OS X

Initial Comment:
The comments for this feature request are compiled from the mailing list:

Peter Centgraf says:

I know this may not be a popular suggestion, but could we make 
it a feature/improvement project to speed up the main editor?  
Right now speed is the primary reason why I cannot use Dr. Java 
for real programming.  According to several online tests, I type 
at approximately 60 wpm.  This is certainly not expert typing 
performance by clerical standards, but it is above average.  I 
believe it is reasonable to expect Dr. Java to be able to keep 
up with this rate of input.  Unfortunately, I can type "public 
static int" in less time than it takes Dr. Java to display 
"public static" with proper coloring.  This is simply 
unacceptable.  Keep in mind that this is running on a reasonably 
up to date 500 MHz machine with all Swing acceleration features 
turned on.

For comparison, I played with various other Java text 
environments.  The plain-vanilla text box in MRJAppBuilder had 
no trouble keeping up with me.  BlueJ will fall behind if I 
pound arbitrary characters, and it is clear that some lag is 
occurring, but I was not able to produce any "stutter" in my 
text input.  By the time I raised my finger from the last letter 
of a word, BlueJ had always rendered that word.  I also played 
with JBuilder 6.  It was even more responsive.  Even pounding 
random keys as fast as I could manage, JBuilder still produced 
virtually instant response.  Both of the last two examples 
perform fairly complex syntax coloring.  I think that if they 
can do this, we can too.


Later:

I attempted the performance workaround that Brian suggested in 
class.  I commented out the entire body of the 
DefinitionsDocument._styleChanged() method and then rebuilt with 
ant.  It is hard to tell if there is any real change in 
performance.  Using the same test as before, Dr. Java was able 
to update "public static int" fast enough to start drawing "int" 
by the time I stopped typing, but it was still several 
characters behind what I was currently typing.  If I wrote a 
larger block of text, like would happen in a comment block, 
sometimes entire words of 6-8 characters would lag and seem to 
appear all at once.  It feels subjectively like there was an 
improvement, but I might also be typing slightly slower than I 
was earlier today.  The window still seems to flicker while I 
type, but I think most of that effect is caused by the selection 
on the list of open documents.  I don't think this "fix" is a 
panacea for Dr. Java's performance problems on OS X.


From Brian Stoler:

Here's another speed experiment: Try commenting out the overridden
getViewFactory() in model/definitions/DefinitionsEditorKit. This will turn
off our colored display, but it will still leave the underlying model
implementation going. So, the model will be maintained, but not the color
information will be ignored for the UI.


From Charlie Reis:

   Wow-- I can confirm the need to work on speed on OS X.  As a CCA, I 
have one of the older iBooks (the ugly orange handbag-looking thing), 
with OS X 10.0.4 installed.  Granted, it's not the fastest machine, but 
I can get done typing an entire line before it has shown the first word.
   One thing worth noting is that the Interactions pane has acceptable 
performance (it's _much_ faster than the Definitions pane).  I haven't 
tried the suggested fix, but it's worth poking around to see what can be 
done...


And the latest installment:

Commenting out getViewFactory succeeds in disabling all drawing in the definitions pane whatsoever.  Now all I get is the OS X striped-background where the definitions should be.  I'll keep investigating this, however.  I agree that it would be very helpful if we can disable the style routines only and keep the reduced model running.

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

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