Quantcast

Missing 'all Calendar with pypi'

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Missing 'all Calendar with pypi'

Helge.Herz-2
Devs,

since a while I get for Gramps 3.4.6 (from svn) and also for gramps
4.0.2 (r23218M from svn) on win os this message during startup:
WARNING: calendar.py: line 586: sdn not available. Install Calendar with
pypi for native Hebrew calendar calculations.

Any idea/suggestion what's to do for me?
Shall I file one issue for each Gramps version in the bug tracker?

Thanks
-Helge

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Vassilii Khachaturov
On 29.09.2013 11:32, Helge.Herz wrote:
> Devs,
>
> since a while I get for Gramps 3.4.6 (from svn) and also for gramps
> 4.0.2 (r23218M from svn) on win os this message during startup:
> WARNING: calendar.py: line 586: sdn not available. Install Calendar with
> pypi for native Hebrew calendar calculations.
>
> Any idea/suggestion what's to do for me?
> Shall I file one issue for each Gramps version in the bug tracker?
I've added you to the already filed bug #7088 list for more context.
If you're wondering what to do creating a Windows package, I propose to
install the "Calendar" python package from pypi as part of your Gramps
bundle, it'll give better Hebrew calendar calculations in Gramps.

V

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Helge.Herz-2
@Vassilii, thank very much you for linking me to the #7088.

Regarding Win and sdn:
I tried to find a package for Win os. But the only link I did find was
"http://www.funaba.org/en/calendar.html". This page looks very well -
but there is no compiled version for python available. Also at this page
"http://www.lfd.uci.edu/~gohlke/pythonlibs/" I didn't find something
what could be helpful. Because I don't have any C compiler in use I
can't do any thing at the moment than wait until the next Gramps3.4 AIO
is available.

-Helge

Am 29.09.2013 12:33, schrieb Vassilii Khachaturov:

> On 29.09.2013 11:32, Helge.Herz wrote:
>> Devs,
>>
>> since a while I get for Gramps 3.4.6 (from svn) and also for gramps
>> 4.0.2 (r23218M from svn) on win os this message during startup:
>> WARNING: calendar.py: line 586: sdn not available. Install Calendar with
>> pypi for native Hebrew calendar calculations.
>>
>> Any idea/suggestion what's to do for me?
>> Shall I file one issue for each Gramps version in the bug tracker?
> I've added you to the already filed bug #7088 list for more context.
> If you're wondering what to do creating a Windows package, I propose to
> install the "Calendar" python package from pypi as part of your Gramps
> bundle, it'll give better Hebrew calendar calculations in Gramps.
>
> V
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Nick Hall-6
There doesn't seem to be a package available for Ubuntu either.

I'll have a look at fixing the Gramps calendar code.

Nick.


On 29/09/13 13:10, Helge.Herz wrote:
> Regarding Win and sdn:
> I tried to find a package for Win os. But the only link I did find was
> "http://www.funaba.org/en/calendar.html". This page looks very well -
> but there is no compiled version for python available. Also at this page
> "http://www.lfd.uci.edu/~gohlke/pythonlibs/"  I didn't find something
> what could be helpful. Because I don't have any C compiler in use I
> can't do any thing at the moment than wait until the next Gramps3.4 AIO
> is available.


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

John Ralls-2
In reply to this post by Vassilii Khachaturov

On Sep 29, 2013, at 3:33 AM, Vassilii Khachaturov <[hidden email]> wrote:

On 29.09.2013 11:32, Helge.Herz wrote:
Devs,

since a while I get for Gramps 3.4.6 (from svn) and also for gramps
4.0.2 (r23218M from svn) on win os this message during startup:
WARNING: calendar.py: line 586: sdn not available. Install Calendar with
pypi for native Hebrew calendar calculations.

Any idea/suggestion what's to do for me?
Shall I file one issue for each Gramps version in the bug tracker?
I've added you to the already filed bug #7088 list for more context.
If you're wondering what to do creating a Windows package, I propose to
install the "Calendar" python package from pypi as part of your Gramps
bundle, it'll give better Hebrew calendar calculations in Gramps.

Vassilii,

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?

Regards,
John Ralls


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

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

Vassilii,

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


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

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

Vassilii,

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.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

John Ralls-2

On Sep 29, 2013, at 11:47 AM, Vassilii Khachaturov <[hidden email]> wrote:

> 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.

Well, Funaba doesn't have any tests either, so I wouldn't go assuming that it's necessarily right just because somebody put a link to it in PyPI. And as I said,
he's not maintaining it, either: No changes in 6 years. I just checked the sources that come with Calendrical Calculations, and even *they* don't have tests.

To properly test you'll need an authoritative table of Hebrew dates to either serial or proleptic Gregorian dates to compare against. There's a small (32) table of dates in the back of Reingold & Dershowitz which is copied on their CD, which also has tables of every date from 2000-2005. The book currently sells for $22 from Amazon, but there are used ones available for half that. Alternatively, there are a bunch of converters on the web that you could use to generate such a table. Steve Morse, who's pretty well known in US genealogy circles, has one at http://stevemorse.org/jcal/jcal.html.


Regards,
John Ralls


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Paul Franklin-5
In reply to this post by Vassilii Khachaturov
> 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?

I am philosophically opposed to importing old packages,
which may not be maintained anymore.  We have had users
who have been burned because they have imported the
(ancient and buggy) PyXML package, typically because
it was some /optional/ dependency of something they did want.

If Calendar hasn't been touched since 2006 then I vote we
shouldn't be importing it.  Especially since you now have Python
code to cover the problem you thought it solved, back when you
chose to import it.

At the very least I don't think it should be a "warning" log
message, if you insist upon not only importing it but checking
to see that it was imported.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Tim Lyons
Administrator
Optionally importing it seems a terrible idea, if only because if anyone reports a bug, there will be ambiguity as to which package they actually got to use.

At least if we rely on our own package we are in charge of our destiny.

Tim.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Vassilii Khachaturov
In reply to this post by John Ralls-2
Thanks everybody for your input -- I've removed the warnings about the
SDN already and I shall remove the dependency on SDN soon as well, see
bug# 7088.

On 30.09.2013 00:17, John Ralls wrote:
> To properly test you'll need an authoritative table of Hebrew dates to
> either serial or proleptic Gregorian dates to compare against.
I agree. But we don't even have tests that assure us that our port of
the SDN code from C to Python has no mistakes! I'll whip up something to
do that under #7088...
> There's a small (32) table of dates in the back of Reingold &
> Dershowitz which is copied on their CD, which also has tables of every
> date from 2000-2005. The book currently sells for $22 from Amazon, but
> there are used ones available for half that. Alternatively, there are
> a bunch of converters on the web that you could use to generate such a
> table. Steve Morse, who's pretty well known in US genealogy circles,
> has one at http://stevemorse.org/jcal/jcal.html.
That sounds like the best testing approach, but it is a bigger task,
you're welcome to open a separate issue requesting this testing coverage!

V.



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Nick Hall-6
In reply to this post by Tim Lyons
I agree, so I have committed a fix for our code and removed the sdn import.

Both hebrew date functions have been tested from the earliest valid date
to the year 2500.  We now get the same results as the sdn calendar module.

Nick.


On 29/09/13 22:44, Tim Lyons wrote:

> Optionally importing it seems a terrible idea, if only because if anyone
> reports a bug, there will be ambiguity as to which package they actually got
> to use.
>
> At least if we rely on our own package we are in charge of our destiny.
>
> Tim.
>
>
>
> --
> View this message in context: http://gramps.1791082.n4.nabble.com/Missing-all-Calendar-with-pypi-tp4662789p4662809.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Vassilii Khachaturov
I've also removed the SDN version reporting you forgot to remove, that
was supposed to guard against the scenario described by Tim.
On 30.09.2013 20:46, Nick Hall wrote:

> I agree, so I have committed a fix for our code and removed the sdn import.
>
> Both hebrew date functions have been tested from the earliest valid date
> to the year 2500.  We now get the same results as the sdn calendar module.
>
> Nick.
>
>
> On 29/09/13 22:44, Tim Lyons wrote:
>> Optionally importing it seems a terrible idea, if only because if anyone
>> reports a bug, there will be ambiguity as to which package they actually got
>> to use.
>>
>> At least if we rely on our own package we are in charge of our destiny.
>>
>> Tim.
>>


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Nick Hall-6
Vassilii,

Thanks.  I didn't notice the version reporting.

I have now also checked that the gregorian, julian and french calendar
functions return the same results as the sdn module.

Nick.


On 01/10/13 09:42, Vassilii Khachaturov wrote:

> I've also removed the SDN version reporting you forgot to remove, that
> was supposed to guard against the scenario described by Tim.
> On 30.09.2013 20:46, Nick Hall wrote:
>> >I agree, so I have committed a fix for our code and removed the sdn import.
>> >
>> >Both hebrew date functions have been tested from the earliest valid date
>> >to the year 2500.  We now get the same results as the sdn calendar module.
>> >
>> >Nick.
>> >
>> >
>> >On 29/09/13 22:44, Tim Lyons wrote:
>>> >>Optionally importing it seems a terrible idea, if only because if anyone
>>> >>reports a bug, there will be ambiguity as to which package they actually got
>>> >>to use.
>>> >>
>>> >>At least if we rely on our own package we are in charge of our destiny.
>>> >>
>>> >>Tim.
>>> >>


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Vassilii Khachaturov
On 01.10.2013 14:47, Nick Hall wrote:
> Vassilii,
>
> Thanks.  I didn't notice the version reporting.
>
> I have now also checked that the gregorian, julian and french calendar
> functions return the same results as the sdn module.
>
> Nick.
>
Great, thanks a lot! I presume the SDN French threw outside the
Republican period, didn't it?

V

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing 'all Calendar with pypi'

Nick Hall-6
On 01/10/13 20:13, Vassilii Khachaturov wrote:

> On 01.10.2013 14:47, Nick Hall wrote:
>> >Vassilii,
>> >
>> >Thanks.  I didn't notice the version reporting.
>> >
>> >I have now also checked that the gregorian, julian and french calendar
>> >functions return the same results as the sdn module.
>> >
>> >Nick.
>> >
> Great, thanks a lot! I presume the SDN French threw outside the
> Republican period, didn't it?
Yes.  I only tested the French calendar within the valid range of dates.

Nick.


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Loading...