This is from the uckelman-caching branch, and is current w/r/t the trunk.
There are a number of outstanding issues (e.g., anything which I said I’d
do once I finished the error handling project), but there have been so
many bug fixes since beta2 that I think we should release something soon
as beta3 anyway, and figure on having at least a beta4 after that to pick
up the remaining fixes.
There’s a lot of very lightly tested stuff in this, so it might entirely
blow up on you—better to find that now before we release beta3.
As a side note: This build has the BugDialog in it. It occurred to me this
morning (while in the shower) that one downside to making bug reporting so
easy is that we could be receiving bug reports about beta versions long
after they’ve stopped being current. So, before we release beta3 I’m going
to add something which disables the BugDialog at some point in the future.
The most straightforward way would be to stop showing the BugDialog (and
instead show a regular ErrorDialog) after some predetermined amount of time,
say 30 days after the release date of the beta. A more sophisticated way
would be to check some URL we supply to see whether we still want bug
reports from a particular version. I’m not sure which is best—a time limit
is easier to code, but not really suitable for released versions, while
consulting a URL requires a bit more coding and a stable place to host the
file.
It was 20 days between beta1 and beta2, and right now it’s been about 60
days since beta2. I’m guessing it will be 2-3 weeks between beta3 and
beta4, which I’d like to be the last before releasing 3.1.0. 90 days seems
long to me, but not excessively long.
We can’t go with a time-out for full releases, though, as we have no way
to estimate how long they’ll be current.
The right way to do this (IMO) is to have the Bug Dialog not contact SourceForge directly. Instead, have it hit some URL that we control (on vassalengine.org or nomic.net) Then our servlet can check the version number and decide to just drop it if the version is too old, and forward it to SourceForge otherwise. This also makes the transition smooth if we decide to host our own bug-tracking system in the future.
Thanks for the new build, it’s nice to see the Server Status pane up by default!
I’m getting the following exceptions when trying to open any module. It brings up an empty Bug report window then I then have to kill VASSAL manually through Task Manager.
cheers.
[834084552]
-- OS Windows Vista
-- Java version 1.6.0_03
-- VASSAL version 3.1.0-svn3899
-- Manager
[1609686767]
-- OS Windows Vista
-- Java version 1.6.0_03
-- VASSAL version 3.1.0-svn3899
-- Player
[1609686767]
VASSAL.tools.version.VersionFormatException
at VASSAL.tools.version.VassalVersionTokenizer.next(VassalVersionTokenizer.java:142)
at VASSAL.Info.compareVersions(Info.java:144)
at VASSAL.build.GameModule.setAttribute(GameModule.java:217)
at VASSAL.build.AbstractBuildable.build(AbstractBuildable.java:56)
at VASSAL.launch.BasicModule.build(BasicModule.java:136)
at VASSAL.launch.BasicModule.build(BasicModule.java:102)
at VASSAL.build.GameModule.init(GameModule.java:765)
at VASSAL.launch.Player.launch(Player.java:106)
at VASSAL.launch.Launcher$1.run(Launcher.java:132)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
[1609686767]
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(Unknown Source)
at VASSAL.configure.HotKeyConfigurer.decode(HotKeyConfigurer.java:135)
at VASSAL.tools.LaunchButton.setAttribute(LaunchButton.java:126)
at VASSAL.build.module.Map.setAttribute(Map.java:383)
at VASSAL.build.AbstractBuildable.build(AbstractBuildable.java:56)
at VASSAL.build.module.Map.build(Map.java:472)
at VASSAL.build.Builder.create(Builder.java:104)
at VASSAL.build.Builder.build(Builder.java:74)
at VASSAL.build.AbstractBuildable.build(AbstractBuildable.java:68)
at VASSAL.launch.BasicModule.build(BasicModule.java:136)
at VASSAL.launch.BasicModule.build(BasicModule.java:102)
at VASSAL.build.GameModule.init(GameModule.java:765)
at VASSAL.launch.Player.launch(Player.java:106)
at VASSAL.launch.Launcher$1.run(Launcher.java:132)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
[834084552]
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at VASSAL.launch.CommandServer.run(CommandServer.java:62)
at java.lang.Thread.run(Unknown Source)
[834084552]
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at VASSAL.launch.CommandClient.request(CommandClient.java:65)
at VASSAL.launch.AbstractLaunchAction.shutDown(AbstractLaunchAction.java:122)
at VASSAL.launch.ModuleManagerWindow$1.actionPerformed(ModuleManagerWindow.java:171)
at VASSAL.launch.ModuleManagerWindow$2.windowClosing(ModuleManagerWindow.java:194)
at java.awt.AWTEventMulticaster.windowClosing(Unknown Source)
at java.awt.Window.processWindowEvent(Unknown Source)
at javax.swing.JFrame.processWindowEvent(Unknown Source)
at java.awt.Window.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
All I know right now is that the ArrayIndexOutOfBoundsException is the
real problem. The VersionFormatException is not an error, it’s just
being logged for completeness.
I found the problem: We used to be catching Exception immediately after
the place where the problem was occuring. That was masking a 4-year-old
logic bug.
I’m uploading a new build (svn3920) which corrects this and two other
problems right now.
Here it is anyway. I tried to expand a “Charts” tree in the module editor.
[952320981]
-- OS Windows Vista
-- Java version 1.6.0_03
-- VASSAL version 3.1.0-svn3940
-- Manager
C:\Program Files\Java\jre1.6.0_03\bin\java -Xms256M -Xmx512M -cp lib\Vengine.jar;Vengine.jar VASSAL.launch.Editor
[1184294571]
-- OS Windows Vista
-- Java version 1.6.0_03
-- VASSAL version 3.1.0-svn3940
-- Editor
-- Three Battles of Manassas version 0.2
[1184294571]
java.lang.NoSuchMethodException: VASSAL.build.widget.Chart.getConfigureTypeName()
at java.lang.Class.getMethod(Unknown Source)
at VASSAL.configure.ConfigureTree.getConfigureName(ConfigureTree.java:715)
at VASSAL.configure.ConfigureTree$Renderer.getTreeCellRendererComponent(ConfigureTree.java:705)
at javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(Unknown Source)
at javax.swing.tree.AbstractLayoutCache.getNodeDimensions(Unknown Source)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.updatePreferredSize(Unknown Source)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(Unknown Source)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(Unknown Source)
at javax.swing.tree.VariableHeightLayoutCache.ensurePathIsExpanded(Unknown Source)
at javax.swing.tree.VariableHeightLayoutCache.setExpandedState(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.updateExpandedDescendants(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI$Handler.treeExpanded(Unknown Source)
at javax.swing.JTree.fireTreeExpanded(Unknown Source)
at javax.swing.JTree.setExpandedState(Unknown Source)
at javax.swing.JTree.expandPath(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(Unknown Source)
at java.awt.AWTEventMulticaster.mousePressed(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
If you submit a bug with 3940, it will end up on SF automatically, along
with the errorLog. SF is kind of crap for handling notification and
discussions, though, so if you want us to notice the bug report, you might
mention that it exists here.
Soonish I expect to begin directing all of the bug reporting to a Bugzilla
installation, which is good at notification and discussion, but that
won’t change the user-facing parts of the bug dialog.
This is due to VASSAL.build.widget.Chart having no getConfigureTypeName()
method. In ConfigureTree.getConfigureName(), we’re using reflection to
call getConfigureTypeName(). Before, we caught all Exceptions and ignored
them, which is not generally a good idea.
Questions for someone who knows (Rodney? Brent?): Why are we trying to get
this method by reflection? Shouldn’t it be part of an interface instead?
Is it really not an error when we get a NoSuchMethodException here?
Ok, so this means that the only person who might know the answer is Rodney.
In the past two weeks, I’ve looked at every single place in the code where
we use reflection, and this is by far the weirdest. Unless Rodney has some
extremely compelling reason for not having an interface for this (or having
it be part of some existing interface), I’d like to introduce one. In order
to accomodate custom classes which of course won’t implement it, we can
leave a case which uses reflection, but throws up a warning telling you that
you should implement the relevant interface.
Alright, I’ll change it to do that in case of a NoSuchMethodException,
pending the more drastic change I mentioned above.
getConfigureTypeName() is a static method. When the popup menu is built, you only have a reference to the class (e.g. DiceButton.class) and not a reference to an instantiated object. That’s because Configurable.getAllowableChildComponents() returns an array of Class objects. To use an interface, you’d have to instantiate an object, for example using Class.newInstance(). That could work, but be aware of the cost of instantiating a bunch of Buildable objects every time the user right-clicks in the edit window. Also, watch out for bugs in singleton classes, such as GlobalOptions, some of which set a static instance variable to ‘this’ in the constructor.
Ok, that’s a good reason. Interfaces can’t have static methods. I’ll fix
up the code there to do the right thing, and include an explanation for
what’s going on, so Brent isn’t wondering around this time next year.
This is weird. I compressed the module manually the same way I always do (with Winrar) and I can still uncompress it manually. This happens when I try to save the module from within the Editor. (build 3950)
ava.util.zip.ZipException: invalid entry compressed size (expected 10053 but got 10164 bytes)
at java.util.zip.ZipOutputStream.closeEntry(Unknown Source)
at java.util.zip.ZipOutputStream.putNextEntry(Unknown Source)
at VASSAL.tools.ArchiveWriter.write(ArchiveWriter.java:296)
at VASSAL.build.GameModule.save(GameModule.java:889)
at VASSAL.build.GameModule.save(GameModule.java:865)
at VASSAL.launch.ModuleEditorWindow$2.run(ModuleEditorWindow.java:100)
at VASSAL.launch.EditorWindow.saver(EditorWindow.java:289)
at VASSAL.launch.ModuleEditorWindow.save(ModuleEditorWindow.java:98)
at VASSAL.launch.EditorWindow$2.actionPerformed(EditorWindow.java:180)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
This might be related to a change I made in the ArchiveWriter to improve
efficiency when most entries in the ZIP archive are unmodified. What we
had been doing was creating a new ZipEntry for each unchanged ZipEntry,
and then recalculating the size and CRC for entries which were only
stored instead of compressed. This information should already be in the
old ZipEntry, however, so we should be able to reuse that ZipEntry and
put it straight into the ZipOutputStream.
