On 29.09.2013 21:35, Vassilii Khachaturov wrote:
On 29.09.2013 17:09, John Ralls wrote:

Vassilii,

In http://www.gramps-project.org/bugs/view.php?id=7066#c31326 you wrote:
OK, I decided to try the head-on approach and it worked.
I took the jewish.c from the Calendar package sdn subdir,
and it turns out that we had an earlier fork of the same code,
down to the comments and line splits in them. The upstream
had apparently had some bugs fixed since. I did the re-alignment
and BINGO! the thing worked.

I still leave the sdn dependency as an option for those who have it installed,
the others will have the python-only in-gramps fork fallback.


Given that there's already a pure-python solution in Gramps and that the calendar
package seems not to be actively maintained (the files inside the tarball are mostly 
dated 23 Oct 2006, with one header dated 24 Dec 2007), what's the point of the import?

I reasoned that if somebody has the original installed, they probably have a reason, and so why go for our unmaintained and less tested fork copy?
If we *don't* emit a warning here, would this be a problem?

V

Another reason was that I only had time to fully proof-read the hebrew_ymd port, and didn't invest as much into hebrew_sdn. So if there are bugs fixed in upstream in hebrew_sdn, we'll still have them. For me, and for anyone else who has a lot of Hebrew dates in the database, using sdn thus increases confidence in the relevant calculations.

However, since there the hebrew_... calculations are not really a performance bottleneck, perhaps importing them into the calendar.py isn't needed --- rather, I should write an exhaustive test that goes through all the SDNs since the Hebrew era start until now+1000 years, and compares our code with the native sdn? this test would be skipped unless sdn is installed, and it would give us the confidence in our Hebrew calculations. This test could also be extended to provide independent verification of our other SDN code, however there it is less critical as the Hebrew calculations seem the most complex and difficult to test otherwise.

V.