From the GitHub Actions logs, it looks like verify_clean.bat
is not running after run.bat, like I intended. I'm guessing I
need to add "call" before both batch files to ensure that
control returns to the caller.
Weirdly, the python program for generating constellation
data did not seem to run, but that failure did not break
the build directly. I am adding an explicity 'py' command
to run each Python program. Also added a check for missing
output constellation test data.
The version of md5sum.exe that runs in GitHub Actions
gets confused when its input file ends with CRLF,
which is weird because this is supposed to be a Windows
environment. So I added a .gitattributes to force
these checksum files to have LF line endings.
In the GitHub Actions CI environment, the program md5sum.exe
resides in "C:\Program Files\Git\usr\bin\md5sum.exe".
Therefore, to execute it, I need quotes around the executable.
The 'windows' directory is mainly useful for
maintainers, not end users. So I moved it out of
the root to reduce distraction for a first-time
visitor.
While I was fixing up resulting breakage in
Visual Studio project files, I noticed I still had
some hard-coded absolute paths that would only work
on my own Windows laptop (e.g. "c:\don\github\astronomy").
I replaced those with relative paths that will work
regardless of what directory the repo is cloned into.
Safari does not work when you try to do this in JavaScript:
const date = new Date('2022-01-08 17:26:59');
Instead, it requires a 'T' between the date and the time:
const date = new Date('2022-01-08T17:26:59');
Fixed this issue in the moonradar.html and positions.html demos.
We still render the date/time as normal, with the space,
but parse it by replacing the space with 'T'.
Thanks to @ebraminio for reporting this!
The code generator was creating slightly different numeric
values for the Pluto state tables and the Jupiter rotation matrix.
I decreased the output precision by one decimal digit.
This should allow the code generator to produce identical
source code on both Linux and macOS.
More work getting MacOS build process to work.
Avoid excessive number of floating point digits of
output in the demo tests, so that insignificant
floating point variations don't cause unit test failures.
I found a mistake in the raytracer's Spheroid class,
thanks to a warning about an unused member variable.
I don't believe it had any effect on the currently
generated images, but it was important to fix it before
I ever do any set operations on Spheroids.
On macOS, there is no 'realpath' command by default.
So I eliminated some more attempts to use 'realpath'
in the demo test scripts.
Renamed the GitHub Actions tests to be consistent:
Astronomy-Engine-Linux
Astronomy-Engine-Macos
The demo tests on Mac OS failed because of very tiny
floating point discrepancies that don't matter.
Changed the output of the "Moon check" so that slight
differences in vector residue no longer fail the unit tests.
Two different people are currently helping me get the
build process working on Mac OS. They both ran into different
amounts of comparison error in the calculations for different
langauges. I updated the 'diffcalc' bash script to have
slightly less strict tolerances, so the unit tests pass.
Based on a discovery made by someone helping me get
Astronomy Engine building on the Mac. In some versions
of g++ (aliased to clang), if you don't explicitly tell
the compiler to treat .c files as C++, it gives a warning
that escalates to an error due to -Werror.
So I added the same fix to the raytracer build:
pass in the option '-x c++'.
When built using g++ as an alias for clang,
as reportedly happens on Mac OS, we need to explicitly
tell g++ (using option '-x c++') to compile astronomy.c
as C++. Otherwise, it will fail with a deprecation warning.
Pluto is so far away that is angular size seen from Earth
is very small. I had to tweak my internal scaling constants
so that the raytracer was able to resolve it.
Added radius data for the Sun, Moon, and remaining planets.
Test the raytracer for all other bodies except the Earth and Sun.
There is a problem with Pluto that I still need to figure out.
Fixed an issue in the doxygen-to-markdown translator I wrote
(hydrogen.js): it did not handle when one #define referred
to another #define. Created a more generic markdown expansion
that works in all cases, and creates embedded hyperlinks.
The program 'realpath' does not come installed on Mac OS.
This caused the bash script 'makedoc' to fail on Mac.
The only place I used realpath was to convert relative
paths to absolute paths for filenames passed to
check_internal_links.py.
It turns out Python has a standard function os.path.realpath()
that does the same thing, so I moved the logic into the
Python script itself. Thus makedoc no longer needs the
realpath program, and the Python function will work on
all platforms.
There is a general lesson here: in the future I will
consider moving more of my scripting logic into Python.
It has proven to be more portable than a mixture
of bash scripts and Windows batch files.
There was one more place where novas.c calls abs()
that caused a warning when compiled on the Mac.
It was passing long int to abs(). To be abundantly
cautious, instead of using labs(), I just manually
check for negative values and toggle -- inline abs.
I received a report that there are compiler warnings
that break the build in novas.c when building on the Mac.
In two cases, long integers are passed to abs(), which expects
its argument to be int. The warnings broke the build
of the 'generate' program. I patched the code so these
warnings should no longer occur, though I do not have a
Mac to test. Will ask the correspondent to test for me.
Refactored the Jupiter imager to be a generic planet imager.
Added support for drawing an image of Venus.
Verified that its extreme crescent phase looks correct
for the current date.
I will add radius constants to astronomy.h for each body I support.
The raytracer now includes the option -s (without a numeric
spin angle on the command line) to automatically calculate
the spin angle needed to bring the planet's north pole
exactly upward in the generated image.
Improved the way I create the rotation matrix that
aims the virtual camera at Jupiter. The camera still
aims exactly at Jupiter, but this time it defaults
to having the left/right pixel direction aligning
with the Earth's equator. By experiment, I can spin
the longitudinal camera axis by -10 degrees and get
a good fit with Jupiter's equatorial plane. I will
adjust this more exactly in a future commit.
Now the raytracer requires the user to pass in
both the pixel width and pixel height on the command line.
This allows for generating non-square images, which will
be necessary for the general case of imaging the moons
with respect to the planet.
