On 29.09.2013 21:35, Vassilii
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
On 29.09.2013 17:09, John Ralls
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?
|OK, I decided to try
the head-on approach and it worked.
I took the jewish.c from the Calendar package sdn
and it turns out that we had an earlier fork of
the same code,
down to the comments and line splits in them. The
had apparently had some bugs fixed since. I did
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
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?
If we *don't* emit a warning here, would this be a problem?
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.