Time Matters 0.6.0a Alpha Pre-Release - Windows

[Jim Eshelman]

This may be part of the wider "some midpoint things are known to be not right yet," but thought I'd give a specific while I had it.

The 10/31/24 Liblunar for Washington has the following at the end of the Cosmic State report:

Code: Select all

Ne Pi+ F |
Pl Cp    |

         |    
Angle    |    Sa/Ne 45'd      Ve/Ju 60'd      

[Jim Eshelman]

I've lost track... this one isn't fixed yet, right? (Just recreated it on my U.S.A. chart, also in LAT.) Just making sure it's not a "thought fixed, still there" bug. - It just doesn't like "LAT" in that field. I can spell out "Local Apparent Time" and it's fine with it. (Mistaking a string for a value called LAT?)

Same on Queen Elizabeth I. Is it the OS flag? (No, I recalculate the same chart, marking it Temporary, and unchecking OS, and I get the same error.) NOTE: Just saw the same with John Milton (1608 OS). I'm beginning to think it's the date range itself??

No, wait. I've got it. It's the LAT value in the Time Zone field. I thought this field was purely a label (it obviously doesn't give any numerical information) and previously I've been able to mark a chart LMT and adjust the h/m/s below it. Not now. For some reason, it's rejecting the label LAT.

----------2024-09-22 13:18:18----------
Traceback (most recent call last):
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 1921, in __call__
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 839, in callit
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\new_chart.py", line 903, in calculate
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 123, in __init__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 179, in save_and_print
File "C:\Users\mikep\Documents\tmsa_git\src\models\charts.py", line 398, in __init__
AttributeError: 'ChartObject' object has no attribute 'jd'

[Jim Eshelman]

Did inconjuncts (semi-sextile and quincunx) get dropped in some of the refactoring of the aspectarian? I turned them on to check something (with orbs at 1.25/2/3) and they don't appear in my aspectarian. I get this:

Code: Select all

   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sx Ma  1°31'  95%        Mo tr Ve  4°29'  62%        Mo tr Ju  6°13'  29%  
Me co Sa  2°24'  94%        Mo sq Pl  1°57'  56% p      Mo oc Sa  2°33'  26%  
Ve sx Ma  2°57'  83%        Ma op Ju  4°41'  76%        Mo tr Ur  5°56'  35%  
Ve tr Ju  1°44'  94%        Ma op Ur  4°25'  79%        Su sq Ma  6°28'  24%  
Ve tr Ur  1°27'  96%                                    Su co Ne  8°14'  30% M
Ve sq Pl  0°13' 100%                                                          
Ma sq Ne  0° 7' 100% M                                                        
Ju co Ur  0°17' 100%                                                          
Ju sq Ne  2°16'  90%                                                          
Ur sq Ne  2° 0'  92%                                                          
Ne sx Pl  0°46'  99%

With these settings, there should also be:

Venus-Neptune in 0°32'
Uranus-Pluto in 1°14'
Jupiter-Pluto in 1°31'

[Ember Nyx (Mike V)]

I've lost track... this one isn't fixed yet, right? (Just recreated it on my U.S.A. chart, also in LAT.) Just making sure it's not a "thought fixed, still there" bug. - It just doesn't like "LAT" in that field. I can spell out "Local Apparent Time" and it's fine with it. (Mistaking a string for a value called LAT?)

Correct, that is not fixed yet.

Did inconjuncts (semi-sextile and quincunx) get dropped in some of the refactoring of the aspectarian? I turned them on to check something (with orbs at 1.25/2/3) and they don't appear in my aspectarian. I get this...

I totally forgot that these existed because I never use them. I'll have to add these into the aspect calculation.

[Jim Eshelman]

I never use them either (except today when I was going to use them LOL). They were added simply because they're part of the larger aspect paradigm that a lot of people still use, so they should be an option.

Art the moment, I'm curious to watch for a while to see how easily the orb can be discerned between the closest (which are really 10° multiple Novien-based aspects) and the anti-aspect characteristic of the inconjunct. I'd never watched that super-closely even though the components of that have been evident enough.)

[Ember Nyx (Mike V)]

Here's a small patch, 0.6.0a8. https://mega.nz/file/gXskUCQI#qjgCfwion ... wQb4gFOsPs

This fixes:
Planets on Av are no longer mistakenly listed as being on Vx.
Entering "LAT" in the timezone field now correctly calculates LMT.
PVP aspects are now turned on by default for ingresses.

Bugfixes still pending:
- A bunch of miscellaneous midpoint bugs that I haven't had brainpower to tackle
- Precess natal angles in return charts (it's not the calculations that are making this take longer; it's finding a logical way to model and access this stuff without breaking backwards compatibility in the data files)
- Add semi-sextile and quincunx back into aspect calculation
- Set default ingress options to have "other partile" off by default (sorry I missed this one before uploading alpha 8 here)
- Add stationary to Cosmic State - coming back to it again, I think I agree with having Stat. in the dignity row instead of an S in the planet section header thingy.

[Ember Nyx (Mike V)]

Added a button on the main page to show the error file...

Nice! (Like real software <g>.) -- I'm curious, when does this clear? (Perhaps at each new version install it's deleted? I doubt it times out.)

I realize I never answered this question. Currently, there's no code to automatically clear that file, although it can easily be done manually (just CTRL + A and then delete, and save it... or delete the file). I can look into wiping it on install if that seems like the best cleanup cadence. I'll have to get a little creative with that.

[Jim Eshelman]

I'm curious, when does this clear? (Perhaps at each new version install it's deleted? I doubt it times out.)

I realize I never answered this question. Currently, there's no code to automatically clear that file, although it can easily be done manually (just CTRL + A and then delete, and save it... or delete the file). I can look into wiping it on install if that seems like the best cleanup cadence. I'll have to get a little creative with that.

I don't think this is high priority, especially if you have to get creative with it. (I thought it would be simple: Near the top of the install process, delete the file.)

It's unlikely to get too large for the hard drive or for Notepad to manage, especially after 1.0 is stable. My suggestion was more a matter of "rightness." As all errors are necessarily version specific, it seemed "right' that each version installed begins with a clean error slate.

So don't worry about it. - One suggestion, though (since all errors are necessarily version specific and some people - like you and me - could start wandering through old error logs), perhaps output the version number into the log entry? (Am I paying too much attention to this thinking that some people are going to go digging through the error logs out of curiosity?)

I just installed alpha-8 and updated the link. Off to test.

[Jim Eshelman]

Checking alpha-8. (Thanks for the quick patch.)

Planets on Av are no longer mistakenly listed as being on Vx.

Confirmed on my natal.

Entering "LAT" in the timezone field now correctly calculates LMT.

Confirmed fixed on U.S.A. chart. (To be picky, it doesn't calculate in LMT but in LAT .) Also confirmed on natus of Queen Elizabeth I.

PVP aspects are now turned on by default for ingresses.

Confirmed: Deleted Ingress_Default.opt, closed and relaunched program. New file created with PVP aspects enabled.

Bugfixes still pending:
A bunch of miscellaneous midpoint bugs that I haven't had brainpower to tackle

If you need any help "clarifying the question," ask.

Add stationary to Cosmic State - coming back to it again, I think I agree with having Stat. in the dignity row instead of an S in the planet section header thingy.

Planet section header thingy? You mean the leader label (I just made that up! <g>) in each CS row?

Another thing still off is that RA of MC and EP are 180° off. (We're seeing RA IC and WP.) In practice, this isn't a problem since my brain drops all but the last digit to do the mental subtraction, but of course it needs to be fixed at some point. (This popped up when you fixed RA EP to be 90° more than RA MC - which it is! - and, somehow, RA MC got the 180° added before that calculation.)

E.g., MC of 2° Gemini is Tropical 26° Gemini, so it's RA will be a few degrees earlier than 6h = 90°. Center of chart wheel correctly gives RAMC 85°31'. Here's the table. - Declination is wrong on all but MC.

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mc  1Ge46'20" ............. 265°31' 23N23 180° 0' +72°19' ....... 270° 0'  ...
As  2Vi20'25" ..................... 10N39 .......   0° 0' .......   0° 0'  ...
Ep  1Vi 0' 7" ............. 355°31' 11N 7 ....................................
Vx 26Aq12' 1" ..................... 12S47 270° 0' - 5°51' ....................

[Ember Nyx (Mike V)]

I don't think this is high priority, especially if you have to get creative with it. (I thought it would be simple: Near the top of the install process, delete the file.)

It's unlikely to get too large for the hard drive or for Notepad to manage, especially after 1.0 is stable. My suggestion was more a matter of "rightness." As all errors are necessarily version specific, it seemed "right' that each version installed begins with a clean error slate.

So don't worry about it. - One suggestion, though (since all errors are necessarily version specific and some people - like you and me - could start wandering through old error logs), perhaps output the version number into the log entry? (Am I paying too much attention to this thinking that some people are going to go digging through the error logs out of curiosity?)

It's the "near the top of the install process" part that makes this a bit more challenging - I don't actually directly control the installer. cx_freeze creates an installer based off of some setup that I give it, so I don't believe that I can run arbitrary code very easily using it. I'm sure there's some way to do things like this, but it's not clear to me how.

I think adding the version number would be great. There's no harm in it, only help. People can certainly go down that rabbit hole!

[Jim Eshelman]

Rev. Jim Jones, May 13, 1931, 10:00 PM CST. Lynn, IN

In the main data section, Saturn is correctly marked "Ea" and 97% strength: It is the most angular planet, 1°01' from EP in RA.

In the Cosmic State report, it is marked background, though the Needs Hierarchy score gives it full credit for the 97% strength from the angularity.

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Sa 29Sg24'27"  0N14 - 1' 2" 294°59' 21S14 107°10' -12°44' 356°11'  13°19'  97% Ea
Ep  0Cp19'24" ............. 116° 0' 23S27 ....................................
---------------------------------------------------------------------------------
                                  Cosmic State                                   
Sa Sg  B  97%| Su Ar-
             | tr Su  0°47'    sq Ve  1°32'    op Pl  2°20'M   op Ju  3°41'M   
             | sq Me  3°41'M   sq Ur  5°47'    

[Jim Eshelman]

As you know, I almost never consult Moon's Node (so I hadn't had a chance to check this). I just noticed that TM current version doesn't display the node.

Donald Trump was born at a lunar eclipse. I wanted to see how close Node was, so I went into Temporary and added true node. On recalculating... it's not there. (Confirmed on a couple of other charts.)

Mean Node - same thing.

The .dat file has both Mean and True Node regardless of whether they are requested. (I'm not sure where the flag is that determines if they are displayed.)

Code: Select all

"Mean Node": [
        56.76908464938329,
        0.0,
        -0.05299205622629489,
        79.94106604351146,
        23.12422685343077,
        118.30541977158265,
        60.69435202630059,
        40.19007154855939,
        296.29811329718444
    ],
    "True Node": [
        56.81616868658274,
        -4.4801628733903814e-18,
        -6.46472473060865e-05,
        79.99214097358123,
        23.12749079987455,
        118.23462237746423,
        60.6624948331266,
        40.08842151191527,
        296.34289695846746
    ]

[Ember Nyx (Mike V)]

By the way, thank you (all, but especially Jim) for being patient with this last suite of bugs. I have been very busy in my personal life, and also super burnt out on dev work, so all of my focus has been going towards keeping the lights on at work so to speak. I always recover from running out of dev fuel in a relatively short amount of time, so I'll get back to this soon.

As a reminder for everyone, you can see the current status of bugs and features on my Trello board - https://trello.com/b/NpRZTYxh/tmsa-roadmap

As you know, I almost never consult Moon's Node (so I hadn't had a chance to check this). I just noticed that TM current version doesn't display the node.

Donald Trump was born at a lunar eclipse. I wanted to see how close Node was, so I went into Temporary and added true node. On recalculating... it's not there. (Confirmed on a couple of other charts.)

Mean Node - same thing.

Yeah, now that you say that, I see that I totally forgot to wire up Node into the list of calculated planets when I refactored how that code worked. I'll include that one when I get back to bugfixing; should be very easy.

[Ember Nyx (Mike V)]

Finally, at long last, I present to you: an update!

Here's the link to 0.6.0b0, or, "I arbitrarily decided that this is at a beta level of stability because there are few bugs remaining, and several of us have been routinely using the alpha for months now."
https://mega.nz/file/5OM2EBgC#TvQxqs_aC ... yXIOREtxDM

Fixes are small but several:

• Mean and True Node now appear correctly in the chart face and tables when enabled
• Turned off "other partile" as the default setup for Ingress_Default.opt
• Added in code for calculating "inconjunct" aspects (semi-sextile and quincunx)
• Added "Stationary" to the Cosmic State report on the... whatever we're calling the "dignities and stuff" line. I just used the whole word, because it fits; I can abbreviate it Stat. if we really want, but it seems like an unnecessary abbreviation.
• Fixed bug found in Jim Jones's chart, where his foreground Saturn was showing up as "B" in the Cosmic State report - I wrote some bad code and a check to see if "Wa" was the same as "WA" (or "Ea" == "EA") was false, so the planet was mislabeled as background. (This also would've been produced by any other planet specifically on EP/WP in RA. But no more!)
• Added text auto-resizing to the Select Chart page for the longer button labels. These should now look much better on a smaller screen. (I also made the unimplemented Predictive Methods button gray like it is on the homepage.)

If you have time to test out this version and see what else I broke, I thank you.

Known existing bugs:

• Various midpoint misbehavior in natals, ingresses
• Natal angles are not yet being precessed in return charts (and never were)
• Various columns that should be blank in those natal angle fields in return charts are not yet blanked out

[Patrick Machado]

I'll check it out in a bit.

Natal angles are not yet being precessed in return charts (and never were)

Were they meant to be? What for?

[Jim Eshelman]

Natal angles are not yet being precessed in return charts (and never were)

Were they meant to be? What for?

We want to be able to test whether transits to angles work in mundo as well as in eclipto. This requires that the angles be precessed to the same epoch as the transits (or, perhaps better in theory but making little difference in practice) the other way around. One place where this absolutely is important is transits to EP-WP in RA, which need to be measured to a precessed natal RA.

BTW, I suspect the correct way to get the precessed RA of EP-a isn't to precess its longitude (since its longitude is irrelevant) but, rather, to get precessed MC RA and add 90° (since EP-a only really exists as a square to MC in RA).

BTW, I updated the link this morning and haven't had time to do anything else all day - December is a ferociously busy month at work most years, this year we're replacing 100% of fall laptops in the firm, and also I write and maintain the software that IT in all the offices use to make these migrations. So no time to play today

[Patrick Machado]

Ah, that. Already on the horizon?

By the way, I've ran into some significant errors with this latest version. Firstly, upon selecting "Solunars," I got this: https://www.dropbox.com/scl/fi/qlcpo62i ... xy0uu&dl=0

Trying to dismiss the error window didn't work and I had to shut down the program. Next, upon going to "Show Error," this appeared: https://www.dropbox.com/scl/fi/22vu538t ... 5dxa9&dl=0

The file mentioned indeed doesn't exist. Also, upon dismissing that window, this one appeared: https://www.dropbox.com/scl/fi/eycm466r ... i1647&dl=0

And, upon dismissing that, the program closed on its own.

[Ember Nyx (Mike V)]

Those are both really funky. Let me try to reproduce them. Thanks for bringing it to my attention.

[Ember Nyx (Mike V)]

Here, try 0.6.0b1. The button issue should be resolved now.

https://mega.nz/file/gbdTwZab#ea5NwxYOh ... bSMhFu-z3c

As for the error when trying to open the error file - TM attempts to create that file if it doesn't exist each time you start it, so I'm not sure why it also can't find it. It's possible it tried and failed due to permission issues, but then those should've affected other file functionality as well. Can you check your Documents folder and see if Documents\tmsa_errors\error.txt exists?

[Jim Eshelman]

Mike, I can't download this new package. The browser says a virus is detected in the package.

Though there have always been fights between TMSA and security software, this particular thing only happened once before when MikeN actually did have a virus in the package. Perhaps something is at least irregular with the package?

[Jim Eshelman]

Meanwhile, I did hit the install button on 0.6.0b0 before going to work yesterday, so I can check some things on that.

First, of course, thanks for the new version and all the work!

Mean and True Node now appear correctly in the chart face and tables when enabled

Confirming presence and calculation.

I see you've distinguished TN and MN for True Node vs. Mean Node. I see why you might want to do that (and maybe it also makes the .dat file easier?) - for a brief while in the '70s when people were first becoming aware of true lunars nodes, it was customary to put a tiny (barely visible) T under the North Node glyph if true node was used, though none of the emerging calculating services followed suit.

I'm not crazy about this distinction. Most people won't understand what it is. The usual abbreviations (not distinguishing between true and mean theories) are NN for North Node or Dr for Dragon's Head (and, rarely, No for Node). I lean toward NN just because it's almost universally understood.

In any case, the calculations are correct and the object seems to integrate into aspectarian etc. correctly.
 

Turned off "other partile" as the default setup for Ingress_Default.opt

I deleted Ingress_Default.opt and relaunched the program so this would rebuild. It came up with this turned off. All settings in this look good.

Added in code for calculating "inconjunct" aspects (semi-sextile and quincunx)

Is the code active? I added Inconjunct orbs in Temporary and recalculated my chart. None showed up in the aspectarian. With Class 1/2/3 orbs out to 3°, I should have seen Venus-Neptune 0°33', Jupiter-Pluto 1°31', Saturn-Eris 0°56', and Uranus-Pluto 1°14'.

Added "Stationary" to the Cosmic State report on the... whatever we're calling the "dignities and stuff" line. I just used the whole word, because it fits; I can abbreviate it Stat. if we really want, but it seems like an unnecessary abbreviation.

Nice! It looks better than I'd have guessed - I do think this is better than the abbreviation.

Fixed bug found in Jim Jones's chart, where his foreground Saturn was showing up as "B" in the Cosmic State report

Nice fix! (Yes, I'd seen this on other charts - only in the CS report.)

Added text auto-resizing to the Select Chart page for the longer button labels. These should now look much better on a smaller screen. (I also made the unimplemented Predictive Methods button gray like it is on the homepage.)

Confirmed. Looks good.

I also confirmed Patrick's error on the Solunars button though I did get an error log. Main entry:

----------2024-12-13 03:19:22----------
Traceback (most recent call last):
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 1921, in __call__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\select_chart.py", line 129, in resize
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\select_chart.py", line 112, in resize_recalculate
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\widgets.py", line 186, in text
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 1681, in cget
_tkinter.TclError: invalid command name ".!selectchart2.!button4"

[Patrick Machado]

Can you check your Documents folder and see if Documents\tmsa_errors\error.txt exists?

It doesn't, no. Wondering what happens if I create it manually -- if it's only the initial creation that's the problem.

[Ember Nyx (Mike V)]

Creating it manually should solve the issue, I bet. I wonder why it didn't fail during startup if there was a permission issue...

[Ember Nyx (Mike V)]

Mike, I can't download this new package. The browser says a virus is detected in the package.

Though there have always been fights between TMSA and security software, this particular thing only happened once before when MikeN actually did have a virus in the package. Perhaps something is at least irregular with the package?

Hmm, try this? I bumped the beta version by 1 with no other changes (from 0b1).

https://mega.nz/file/tW0HkTrB#SYCtDqqdd ... rFKs7GBmB8

[Jim Eshelman]

Two different chromium browsers, same result. Is this unique to me?

virus.png

[Jim Eshelman]

I turned off real-time protection temporarily, downloaded the file, then ran a manual scan. Got this (below). Now I'm going to look into this Trojan.

Virus2.jpg

It might be a false positive - Sometimes Windows Defender thinks that an unzipped .exe is this Trojan. At the moment I'm acting like it's real.

[Jim Eshelman]

The Microsoft trojan scanner gave the computer a clean bill of health. It's a false positive. Not sure why it triggered.

[Jim Eshelman]

By the way, after installing the latest, the error-on-Solunars bug went away and the fixes are all nicely in place.

Thanks for all the fixes!

I'll wander back through this thread to see if there are other issues still hovering. I'm sure you're on top of whatever the midpoint issues are (I haven't dug into it).

The one remaining bug that matters most to me at the moment is the absence of Moon aspects in dormant ingresses. I have to go back and calculate the ecliptical and mundane Moon aspects for each of these, which isn't the end of the world but does leave me open to making mistakes. (Moon aspects should always be shown for dormant ingresses, since they operate worldwide regardless of whether anything is angular to localize the ingress.)

[Jim Eshelman]

The following may already be on your mind, I'm just listing stuff as I come across it...

Not a bug, but an expansion that would be great, that I think you were excited about, and that sets us up for things we need in the future: Allowing users the option of displaying angularities as aspects in the aspect list.

Some adjustments to how angle coordinates are handled, e.g., RA MC can be 180° off (it should always match RAMC in the center of the wheel); and precessing RA EP should likely be done by adding 90° to RA MC (since the ecliptical position of EP-a is a fiction). There may be more, I haven't QA'd the table lately (will do so today and amend this if necessary).

I'm not sure what you meant by enabling inconjunct code in the recent beta. With those aspects set, those aspects don't appear in the aspect table (maybe that's not the part you meant).

A retrieved (previously calculated) chart for 12:00 PM always pulls up (on recalc and maybe other places) as 12:00 AM.

This CS display bug is still there (maybe part of your midpoint list): viewtopic.php?p=62631#p62631


As I go through these older posts I'm remembering how helpful two innovations you made are: adding the error log and allowing default options files to be regenerated by deleting them! (It's also reminding me of all the great additions - often small but important - such as getting stations added.)

[Jim Eshelman]

While you're working on aspects anyway (the inconjunct matter), how hard would this be to sneak in?
https://www.solunars.com/viewtopic.php?t=9191

[Jim Eshelman]

I had time to check the coordinates calculated for angles. Several are still off. Here is what TM produces for my local chart (34N03'46" 118W18'47"):

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mc  1Ta38'15" ............. 233°25' 19N12 180° 0' +75° 8' ....... 270° 0'  ...
As  5Le14'16" ..................... 18N58 .......   0° 0' .......   0° 0'  ...
Ep 26Cn55' 0" ............. 323°25' 20N47 ....................................
Vx 19Sg51'17" ..................... 23S 3 270° 0' -43°35' ....................

Comparing against Solar Fire:

• As already discussed, RA MC is 180° off. It should be 53°25'. This can be copied directly from RAMC in the chart center or by the test: MC TZ 0° Aries to 0° Libra is < 180; TZ 0° Libra to 0° Aries is > 180°. - This causes RA EP to be off, but it's calculated correctly from what's there.
• Declination MC is nonetheless correct! (It's also true that RA MC is < 180° if Dec is North, > 180° if Dec is South.)
• But Dec Asc and Vx are wrong. They should be, respectively, 11N42 and 22S43. WAG: Are these calculated being using the Sidereal longitude instead of Tropical?

The rest are all correct.

[Jim Eshelman]

I'm not sure what you meant by enabling inconjunct code in the recent beta. With those aspects set, those aspects don't appear in the aspect table (maybe that's not the part you meant).

This statement seems to be wrong - at least wrong sometimes. In looking at the chart for Solunars.net first going online, I see inconjuncts!

So let's go back to my chart, which didn't have them last time I looked: Recalculating my chart in the recent version... inconjuncts aren't there! Inconjunct orbs are set at 1.25/2/3 and none of my three semi-sextiles show.

Just in case the problem was with recalculation, I ran my chart again, a new test chart with the same data. Again, the semi-sextiles don't show.

But the Solunars.net chart has the Venus-Uranus (0°04') inconjunct (quincunx).

Marion's chart shows Jupiter-Neptune inconjunct (1°27', a quincunx) but not the Venus-Jupiter semi-sextile (1°30'). Aha! Is it perhaps that inconjunct code is catching quincunxes but not semi-sextiles? Yes, that's it! Adding Eris back to my chart, I see it catches the Saturn-Eris quincunx (0°55') and still misses the semi-sextiles.

So I stand corrected: Inconjuncts work correctly half the time, catching quincunxes but not semi-sextiles.

[Ember Nyx (Mike V)]

I'll wander back through this thread to see if there are other issues still hovering.

I see your recent posts on the Novien and angles in data table threads, and will go through the rest here.

The one remaining bug that matters most to me at the moment is the absence of Moon aspects in dormant ingresses.

Some adjustments to how angle coordinates are handled, e.g., RA MC can be 180° off (it should always match RAMC in the center of the wheel); and precessing RA EP should likely be done by adding 90° to RA MC [...]
I had time to check the coordinates calculated for angles. Several are still off. Here is what TM produces for my local chart (34N03'46" 118W18'47")
[...]

A retrieved (previously calculated) chart for 12:00 PM always pulls up (on recalc and maybe other places) as 12:00 AM.

This CS display bug is still there (maybe part of your midpoint list): viewtopic.php?p=62631#p62631

I'm not sure what you meant by enabling inconjunct code in the recent beta. With those aspects set, those aspects don't appear in the aspect table [...]

So I stand corrected: Inconjuncts work correctly half the time, catching quincunxes but not semi-sextiles.

Added these to my list of bugfixes for 0.6.x, in addition to the pile of midpoint bugs I have been dreading.

Not a bug, but an expansion that would be great, that I think you were excited about, and that sets us up for things we need in the future: Allowing users the option of displaying angularities as aspects in the aspect list.

Added to the 0.7.0 column. I think this is a little bit heavy to try to squeeze into the already large 0.6.x release. On paper, it's totally trivial, but in code, this has implications for the architecture of several classes which are moderately complex to work out.

While you're working on aspects anyway (the inconjunct matter), how hard would this be to sneak in?
[Link to decile thread]

Not hard to write, but probably medium-weight to QA. I'm also filing this under 0.7.0 so that 0.6.x doesn't keep growing in scope.

[Jim Eshelman]