I have committed fixes for the following to bobd-bugfixes3.1
Bug 3463 - Infinite recursion if $PieceName$ specified as Text Label
SVN revision 7658
I think I am the only one who has hit this one.
Bug 3465 - Empty DynamicProperty causes IllegalStateException on loading
SVN revision 7659
This was traced to a propblem with SequenceEncoder that I think is the
culprit for many of the “IllegalStateException No state for Decoder”,
and the older “NoSuchElementException in
SequenceEncoder.Decoder.nextToken”, bugs.
Bug 3472 - Initial value of DynamicProperty is not getting evaluated
SVN revision 7660
This was something I wanted, no one else has asked for it.
I’ll try to review these soon. I’m finding that I’m being overtaken
by events right now…
Should I mark these as TRIAGED? (I only have the option of TRIAGED,
ASSIGNED OR RESOLVED)
TRIAGED indicates that someone has looked at the bug, verified that it
is a bug, and also not a dupe of an existing bug.
ASSIGNED indicates that someone has comitted to working on the bug.
(However, take this with a grain of salt—there are many bugs assigned
to me which I intend to work on, but I’m not working on presently.)
If you’re working on a bug, you should also assign it to yourself. Right
now, everything is assigned to me by default.
RESOLVED means that the bug is fixed and code committed to the repo.
And re: bug 3465 - Do you want me to mark those I think are duplicates
as such?
I have committed fixes for the following to bobd-bugfixes3.1
I started looking at these, but ran into a problem: You didn’t say
which revisions on your branch contain these fixes, and you didn’t
include any log messages with your revisions so that I could tell
what the changes were for.
Sorry about no commit message, the eclipse plugin didn’t prompt me for a message and I didn’t think about it until after I had committed all of the changes. I will have to research how to add commit messages before I do anymore work.
Bug 3463 - Infinite recursion if $PieceName$ specified as Text Label
SVN revision 7658
Sorry about no commit message, the eclipse plugin didn’t prompt me for a
message and I didn’t think about it until after I had committed all of
the changes. I will have to research how to add commit messages before
I do anymore work.
Bug 3463 - Infinite recursion if $PieceName$ specified as Text Label
SVN revision 7658
There’s a problem with this commit, namely that you’ve entirely replaced
SequenceEncoder.java instead of commiting just the changed lines. I’m
not sure how you did that, as it’s not what I would expect to happen by
default.
Sorry about no commit message, the eclipse plugin didn’t prompt me for a
message and I didn’t think about it until after I had committed all of
the changes. I will have to research how to add commit messages before
I do anymore work.
Bug 3463 - Infinite recursion if $PieceName$ specified as Text Label
SVN revision 7658
There’s a problem with this commit, namely that you’ve entirely replaced
SequenceEncoder.java instead of commiting just the changed lines. I’m
not sure how you did that, as it’s not what I would expect to happen by
default.
I see what’s wrong: You’re saving files with DOS newlines instead of
UNIX ones. All of our source files use UNIX newlines; if you’re using
DOS newlines, it screws up diffs: What I was seeing when I merged this
change was that every single line in the file was different—due to
to each ‘\n’ having been converted to ‘\r\n’.
There’s a setting in Eclipse which you can change to avoid this problem:
Sorry about the newline thing, I will look at my other changes and make sure all are just LFs.
I missed one issue in Vassal, Embelishment.oldGetType(). Nothing in Vassal uses it but I suppose some custom module might so I should make a change to that as well. Sorry about that.
I haven’t checked non-Vassal code for use of SequenceEncoder, which modules should I check?
Sorry about the newline thing, I will look at my other changes and make
sure all are just LFs.
I missed one issue in Vassal, Embelishment.oldGetType(). Nothing in
Vassal uses it but I suppose some custom module might so I should make a
change to that as well. Sorry about that.
This is in reference to which of the three bugs?
I checked the log for Embellishment. Embellishment.Ed.oldGetType()
I deprecated in 4062, back in 2008. It might well have been an
oversight that I didn’t also deprecate Embellishment.oldGetType() at the
same time.
Generally, we do want to keep deprecated code working until we remove
it, to give anything which depends on it time to stop relying on it.
I haven’t checked non-Vassal code for use of SequenceEncoder, which
modules should I check?
Practically any module with custom Buildables would use it.
Have fixed the newlines, the tests had Windows newlines so I have changed those in rev 7666.
Embellishment.oldGetType() is fixed in rev 7667
I don’t wish to appear stupid (ha!) but how do I know which modules have custom buildables? Do you download all the modules on the Vassal site to keep an eye on what custom code there is in use?
Have fixed the newlines, the tests had Windows newlines so I have
changed those in rev 7666.
Embellishment.oldGetType() is fixed in rev 7667
I don’t wish to appear stupid (ha!) but how do I know which modules have
custom buildables?
It’d not a dumb question. The only way to tell is to check each module.
I’m not suggesting you do that. An easier way would be to ask some of
the more knowledgable module designers for suggestions of what to check.
I’m affraid I can’t offer any suggestions myself here.
Do you download all the modules on the Vassal site
to keep an eye on what custom code there is in use?
No. Right now we have no idea how much custom code is out there.
Sorry about no commit message, the eclipse plugin didn’t prompt me for a
message and I didn’t think about it until after I had committed all of
the changes. I will have to research how to add commit messages before
I do anymore work.
Bug 3463 - Infinite recursion if $PieceName$ specified as Text Label
SVN revision 7658
No I don’t think so - but I know what to test when it comes out . It’s an enhancement Bob wanted like he says, not a bug. Custom mods should rely/worked with the basic behavoior of DP and not expect initial value to evaluate.