swe_gauquelin_sector() crashes the program

[timotejroiko]

just a heads up:

Using swe_gauquelin_sector() with methods 0 or 1 crashes the program. Methods 2, 3, 4 and 5 are not affected, however using stars does not work.

tests (using node v12):

• using method 0/1 with valid star without setting ephe path (error star not found)
• using method 0/1 with valid star with correct ephe path (crash)
• using method 0/1 with empty star string without setting ephe path (crash)
• using method 0/1 with empty star string with correct ephe path (crash)
• using method 2/3/4/5 without setting ephe path (planet works, star is always ignored)
• using method 2/3/4/5 with correct ephe path (planet works, star is always ignored)

The function should prioritize stars if a star string is present and it should fallback to planets if an empty star string is given. I have attempted to fix this problem without success.

This issue is not important as swe_house_pos() can be used as a replacement, and in most cases, using swe_houses_pos() should be more appropriate anyway.

[krisztianb]

Do you think this is a bug in this library or the Swiss Ephemeris itself?

[timotejroiko]

Do you think this is a bug in this library or the Swiss Ephemeris itself?

It should be a bug in this library, possibly also related to NAN. This is not the only function that has issues when trying to use NULL or empty strings as parameters.

I have since moved to a different library (sweph) that uses N-API instead of NAN, and i havent seen such issues there. But i could try taking a look at this again at some point if there is any demand for it.

[krisztianb]

Is that sweph library developed by you? Unfortunately I didn't find it when I was looking for Node.js implementations of Swiss Ephemeris. I might have used your library instead. Will take a look though.

[timotejroiko]

Is that sweph library developed by you? Unfortunately I didn't find it when I was looking for Node.js implementations of Swiss Ephemeris. I might have used your library instead. Will take a look though.

yes it is, its fairly recent so it might not have been on npm yet at that time

[krisztianb]

May I ask why you created another package?

[timotejroiko]

May I ask why you created another package?

different direction, different philosophy, different goals, different API (the latter requiring a full rewrite from scratch anyway) and i dont want force my ideas onto someone else's library, especially when they require basically deleting everything the other person did.

[krisztianb]

My goal is to use the Swiss Ephemeris functions efficiently. In what way is your library different than this one?

[timotejroiko]

My goal is to use the Swiss Ephemeris functions efficiently. In what way is your library different than this one?

Not sure if this is the appropriate place to discuss this, but here:

From a user perspective, the main difference is that the sweph api is as close as possible to the original C api, while swisseph makes some adaptations. For example sweph returns everything to the user, including flags and error messages, while swisseph handles flags internally and gives only the relevant data to the user. Most sweph functions return data as indexed arrays like the C api does, swisseph converts them to key-value objects with custom keys.

Internally, sweph uses N-API (node addon api), swisseph uses NAN (native abstractions for node). N-API has many advantages over NAN but most importantly its a standard that guarantees that the C code will work in all future versions of node.js, while NAN cannot guarantee this and requires testing every time a new node.js version comes out. You cannot convert swisseph from NAN to N-API without rewriting it from scratch.

Swisseph is an older project, has been around for a while, and maintaining old projects is a big pain for developers, so its understandable the owner and original maintainers are not very active anymore. I was the one who updated swisseph the last few times instead because i needed it, but maintaining someone else's project is also not easy due to differences in ideas, style, waiting for approval, etc... Therefore the best course of action was to make a separate project my own way. The end result is that sweph is easier for me to use, maintain and update, which i plan to for the foreseeable future.

If you would like to discuss further, feel free to contact me or open an issue in the sweph repo.

[krisztianb]

Thanks a lot for taking the time and writing this summary. I'll really have to take a close look at your library and try it out. Nevertheless I'm going to finish the work I started in improving this library as I don't like leaving things undone.