Vassal 3.1.5 Bug Fixes

Joel,

One small bug fix for 3.1.6 in swampwallaby-3.1@5648

A typo when I refactored part of the FormattedString class.

B.

BTW,

3.1.5 seems to have choked off the slow but steady stream of ‘really weird bugs’. Good catch on the threading problems! I wonder how many of the still open bugs could also be put down to that?

B.


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

Post generated using Mail2Forum (mail2forum.com)

Swampwallaby-3.1@5649 has a fix for

Bug [2794703] StackOverFlow using Embellishment level following property

If an Embellishment level following a property is not an integer, it causes
a StackOverflow trying to report the trait name. This was a bug introduced
into 3.1.5 when Bug 2787242 was fixed.

Also modified the error reporting for Embellishment Level following a
property. A value of null for the property no longer reported as an error,
but is interpreted as the First level value so that the initial level is
displayed. Bug fix 2787242 was causing spurious error reports.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Ok, I’ll try to pick these up later today.

(Incidentally, the work I’m doing on editors would also prevent these
problems, unless they were introduced by hand-editing a buildFile, since
the numeric editors do validation as you type. E.g., you can’t get a
number with a decimal point in an IntegerEditor because it won’t let you
type a period.)


J.


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

Post generated using Mail2Forum (mail2forum.com)

A few things to think about.

Most of the Integer fields in traits are actually input as StringConfigurers since they can contain either an integer OR a Formatted String Expression (e.g. $variable$).

I am in the process of replacing Formatted String Expressions with BeanShellExpressions (aka JavaExpressions), but the problem remains that these fields can contain either a basic type (e.g. Integer) validated at Edit time or an expression that can only be evaluated and validated during play

Generalising this, any field at all could potentially (should?) allow the entry of an Expression instead of a basic validated type.

B.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

That’s ok—what’s permissible is determined by the validator you use.

Here’s the Validator interface as I have it right now:

public interface Validator {
public static final int INVALID = -1;
public static final int INTERMEDIATE = 0;
public static final int VALID = 1;

public int validate(String input);

public String fixup(String input);
}

These can be attached to Editors which have text fields. Whenever a change
is made, validate() is called, and will return one of the constants defined
just above it. Valid input is acceptable as-is, and invalid input is clearly
unacceptable. Intermediate input is something which isn’t valid now, but
could be with some editing. (E.g., ‘foo’ is invalid as an integer in base 10.
‘-’ is intermediate because the user could be on his way to typing a negative
number.) The purpose of fixup() is to convert an invalid input into a valid
one (which might not always be possible to do in a sensible way). (For
comparison, this is the same way that Qt does input validation. I found that
it worked pretty well when I used Qt.)

This is what my IntegerValidator implementation looks like right now:

public class IntegerValidator implements Validator {

public int validate(String input) {
// the empty string and a minus sign are intermediate
if ("".equals(input) || “-”.equals(input)) return INTERMEDIATE;

// everything else which does not parse to an integer is invalid
try {
Integer.parseInt(input);
return VALID;
}
catch (NumberFormatException e) {
return INVALID;
}
}

public String fixup(String input) {
return input;
}
}

For expressions, the validator could feed the expressions to the BeanShell,
and check whether it thinks they’re ok, right?


J.


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

Post generated using Mail2Forum (mail2forum.com)

Sure, but how do you envisage the interaction between an integer and a partial expression within the same field?

The model I am working on at the moment is that BeanShell expressions will be enclosed by braces {} to identify them. I need to do this to be able to distinguish BeanShell expressions from Formatted String expressions that may exist from a module created with an older version of Vassal.

B.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Is an integer a valid BeanShell expression?


J.


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

Post generated using Mail2Forum (mail2forum.com)

Beanshell expressions are just java expressions, so any valid java expression is ok, including an integer.


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

In that case, since an integer is a valid BeanShell expression, then
BeanShell can validate all of those.


J.


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

Post generated using Mail2Forum (mail2forum.com)

Lost me. Are you saying we have BeanShell replace the IntegerValidator?


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

No. I’m saying that you have a BeanShellValidator for fields where you
can type BeanShell expressions, and that would cover both the case where
you type a BeanShell expression which is just an integer and the case
where you type a more complex expression.

The IntegerValidator (with some additional bounds) is still useful for
places where we don’t want the user to type a BeanShell expression, like
for the heap size prefs.


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’ve noticed that we seem to be ahead of the bugs now. I doubt that many
of the remaining reports are related to the threading problems I fixed.
Swing threading problems have a particular signature, namely that you get
an NPE in a Swing method which has no obvious cause. Are any of the open
bugs like this (I haven’t checked recently.)

It would be great if we could close out most of these soon.


J.


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

Post generated using Mail2Forum (mail2forum.com)

2756816 seems the only obvious candidate.

B.


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 3.1@5660, trunk@5661.


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 agree. I’m closing that one as fixed.


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 3.1@5662, trunk@5663.


J.


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

Post generated using Mail2Forum (mail2forum.com)