drjava-hackers Mailing List for DrJava (Page 75)

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
> 

   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
> 
> .
> 
> 

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

> 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

> /home/goberoi/school/comp312/sf/src/edu/rice/cs/util/build.xml:14:
> taskdef class edu.rice.cs.util.ant.TstampGMT cannot be found

I bet you followed steps out of order :)

Anyhow, to resolve this:

cd util
cvs update -d
java -classpath $ANT_HOME/lib/ant.jar:$CLASSPATH -d ~/school/comp312/sf/built ant/TstampGMT.java

That should do it.

-brian

I think this change broke something.

I'm in the process of setting up DrJava on my machine so that it builds.
After downloading the source (recent enough to include this update) and
installing all necessary programs, I ran "ant compile" in the 'util'
directory. It spat out the following error:

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

[goberoi@shiva util]$ ant compile
Buildfile: build.xml

BUILD FAILED

/home/goberoi/school/comp312/sf/src/edu/rice/cs/util/build.xml:14:
taskdef class edu.rice.cs.util.ant.TstampGMT cannot be found

Total time: 1 second

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

Any ideas?

Gaurav


On Thu, 2002-02-21 at 09:59, Brian Stoler wrote:
> OK, I figured out that the default ant Tstamp task does not commit to
> using any particular time zone. This is bad.
> 
> To get around this, I wrote my own time stamping task that always uses
> GMT. One consequence of this is that I had to update build-common.xml,
> which is not usually updated when you do "ant update". (But it changes
> infrequently enough that it's OK.)
> 
> So, you'll all need to do the following, in this order:
> 
> 1) cd util
> 2) ant update compile
> 3) cd ..
> 4) cvs update build-common.xml
> 5) cd drjava
> 6) ant update compile
> 
> That will do it. (Note that you need to update/compile util before
> updating build-common.xml, since build-common references the new task I
> created, which is in util!)
> 
> Anyhow, now DrJava version stamps will always be in GMT, no matter what
> machine it's set on.
> 
> -brian
> 
> 
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> 

OK, I figured out that the default ant Tstamp task does not commit to
using any particular time zone. This is bad.

To get around this, I wrote my own time stamping task that always uses
GMT. One consequence of this is that I had to update build-common.xml,
which is not usually updated when you do "ant update". (But it changes
infrequently enough that it's OK.)

So, you'll all need to do the following, in this order:

1) cd util
2) ant update compile
3) cd ..
4) cvs update build-common.xml
5) cd drjava
6) ant update compile

That will do it. (Note that you need to update/compile util before
updating build-common.xml, since build-common references the new task I
created, which is in util!)

Anyhow, now DrJava version stamps will always be in GMT, no matter what
machine it's set on.

-brian

OK ... you may have noticed the util package, which lives in edu.rice.cs.
This package was theoretically going to be better separated from DrJava,
to promote its use in other places. That hasn't happened well yet, and as
it's been, it has made life confusing.

I realized that the problem here is that there is no way to know when you
have to update the util package (most of you probably do, BTW). I've been
pondering ideas on this for a while, and I think I just found one: I made
a test case that checks whether the util package is current!

This test case is edu.rice.cs.drjava.DependenciesTest. It's use is simple:
If you change the util package, and want this change to propogate its way
into DrJava (you clearly do, or else you wouldn't have fixed it!), you
*must* change the REQUIRED_UTIL_VERSION field in DependenciesTest. This
will make sure that each person that checks out DrJava gets the newest
util package too.

I like this system because it will allow us to more fully decouple util in
the future, but it still allows automated checking that the dependency is
OK. We can also use this type of system for other dependencies at some
point (DynamicJava).

To see this change in action, check out the newest drjava code, then run
the test cases. You'll see DependenciesTest fail until you
update/compile the util package again.

This all came about during my struggle with/triumph over a horrible bug
that was totally my fault, #520519.

BTW, the util version is util-20020221-0455, and the new DrJava I just
released is drjava-20020220-2334.

OK, this is strange. The util package got a GMT time but drjava got a
local time. WTF? (There was a reboot in between the two; perhaps that was
it?) Doesn't matter really, though I guess we should theoretically try
hard to ensure we all use the same time zone? But Ant is magically
creating these time stamps ... . Another problem for another day.

-brian

   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...

Charlie


Peter Centgraf wrote:
> 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.
> 
> -- 
> Peter Centgraf
> Lovett College
> Rice University
> Houston, TX
> 
> 
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
> 
> .
> 

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

Category: User interface
Group: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Undo/Redo button text in JDK 1.3

Initial Comment:
Using drjava-20020219-2253 on any platform (Linux, 
Windows, OS X) in JDK 1.3, the Undo and Redo buttons 
in the toolbar contain text after a file is opened 
(probably when their state gets updated).  This 
should definitely not be there, since the text gets 
fairly long once you start typing (eg. "Undo 
addition").  My guess is that it has something to do 
with DelegatingAction (in edu.rice.cs.util.swing), 
and the fact that the name of the action gets updated 
dynamically.  Not sure, though...  Note that this 
isn't a problem in JDK 1.4.


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

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

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

Category: User interface
Group: None
Status: Open
Priority: 5
Submitted By: John Garvin (johngarvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: make Compile button semantics intuitive

Initial Comment:
I was going to submit this as a bug, but the code
actually follows the specification, so it's not
"really" a bug.  I just think the specification is
wrong.

You have to save before you can compile.  We know this,
but to a new user, this fact is hardly intuitive. 
There is no immediately obvious reason why the Compile
button is initially unavailable, and it's not at all
clear what has to be done to allow one to compile.

Possible solution: the Compile button should really be
a "Save and Compile" button, which will (a) decide if
saving is necessary, (b) if so, save the file, and (c)
compile.  If the current document is untitled, it
should pop up a "Save As..." dialog.  Right now,
there's no connection between the Save and Compile
actions, which is quite confusing.

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

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

> In the interactions window it would be great if we could have, by the
> right side, a toolbar with:
>   - a button to save the content of the interaction window
>   - a button to load a previously saved interaction sequence (...)
>   - a button to kill the last command (this is extremely useful when a
> student makes an endless loop... and believe me : they do ;) )
>   - a button to reset all interactions
>   - when ESC is pressed it would be great if the current line was
> emptied (eg. if you browse the history with up and down arrows you
> cannot escape it and go back to an empty line)

It wouldn't be too hard to add a toolbar there, and we've already got 
buttons for aborting and resetting the interactions.  Saving and loading 
would be nice-- I don't imagine it being too difficult, though we'd need 
a mechanism to feed the input into the pane.  Probably a good small 
feature project.


> For the top toolbar:
>   - the 'Compile' button could use an icon like others
>   - A run button (icon = gears) that launches the active file would be great

Already have the compile button.  Do we want a run command separate from 
the interactions?


> For the edition area:
>   - line numbers (they maybe useful for exceptions)
>   - selection on double clicks :  if I have in my code the text
> "my_variable.getValue()" and I double click on variable, the editor
> selects "variable.getValue" which is not the behavior I was expecting. I
> was expecting "my_variable" to be selected.

Line numbers are on their way (right Jim?).  And I agree with the double 
click selection-- I've run into that plenty of times.  Is there a way to 
set selection delimiters in a JEditorPane or an EditorKit?


> File Menu:
>   - at the end of this menu it would be nice to have the 4 last files opened

Another nifty feature for a small project...


> Detail: IMHO 'Previous document' and 'Next document' buttons or menu
> items are not very useful. They are redundant with the list of open
> files. Be careful not to add options that will make your interface too
> complex while not adding much usability.

The original reason for the menu items was to publicize the keyboard 
shortcuts (ctrl-, and ctrl-.).  By the way, I originally wanted to use 
something like ctrl-tab or ctrl-arrows, but these are caught by window 
managers or java and are used for other things.  I guess the 
configurability project can address this some...  Anyway, I think it's 
worth keeping the menu items for now, and definitely the toolbar buttons.

Charlie

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.

--
Peter Centgraf
Lovett College
Rice University
Houston, TX

FYI. We should go back over this list and consider them as bug/feature
requests.

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

---------- Forwarded message ----------
Date: Wed, 20 Feb 2002 19:56:13 +0100
From: - Fabien Gandon - <Fab...@so...>
To: Brian Stoler <bs...@bs...>
Cc: Jean-Paul Roy <Jea...@un...>
Subject: Return of experience on DrJava.

Hello,


     - First of all: DrJava IS A VERY GOOD TOOL ! -
                  - I like it ! -


Today I have submitted two bug reports on Source Forge. Moreover, after
a first practical session with my students I collected some ideas for
future improvements. They should be taken as humble suggestions or "nice
to have" and nothing else. ;)

In the interactions window it would be great if we could have, by the
right side, a toolbar with:
  - a button to save the content of the interaction window
  - a button to load a previously saved interaction sequence (...)
  - a button to kill the last command (this is extremely useful when a
student makes an endless loop... and believe me : they do ;) )
  - a button to reset all interactions
  - when ESC is pressed it would be great if the current line was
emptied (eg. if you browse the history with up and down arrows you
cannot escape it and go back to an empty line)

For the top toolbar:
  - the 'Compile' button could use an icon like others
  - A run button (icon = gears) that launches the active file would be great

For the edition area:
  - line numbers (they maybe useful for exceptions)
  - selection on double clicks :  if I have in my code the text
"my_variable.getValue()" and I double click on variable, the editor
selects "variable.getValue" which is not the behavior I was expecting. I
was expecting "my_variable" to be selected.

File Menu:
  - at the end of this menu it would be nice to have the 4 last files opened

Detail: IMHO 'Previous document' and 'Next document' buttons or menu
items are not very useful. They are redundant with the list of open
files. Be careful not to add options that will make your interface too
complex while not adding much usability.

Otherwise, I insist, this is good job.

Best regards,

CU

Fabien

-- 

  ____________
|__ _ |_  INRIA Nice Sophia Antipolis - Tel: (33)(0)4 92 38 77 88
|  (_||_) http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/

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.

--
Peter Centgraf
Lovett College
Rice University
Houston, TX

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

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incompatible Types Ignored.

Initial Comment:
Hi,

Still using my stupid class file:

class VehiculeRoutier
{
}

class Voiture extends VehiculeRoutier
{
}

class Monospace extends Voiture
{
}

class Berline extends Voiture
{
}

class Coupe extends Voiture
{
}

class Velo extends VehiculeRoutier
{
}

class VTT extends Velo
{
}


class Tandem extends Velo
{
}

class Bus extends VehiculeRoutier
{
}



In interactions if I do:

Welcome to DrJava.
> VehiculeRoutier V1= new Voiture();
> Voiture V2 = new VehiculeRoutier();
>

The first line is OK, but the second one should be
rejected for 'incompatible types'.
Did I miss something ?

Regards,

Fabien


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

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

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

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: instantiation problem

Initial Comment:
Hi,

I have a file VehiculeRoutier.java containing dummy
classes:

class VehiculeRoutier
{
}

class Voiture extends VehiculeRoutier
{
}

class Monospace extends Voiture
{
}

class Berline extends Voiture
{
}

class Coupe extends Voiture
{
}

class Velo extends VehiculeRoutier
{
}

class VTT extends Velo
{
}

class Tandem extends Velo
{
}

class Bus extends VehiculeRoutier
{
}



It compiles OK. But when I interact:

Welcome to DrJava.
> Voiture Laguna = new Berline();
> VehiculeRoutier mx5 = new Coupe();
java.lang.LinkageError: 
  at java.lang.ClassLoader.defineClass0(Native Method)
  at java.lang.ClassLoader.defineClass(Unknown Source)
  at java.lang.ClassLoader.defineClass(Unknown Source)
  at
edu.rice.cs.util.classloader.StickyClassLoader.loadClass(StickyClassLoader.java:197)
  at java.lang.ClassLoader.loadClass(Unknown Source) at
edu.rice.cs.drjava.model.repl.DynamicJavaAdapter$ClassLoaderExtension.loadClass(DynamicJavaAdapter.java:284)
  at java.lang.ClassLoader.loadClass(Unknown Source)
  at java.lang.ClassLoader.loadClassInternal(Unknown
Source)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Unknown Source)

If I do it the other way:
Welcome to DrJava.
> VehiculeRoutier mx5 = new Coupe();
> Voiture Laguna = new Berline();
java.lang.LinkageError: 
  at java.lang.ClassLoader.defineClass0(Native Method)
  at java.lang.ClassLoader.defineClass(Unknown Source)
  at java.lang.ClassLoader.defineClass(Unknown Source)
  at
edu.rice.cs.util.classloader.StickyClassLoader.loadClass(StickyClassLoader.java:197)
  at java.lang.ClassLoader.loadClass(Unknown Source) at
edu.rice.cs.drjava.model.repl.DynamicJavaAdapter$ClassLoaderExtension.loadClass(DynamicJavaAdapter.java:284)
  at java.lang.ClassLoader.loadClass(Unknown Source)
  at java.lang.ClassLoader.loadClassInternal(Unknown
Source)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Unknown Source)

So it looks like the second instantiation causes a
problem...

Have I made something wrong ?


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

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

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

Category: User interface
Group: Ugly
Status: Open
Resolution: None
Priority: 3
Submitted By: Theo Yaung (theoyaung)
Assigned to: Theo Yaung (theoyaung)
Summary: StatusBar NonIntuitive on MacOS-X

Initial Comment:
The status bar implemented as a JTextField does not
have an intuitive "non-editable" look on MacOS-X, even
if setEditable() is passed "false".

Fix: Use a JLabel (which is documented  as a prefered
means of displaying uneditable text).

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

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

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

Category: User interface
Group: None
Status: Open
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Add toolbar buttons for abort and reset

Initial Comment:
It's easy and there's space, so why not? :)

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

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

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

Category: Other
Group: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Stoler (brianstoler)
Assigned to: Brian Stoler (brianstoler)
Summary: Redundant enabling of menu/toolbar items

Initial Comment:
It's best to always enable actions by
Action.setEnabled, rather than JButton.setEnabled and
JMenuItem.setEnabled. Then you only need one call to
set all of them!

I'm going to clean this up.

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

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

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

Category: Other
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Theo Yaung (theoyaung)
Summary: Mac OS X Build Packaging

Initial Comment:
It would be nice to automatically build a Mac OS X application package via ant.  Ideally, it would be possible to build the package from any platform.

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

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

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

Category: Other
Group: None
Status: Open
Priority: 5
Submitted By: Jim Van Fleet (bigfleet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Favorite directories/files

Initial Comment:
Add in some notion of favorite directories and files to aide in quicker opening.  It's a pain when you only have one or two directories that you work in which are far apart in the dir tree to have to navigate all the way up and all the way back.

We might be able to utilize a java.util.Properties element for this, since it would seem to provide the right kind of data structure to get at the directory/file names easily and quickly.

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

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

Just a few things I want to mention:

1) Sign up for the mailing list! I'm going to stop duplicately posting to
the newsgroup. Go to
https://lists.sourceforge.net/lists/listinfo/drjava-hackers to do it.
(Please don't make me figure out who didn't sign up and sign up for you.)

2) As you are working on your tasks, please update the bug/feature report
on SF with your progress. You should at least update it when you find the
problem (or how to implement the feature) and then close it when it's
implemented. One important thing when you close a bug: Put into the
comments the version of DrJava in which the bug was fixed/feature was
added! This is important! (Note that this means you must commit first,
then close bugs.)

3) Put in useful CVS commit comments. Most notably, include the
bug/feature # for each fixed/implemented one, along with the short
description (copy/pasted from SF if you like). Feel free to elaborate a
bit, but really, elaboration about fixes is best put in the bug database.

4) Do *not* commit unless you're using "ant commit". This does magical
stuff that's important to do (like ensuring tests pass, and like tagging
the source, and like making a new version stamp). If you're having
problems with ant commit, talk to me.

5) If you need help with using CVS and/or ant, ask me or this list or
someone else in the class.

6) Let's all be able to give a 10 second summary of their bug/feature for
class?

7) I think I'm out of things to rant about.


By the way, I'm very encouraged about everyone's enthusiasm for working on
DrJava! I know I'm really excited that we finally are going to have the
resources to make it as great as we've been talking about it to be.

-brian

Jim:

What you bring up fits nicely with what Charlie and I were talking about
on Friday, as he is in the middle of creating a toolbar and status bar in
DrJava. The line number info belongs in the status bar. But, as you say,
it seems nasty to have to dig into the UI code to deal with this, as it's
really something that should be kept out of the UI (except for the actual
display on the #).

The answer that Charlie and I talked about is creating a StatusModel,
which would be contained by the GlobalModel. The model would keep the
status object updated and would fire event(s) when the status changed.
The events would allow the UI to know when to update the status bar. The
StatusModel would contain, at least, line/column number and the current
file name. (This would, of course, be subject to later extension.) Another
possibility would be a "status" section, which would say "Compiling",
"Running", or be empty, based on what's going on.

What does everyone think? If this seems reasonable, we should talk maybe
tomorrow about how to actually get this done!

-brian

First, a description of an issue I'm having and then the discussion of
whether or not it's of interest to the group.

In developing the line numbering mini-problem, I'm running into the
problem that I have nowhere to appropriately put my output on screen.
(We're first seeking to do the DrScheme like line:col readout, as opposed
to actually numbering every line.)

So, we're either going to have to dig into the graphic code, or perhaps
find some creative way to solve the problem.

Could this fit in nicely with some of the extensions we want to add?  For
example, we're planning on integrating JUnit and ant, but people might not
want to use it or see it in their program.  Would it be possible to have
some kind of CommandBa