I would like to lend a hand

Hi all

My name is Bo. I have been using vassal for several years, and have always been very impressed by its cababilities. If you got room for another developer, I would like to help make vassal even better.

I have 15 years of programming experience, and have worked with Java for more than 10 years, primarily on the serverside (JEE), designing and developing large systems for a large Danish financial institution.

I have checked out the source from sourceforge (user: bolabola2), and have a couple of ideas of where I might start. I have looked at the DataArchieve, and have a couple of ideas of how to improve it, making it more flexible using plugable readers/writers and adding a cache manager, allowing for more advanced caching strategies. I also think that your project on seperating concerns (MVC) sounds very interesting. I could also help trying to document the code with class and sequence diagrams, making it easier for new developers to start working on the code.

A bit about myself:

I live in Denmark, Copenhagen and have been playing boardgames for many years (Europe engulfed, Eastfront, Napoleonic wars, Breakout Normandy to name a few).

Kind regards
Bo Leer-Andersen

Thus spake “bolabola”:

Yes, we’d be happy to have more help. Welcome!

The project I’m currently working on involves work in that area, namely to
throw away DataArchive (and ArchiveWriter) entirely and replace it with a
JDK7-style ZIP archive FileSystem (work for this is happening on the nio-fs
branch), and to build an disk cache of compressed (but decoded) image tiles.

Background: I found from testing that the main reason for poor performance
right now is needing to load and store large map images. Loading them—
in particular, decoding the image files to pixel arrays—is slow, and the
image data is often large enough to push everything else out of the in-
memory image cache. Instead, we can slice large images into tiles and save
the compressed, undedocded pixel data in an on-disk image cache. This makes
image decoding a one-time cost, instead of any every-time cost, and means
that the data which goes into the in-memory cache can be evicted in smaller
pieces. All of this is already coded, and works well.

What’s missing right now is the manager for the on-disk tile cache, to
ensure that when a module is loaded, the cached tiles aren’t stale. This
is where DataArchive comes in—it provides no way to check the attributes
of files in modules, and hence there’s no way to determine whether the disk
cache is stale. (Recreating it each time the module is loaded is not a good
option, since for large modules, creating the cache can take up to 5
minutes.)

So, this is why I’m implementing a FileSystem (which supports the
operations we need) to replace DataArchive, right now.

What changes did you have in mind?

Having help on the MVC project would be great—there are a few prereqs
for it. I’ve started on some of them, and would be happy to go into more
detail about what I think needs to be done and why.

Also there’s, some planning stuff here:

vassalengine.org/forums/viewtopic.php?t=2577

Having better code documentation would be wonderful… Having any kind of
documentation for the overall structure of VASSAL would be wonderful.

Good to meet you. I’m an American living in Amsterdam, having just finished
my PhD in computer science at the UvA. I’ve been playing boardgames for 15
years now. Things I’ve had on the table in recent years include Empires
in Arms, The Longest Day, Three Battles of Manassass, Reds!, Twilight
Struggle, Monty’s Gamble, SPQR, Terrible Swift Sword… I also have a ton
of games I’ve never had the chance to play, sadly.

Other people:

  • Rodney is the project founder. He’s around, but not so active presently.
    Rodney’s also the VASL maintainer.

  • Brent is the expert on the parts of VASSAL under the build hierarchy,
    is a champion bug-fixer, and is presently working on the new Jabber
    client.

  • Michael wrote all of the ADC2 conversion code, and demos for our switch
    to JOGL.

  • Jim just started a few weeks ago, and is presently fixing bugs.

  • Ben runs the forum and is patiently waiting for me to look at his patches.

  • Tim is the resident module-design guru, and has done some work on
    sorting out translation keys.

I think that’s everybody who’s doing anything, coding-wise right now.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I am happy to help in any way I can.

My basic idea with rewriting the DataArchieve was to make it more flexible, making it possible to read modules from different kind of “stores” (zip file, jar file, exploded dir, http server or even ftp), and allowing for file caching by attaching a cacheManager, making it possible to use different caching strategies based on free heap, hit rates and so forth. The design would also allow for easy conversion between “store” formats. I have attached a class diagram that should give an overview of my thoughts.

The main reason I picked DataArchive to start with was that it is pretty isolated from the rest of the code (it can be rewritten/refactored) without affecting to much of the code base). And I am a bit worried about starting out on something that affects a larger portion of the codebase :confused:.

If work is already being done is this area, I could start looking at the user interface. Here I am particually thinking about the module designer, that could use some love, for example by using the MIG2 layout manager allowing for proper alignment and spacing between components. This would require a bit more time on my part though, as I don’t have much experience with Swing.

Bo

Thus spake “bolabola”:

The work I’m doing right now is compatible with all of that, but it might
make sense to wait for the dust to settle before doing it, just so we have
a stable API to work against.

Regarding different caching strategies, in particular: I don’t know whether
a different cache type, say, LRU or LFU would be better than the one we
have which relies on SoftReferences. My guess is that once all of the
cached data is in small chunks, it won’t much matter, but I’m open to giving
other kinds of caches a try.

Sure, I understand. Give me until the end of the week to shake out all
of the remaining work that I’m doing in this area.

We’re already using MigLayout in a few places, mostly in code which is less
than two years old. I’d like to be using it everwhere, but we haven’t had
enough time to do it yet. Using it everywhere would certainly improve the
appearance of VASSAL.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spoke “uckelman”

Absolutely. I’ll wait with the DataArchieve until you are done with the NIO implementation.

I’ll start by familiarize myself with the codebase, and look at the MIG layout and the Module designer.

Bo

Thus spake “bolabola”:

If you’re planning to do layout work, the Editor is the wrong place to
start. Most of the (ugly) layouts in its dialogs are automatically
generated, and I’m already halfway into fixing those. It would be better
to work on the hand-coded layouts elsewhere, in the Player and Module
Manager, as those aren’t being worked on by anyone, presently.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spoke “Uckelman”:

I knew that the Module editor layouts where automatically created (just looking at them gives them away :smiley:).
I’ll start looking at the hardcoded layouts in the Player. Can I get access to the vassal SVN repository, so I can create a work branch?

Hi Bo,

Great to have you here!

In general, in the Editor, only ‘Components’ (i.e. classes that extend AbstractConfigurable) have automatically generated config dialogs. All off the configuration for the ‘Traits’ (i.e. subclasses of Decorator in VASSAL.counters) are hand generated in the Ed subclass and can be fixed up independently of the work Joel is doing on the AutoConfigurer.

In fact, you might also want to have a look at the PieceDefiner which is the primary interface a module designer uses.

Joel, You and I need to get the Trunk into usable shape ASAP. Not necessarily all work done, but not crashing on startup. I think I have it stable on the Jabber side (not quite working, but not crashing ;), and just trying to sort out another problem with NamedKeyStrokes. I’ve finished adding new features for now and am planning to go back over everything new I have added and refine it

Cheers,
Brent.

*********** REPLY SEPARATOR ***********

On 23/01/2010 at 7:45 AM bolabola wrote:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Agreed. The work I’m doing now should close out those now very, very old
bugs you filed when I first started messing with DataArchive, so that
should help a little.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “bolabola”:

I’ve been working on a way of generating them automatically which won’t
be so ovbiously autogenerated-looking. Right now the editor dialogs remind
me of nothing more than stacks of Jenga blocks—they’ve been my most hated
things about the VASSAL UI every since I joined the project.

You’re added. Welcome aboard.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “bolabola”:

Ok, the dust is settling on my ZIP changes now. Your UML diagram seems
reasonable to me, with one exception: Caching image files in memory
is not useful for modules which exist locally. This is something I’ve
verified experimentally—reading the bytes of an image file from a
module takes a negligible amount of time in comparison with decoding the
image data. (This might be different if the file is not local, however.)

What the cache manager needs to cache in the case of images is not the
bytes read, but rather the BufferedImages which result. (This is being
done by VASSAL.tools.opcache.OpCache, pressently. It’s essentially a
thread-safe memoizer. Have a look there.)

ModuleReader needs to offer at least the following:

InputStream getInputStream(String path)
SeekableByteChannel getChannel(String path) (maybe)
URL getURL(String path)
boolean exists(String path)
long getMTime(String path)
List getChildren(String path)
void close()

ModuleWriter needs to offer at least the following:

OutputStream getOutputStream(String path)
SeekableByteChannel getChannel(String path) (maybe)
void flush()
void close()

There’s also the issue of how to handle module extensions…

What’d you use to make the diagram, BTW?

J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Joel Uckelman:

Or, we could use all the spiffy Path stuff, which would mean that Path
would provide all the streams, channels, URLs, attributes, navigation,
etc., so then ModuleReader would need only

Path get(String path)
void close()

and ModuleWriter only

void flush()
void close()

because Path can handle writing itself, but only if there’s already
an underlying NIO FileSystem implementation (which we could rely on
for the disk and ZIP archives, but not for HTTP.). Hmm…

Thoughts?

J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Joel Uckelman:

Right now I’m merging all of my JSR 203 NIO stuff to the trunk. I was
getting frustrated by how long writing this was taking, but tonight I
realized that the code plus tests is just under 12k lines!

Eventually we’ll be able to remove all of this from our tree, because
it will all be available in the JDK itself (the disk FS implementation
because it’s already in JDK 7, and the zip FS implementation because
I’m contributing what I wrote back to OpenJDK).

I haven’t started adjusting DataArchive to use any of this yet—that’s
a job for tomorrow.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

My zipfs changes are in the trunk now. Here’s a proposal for the methods in ModuleReader and ModuleWriter:

public interface ModuleReader {
  public FileRef getRef(String path) throws IOException;
  public byte[] getBytes(String path) throws IOException;
  List<String> getChildren(String path) throws IOException;
  URL getURL(String path) throws IOException;  // maybe not needed?
  public close() throws IOException;
}

public interface ModuleWriter {
  public FileRef getRef(String path) throws IOException;
  public putBytes(String path, byte[] bytes) throws IOException;
  public void delete(String path) throws IOException;
  public void flush() throws IOException;
  public void close() throws IOException;
}

FileRef is a class which provides methods for getting InputStreams and OutputStreams, as well as getting and setting file attributes. (The reason I want to make these accessible via a FileRef rather than directly from the ModuleStore is that then we can have background tasks which take FileRefs instead of passing around streams, which makes locking complex.)

Were you envisioning that ModuleStore would have getReader/Writer methods, or that ModuleStore itself would implement both ModuleReader and ModuleWriter? I was thinking that the latter would result in less verbose code on the caller side and would make it easier to handle the composition of archives which happens when we use module extensions. Then ModuleStore would delegate to the “real” Reader and Writer (and also return a composite FileRef, which delegates its read methods to the Reader and write methods to the Writer).

An example of what I mean: Suppose that ModuleStore has an addExtension(…) method, by which something (either other ModuleStores, or maybe pairs of Readers and Writers?) can be added as a secondary archive. When ModuleStore.getRef(“foo”) is called, if “foo” isn’t located by the primary ModuleReader, then the request fails over to any secondary ModuleReaders.

Bo, your thoughts? (Also anyone else who wants to jump in.)

Joel,

Code is not Jre 1.5 compatible. java.io.IOError referenced in SimpleFileVistor.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

It also crashes on startup for me, with or without an extant Preferences file, with:

21 Feb 2010 12:24:29.662 0 – Starting
21 Feb 2010 12:24:29.664 0 – OS Windows Vista
21 Feb 2010 12:24:29.664 0 – Java version 1.6.0_17
21 Feb 2010 12:24:29.664 0 – VASSAL version 3.2.0-svn4869
21 Feb 2010 12:24:29.665 0 – Editor
21 Feb 2010 12:24:29.754 0 java.lang.ExceptionInInitializerError
at VASSAL.launch.LoadModuleAction.(LoadModuleAction.java:50)
at VASSAL.launch.EditModuleAction.(EditModuleAction.java:42)
at VASSAL.launch.Editor.launch(Editor.java:67)
at VASSAL.launch.Launcher$1.run(Launcher.java:160)
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)
Caused by: java.lang.IllegalArgumentException
at java.net.URI.create(Unknown Source)
at VASSAL.preferences.Prefs.getGlobalPrefs(Prefs.java:250)
at VASSAL.i18n.Resources.(Resources.java:94)
… 12 more
Caused by: java.net.URISyntaxException: Illegal character in authority at index 6: zip://C:\Users\Brent\VASSAL\Preferences
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.parseAuthority(Unknown Source)
at java.net.URI$Parser.parseHierarchical(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.(Unknown Source)
… 15 more

*********** REPLY SEPARATOR ***********

On 21/02/2010 at 10:51 PM Brent Easton wrote:


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Fixed in trunk@6525.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I was building URIs from file paths using string concatenation;
unfortunately, the slashes slant the wrong way in Windows paths.

I’ve committed a potential fix to trunk@6526. Let me know if this
works on Windows. If so, then I need to clean it up, since I just
tossed this together.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

that’s solved the startup problem.

*********** REPLY SEPARATOR ***********

On 22/02/2010 at 1:08 AM Joel Uckelman wrote:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Editor starts up, but get the following (no submit button):

22 Feb 2010 04:26:49.804 0 – Starting
22 Feb 2010 04:26:49.806 0 – OS Windows Vista
22 Feb 2010 04:26:49.806 0 – Java version 1.5.0_17
22 Feb 2010 04:26:49.806 0 – VASSAL version 3.2.0-svn4869
22 Feb 2010 04:26:49.808 0 – Editor
22 Feb 2010 04:26:50.307 0 VASSAL.tools.nio.file.FileSystemException: C:\Users\Brent\AppData\Local\Temp\rwzipfs7612007873098475730.zip → C:\Users\Brent\VASSAL\Preferences:
at VASSAL.tools.nio.file.realfs.RealPath.moveTo(RealPath.java:263)
at VASSAL.tools.nio.file.zipfs.ZipFileSystem.flush(ZipFileSystem.java:345)
at VASSAL.preferences.PrefsEditor.write(PrefsEditor.java:284)
at VASSAL.preferences.Prefs.write(Prefs.java:232)
at VASSAL.preferences.Prefs.getGlobalPrefs(Prefs.java:277)
at VASSAL.i18n.Resources.(Resources.java:94)
at VASSAL.launch.LoadModuleAction.(LoadModuleAction.java:50)
at VASSAL.launch.EditModuleAction.(EditModuleAction.java:42)
at VASSAL.launch.Editor.launch(Editor.java:67)
at VASSAL.launch.Launcher$1.run(Launcher.java:160)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(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)

22 Feb 2010 04:26:53.098 0 – Named Key Test version 0.8
22 Feb 2010 04:26:53.098 0

*********** REPLY SEPARATOR ***********

On 22/02/2010 at 12:42 PM Brent Easton wrote:


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)