[cp-patches] Re: 0.93 branch created
Am Dienstag, den 05.12.2006, 10:42 +0100 schrieb Roman Kennke:
Am Montag, den 04.12.2006, 15:52 -0500 schrieb Thomas Fitzsimmons:
Mark Wielaard wrote:
Hi,
With the mauve regressions cleaned up we finally have a branch for 0.93
(tagged as classpath-0_93-branch with classpath-0_93-branch-point as
marker on the trunk). So things todo before release:
- sync up generics branch again.
- Run some larger applications as smoke tests
eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets,
etc. to make sure they still run as well as they did with 0.92.
Reports welcome!
I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many
exceptions like this:
Exception during event dispatch:
java.lang.NullPointerException
at
gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316)
That's my fault. I fix this.
We need to 'coalesce' the paint area from the current event too in the
case when an application bypasses the eventqueue and sends PaintEvents
directly.
2006-12-05 Roman Kennke [EMAIL PROTECTED]
(paintComponent): Include paint area from event.
(updateComponent): Include paint area from event.
/Roman
Index: gnu/java/awt/peer/gtk/GtkComponentPeer.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java,v
retrieving revision 1.123
diff -u -1 -5 -r1.123 GtkComponentPeer.java
--- gnu/java/awt/peer/gtk/GtkComponentPeer.java 3 Dec 2006 16:01:11 - 1.123
+++ gnu/java/awt/peer/gtk/GtkComponentPeer.java 5 Dec 2006 09:55:35 -
@@ -301,30 +301,34 @@
// This method and its overrides are the only methods in the peers
// that should call awtComponent.paint.
protected void paintComponent (PaintEvent event)
{
// Do not call Component.paint if the component is not showing or
// if its bounds form a degenerate rectangle.
if (!awtComponent.isShowing()
|| (awtComponent.getWidth() 1 || awtComponent.getHeight() 1))
return;
// Creating and disposing a GdkGraphics every time paint is called
// seems expensive. However, the graphics state does not carry
// over between calls to paint, and resetting the graphics object
// may even be more costly than simply creating a new one.
+
+// Make sure that the paintArea includes the area from the event
+// in the case when an application sends PaintEvents directly.
+coalescePaintEvent(event);
Rectangle paintArea;
synchronized (this)
{
paintArea = currentPaintArea;
currentPaintArea = null;
}
if (paintArea != null)
{
Graphics g = getGraphics();
try
{
g.setClip(paintArea);
awtComponent.paint(g);
}
@@ -333,30 +337,33 @@
g.dispose();
}
}
}
// This method and its overrides are the only methods in the peers
// that should call awtComponent.update.
protected void updateComponent (PaintEvent event)
{
// Do not call Component.update if the component is not showing or
// if its bounds form a degenerate rectangle.
if (!awtComponent.isShowing()
|| (awtComponent.getWidth() 1 || awtComponent.getHeight() 1))
return;
+// Make sure that the paintArea includes the area from the event
+// in the case when an application sends PaintEvents directly.
+coalescePaintEvent(event);
Rectangle paintArea;
synchronized (this)
{
paintArea = currentPaintArea;
currentPaintArea = null;
}
if (paintArea != null)
{
Graphics g = getGraphics();
try
{
g.setClip(paintArea);
awtComponent.update(g);
}
Re: 0.93 branch created
Am Montag, den 04.12.2006, 15:52 -0500 schrieb Thomas Fitzsimmons: Mark Wielaard wrote: Hi, With the mauve regressions cleaned up we finally have a branch for 0.93 (tagged as classpath-0_93-branch with classpath-0_93-branch-point as marker on the trunk). So things todo before release: - sync up generics branch again. - Run some larger applications as smoke tests eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets, etc. to make sure they still run as well as they did with 0.92. Reports welcome! I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many exceptions like this: Exception during event dispatch: java.lang.NullPointerException at gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316) That's my fault. I fix this. /Roman
Re: 0.93 branch created
Am Dienstag, den 05.12.2006, 10:42 +0100 schrieb Roman Kennke:
Am Montag, den 04.12.2006, 15:52 -0500 schrieb Thomas Fitzsimmons:
Mark Wielaard wrote:
Hi,
With the mauve regressions cleaned up we finally have a branch for 0.93
(tagged as classpath-0_93-branch with classpath-0_93-branch-point as
marker on the trunk). So things todo before release:
- sync up generics branch again.
- Run some larger applications as smoke tests
eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets,
etc. to make sure they still run as well as they did with 0.92.
Reports welcome!
I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many
exceptions like this:
Exception during event dispatch:
java.lang.NullPointerException
at
gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316)
That's my fault. I fix this.
We need to 'coalesce' the paint area from the current event too in the
case when an application bypasses the eventqueue and sends PaintEvents
directly.
2006-12-05 Roman Kennke [EMAIL PROTECTED]
(paintComponent): Include paint area from event.
(updateComponent): Include paint area from event.
/Roman
Index: gnu/java/awt/peer/gtk/GtkComponentPeer.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java,v
retrieving revision 1.123
diff -u -1 -5 -r1.123 GtkComponentPeer.java
--- gnu/java/awt/peer/gtk/GtkComponentPeer.java 3 Dec 2006 16:01:11 - 1.123
+++ gnu/java/awt/peer/gtk/GtkComponentPeer.java 5 Dec 2006 09:55:35 -
@@ -301,30 +301,34 @@
// This method and its overrides are the only methods in the peers
// that should call awtComponent.paint.
protected void paintComponent (PaintEvent event)
{
// Do not call Component.paint if the component is not showing or
// if its bounds form a degenerate rectangle.
if (!awtComponent.isShowing()
|| (awtComponent.getWidth() 1 || awtComponent.getHeight() 1))
return;
// Creating and disposing a GdkGraphics every time paint is called
// seems expensive. However, the graphics state does not carry
// over between calls to paint, and resetting the graphics object
// may even be more costly than simply creating a new one.
+
+// Make sure that the paintArea includes the area from the event
+// in the case when an application sends PaintEvents directly.
+coalescePaintEvent(event);
Rectangle paintArea;
synchronized (this)
{
paintArea = currentPaintArea;
currentPaintArea = null;
}
if (paintArea != null)
{
Graphics g = getGraphics();
try
{
g.setClip(paintArea);
awtComponent.paint(g);
}
@@ -333,30 +337,33 @@
g.dispose();
}
}
}
// This method and its overrides are the only methods in the peers
// that should call awtComponent.update.
protected void updateComponent (PaintEvent event)
{
// Do not call Component.update if the component is not showing or
// if its bounds form a degenerate rectangle.
if (!awtComponent.isShowing()
|| (awtComponent.getWidth() 1 || awtComponent.getHeight() 1))
return;
+// Make sure that the paintArea includes the area from the event
+// in the case when an application sends PaintEvents directly.
+coalescePaintEvent(event);
Rectangle paintArea;
synchronized (this)
{
paintArea = currentPaintArea;
currentPaintArea = null;
}
if (paintArea != null)
{
Graphics g = getGraphics();
try
{
g.setClip(paintArea);
awtComponent.update(g);
}
Re: 0.93 branch created
Mark Wielaard wrote: - Run some larger applications as smoke tests eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets, etc. to make sure they still run as well as they did with 0.92. Reports welcome! I tried things like our examples, SwingSet2, Java2D and RSSOwl already and things look pretty good. Hi Mark, I've run: (1) The JFreeChart 1.0.3 demo. This is working pretty well. There are a couple of graphical glitches, which I'll report as bugs, but I don't think these are regressions and certainly they're not release blockers; (2) StatCVS 0.2.3. This is working well, I ran it on the Mauve CVS log file. I'll post the report shortly. (3) JEdit 4.2. Roman's HTML work has certainly improved the first impressions in JEdit, it looks really good - I was able to read through the help files, clicking hyperlinks etc. Very nice! I am able to generate the following exception fairly easily, by loading a large-ish Java source file and scrolling through it page by page. I don't know if this is a regression, because I only briefly tried JEdit on Classpath 0.92, but it means that JEdit isn't entirely usable for me just yet. Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) [error] AWT-EventQueue-2:at gnu.regexp.RE.isMatch(RE.java:1500) [error] AWT-EventQueue-2:at gnu.regexp.RE.isMatch(RE.java:1476) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.syntax.TokenMarker.markKeyword(TokenMarker.java:700) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.syntax.TokenMarker.markTokens(TokenMarker.java:210) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.Buffer.markTokens(Buffer.java:2115) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.textarea.ChunkCache.lineToChunkList(ChunkCache.java:752) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.textarea.ChunkCache.updateChunksUpTo(ChunkCache.java:627) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.textarea.ChunkCache.getLineInfo(ChunkCache.java:244) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.textarea.ExtensionManager.paintScreenLineRange(ExtensionManager.java:93) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.textarea.TextAreaPainter.paintComponent(TextAreaPainter.java:722) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1839) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintChildren(JComponent.java:1974) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1842) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintChildren(JComponent.java:1974) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1842) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintChildren(JComponent.java:1974) [error] AWT-EventQueue-2:at org.gjt.sp.jedit.gui.DockableWindowManager.paintChildren(DockableWindowManager.java:1113) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1842) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintChildren(JComponent.java:1974) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1842) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintChildren(JComponent.java:1974) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1842) [error] AWT-EventQueue-2:at javax.swing.JLayeredPane.paint(JLayeredPane.java:713) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintChildren(JComponent.java:1974) [error] AWT-EventQueue-2:at javax.swing.JComponent.paint(JComponent.java:1842) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:2354) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintImmediately2(JComponent.java:2271) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintImmediately(JComponent.java:2110) [error] AWT-EventQueue-2:at javax.swing.JComponent.paintImmediately(JComponent.java:2136) [error] AWT-EventQueue-2:at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:598) [error] AWT-EventQueue-2:at javax.swing.RepaintManager$RepaintWorker.run(RepaintManager.java:173) [error] AWT-EventQueue-2:at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:200) [error] AWT-EventQueue-2:at javax.swing.RepaintManager$RepaintWorkerEvent.dispatch(RepaintManager.java:117) [error] AWT-EventQueue-2:at java.awt.EventQueue.dispatchEvent(EventQueue.java:617) [error] AWT-EventQueue-2:at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) Anyway, looking forward to the new release... Regards, Dave
Re: 0.93 branch created
David Gilbert wrote: Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) Looks weird to me, I thought the regexp package moved to gnu.java.util.regexp ? cheers, dalibor topic
Re: 0.93 branch created
Am Montag, den 04.12.2006, 11:57 +0100 schrieb Dalibor Topic: David Gilbert wrote: Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) Looks weird to me, I thought the regexp package moved to gnu.java.util.regexp ? oh yeah. This was indeed _why_ I moved it to gnu.java.util.regexp. JEdit ships with its own (older) version of it which interfered with our regexp packages. I was getting AbstractMethodErrors back then because some old class in JEdit wasn't implementing a newer interface method or similar. David, can you check if you have for some odd reason the old regexp classes in you classpath build/install dir? /Roman
Re: 0.93 branch created
On Mon, 2006-12-04 at 11:57 +0100, Dalibor Topic wrote: David Gilbert wrote: Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) Looks weird to me, I thought the regexp package moved to gnu.java.util.regexp ? Yes it did (so as not to clash with projects shipping the old gnu.regex code). So this is an error in code bundled with jedit. But the AbstractMethodError shouldn't happen unless it is shipping broken byte code, or there is a VM bug not resolving the method correctly. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Roman Kennke wrote: Am Montag, den 04.12.2006, 11:57 +0100 schrieb Dalibor Topic: David Gilbert wrote: Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) Looks weird to me, I thought the regexp package moved to gnu.java.util.regexp ? oh yeah. This was indeed _why_ I moved it to gnu.java.util.regexp. JEdit ships with its own (older) version of it which interfered with our regexp packages. I was getting AbstractMethodErrors back then because some old class in JEdit wasn't implementing a newer interface method or similar. David, can you check if you have for some odd reason the old regexp classes in you classpath build/install dir? /Roman Hi, Thanks for the fast responses...I do seem to have both the old and new class files. I'll fix that, try JEdit again, and report back. Regards, Dave
Re: 0.93 branch created
David Gilbert wrote: Roman Kennke wrote: Am Montag, den 04.12.2006, 11:57 +0100 schrieb Dalibor Topic: David Gilbert wrote: Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) Looks weird to me, I thought the regexp package moved to gnu.java.util.regexp ? oh yeah. This was indeed _why_ I moved it to gnu.java.util.regexp. JEdit ships with its own (older) version of it which interfered with our regexp packages. I was getting AbstractMethodErrors back then because some old class in JEdit wasn't implementing a newer interface method or similar. David, can you check if you have for some odd reason the old regexp classes in you classpath build/install dir? /Roman Hi, Thanks for the fast responses...I do seem to have both the old and new class files. I'll fix that, try JEdit again, and report back. Regards, Dave OK, it is working much better now...sorry for the noise. Regards, Dave
Re: 0.93 branch created
Hi there, I just tried out BeanShell GUI and it seems quite badly broken. AFAICS, this has to do with some reflection magic. Exception during event dispatch: java.lang.reflect.UndeclaredThrowableException at $Proxy3.internalFrameActivated(Unknown Source) at javax.swing.JInternalFrame.fireInternalFrameEvent(JInternalFrame.java:707) at javax.swing.JInternalFrame.setSelected(JInternalFrame.java:1664) at javax.swing.JDesktopPane.setSelectedFrame(JDesktopPane.java:267) at javax.swing.DefaultDesktopManager.activateFrame(DefaultDesktopManager.java:298) at javax.swing.plaf.basic.BasicInternalFrameUI.activateFrame(BasicInternalFrameUI.java:1754) at javax.swing.plaf.basic.BasicInternalFrameUI $BorderListener.mousePressed(BasicInternalFrameUI.java:345) at javax.swing.plaf.basic.BasicInternalFrameUI $GlassPaneDispatcher.mousePressed(BasicInternalFrameUI.java:761) at java.awt.Component.processMouseEvent(Component.java:3812) at java.awt.Component.processEvent(Component.java:3674) at java.awt.Container.processEvent(Container.java:1027) at java.awt.Component.dispatchEventImpl(Component.java:5741) at java.awt.Container.dispatchEventImpl(Container.java:1922) [...] Many of these are thrown and it basically seems to prevent the thing from working at all. /Roman
Re: 0.93 branch created
Mark Wielaard wrote: Hi, With the mauve regressions cleaned up we finally have a branch for 0.93 (tagged as classpath-0_93-branch with classpath-0_93-branch-point as marker on the trunk). So things todo before release: - sync up generics branch again. - Run some larger applications as smoke tests eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets, etc. to make sure they still run as well as they did with 0.92. Reports welcome! I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many exceptions like this: Exception during event dispatch: java.lang.NullPointerException at gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316) at gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(GtkComponentPeer.java:284) at gnu.java.awt.peer.gtk.GtkPanelPeer.handleEvent(GtkPanelPeer.java:63) at java.awt.Component.dispatchEventImpl(Component.java:5749) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Component.dispatchEvent(Component.java:2833) at java.awt.EventQueue.dispatchEvent(EventQueue.java:626) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) at java.lang.VMThread.run(VMThread.java:120) and (likely as a result of these exceptions) GTK widgets aren't being painted correctly. I'm investigating... Tom
Re: 0.93 branch created
Hi Tom, On Mon, 2006-12-04 at 15:52 -0500, Thomas Fitzsimmons wrote: I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many exceptions like this: Exception during event dispatch: java.lang.NullPointerException at gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316) at gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(GtkComponentPeer.java:284) at gnu.java.awt.peer.gtk.GtkPanelPeer.handleEvent(GtkPanelPeer.java:63) at java.awt.Component.dispatchEventImpl(Component.java:5749) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Component.dispatchEvent(Component.java:2833) at java.awt.EventQueue.dispatchEvent(EventQueue.java:626) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) at java.lang.VMThread.run(VMThread.java:120) and (likely as a result of these exceptions) GTK widgets aren't being painted correctly. I'm investigating... Found that already. Lifting this patch from head to the release branch now: 2006-12-03 Mark Wielaard [EMAIL PROTECTED] * gnu/java/awt/peer/gtk/GtkComponentPeer.java (paintArea): Renamed to currentPaintArea. (paintComponent): Work with local reference to currentPaintArea. (updateComponent): Likewise. (coalescePaintEvent): Set currentPaintArea. Plus some of the others we found during testing this weekend. Please retest in half an hour when I flushed all appropriate patches to the branch. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Mark Wielaard wrote: Hi Tom, On Mon, 2006-12-04 at 15:52 -0500, Thomas Fitzsimmons wrote: I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many exceptions like this: Exception during event dispatch: java.lang.NullPointerException at gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316) at gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(GtkComponentPeer.java:284) at gnu.java.awt.peer.gtk.GtkPanelPeer.handleEvent(GtkPanelPeer.java:63) at java.awt.Component.dispatchEventImpl(Component.java:5749) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Component.dispatchEvent(Component.java:2833) at java.awt.EventQueue.dispatchEvent(EventQueue.java:626) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) at java.lang.VMThread.run(VMThread.java:120) and (likely as a result of these exceptions) GTK widgets aren't being painted correctly. I'm investigating... Found that already. Lifting this patch from head to the release branch now: 2006-12-03 Mark Wielaard [EMAIL PROTECTED] * gnu/java/awt/peer/gtk/GtkComponentPeer.java (paintArea): Renamed to currentPaintArea. (paintComponent): Work with local reference to currentPaintArea. (updateComponent): Likewise. (coalescePaintEvent): Set currentPaintArea. Plus some of the others we found during testing this weekend. Please retest in half an hour when I flushed all appropriate patches to the branch. OK, that fixed the exception, thanks. I'm still seeing the GTK widget painting problems, and also this when I try to show MegaMek's documentation widget: Exception in thread main java.lang.NullPointerException at gnu.java.awt.peer.gtk.GtkToolkit.getFontMetrics(GtkToolkit.java:318) at java.awt.Component.getFontMetrics(Component.java:2193) at megamek.client.ui.AWT.widget.AdvancedLabel.getSizes(AdvancedLabel.java:71) at megamek.client.ui.AWT.widget.AdvancedLabel.getMinimumSize(AdvancedLabel.java:87) at megamek.client.ui.AWT.widget.AdvancedLabel.getPreferredSize(AdvancedLabel.java:82) at java.awt.ScrollPane.layout(ScrollPane.java:488) at java.awt.ScrollPane.doLayout(ScrollPane.java:470) at java.awt.ScrollPane.addImpl(ScrollPane.java:458) at java.awt.Container.add(Container.java:227) at megamek.client.ui.AWT.CommonHelpDialog.init(CommonHelpDialog.java:54) at megamek.MegaMek.showHelp(MegaMek.java:671) at megamek.MegaMek.showHelp(MegaMek.java:656) at megamek.MegaMek.init(MegaMek.java:144) at megamek.MegaMek.main(MegaMek.java:818) Investigating... Tom
Re: 0.93 branch created
Hi David, On Mon, 2006-12-04 at 10:44 +, David Gilbert wrote: (1) The JFreeChart 1.0.3 demo. This is working pretty well. There are a couple of graphical glitches, which I'll report as bugs, but I don't think these are regressions and certainly they're not release blockers; (2) StatCVS 0.2.3. This is working well, I ran it on the Mauve CVS log file. I'll post the report shortly. (3) JEdit 4.2. Roman's HTML work has certainly improved the first impressions in JEdit, it looks really good - I was able to read through the help files, clicking hyperlinks etc. Very nice! Thanks for all this testing. Seems our little release is shaping up nicely. Also thanks for the new cvsstat reports on your blog and planet classpath. Hope the web server crash you reported wasn't caused by some bug in classpath clobbering your kernel somehow. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Hi Roman, On Mon, 2006-12-04 at 21:21 +0100, Roman Kennke wrote: I just tried out BeanShell GUI and it seems quite badly broken. AFAICS, this has to do with some reflection magic. Exception during event dispatch: java.lang.reflect.UndeclaredThrowableException at $Proxy3.internalFrameActivated(Unknown Source) at javax.swing.JInternalFrame.fireInternalFrameEvent(JInternalFrame.java:707) at javax.swing.JInternalFrame.setSelected(JInternalFrame.java:1664) at javax.swing.JDesktopPane.setSelectedFrame(JDesktopPane.java:267) at javax.swing.DefaultDesktopManager.activateFrame(DefaultDesktopManager.java:298) at javax.swing.plaf.basic.BasicInternalFrameUI.activateFrame(BasicInternalFrameUI.java:1754) at javax.swing.plaf.basic.BasicInternalFrameUI $BorderListener.mousePressed(BasicInternalFrameUI.java:345) at javax.swing.plaf.basic.BasicInternalFrameUI $GlassPaneDispatcher.mousePressed(BasicInternalFrameUI.java:761) at java.awt.Component.processMouseEvent(Component.java:3812) at java.awt.Component.processEvent(Component.java:3674) at java.awt.Container.processEvent(Container.java:1027) at java.awt.Component.dispatchEventImpl(Component.java:5741) at java.awt.Container.dispatchEventImpl(Container.java:1922) [...] Many of these are thrown and it basically seems to prevent the thing from working at all. I only see this when trying to work with the Class Browser in bsh, everything else seems to work perfectly. Also this only seems to happen with jamvm, not with cacao (from SVN). So I suspect a bug in jamvm, not in the class libraries. I don't have a simple testcase though. If someone is interested in tracking this down: simple try running bsh (1.3.0) jamvm -jar bsh.jar and right clicking on the jdesktop to get a popup select Class Browser and you get the above stack trace (plus some extra info). Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
On Sat, 2006-12-02 at 02:56 +0100, Mark Wielaard wrote:
Hi,
With the mauve regressions cleaned up we finally have a branch for 0.93
(tagged as classpath-0_93-branch with classpath-0_93-branch-point as
marker on the trunk). So things todo before release:
- sync up generics branch again.
- Run some larger applications as smoke tests
eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets,
etc. to make sure they still run as well as they did with 0.92.
Reports welcome! I tried things like our examples, SwingSet2, Java2D
and RSSOwl already and things look pretty good.
- Fixup any last minute regresions if found (please do that on the
trunk, they will be merged onto the branch if OK - CC me on any patch
that you think should go on the release [and generics] branch).
- Update NEWS (please add your cool stuff!)
- Release! :)
http://builder.classpath.org/dist/classpath-0.93-pre.tar.gz
Cheers,
Mark
Great news Mark! What's the plan for the generics branch? From this,
it sounds like we keep it around until the release itself, which seems
sensible (so we have a 0.93 generics release). I guess after that it
gets synchronized with HEAD again, and then the updated branch becomes
HEAD (after creating a 1.4 branch). Does that sound about right?
Cheers,
--
Andrew :-)
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
Re: 0.93 branch created
Hi Andrew, On Sat, 2006-12-02 at 10:47 +, Andrew John Hughes wrote: Great news Mark! What's the plan for the generics branch? From this, it sounds like we keep it around until the release itself, which seems sensible (so we have a 0.93 generics release). Yes that is a good plan. And if everything goes right then that will be till Monday at the latest. I guess after that it gets synchronized with HEAD again, and then the updated branch becomes HEAD (after creating a 1.4 branch). Does that sound about right? I don't believe you can 'switch' a branch to become the trunk with CVS. So after the resync with HEAD we need to actually merge the generics-branch changes onto the trunk (which should be just one big diff because they just got synced, but watch out for those added/removed files). Cheers, Mark
Re: 0.93 branch created
Mark Wielaard writes: On Sat, 2006-12-02 at 10:47 +, Andrew John Hughes wrote: Great news Mark! What's the plan for the generics branch? From this, it sounds like we keep it around until the release itself, which seems sensible (so we have a 0.93 generics release). Yes that is a good plan. And if everything goes right then that will be till Monday at the latest. I guess after that it gets synchronized with HEAD again, and then the updated branch becomes HEAD (after creating a 1.4 branch). Does that sound about right? I don't believe you can 'switch' a branch to become the trunk with CVS. So after the resync with HEAD we need to actually merge the generics-branch changes onto the trunk (which should be just one big diff because they just got synced, but watch out for those added/removed files). OK. I'd like to have a semi-official 0.93 generics release for gcj. If we have that then gcj can go to Java 5 at the end of next week (i.e. we'll merge gcj-eclipse branch to trunk.) Andrew.
Re: 0.93 branch created
On Sat, 2006-12-02 at 11:08 +, Andrew Haley wrote: OK. I'd like to have a semi-official 0.93 generics release for gcj. If we have that then gcj can go to Java 5 at the end of next week (i.e. we'll merge gcj-eclipse branch to trunk.) Cool. Yes, the plan is to push out a fairly-official classpath-generics 0.93 release together with the classpath 0.93 release. Cheers, Mark
Re: 0.93 branch created
On Sat, 2006-12-02 at 12:00 +0100, Mark Wielaard wrote:
Hi Andrew,
On Sat, 2006-12-02 at 10:47 +, Andrew John Hughes wrote:
Great news Mark! What's the plan for the generics branch? From this,
it sounds like we keep it around until the release itself, which seems
sensible (so we have a 0.93 generics release).
Yes that is a good plan. And if everything goes right then that will be
till Monday at the latest.
I guess after that it
gets synchronized with HEAD again, and then the updated branch becomes
HEAD (after creating a 1.4 branch). Does that sound about right?
I don't believe you can 'switch' a branch to become the trunk with CVS.
So after the resync with HEAD we need to actually merge the
generics-branch changes onto the trunk (which should be just one big
diff because they just got synced, but watch out for those added/removed
files).
Yes, when I said 'switch' I was referring to the effective result
afterwards, rather than the hackery we will have to go through with
CVS :)
Cheers,
Mark
--
Andrew :-)
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
0.93 branch created
Hi, With the mauve regressions cleaned up we finally have a branch for 0.93 (tagged as classpath-0_93-branch with classpath-0_93-branch-point as marker on the trunk). So things todo before release: - sync up generics branch again. - Run some larger applications as smoke tests eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets, etc. to make sure they still run as well as they did with 0.92. Reports welcome! I tried things like our examples, SwingSet2, Java2D and RSSOwl already and things look pretty good. - Fixup any last minute regresions if found (please do that on the trunk, they will be merged onto the branch if OK - CC me on any patch that you think should go on the release [and generics] branch). - Update NEWS (please add your cool stuff!) - Release! :) http://builder.classpath.org/dist/classpath-0.93-pre.tar.gz Cheers, Mark signature.asc Description: This is a digitally signed message part
