Vassal 3,2 and 4

Does anyone know roughly when we might expect to see Vassal 3.2? And Vassal 4? I know these things are a bit difficult to predict but are we talking weeks months or years here?

Thus spake Slarty:

Does anyone know roughly when we might expect to see Vassal 3.2? And
Vassal 4? I know these things are a bit difficult to predict but are we
talking weeks months or years here?

Weeks for 3.2.0-beta1. Months for (usable) V4 demos. 4.0.0 has to be
able to replace 3.2, so there will likely be a significant period where
we have V4 demos which are usable for most things, but are not yet a
replacement for 3.2 in every respect.


J.

Excellant news.

Do you need any help? I’ve done a bit of programing in the past but mostly RPG and Oracle /PLSQL so I’m program literate but I won’t be much help on the programming front at least initialy, although I would be able to carry out a little testing etc if you wish.

Thus spake Slarty:

Excellant news.

Do you need any help? I’ve done a bit of programing in the past but
mostly RPG and Oracle /PLSQL so I’m program literate but I won’t be much
help on the programming front at least initialy, although I would be
able to carry out a little testing etc if you wish.

  1. There is a lot of bug fixing work to be done on the 3.1 and 3.2
    branches. If you look in the bug tracker under the ‘3.2’ milestone,
    you’ll see bugs which have to be fixed before we can release 3.2:

vassalengine.org/tracker/bug … tone=3.2.0

Bugs marked with the 3.1.19 milestone should be fixed for 3.1.19:

vassalengine.org/tracker/bug … one=3.1.19

Any bug marked NEW which has “ABR” (Automatic Bug Report) in its summary
is one which hasn’t been looked into:

vassalengine.org/tracker/bug … list_id=58

Lots of these are duplicates of other bugs, and it would be helpful to
have them marked as such. In other cases, it would be useful to
determine what triggers the bugs, because we can’t normally fix bugs we
can’t reproduce.

  1. Using 3.2 builds and reporting back on problems you find is helpful.

  2. There’s a great deal of design work to be done for VASSAL 4, which I
    want to get started on soon. I’m planning to present a rather largish
    design document in a week or two, at which point I hope people will pick
    at it and help improve it.


J.

I will certainly look at the Vassal 4 documentation when available.

In the mean time I’ll have a look through the bug list to identify duplicates. I have found a couple already I think 3564 and 3703 are duplicates of 2994 so I have marked them as such. I think you were sent an email to confirm.

Before I go through more of these how certain do I need to be that I have found a duplicate to mark it as such?

  1. Is Exactly the same title sufficient?

  2. Exacly the same title but excluding anything vague or short like “syntax error” or anything else that might refer to different things?

  3. Same as 2 but must do some investigation as well to make sure?

In the above example “ABR: IllegalComponentStateException: component must be showing on the screen to determine its location”
It’s the same title it’s specific and although I havn’t done much investigation I can almost invisage what has happened.

Is it sufficient to just mark them as duplicates or do you want any further comment as to why or which others are linked?

Let me know what you think and I will process a lot more

Thus spake Slarty:

I will certainly look at the Vassal 4 documentation when available.

In the mean time I’ll have a look through the bug list to identify
duplicates. I have found a couple already I think 3564 and 3703 are
duplicates of 2994 so I have marked them as such. I think you were sent
an email to confirm.

Before I go through more of these how certain do I need to be that I
have found a duplicate to mark it as such?

  1. Is Exactly the same title sufficient?

  2. Exacly the same title but excluding anything vague or short like
    “syntax error” or anything else that might refer to different things?

  3. Same as 2 but must do some investigation as well to make sure?

The way to check for duplicates is to compare stack traces in the
attached errorLogs. This is slower, but more accurate, and eventually
you start to recognize stack traces. (I know I have.)

In the above example “ABR: IllegalComponentStateException: component
must be showing on the screen to determine its location”
It’s the same title it’s specific and although I havn’t done much
investigation I can almost invisage what has happened.

Is it sufficient to just mark them as duplicates or do you want any
further comment as to why or which others are linked?

If there’s an email address in the duplicate, note it in the bug of
which it is a duplicate. (The point of this is so that anyone looking
at the “master” bug doesn’t have to hunt through all of the dupes in
order to figure out who to email.

Let me know what you think and I will process a lot more

Great! Please do.


J.

“The way to check for duplicates is to compare stack traces in the
attached errorLogs. This is slower, but more accurate, and eventually
you start to recognize stack traces. (I know I have.)”

OK I can do that, it will just take a bit longer, but baring in mind that I’m not at all familiar with Java, I will need some ground rules. I compared an existing pair of duplicates and I see that the bottom 6 rows from the stack trace matched. Would this be sufficient in every case? What if only the last 4 matched? Presumably the more that match the better but Is there anything difinitive or a rule of thumb? If you’re going to say well that depends, then unless what it depends on is reasonably clear cut it could prove problematic. The last thing I want to do is to mark up a load of bugs as duplicates when they’re not.

Thus spake Slarty:

“The way to check for duplicates is to compare stack traces in the
attached errorLogs. This is slower, but more accurate, and eventually
you start to recognize stack traces. (I know I have.)”

OK I can do that, it will just take a bit longer, but baring in mind
that I’m not at all familiar with Java, I will need some ground rules. I
compared an existing pair of duplicates and I see that the bottom 6 rows
from the stack trace matched. Would this be sufficient in every case?

No. The nesting of calls is bottom up, so the outermost calls are the
ones at the bottom. Matching the bottom six lines tells you basically
nothing (unless you’re dealing with a stack trace that’s only six
frames deep). What you want to be looking for is matches from the top.
If the top several lines match, that’s a good indication that you have
a duplicate.

If you’re unsure whether two bugs are duplicates, ask.


J.

I’ve done a few now and seem to be getting the hang of it.

However it does seem painfully slow. Is it possible to access the error logs in any other way? If we could search a file containing all of the text from all of the logs then duplicates could probably be found a lot quicker simply by searching for the first line or 2 from each code in all of the others to see if it was the first line in any other. Obviously some care would be needed, but I think it would be much easier. If no such file is available then it might even be possible to copy and paste them into a small set of word docs in a single folder and search that. Might even detect old bugs from old reports that have already been fixed.

Thus spake Slarty:

I’ve done a few now and seem to be getting the hang of it.

However it does seem painfully slow. Is it possible to access the error
logs in any other way? If we could search a file containing all of the
text from all of the logs then duplicates could probably be found a lot
quicker simply by searching for the first line or 2 from each code in
all of the others to see if it was the first line in any other.
Obviously some care would be needed, but I think it would be much
easier. If no such file is available then it might even be possible to
copy and paste them into a small set of word docs in a single folder and
search that. Might even detect old bugs from old reports that have
already been fixed.

I believe the right way to do this is to hash the stack traces, similar
to what RedHat’s Bugzilla instance does. Stack traces which hash the
same are from the same bug with probability close to 1. However, doing
this would require some programming effort on the server side. I likely
will do the work required for it for V4, but that work will be somewhat
different from what’s needed for V3.


J.

  1. There’s a great deal of design work to be done for VASSAL 4, which I
    want to get started on soon. I’m planning to present a rather largish
    design document in a week or two, at which point I hope people will pick
    at it and help improve it.

Hi Joel,

Any progress on that front? Any discussions that I might be missing?

  • M.

Thus spake Michael Kiefte:

  1. There’s a great deal of design work to be done for VASSAL 4, which I
    want to get started on soon. I’m planning to present a rather largish
    design document in a week or two, at which point I hope people will pick
    at it and help improve it.

Hi Joel,

Any progress on that front? Any discussions that I might be missing?

I was hit with a combination of being ill for 6 weeks, having guests for
half of April, and my company being in the run-up to releasing our first
product. With two of the three, I could have made progress, but as it is
I’m still trying to get 3.2-beta1 out.

We are moving again on 3.2, though; I am, perhaps optimistically, aiming
for 3.2-beta1 by the end of May.


J.