It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
The help pages for the Java and Kotlin demos mention
a Windows batch file `rundemo.bat`, but they did not exist.
I created them, so now the documentation is correct.
Three of the lunar eclipse demos (Python, Java, Kotlin)
provided a less than ideal example of efficient computation.
They were wasting a lunar eclipse search by calculating it
but not printing it. Now after printing exactly 10 lunar
eclipses, stop running immediately.
Added Java demo to search for rise/set/culmination
of the Sun and Moon.
Also added the missing entry for the Kotlin
rise/set/culmination demo that I had forgotten.
Added Kotlin and Java demos for calculating Jupiter's moons.
Illustrates correcting for light travel time.
I added named getters for the 4 moons in `JupiterMoonsInfo`,
because in Java it was really ugly to write
`jm.getMoon()[0]`, etc.
I had to add a new method `Vector.withTime` to work around
the error checking that throws an exception if vectors
from different times are added.
Also made Kotlin constants public:
MINUTES_PER_DAY
SECONDS_PER_DAY
MILLISECONDS_PER_DAY
Deleted the do-nothing placeholders for installing
the Kotlin Native compiler. We are not going to support
Kotlin Native for now.
Removed redundant installation of pylint from the
Windows commit_hook.bat.
Other batch file cleanup, now that I know "||" works in Windows.
I made the scripts for testing the demos for
C, C#, JavaScript, and Python follow the improved
pattern used for Java and Kotlin: much smaller
and easier to maintain thanks to bash functions.
I also reworked how the Java and Kotlin demos
process errors in the command line arguments.
Using exceptions that are caught by main() rather
than directly exiting the process where the errors
are detected.
I found that it is possible to use the "||" operator
in Windows batch files, and it works the same as the
"||" operator in bash scripts.
This inspired me to rework the bash scripts and
Windows batch files for running the Java/Kotlin demo
tests to be much more compact using functions/subroutines.
The best part is, the new approach will make it much
easier to add more demo tests in the future.
Removed the "now" test from Java demos, because it
does not follow the same pattern as the other demos,
plus it is not really demonstrating astronomy calculations.
Starting working on the Positions.kt demo; but not finished yet.
I refactored the unit tests for all the demo programs
to follow a different pattern that makes it simpler
to add more demo tests in the future.
The main thing is that correct output and generated
output are now in separate directories `correct` and `test`.
I have moved the test scripts from `test/test` to `./demotest`
in all the langauge demo directories.
This makes it simpler to clean up any stale generated
files before each test run by `rm -f test/*.txt`.
I stumbled across this while making the Java demo tests,
and it was a better solution, so now all the other languages
are consistent with the Java demo tests.
In the C demo tests, I also decided to compile all the
binary executables into a subdirectory `bin` that can
be cleaned out before each run, to make sure there are
no stale executables from an earlier run.
As I add more Java demos, it will make the code more
compact to factor out argument count checking, etc.
Reworked as a table-driven model instead of using `switch`,
so that I will be able to add new demos more concisely.
Run the Java demo unit test as part of the automated test suite.
If the test fails, print the xml test results to the screen,
so if it happens in GitHub Actions, we can see what went wrong
and diagnose the problem.
