[Plplot-devel] ocaml install dir

2008-09-02 Thread orion
Looks like OCAML_INSTALL_DIR should be set to the output of "ocaml -where". This will allow for the differences in Debian and Fedora (and other) install locations. Debian guidelines: 1.3.2. OCaml Location The root of all installed OCaml libraries is the OCaml standard library directory, w

Re: [Plplot-devel] What is needed to build docs?

2008-09-02 Thread Alan W. Irwin
On 2008-09-02 21:28-0600 [EMAIL PROTECTED] wrote: > -- WARNING: DSSSL Style Sheet DTD not found > -- WARNING: DocBook HTML Stylesheet not found > -- WARNING: DocBook Print Stylesheet not found > -- WARNING: DocBook DTD not found > -- WARNING: Not building print documentation - dtd files / style sh

Re: [Plplot-devel] Looking into problem with Ada example 19

2008-09-02 Thread Jerry
On Sep 2, 2008, at 7:30 PM, [EMAIL PROTECTED] wrote: > >> Attached is a zip file that more closely emulates the PLPlot >> situation, with plmap written in C but with the callback, mapform19, >> written in Ada. Could a few of you test it to see if it runs or >> crashes on your machines? Either way

[Plplot-devel] What is needed to build docs?

2008-09-02 Thread orion
-- WARNING: DSSSL Style Sheet DTD not found -- WARNING: DocBook HTML Stylesheet not found -- WARNING: DocBook Print Stylesheet not found -- WARNING: DocBook DTD not found -- WARNING: Not building print documentation - dtd files / style sheets are missing -- WARNING: Not building html documentation

Re: [Plplot-devel] Looking into problem with Ada example 19

2008-09-02 Thread orion
> Attached is a zip file that more closely emulates the PLPlot > situation, with plmap written in C but with the callback, mapform19, > written in Ada. Could a few of you test it to see if it runs or > crashes on your machines? Either way, I'd like to report back to the > geniuses at comp.lang.ada

Re: [Plplot-devel] time

2008-09-02 Thread Steve Schwartz
Hello Alan, On Tue, 2008-09-02 at 12:18 -0700, Alan W. Irwin wrote: > I think we should deal properly with leap seconds because of the > problem you > mentioned above and also the problem that our fundamental time > variable > would then have a strange relationship with externally defined time > s

Re: [Plplot-devel] Time calculation in Ada example 29

2008-09-02 Thread Jerry
On Sep 2, 2008, at 12:38 PM, Andrew Ross wrote: > On Tue, Sep 02, 2008 at 02:03:25AM -0700, Jerry wrote: >> >> On Sep 1, 2008, at 4:10 PM, Alan W. Irwin wrote: >> >>> On 2008-09-01 14:58-0700 Jerry wrote: >>> Andrew, Does the Ada example, with xmin hardcoded to 1_133_395_200.0, >>>

Re: [Plplot-devel] Time calculation in Ada example 29

2008-09-02 Thread Andrew Ross
On Tue, Sep 02, 2008 at 02:03:25AM -0700, Jerry wrote: > > On Sep 1, 2008, at 4:10 PM, Alan W. Irwin wrote: > > > On 2008-09-01 14:58-0700 Jerry wrote: > > > >> Andrew, > >> > >> Does the Ada example, with xmin hardcoded to 1_133_395_200.0, > >> generate the same Postscript as the C example? > >

Re: [Plplot-devel] time

2008-09-02 Thread Alan W. Irwin
On 2008-09-02 13:18+0100 Schwartz, Steven J wrote: > We don't deal with leap seconds. As long as we use our own routines to get from broken-down time to epoch time and back, the result is clean and consistent, although this means we only allow a minute to have 60 seconds. Thus a time series that a

Re: [Plplot-devel] time

2008-09-02 Thread Schwartz, Steven J
Andrew/Alan, Thanks for picking up this thread. I think your remarks are all sensible. We have code and experience in going back and forth from broken-down time to time since an epoch and I think we should be able to bundle that and supply it as pltimeutc and its inverse. Give me some time to

Re: [Plplot-devel] Time calculation in Ada example 29

2008-09-02 Thread Jerry
On Sep 1, 2008, at 4:10 PM, Alan W. Irwin wrote: > On 2008-09-01 14:58-0700 Jerry wrote: > >> Andrew, >> >> Does the Ada example, with xmin hardcoded to 1_133_395_200.0, >> generate the same Postscript as the C example? > > The current Ada example 29 code has > > xmin := 1133395200.0; > > (no und

Re: [Plplot-devel] time

2008-09-02 Thread Andrew Ross
Steve, Alan, I entirely agree that the only sane, cross-platform and cross-language way of dealing with the timegm (and possible gmtime) problem is to add our own implementation. This is relatively straightfoward and I can see no reason not to. The bigger question is whether we carry on using s