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
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.
This is the first substantial demo of using
the Kotlin version of Astronomy Engine from
a Java program.
Structured the README.md so I can keep adding more and
more demos as separate Java class files.
The `demotest` script builds the code and will run
each demo one at a time, verifying each one's output.
While working on the Kotlin version of lunar libration,
I discovered the other languages were reporting
the Moon's ecliptic latitude and longitude in radians,
which was not the intended units. Pulled changes
from the `kotlin` branch where these angles are
reported in degrees instead of radians.
The existing lunar libration functions in the
other languages (C, C#, Python, JavaScript) were
calculating the Moon's ecliptic latitude and longitude
in radians, not degrees as intended. They have been fixed.
Implemented the libration function for Kotlin.
We are having difficulty getting Kotlin code to build for
both JVM and Native. For now, the priority is to support JVM,
so I am turning off installation of the Kotlin Native compiler.
The Kotlin version of Astronomy Engine was using Java
classes like `Date` and `GregorianCalendar`.
Reworked the code to use a completely self-contained
representation of calendar date/time, just like the C version does.
Now Astronomy Engine does not depend on anything outside of
the Kotlin standard library. This should allow us to use
Astronomy Engine for Kotlin Native apps, Web Assembly, etc.
Updated Java demo to use the new method Time.fromMillisecondsSince1970.
The Mac OS tests failed because the Kotlin Native
compiler created an unexpected directory:
demo/kotlin/native/moonphase.kexe.dSYM/
I fixed this by adding *.dSYM to .gitignore.
Also, the GitHub Action `fwilhe2/setup-kotlin@main`
defaults to an older version of the compiler.
I added an option to specify using version 1.6.20.
Nothing very interesting yet.
Just building a very basic Kotlin Native app
to make sure build and execute work on GitHub Actions,
on Linux and Mac OS. I will worry about Windows later.
Moved the step that creates the fatJar into
the main build process for Kotlin. This is
needed to run the Java demos, and it is good
to fail early if it cannot be built.
