Upgrades, and introduction of utils namespace #24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Haven't quite figured out how to have Nix also generate the haddock, but at least it currently generates a cabal build + the tarball.
This is not _oficially_ part of swiss ephemeris, but it was shared by Alois in a forum message and expressed to have the same license: https://groups.io/g/swisseph/message/5564
* Correct some includes in the C libs to actually work within the existing SWE ecosystem. * Introduce very basic bindings to the grav_group* functions.
A bit clunky in the API, but it makes sense (?)
Leverages the somewhat naïve `housesToCusps` function, also introduced, for the EZ versions.
* Couple of tests demonstrating both `groupGrav` strategies * Use `CInt` for the boolean argument to `group_grav2` to be compatible with haskells <= ghc8.0.2
Also, introduce tentative testing on ghc 9!
This is but one of the tiny things we had capitulated on for ghc <= 8.0.2 (also, `(<>)` from semigroup included in Prelude -- not a fan of `(++)`)
Using a somewhat brutalist "I see int, I write double" approach. Trying to lay the groundwork for avoiding precision-losing roundtripping of positions.
* Accepts instances of the new `HasEclipticLongitude` class: anything that can be located in the ecliptic. That way, we can send any product of `(Planet, HasEclipticLongitude)`, vs. being tied to `EclipticPosition` * Returns the `GlyphInfo` objects only: this avoids the wasteful "pairing back up" state, but it preserves enough information to meaninfully zip it back up -- by the caller, not us.
There's a few functions that expect a char* (string) but are _not_ guaranteed to initialize it. One should either provide an array of characters with an explicit length, or a NUL-terminated string. I'm chosing the latter to strike a balance between memory conservancy and safety, via `withCAString` (since strings seem to be ASCII coming from SWE.) We could also use `withCAStringLen`, which seems to be equivalent to the `allocaArray` approach being replaced here. See #9 and: https://www.haskell.org/onlinereport/haskell2010/haskellch27.html
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ChartUtilsnamespace, with functions to help situate celestial objects in charts (fixes Include the "grav_group" functions for graphics assistance #22 )errstrings: usewithCAString(vs.allocaArray 256, ) should be memory safe, without being wasteful. Will keep an eye out for errors of a similar flavor to Fixes memory leak caused by error string. #9