On Fri, 12 Oct 2012 01:39:25 PM Lone_Wolf wrote: > I've been running svn builds compiled for java7 for some time now and > noticed the log increased a lot with wanrings, npes etc after playing a > while.
Which is to be expected with intrusive AI changes afoot. FWIW, the current
state is that:
- I can reliably run a single case of my standard 7-AIs-to-1700 test game/s
and it will complete without a total crash
- I can usually run a single game without seeing caught AI exceptions in the
logs
- I can *not* usually run an overnight run of 20+ test games without seeing
caught AI exceptions in the logs. This is where I am working ATM, hunting
down and fixing the exceptions one by one.
- The efficiency of the AI transport code continues to improve. Every crash
fixed helps.
- However, there remain cases where the AI does something lame. For example
ATM there are mysterious cases where it aborts a delivery when it is already
underway. I have an evil piece of emacs-lisp that reads FreeCol log files and
threads each AI mission, so you can step through exactly what steps were
taken. Every time I run this, and examine the resulting TransportMissions in
turn, I get further before finding a case where a poor choice was made.
One day I hope to get all the way through the log.
- Save/restore `works' only in the sense of not crashing utterly. AIGoods
remain problematic, but then again, they were known broken before I started
kicking the AI, and at least now there should be enough logging to track down
where they are going astray. This is next on the list after I can run
overnight tests without exceptions, or perhaps, when I can run overnight tests
without exceptions, these bugs will have been fixed.
- AI-only games are not that realistic, games involving humans are to be
expected to throw up other bug categories
- There are some new warnings being generated (`Can not claim transportable'
IIRC) that are turning out to be mostly harmless. A review of the logging is
the last thing to do.
> I ran
>
> find . -type f -exec grep -l 'SuppressWarnings' {} \;
> from the src/net/sf/freecol folder and found many files where
> SuppressWarnings is used.
grep -r src/net/sf/freecol/server/ai -e Suppress
=> 7 "unused" cases, all for the class Logger. These are expected.
No new warning suppressions have been added in the destabilizing AI changes.
> further analysis showed there are 3 kinds of warnings that are suppressed :
>
> A. @SuppressWarnings("static-access")
This looks odd, and removing it does not generate compiler warnings for me,
so I removed it, and a couple of now incorrect "unused"s in svn.10209. Folks,
feel free to revert if your compiler whines about this.
> B. @SuppressWarnings("unused")
We have a convention in FreeCol that every class is allowed to grow a Logger.
At any point in time, some are in use, some are not, and when they are not the
warning is suppressed. The overhead of unused loggers is minor
and harmless We could probably do this more elegantly, but there are far
worse problems. IMHO of course, as I use logging a lot and encourage it.
> C. @SuppressWarnings("unchecked")
Here you have a point. In an ideal perfectly type-secure codebase we would
not have any of these. FreeCol is not (yet) such a codebase, nor is that a
realistic goal ATM while we are at least claiming to be able to build FreeCol
on Java5, 6 and 7. There are several core classes that are now type-
qualifiable in 7 which were not in 5, which annoys Java7 compilers.
> The SuppressWarnings don't seem to come with many explanation why they are
> used.
The (right) compiler will explain category C cases if you remove the warning
suppressions:-).
> Personally i feel using SuppressWarnings hides problems in the code that
> need to be taken care of, not hidden.
Patches welcome to fix the category C cases. The patched code should compile
without warnings in Java5,6 and 7 environments. I had a brief crack at this a
while back without success. Good luck!
> Are there disadvantages to removing/commenting out the SuppressWarnings ?
Does `mpope gets annoyed by compile time warnings' count:-)? I compile
FreeCol a lot, and stepping though repeated warnings is tedious, so I either
fix them if I can, suppress them if appropriate, or complain about them on this
list. AFAICT ATM the FreeCol codebase only contains suppressed warnings that
are harmless (B) or I can not fix (C).
Cheers,
Mike Pope
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ Freecol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
