TM 0.5 priority repairs and new features

[Jim Eshelman]

In this thread, I will build my "high priority" TM fix/add list. By this I mean: There are a few places TM is broken or non-ideal, and a few places that new details could be enormously valuable, none of which individually will take a lot of work - so we could have them quickly. As items are finished, I'll cross them out or delete them. (The list - this first post on this thread - will be an evolving post.)

My recommendation to Mike V is that we roll these out as new small versions (0.5, 0.5.1, etc.) as work is completed. This way, whatever is done will be available to people. (We lost so much because Mike N was holding everything back until he could unveil a finished 1.0 version.)

If there is anything anyone thinks I've missed, please say so. (It may be a matter of priority, with other items still left on the general Wish List thread.) If you want to request other future expansions, please start a new thread.

NOTE to Mike V: Here is the new Natal_Default file format Mikestar13 created to include expansions he had in mind: https://www.solunars.com/viewtopic.php? ... 846#p52001

1. Add angles to the data table Add lines for MC, As, EPa, and Vx to planet data table with only select columns showing for each. Vx only shown if Vx is enabled in Chart Options. - Concurrently remove the display if EP-a and Vx from the face of the chart. [Added, and minor angles dropped from chart face. Debugging some of the values currently.]
2. Add Novien table to bottom of chart page. Create toggle in Chart Options for whether to include it. [The entire thread is interesting for many dev reasons. Mike N was going to create an entire Novien setup page with many options. I think originally it can be one standard with an on-off toggle.]
3. Add Sidereal Astrology Landmarks as an integrated page.
4. Final edits of title page text.
5. Can this be recompiled for MacOS? If it's just a matter of using a different compiler, we should do this (and talk about it compiling for Android and iOS). [This can wait until after 1.0 if necessary, we won't be evangelizing the program until then.]
6. When these things are complete and stable, republish as 1.0.

At the time this is ready to roll into a version 1.0 release, we may want to consider adding a few more relatively simple fixes and tweaks from the TMSA Wish List thread (which i will restore to its primary place after this "priority" list is complete).

COMPLETED:

• BUG/FEATURE FIX - Repair strength values for minor angles.
• FEATURE FIX - Remove auto-advance code from New Chart page and other input fields.
• Add Vertex/Antivertex markers to G field
• Add Meridian Longitude (ML) column after Altitude column.
• With ML available, allow Prime Vertical Parans display with a toggle in Chart Options.
• Amend naming conventions for Chart Options default files, e.g., change Default_Natal.opt to Natal_Default.opt. NOTE to Mike V: Here was Mike N's plan on how to make option files more stable.
• Add my new single-equation angularity formula ("Eureka") as a third option of angular rating (with selection option in Chart Options).
• Add the Needs Hierarchy initially excluding the (rarely relevant) Stationary characteristic.
  
• Add Planetary Stations (if easy to grab from Swiss ephemeris). If this is done, include this characteristic in the Needs Hierarchy.

[Mike V]

Thank you for condensing all of this into a single thread! It makes my job much easier.

Some initial thoughts...

My recommendation to Mike V is that we roll these out as new small versions (0.5, 0.5.1, etc.) as work is completed. This way, whatever is done will be available to people. (We lost so much because Mike N was holding everything back until he could unveil a finished 1.0 version.) I know he will need time to initially get up to speed on how Mike N packaged his program.

Totally agree. I like more releases rather than fewer. If the updates are really minor, people can always decide to wait on a later update. It also means the difference between a release that is "oh oops, that's broken isn't it" and the previous one is relatively small.

NOTE to Mike V: Here is the new Natal_Default file format Mikestar13 created to include expansions he had in mind...

JSON makes sense as the file format for that. I added it to my personal notes. I think I can make some tweaks to simplify this a bit too.

Can this be recompiled for MacOS? If it's just a matter of using a diffrent compiler, we should do this (and talk about it compiling for Android and iOS).

For MacOS and Linux, the short answer is "given enough time, absolutely." The longer answer for all the non-Windows platforms is this:

• The primary thing that needs to be recompiled is the actual Swiss Ephemeris binary. I've already done that (for both MacOS and Linux) for my personal projects and confirmed it works, so while I'm not positive that my binaries are based on the absolute newest version of the Swiss Ephemeris anymore, recompilation can be and has been done. (I'd have to re-figure it out again with the newest version; it's been a few years.)
• Secondarily, some software development packages (Python packages, in this case) may have dependencies on system packages, like Windows DLLs. I don't know if this is the case with TMSA; I'll have to discover it piece by piece as things fail to build and I chase down the errors. Python code per se runs just fine on any (desktop) OS, but depending on what 3rd party packages Mike N used, we may or may not have to figure out workarounds for them.
• Mobile use is much harder. There are a large number of roadblocks. First and foremost are that the project would have to be completely rewritten twice, once for Android in Kotlin/Java/Rust/C++, and again in Swift/Objective-C for iOS. It is essentially a brand new project. (I am not convinced that the current write-once-deploy-everywhere cross-platform toolsets, like React Native and Flutter, are any good.) Secondly, the Swiss Ephemeris would have to be recompiled for those architectures (iPhones mostly use ARM architectures, apparently); that can likely be done but I don't know for sure until I try. Lastly, we would have to figure out how to actually interact with that library on a mobile device - a cursory google search tells me that this is not trivial.

Regarding mobile use: a quick test using iPhemeris on iOS (which is based on the Swiss Ephemeris) shows that it does work offline, i.e. they're not calling a server somewhere else that actually has the Swiss Ephemeris code on it, so they must have it bundled into the iOS app. I'm also vaguely aware of an Android app that the Astrodienst folks released (Astro Gold, maybe?). Evidently, several people have solved it, but I don't know how exactly. The biggest issue is still just that a desktop app like this is not plug-and-play on mobile devices.

This cross-platform issue is why my own project (currently titled Nova) is going to be a web application - as long as you have internet access, it doesn't matter what device you're on. (Plus, you'll almost never have to intentionally update your version, etc etc.)

I'm working on adding the other notes into Trello, and I'll ask questions on those posts.

[Jim Eshelman]

I suspect we think similarly about version numbering (and perhaps you have an industry standard practice). I think in terms of primary version being generational, .x being primary significant releases (highly distinguishable, usually by significant feature distinctions or the rare "I just want to abandon that last one"), and .x.x being minor changes (essentially builds). This provides strong guidance to users who can be advised to always get x and x.x versions and, unless strongly advised otherwise, do as you please on x.x.x.

Sounds like: Let's not worry about the phone right now. (An eventual webapp deployment might be good not only for solunars.org deployment but also because the layout of TMSA charts is already so suited for a portrait phone display). I'm also not personally invested in MacOS since I never touch one and they only make up 5-10% of the computer base, but if it becomes doable and mostly easy at some point, I think we should do it.

AstroGold btw is by the people who created Solar Fire. I'm pretty sure (but could be wrong) that it's SE based, since SF is SE based.

[Mike V]

I suspect we think similarly about version numbering (and perhaps you have an industry standard practice).

We do think along the same lines. There's more than one way to do it, but the most common style is semantic versioning. I know Mike N referred to it in places, so it was on his mind as well, and it's very, very close to what you wrote. Here's the way it is typically used:

Version [major.minor.patch], and while zero values can be elided (version 2 or 2.0 instead of 2.0.0), technically all 3 do have values at all times.

Major version bump: Breaking changes. For devs, this means "the way you interact with it must change and you need to migrate to the new version," but for use cases like this, it is closer to just "really fundamental upgrades have happened." I think for us it will be mostly a vibe thing as to what constitutes "is this big enough to be considered foundational and to distinguish from everything that came before it?"
With that said, the expectation is that for anything with major version 0, foundational things can change at any time. It is, for an intents and purposes, a beta release. It sounds like TMSA was previously versioned with this intention in mind anyway.

Minor version bump: New features or relatively significant additions to existing ones. This is really where most changes happen.

Patch version bump: Small tweaks and bug fixes that are easy to miss.

I'm also not personally invested in MacOS since I never touch one and they only make up 5-10% of the computer base, but if it becomes doable and mostly easy at some point, I think we should do it.

I do think it will be doable and mostly easy once I figure out bundling/installation stuff. I'd love to get to the point of simultaneous releases across Windows/Mac/Linux that have essentially no visible differences in them.

AstroGold btw is by the people who created Solar Fire. I'm pretty sure (but could be wrong) that it's SE based, since SF is SE based.

I am 99% sure you are right, and that's the app I was thinking of.

[Mike V]

It seems to me that Mike N versioned along the lines of [major.minor.super-minor.patch].

[Jim Eshelman]

Astrovizor is the best phone app I know at present, though

[Jim Eshelman]

It seems to me that Mike N versioned along the lines of [major.minor.super-minor.patch].

Yes. X.x.x.x is an "Oops" build. Everything else is planned even if small

I followed this on certain document sets I know are in your library.

[Mike V]

I reorganized and re-prioritized all the wishlist items in Trello based on the list above (and tweaked very slightly based on complexity or dependencies).

[Jim Eshelman]

Scnning the updated list, I see an item for allowing recalculation of Solunars. Solunars can already be recalculated. (Maybe there are limitations. I know that generally this can be done.) For example, the way to calculate an Anlunar is to run the SSR, then pick Calculate Chart for the SSR, then run the lunar from that. I've never tried it with SLRs (haven't had a reason). And, of course, one can easily do a series of locations by remaining in the Solunars page.

I didn't add improved search features to the list because I knew MikeN already had code for this (from his music library personal program) but didn't know how readily available such stuff was. (I did suspect that search is a pretty basic thing and probably a zillion programmers have created ways of doing it, and probably industry-spanning conversations on different approaches.) Regardless: While at the moment we can work fine with what we have, expanded and more flexible search capabilities would always be welcome.

Mutual Reception is something I've been asking for while think it wasn't urgent; and though I've proposed layouts, I'm not convinced my proposal will do more than make the page look crowded and cryptic. "Problem to be solved," possibly dependent on first creating the user-controlled variable dignities page that I think MikeN had finished, and not as important as other things here.

I don't know what "Solunars foreground report" means.
'
Transiting parans are a long-term goal. Natal parans, though, is a BIG priority. It would be awesome to have it while I'm still working on Volume 1 so we can get some serious research in for a few months and possibly affect what I say (though later rewrite is always possible). I probably should have had it on the First Priority list, but I suspect some layers have to be developed first (though not hard). Once that's in place, and ecliptic transits are programmed, paran transits should be trivial.

I see the second column is marked "included in 1.0." I think we're in agreement (though explicit communication is better than implicit), I'd like to do all this dev and initial deployment under 0.5 and, when its solid, debugged, and complete to current-stage plan, reissue as 1.0.

I like the 0.4.10 re-release idea to make sure the wheels don't fall off.

[Mike V]

I don't know what "Solunars foreground report" means.

I was referring to this thread with astro-mapping... and then I named titled the Trello item poorly for some mysterious reason! (What made it worse was I already had a card for astro mapping, which I didn't see or didn't realize was referring to the same thing.)

https://solunars.com/viewtopic.php?f=74 ... map#p48258

[Jim Eshelman]

My "single-equation angularity curve" needs a name for labeling in the program. Something concise and expressive is hard. I toyed with "21C Fluid," meaning it was a 21st century fluidic model.

For now, I've decided to call it the first thing I said when I worked out the formula: Eureka! It's the Eureka curve.

I'm not saying this is the best name or that it won't be changed but, for now, it's what I've got lol.

[Mike V]

Works for me! We can always change it later.

[Jim Eshelman]

Yes. We can even drop it later if it turns out to be too weird, e.g. because it isn't EXACTLY bilaterally symmetrical.

[Jim Eshelman]

I added #14.

[Jim Eshelman]

If cleaned up the above list, separating out completed items (to give the psychological effect of showing we are zooming in on the last few items). Rephrased a bit given how the conversation has gone so far, and adjusted priorities just a little.