candidate for beta7, please try

I’ve uploaded 3.1.0-svn4765 as a candidate for 3.1.0-beta7. Please try this
and let me know if you encounter any serious problems which didn’t exist in
beta6.

nomic.net/~uckelman/tmp/vassal/

Wrong number: 4756 I think

Post generated using Mail2Forum (mail2forum.com)

svn4766 contains fixes for Bugs 2493325 and 2475197, which were causing the Mac bundle to crash, and giving us lots of strange error reports, respectively.

Once I’ve heard from someone on Windows and MacOS that this build works, I’ll
release it as 3.1.0-beta7.

nomic.net/~uckelman/tmp/vassal/

Opens fine on Mac - 10.4.11 - has the New Icon as well (looks great)

Loaded up Command and Colors 3.1 Ancients Module just fine as well as V40k and watched a game in action.

On Jan 8, 2009, at 4:52 AM, uckelman wrote:

OK. Intel Core-2 Duo. Mac OS X, v. 10.5.6

The application launches correctly.

In the Finder, the application shows its icon nicely.

This works across all of the various views. In fact, the “cover flow”
view is really stunning. (See attached, if it makes it).

In the doc, the Vassal program shows its icon nicely.
Launched games, however, show only a generic application icon.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake Thomas Russ:

Yeah, that’s not bad.

I suspected this would be the case, hence my question about it. I’ve added
the ‘-Xdock:icon’ option to the command line which launches the Player and
Editor. Try this build and let me know what you see:

nomic.net/~uckelman/tmp/vass … macosx.dmg


J.


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

Post generated using Mail2Forum (mail2forum.com)

On Jan 8, 2009, at 11:56 AM, Joel Uckelman wrote:

OK. Here’s the quick test results.

The icons now appear for both Player and Editor. But they have a
solid white background instead of being transparent. I assume that is
a simple matter of choosing which icon to use? See the screen shot.
And yes, I have very small icons…

BTW, if there were some differentiation in the icon for the editor and
player that would also be nice. Even something as simple as adding a
“E” or “P” in a corner. That way the different program instances
look different in the dock. But that’s really a minor issue. And it
might reduce the aesthetics. Perhaps something more subtle like using
a different hex or letter color (or shade) would work.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake Thomas Russ:

That’s weird. I didn’t create any test icons without transparent backgrounds,
so I don’t know why that’s happening.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Final client change to display CRC committed to swampwallaby-work@4789. Also collected all existing CRC related code into one place.

I just have two bugs to go…

B.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Good idea collecting all of the CRC stuff in one place. I have a few
comments on the CRCUtils methods:

  1. getCRC(File) and buildCRC(File,CRC32,bytes) both create a bare
    FileInputStream, which is ok so long as we do buffering ourselves. The
    byte buffer in buildCRC(InputStream,CRC32,int) is kind of small, though.
    People usually use 4096- or 8192-byte buffers. (You’re never going to have
    a drive which does reads in blocks smaller than 4kB these days, anyway.)

  2. The use of getCRC(List files) is going to be error-prone unless
    we always make sure that the list of files is always in the right order.
    (E.g., we’re in trouble if ZipFile gives us Files in a different order
    on two different platforms…)

  3. Right now, there are no public methods where the caller passes in an
    existing buffer to be used when calculating the checksum. This makes a
    big difference when you’re going calculate a lot of checksums consecutively,
    as we do when replacing files in a ZIP archive. If you look at
    ArchiveWriter.write(boolean) on the trunk, we create exactly one buffer and
    reuse it for all of our stream-to-stream copying and checksums. Consider
    what happens for a module containing about 3000 files if we create a new
    buffer each time we do a checksum…

So, what I suggest is adding a version of each of the getCRC() methods
(except the one which acts on a byte array directly) which takes a byte
as its final argument and passes it to buildCRC as the buffer to use.
Then, have the existing getCRC() methods create a buffer of the default
size and pass that to the new getCRC() methods which accept a buffer.
(This is exactly the pattern I used in IOUtils. Look at the pair
copy(InputStream,OutputStream) and copy(InputStream,OutputStream,byte)
for an example of this.)


J.


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

Post generated using Mail2Forum (mail2forum.com)

Hi Joel,

Changes committed to swampwallaby-work@4801.

Done.

I guess so, but the only use I am making of it at the moment is to accumulate a CRC over the module and all loaded extensions. The order of extensions will be the same on all platforms.

I am going to leave it like this with a comment in the source that it is up to the calling routine to ensure a consistent ordering of the file list.

I’m not sure I understand your ZipFile comment, the only thing you would get is ZipEntries, which you cannot pass to this function.

Done, plus have chaned the Zip writing code to use these.


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 thinking if you wanted to calculate a CRC32 for the contents of
a ZipFile, you might use something like this by feeding it a list of Files
obtained that way. This wasn’t meant as a complaint, just something to
be careful of.

Looks good, I’ll pick this up in the morning.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Merged to trunk@4804.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

One more thing:

I noticed that you declare a size variable in various places in CRCUtils
which but never use the value, and similarly for the bytes argument to
buildCRC().

When you call buildCRC(InputStream in, long crc, int bytes, byte buffer)
in ArchiveWriter.write(), I think you must be intending for checksum and
count to be passed by reference—but, like all arguments in Java, they’re
passed by value, and so the original variables will still be zero after
buildCRC returns. (For contrast, if you were doing this in C++, you could
pass pointers or references to these two variables and have it work the way
you intended.)

So, right now what’s in the trunk won’t successfully write a ZIP archive.

I’m unsure what the best way to go here is. We need to know the sizes of
new files when we add them to a ZIP archive, and at the time I wrote this
code, the simplest way was to keep count as we calculated the CRC. This
isn’t the only way to get the file size—we could use File.length() to
stat the file, e.g., or we could revert this part of the code back to
what it had been.

It’s obnoxious that ZipOutputStream requires that you already know the
file size and CRC before writing to the stream. Otherwise there would
be a very simple solution to the problem—have the stream calculate
the file size and CRC for you as you write the file.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake Joel Uckelman:

BTW, I’m writing a nicer API for handling ZIP files right now, so we should
be able to avoid the whole mess in ArchiveWriter…


J.


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

Post generated using Mail2Forum (mail2forum.com)

Is this for 3.1? So I can leave it to you to clean up my mess :slight_smile:

B.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Yes, I’m just about done. It’s a cover for ZipFile which will work the way
you’d expect it to, instead of how ZipFile actually works. I wasn’t planning
to do this for 3.1, but my residual irritation with ZIP handling became
overwhelming.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Have a look at the VASSAL.tools.io.FileArchive interface and the
VASSAL.tools.io.ZipArchive implementation on the uckelman-work branch.

What I’ve done is create a wrapper for ZipFile which

(1) supports both reads and writes,
(2) caches modifications to disk, so as not to use a huge amount of memory
(3) is automatically reopened if a read or write operation is attempted
after closing
(4) can be copied from another FileArchive
(5) is easy to add files to, and remove files from

This particular implementation supports multiple concurrent reads from
different threads, but only a single write operation at a time (this is
enforced through a ReadWriteLock, so you can attempt reads and writes
whenever you want).

Please comment on the API for FileArchive. Does it provide all of the
functionality we want? Is anything missing? Cumbersome? Misnamed?

BTW, I found a solution to the CRC32 problem as a side-effect of doing this:
ZipArchive writes added files out to temp files when you add them. There’s
an API class called CheckedOutputStream which will calculate Checksums
for you on the data passing through it—I extended it to count bytes as
well. As it happens, the only files for which we don’t already have a valid
CRC32 and size are exactly the ones which have been added, and this is
the only place where we need a byte count. So, I should be able to simplify
CRC32Utils a bit now.

Another side-effect of this is that we can stop using ArchiveWriter for
storing preferences. The code in ArchiveWriter for handling prefs was
always an odd fit with the rest of the code there.


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’m uploading a build containing ZipArchive now. Please check the following
things:

  1. Are your preferences read correctly? Saved correctly?
  2. Can you open modules? Open games? Save games?
  3. Can you create a new module and save it?
  4. Can you save an edited module? Do the changes take if you reopen it?
  5. Can you Save As after editing? Is the new module modified? Is the old
    module modified if you reopen it, after having not saved it?
  6. Is anything much different in terms of performance?

The build to check is svn4819:

nomic.net/~uckelman/tmp/vassal/

WARNING WARNING WARNING

Do not use svn4819 for anyting serious—just use it to make these
checks. I make no guarantees that it won’t kick your dog or eat your
children.


J.


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

Post generated using Mail2Forum (mail2forum.com)

On Vista - Didn’t quite kick my dog, but…

Starting up the Module Manager, I get:

java.io.IOException: Unable to overwrite C:\Users\Brent\VASSAL\Preferences, data written to C:\Users\Brent\VASSAL\tmp4637955216810390320.zip instead.
at VASSAL.tools.io.ZipArchive.flush(ZipArchive.java:447)
at VASSAL.preferences.PrefsEditor.write(PrefsEditor.java:252)
at VASSAL.preferences.Prefs.write(Prefs.java:222)
at VASSAL.preferences.Prefs.getGlobalPrefs(Prefs.java:245)
at VASSAL.launch.ModuleManager.main(ModuleManager.java:96)

Trying to open a module I get

java.io.IOException: Unable to overwrite C:\Users\Brent\VASSAL\Preferences, data written to C:\Users\Brent\VASSAL\tmp4406703482057473926.zip instead.
at VASSAL.tools.io.ZipArchive.flush(ZipArchive.java:447)
at VASSAL.preferences.PrefsEditor.write(PrefsEditor.java:252)
at VASSAL.preferences.Prefs.write(Prefs.java:222)
at VASSAL.preferences.Prefs.getGlobalPrefs(Prefs.java:245)
at VASSAL.i18n.Resources.(Resources.java:90)
at VASSAL.launch.PlayerWindow.(PlayerWindow.java:68)
at VASSAL.build.GameModule.(GameModule.java:137)
at VASSAL.launch.BasicModule.(BasicModule.java:74)
at VASSAL.launch.Player.createModule(Player.java:155)
at VASSAL.launch.Player.launch(Player.java:112)
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)

Deleting the Preferences file, I get the same thing, but a nearly empty Preferences file eventually gets created.

Brent.


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

Post generated using Mail2Forum (mail2forum.com)