PLplot

Alan,

On Fri, 2009-01-30 at 10:52 -0800, Alan W. Irwin wrote:
> On behalf of the PLplot developers, I thank the QSAS team for their
> donation.

Thanks for this. I see it more as a contribution in return for our use
of plplot, which has opened up or facilitated a variety of advancements
of our own software, not least of which is the ability to port it to a
Windows platform.

Yours
Steve

PS And while I "lead" the team, the hard work is all done by them (Tony
Allen and Alban Rochel) rather than me.

-- 
+-------------------------------------------------------------------+
Professor Steven J Schwartz        Phone: +44-(0)20-7594-7660
Head, Space & Atmospheric Physics  Fax:   +44-(0)20-7594-7900
The Blackett Laboratory            E-mail: s.schwartz@...
Imperial College London            Office: Huxley 711A 
London SW7 2AZ, U.K.               Web: http://www.sp.ph.ic.ac.uk/~sjs
+-------------------------------------------------------------------+

On 2009-01-30 10:52-0800 Alan W. Irwin wrote:

> The QSAS team lead by Steve Schwartz have donated time-handling software to
> PLplot under the LGPL license today.

I think it is best to keep this as a separate library with the name
qsastime.  qsastime has no google hits at all.  Alternative library names
such as mjdtime, icltime, time, and freetime were considered, but all of
those have potential present or future name clashes as revealed by lots of
google hits.  (I am concerned about such name clashes because I even ran
into such a clash with my FreeEOS project).  qsastime is also consistent
with our naming convention for the csa and nn libraries which we called
csironn and csirocsa in honor of the institution of the individual that
donated the code to us while simultaneously dealing with name clash
concerns.

Accordingly, I have just (revision 9433) committed the code and html
documentation of that code in lib/qsastime and also updated our build system
(revision 9434) to build and install that library, make libplplotd
build-depend on that library (even though libplplotd currently has no calls
to that library), and build an executable in lib/qsastime in the build tree
to test the qsastime library.

The build and test code all work fine for me on Debian testing.  However, I
need volunteers to deal with the visibility issues, windows build, etc.

Further work to actually use that library from within plplot for all
time-related issues is planned but not implemented yet.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On 2009-02-02 12:50-0800 Alan W. Irwin wrote:

> The [libqsastime] build and test code all work fine for me on Debian testing.  However, I
> need volunteers to deal with the visibility issues, windows build, etc.

Here is some further libqsastime news as of revision 9455.

The visibility issues have now been solved following what was done
for the csiro libraries and the result works on Linux at least.
Also, Andrew has changed libplplot to use the libqsastime
time formatting function which is exercised by example 29.

Today, I renamed all files using the mapping MJDtime ==> qsastime.  I also
split qsastime.c (nee MJDtime.c) and qsastime.h into the essential part
(still called qsastime.[ch]) that we need (three key functions and their
helpers), and a part (called qsastime_extra.[ch]) that has inessential code
for our needs but which is useful for helping to test libqsastime. Currently
qsatime.c is built into the libqsastime library and qsatime_extra.c is built
as part of the qsastime_test executable.  I prefer this factoring of the
code because from now on I want to concentrate just on the code in qsatime.c
since that is what PLplot will be using.  The refactored code still gives a
good library build that gives good example 29 results. The qsatime_test code
also appears to work well (except for a locale issue [8 hours out
corresponding to my time zone] I discovered with the %s formatter for the
comparison Linux strftime routine.)

My immediate further plans at this stage are to directly test the three key
functions (setFromUT, breakDownMJD, and strfMJD) currently in libqsastime
against their closest Linux counterparts (timegm, gmtime, and strftime) for
the complete range of valid Linux times (if that range is only the
1901-12-13 through 2038-01-18 that is normally quoted for 32-bit systems) or
something larger than that 32-bit range if a larger range of Linux times is
available on my 64-bit system. I plan to use independent source code named
qsastime_testlib.c for this task so as not to interfere with the current
qsastime_test.c code. I plan to locally force the zulu locale following the
advice in the timegm man page to make the comparisons independent of Linux
locale issues (such as the above %s Linux result). It's possible leap
seconds will also be an issue on the Linux side of the comparison (see the
horrible history of Unix time in http://en.wikipedia.org/wiki/Unix_time),
but I have svn committed all the data on those (see tai-utc.dat) so I should
be able to deal with such issues if they come up in the comparison.

I will quit there about plans I have put together for the remaining
development since those might change depending on the results of the tests.
But to summarize my feelings at this stage, I am quite positive about the
prospects of fully integrating libqsastime into PLplot with specific
additions to the public API for libplplot so we end up indirectly depending
upon a well-tested libqsastime for all time-related plotting activity in a
cross-platform way.

Speaking of cross-platform, it would be good if OS X and Windows developers
did an ordinary PLplot build to make sure that libqsastime gets built
automatically and without build errors as part of that process.  If no build
errors occur for those platforms, further testing of example 29 (to
indirectly test strfMJD) and running lib/qsastime/qsastime_test in the build
tree is requested.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi,



----- Original Message ----
From: Alan W. Irwin <irwin@...>
To: PLplot development list <Plplot-devel@...>
Sent: Thursday, 5 February, 2009 6:27:53
Subject: Re: [Plplot-devel] time

On 2009-02-02 12:50-0800 Alan W. Irwin wrote:

> The [libqsastime] build and test code all work fine for me on Debian testing.  However, I
> need volunteers to deal with the visibility issues, windows build, etc.


Please find attached a patch file to build and run qsastime and example 29
when using
  Windows XP 
  Microsoft Visual Studio 2008 (Express Edition) on 
  CMake 2.6.2

I also tested against cygwin 1.5, gcc 3.4.4, CMake 2.6.2

The changes required are all in qsastime- 
1. qsastime/CMakeLists.txt
   1.1 Remove qsastime.h and qsastimedll.h from qsastime_LIB_SRCS
       If these are included the qsastime library is not built by MSVC

       Looking at other CMake examples add_library specifications 
       do not include header files, so I don't think this is MSVC 
       specific.

   1.2 Add extra install command to install the headers. 

2. qsastime.c
   2.1 Add #include <ctype.h> for isdigit. This is a standard header
       so I have not made it MSVC specific.

   2.2 fmtlen = strlen(format)
       while(i<fmtlen) ....

       This is basically to remove a warning from MSVC.

   2.3 The rest of the changes are to move variable declarations to the 
       beginning of each function.

3. qsastime.h
   3.1 Add include guard on header file.         
        
4. qsastime_extra.c 
   4.1 Move variable declarations to the beginning of each function.
   4.2 In passing note that the function getISOString is not thread safe.

5. qsastime_extra.h
   5.1 Add include guard on header file.
   5.2 In passing note that the function getISOString is not thread safe.

6. qsastime_test.c
   6.1 Move variable declarations to the beginning of each function.

   6.2 The MSVC version of strftime does not support all the linux 
       strftime format options. Using the original options raises 
       a runtime exception in the MSVC 2008 Debug Configuration.

       Where possible I put in equivalent more basic (MSVC) options 
       when compling with MSVC

   6.3 Note that cygwin supports all the linux options except %s

Kind regards


Terrence

On Thu, 5 Feb 2009 12:54:51 +0000 (GMT)
  trc <keats73-plplot@...> wrote:
>> 
> The changes required are all in qsastime- 
> 1. qsastime/CMakeLists.txt
>   1.1 Remove qsastime.h and qsastimedll.h from 
>qsastime_LIB_SRCS
>       If these are included the qsastime library is not 
>built by MSVC
> 
>       Looking at other CMake examples add_library 
>specifications 
>       do not include header files, so I don't think this 
>is MSVC 
>       specific.
> 
>   1.2 Add extra install command to install the headers. 
> 
> 2. qsastime.c
>   2.1 Add #include <ctype.h> for isdigit. This is a 
>standard header
>       so I have not made it MSVC specific.
> 
>   2.2 fmtlen = strlen(format)
>       while(i<fmtlen) ....
> 
>       This is basically to remove a warning from MSVC.
> 
>   2.3 The rest of the changes are to move variable 
>declarations to the 
>       beginning of each function.
> 
> 3. qsastime.h
>   3.1 Add include guard on header file.         
>        
> 4. qsastime_extra.c 
>   4.1 Move variable declarations to the beginning of 
>each function.
>   4.2 In passing note that the function getISOString is 
>not thread safe.
> 
> 5. qsastime_extra.h
>   5.1 Add include guard on header file.
>   5.2 In passing note that the function getISOString is 
>not thread safe.
> 
> 6. qsastime_test.c
>   6.1 Move variable declarations to the beginning of 
>each function.
> 
>   6.2 The MSVC version of strftime does not support all 
>the linux 
>       strftime format options. Using the original 
>options raises 
>       a runtime exception in the MSVC 2008 Debug 
>Configuration.
> 
>       Where possible I put in equivalent more basic 
>(MSVC) options 
>       when compling with MSVC
> 
>   6.3 Note that cygwin supports all the linux options 
>except %s
> 

I have used MSVC 6.0 on Windows XP and I find largely the
same issues. Terrence has clearly looked deeper than I
have - I merely responded to the compiler messages.

I am not sure I can incorporate his patches in the source
code today, but I will try.

Regards,

Arjen


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Terrence,

Thanks for the bug report, and thanks even more for the patch to fix it.
I have applied the patch to svn and it works fine for me on Linux. Could
other users, particularly on Windows / Mac please check it works for
them?

Andrew

On Thu, Feb 05, 2009 at 12:54:51PM +0000, trc wrote:
> Hi,
> 
> 
> 
> ----- Original Message ----
> From: Alan W. Irwin <irwin@...>
> To: PLplot development list <Plplot-devel@...>
> Sent: Thursday, 5 February, 2009 6:27:53
> Subject: Re: [Plplot-devel] time
> 
> On 2009-02-02 12:50-0800 Alan W. Irwin wrote:
> 
> > The [libqsastime] build and test code all work fine for me on Debian testing.  However, I
> > need volunteers to deal with the visibility issues, windows build, etc.
> 
> 
> Please find attached a patch file to build and run qsastime and example 29
> when using
>   Windows XP 
>   Microsoft Visual Studio 2008 (Express Edition) on 
>   CMake 2.6.2
> 
> I also tested against cygwin 1.5, gcc 3.4.4, CMake 2.6.2
> 
> The changes required are all in qsastime- 
> 1. qsastime/CMakeLists.txt
>    1.1 Remove qsastime.h and qsastimedll.h from qsastime_LIB_SRCS
>        If these are included the qsastime library is not built by MSVC
> 
>        Looking at other CMake examples add_library specifications 
>        do not include header files, so I don't think this is MSVC 
>        specific.
> 
>    1.2 Add extra install command to install the headers. 
> 
> 2. qsastime.c
>    2.1 Add #include <ctype.h> for isdigit. This is a standard header
>        so I have not made it MSVC specific.
> 
>    2.2 fmtlen = strlen(format)
>        while(i<fmtlen) ....
> 
>        This is basically to remove a warning from MSVC.
> 
>    2.3 The rest of the changes are to move variable declarations to the 
>        beginning of each function.
> 
> 3. qsastime.h
>    3.1 Add include guard on header file.         
>         
> 4. qsastime_extra.c 
>    4.1 Move variable declarations to the beginning of each function.
>    4.2 In passing note that the function getISOString is not thread safe.
> 
> 5. qsastime_extra.h
>    5.1 Add include guard on header file.
>    5.2 In passing note that the function getISOString is not thread safe.
> 
> 6. qsastime_test.c
>    6.1 Move variable declarations to the beginning of each function.
> 
>    6.2 The MSVC version of strftime does not support all the linux 
>        strftime format options. Using the original options raises 
>        a runtime exception in the MSVC 2008 Debug Configuration.
> 
>        Where possible I put in equivalent more basic (MSVC) options 
>        when compling with MSVC
> 
>    6.3 Note that cygwin supports all the linux options except %s
> 
> Kind regards
> 
> 
> Terrence 
> 
> 
>       

> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

On 2009-02-05 20:23-0000 Andrew Ross wrote:

>
> Terrence,
>
> Thanks for the bug report, and thanks even more for the patch to fix it.

I would like to second that.

> I have applied the patch to svn and it works fine for me on Linux.

I confirm that. I found identical qsastime_test results and identical x29
PostScript driver results for revision 9458 compared to previous on my Linux
(Debian testing) platform.

Terrence's report of success on his particular Windows platform for what was
effectively revision 9458 is most encouraging. Hopefully, the requested
further testing on all the different Windows and Mac OS X platforms
accessible to our users and developers here will show no further platform
issues for revision 9458.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On 2009-02-04 22:27-0800 Alan W. Irwin wrote:

> My immediate further plans at this stage are to directly test the three key
> functions (setFromUT, breakDownMJD, and strfMJD) currently in libqsastime
> against their closest Linux counterparts (timegm, gmtime, and strftime) for
> the complete range of valid Linux times.

I am making some good progress on this.  First I discovered I have access to
essentially unlimited date ranges for my Linux 64-bit system (time_t has a
sizeof 8, i.e., it is 64-bits) so that and the availability of timegm (the
inverse of gmtime) for the Linux C library makes my platform ideal for
comprehensive testing of libqsastime.

I had to implement a Gregorian proleptic (proleptic means extended
consistently backward in time) calendar option (forceJulian=-1) and sort out
leap year bugs for negative years for that case.  I also documented and
simplified the existing forceJulian=1 (Julian proleptic calendar) leap-year
logic.

I have tested setFromUT for a range of years near the Julian date epoch, the
year epoch, and the MJD epoch, and obtained the expected results in all
cases.  I have also tested setFromUT against timegm for an extremely wide
date range (+/- 5 million years, just narrow enough not to overflow the
32-bit integer part of MJD), and got exact agreement for the results in
(time_t) seconds since the Unix epoch.  That result indicates clearly that
the Linux C library uses the Gregorian proleptic calendar for all dates.
This initial comparison is rather coarse (every million years), and I plan
to run one with much finer spacing and also do some fine comparisons between
breakDownMJD and strfMJD and their Linux counterparts.

In sum, it is looking extremely encouraging as of revision 9472, but there
is still more testing to do, and I also have some additional development
plans to add some features to libqsastime (see README.qsastime_API) before I
finalize how we use this library from the libplplot library.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On 2009-02-07 16:47-0800 Alan W. Irwin wrote:

> [...]I plan
> to run one [test of setfromMJD versus timegm] with much finer spacing.

I did such a test with 10 million calls and it turns out setfromMJD is
roughly 4 times faster than timegm.  That is, on my 2.4GHz box, the time per
call is 200 ns for timegm and 50 ns for setfromMJD. (Nice efficiency,
Tony!) Furthermore, the two calls agree exactly with each other for

<year>:01-01 00:00:00

for every (Gregorian proleptic calendar) year from -5 million to + 5 million.

For my very first test of breakDownMJD, I compared its results with gmtime
for 60 million calculations (every second between 2008 and 2010).  gmtime
and breakDownMJD took roughly 100 ns and 200 ns per call and agreed exactly
despite the official insertion of a leap second in the middle of the range.
The breakDownMJD efficiency is two times worse than gmtime.  I am not deeply
concerned with that, but it is possible there is room for substantial
improvement there so I will keep my eyes open for anything obvious.

I think what is going on with the leap seconds is that gmtime ignores leap
seconds all together when it converts time_t values to broken-down time.
Certainly, that is what breakDownMJD does, and since the two programmes
agree exactly, I think that happens for gmtime as well. I assume the actual
leap second insertion on a Linux computer is implemented by simply getting
the system time_t to repeat once which gives both a time_t discontinuity and
broken-down time discontinuity at the real instant when a leap second is
inserted.

My next step is to implement forceJulian=-1 (i.e., forced proleptic
Gregorian mode regardless of date) for breakDownMJD, and then to compare
breakDownMJD with gmtime for forceJulian=-1 over a very wide range of date.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi Alan,

> Speaking of cross-platform, it would be good if OS X and Windows developers
> did an ordinary PLplot build to make sure that libqsastime gets built
> automatically and without build errors as part of that process.  If no build
> errors occur for those platforms, further testing of example 29 (to
> indirectly test strfMJD) and running lib/qsastime/qsastime_test in the build
> tree is requested.
>   
I compiled the latest svn version (9470) with Visual C++ 2008 and the 
qsastime library built fine, also example 29. I could run example 29 and 
it looked fine, no crashes or warnings (we had this before).

Running lib/qsastime/qsastime_test I get:

------------------------------------------------------------------------------------------------------

Start date/time components: 2004-1-23 13:39:  2.345678901
date/time components: 2004-1-23 13:39:  2.345678901

MJD = 53027, seconds =   49142.345678901
 MJD =   53027.5687771491
 JD = 2453028.0687771491

ISO string = '2004-01-23 13:39:02.3456789010'

strfMJD:ISO equiv:   '2004-01-23 13:39:02.345678901'
strfMJD:ISO equiv:  '2004-01-23T13:39:02.3456Z'
difference MJD (month/day) - MJD(doy) '0'

difference MJD (d-1, h+24) - MJD(d, h) '-8.42125e-017'

CDF epoch sec 63242084342345.680
from CDF ISO string (CDF epoch is accurate to msec only) = 
'2004-01-23T13:39:02.3456802368Z'
Day of week is/was Fri

ISO string = '2004-01-23 13:39:02.3456789010'

for 2004-01-23 13:39:02.3456789010, MJD = 53027, seconds =      49142.345679
ISO string = '2004-01-23T13:39:02.3456789010Z'

for 2004-01-23T13:39:02.3456789010Z, MJD = 53027, seconds =      
49142.345679

Gregorian = '1752-09-15 00:39:02.3456789010'
1752-09-26T00:39:02.3456789010Z Julian = '1752-09-15 
00:39:02.3456789010' Gregorian, (give us back our 11 days)
chars 154 for
   strfMJD():
   --------
 'Fri Jan 23 13:39:02 UTC 2004'
 Fri Jan 23 13:39:02 2004
 01/23/04 2004-01-23
 023
 01:39:02 PM
 1074865142
 23-Jan-2004


  strftime(): (invalid before 1970)
   ------
 'Fri Jan 23 13:39:02 UTC 2004'
 01/23/04 13:39:02
 01/23/04 2004-01-23
 023
 01:39:02 PM
 %s not implemented
 23-Jan-2004

------------------------------------------------------------------------------------------------------

Great work, that it compiles and runs on Windows out of the box!

Regards,
Werner

-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Hi Alan,
> I confirm that. I found identical qsastime_test results and identical x29
> PostScript driver results for revision 9458 compared to previous on my Linux
> (Debian testing) platform.
>   
I would propose a new test: if a change is done in the PLplot core and 
output of examples changes as well the tests will not show this issue. 
So I would propose that we run all examples now and save the ps files 
and upload them somewhere. We should add another test to the tests, so 
if these "correct" plots are found somewhere the C output is compared to 
these plots for changes. So changes due to PLplot core coding would show 
up. If this changes are deliberately we'll save a new set of plots. I 
wouldn't add theses plots to the src packages, since this would only be 
needed for thoroughly testing of  the library.  In addition, it would 
then also be possible to compare results between the different 
platforms. So far we don't know if the Windows, Mac OS X and Linux port 
produce the same output.

I have another proposal for the test as well: so far we only test what 
happens if we successfully run an example. But what happens if PLplot 
aborts or exits because of some problem? A well written library should 
have freed all memory, shouldn't crash and so on. So it would be nice to 
have an example which aborts and exits for various reason (e.g. 
depending on a command line option). Such an example would not produce 
any output and may only be useful in combination with a debugger or 
valgrind, but we should think about such an "example", or?

Regards,
Werner

-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

On 2009-02-08 21:46+0100 Werner Smekal wrote:

> Hi Alan,
>> I confirm that. I found identical qsastime_test results and identical x29
>> PostScript driver results for revision 9458 compared to previous on my 
>> Linux
>> (Debian testing) platform.
>> 
> I would propose a new test: if a change is done in the PLplot core and output 
> of examples changes as well the tests will not show this issue. So I would 
> propose that we run all examples now and save the ps files and upload them 
> somewhere. We should add another test to the tests, so if these "correct" 
> plots are found somewhere the C output is compared to these plots for 
> changes. So changes due to PLplot core coding would show up. If this changes 
> are deliberately we'll save a new set of plots. I wouldn't add theses plots 
> to the src packages, since this would only be needed for thoroughly testing 
> of  the library.  In addition, it would then also be possible to compare 
> results between the different platforms. So far we don't know if the Windows, 
> Mac OS X and Linux port produce the same output.

This is an excellent idea that has been proposed a number of times, but
concerns over rounding differences from one platform to the next have
stopped anybody actually implementing it up to now. However, if such
rounding issues proved to be a major issue, you could get around that by
using ndiff (a fuzzy diff) and setting the difference criterion equal to one
or two units in the last PostScript place.

ndiff can only be built and installed on Unix at the moment, but according
to the package INSTALL file it should be possible to build it for any
Windows environment where a POSIX-compliant shell (including AWK which is
mentioned especially) is available.  Currently, it is built using autotools.
I assume changing over to CMake would be required (and also straightforward
since it is a pretty small software package) to make the ndiff build
possible on Windows.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi Alan,



> On 2009-02-04 22:27-0800 Alan W. Irwin wrote:

 
> In sum, it is looking extremely encouraging as of revision 9472, but there
> is still more testing to do, and I also have some additional development
> plans to add some features to libqsastime (see README.qsastime_API) before I
> finalize how we use this library from the libplplot library.

I had a very quick look at the README.qsastime_API document. 

ctime is already used in the C standard library (see time.h) so will need to be renamed. Perhaps all the functions should be prefixed to avoid further clashes.

Also at some point it would be useful to address localization issues with regard to day and month names.


Terrence

On Feb 5, 2009, at 1:50 PM, Alan W. Irwin wrote:

> Terrence's report of success on his particular Windows platform for  
> what was
> effectively revision 9458 is most encouraging. Hopefully, the  
> requested
> further testing on all the different Windows and Mac OS X platforms
> accessible to our users and developers here will show no further  
> platform
> issues for revision 9458.
>
> Alan

Built 9474 OK today on OS X 10.4.11.
Jerry

Hi,

Alan W. Irwin wrote:
> On 2009-02-08 21:46+0100 Werner Smekal wrote:
> 
>> Hi Alan,
>>> I confirm that. I found identical qsastime_test results and identical x29
>>> PostScript driver results for revision 9458 compared to previous on my 
>>> Linux
>>> (Debian testing) platform.
>>>
>> I would propose a new test: if a change is done in the PLplot core and output 
>> of examples changes as well the tests will not show this issue. So I would 
>> propose that we run all examples now and save the ps files and upload them 
>> somewhere. We should add another test to the tests, so if these "correct" 
>> plots are found somewhere the C output is compared to these plots for 
>> changes. So changes due to PLplot core coding would show up. If this changes 
>> are deliberately we'll save a new set of plots. I wouldn't add theses plots 
>> to the src packages, since this would only be needed for thoroughly testing 
>> of  the library.  In addition, it would then also be possible to compare 
>> results between the different platforms. So far we don't know if the Windows, 
>> Mac OS X and Linux port produce the same output.
> 
> This is an excellent idea that has been proposed a number of times, but
> concerns over rounding differences from one platform to the next have
> stopped anybody actually implementing it up to now. However, if such
> rounding issues proved to be a major issue, you could get around that by
> using ndiff (a fuzzy diff) and setting the difference criterion equal to one
> or two units in the last PostScript place.

> ndiff can only be built and installed on Unix at the moment, but according
> to the package INSTALL file it should be possible to build it for any
> Windows environment where a POSIX-compliant shell (including AWK which is
> mentioned especially) is available.  Currently, it is built using autotools.
> I assume changing over to CMake would be required (and also straightforward
> since it is a pretty small software package) to make the ndiff build
> possible on Windows.

1. ndiff builds and installs(*) on cygwin. Until someone ported ndiff to basic windows system the cygwin version could be used to testing both cygwin and basic windows versions plplot. (* I needed to use - make install CP=cp)

2. Note the default PLplot build on windows does not include freetype.  If this test is implemented, the build options need to be included somewhere to highlight this possible major difference.
 

Terrence

On 2009-02-08 08:18-0800 Alan W. Irwin wrote:

> My next step is to implement forceJulian=-1 (i.e., forced proleptic
> Gregorian mode regardless of date) for breakDownMJD, and then to compare
> breakDownMJD with gmtime for forceJulian=-1 over a very wide range of date.

I finished (revision 9491) a first pass at the implementation, and the result
seems to work for test1 of qsastime_testlib.  You can run test1 by running

echo 0xffff |lib/qsastime/qsastime_testlib

from the top of the build tree.  The echo 0xffff provides a bit pattern that
potentially runs the first 16 tests, but only one has been implemented so
far.  test1 does some standard comparisons of setFromUT, breakDownMJD, and
strfMJD with the my_timegm POSIX emulation of the Linux C library timegm
routine and the C library routines gmtime and strftime.  The reason why I
emulate the Linux C library timegm routine with my_timegm is so that both
Linux and non-Linux POSIX compliant systems can run the above test.  Note
test 1 is just for a small epoch range near the Julian day number epoch, and
I plan to try other more extensive ranges for test2, etc.  (Some of these
further tests will be a repeat of previous work (currently bypassed with
"if(0) " but done in a systematic way and controlled with the bit pattern of
whatever is fed to stdin as above.  As the systematic versions of the tests
get implemented, the hodge-podge of bypassed code at the tail-end of
qsastime_testlib.c will gradually disappear.)

The above test immediately exits if sizeof(time_t) !=8 or sizeof(int) != 4.
The reason for those constraints is you need a 64-bit time_t to have access
to large date ranges in the C library, and you need access to 32-bit ints to
test how we expect libqsastime to work on 32-bit systems.  Probably most
64-bit hardware platforms will pass these criteria, most 32-bit platforms
will pass the sizeof(int) criterion, but few 32-bit platforms will pass the
sizeof(time_t) criterion (which is one of our motivations for implementing
this library in the first place.)

If you have a 64-bit system (especially Mac OS X and Windows since I don't
have access to those platforms), please give the above test a try. I suspect
it will build and run out of the box on Mac OS X.  It's probable some
additional work will be required to build the test on Windows. If it turns
out such a build is not possible on Windows, you should bypass
the build of qsastime_testlib in our CMake build system file,
lib/qsastime/CMakeLists.txt, by modifying that build logic as follows:

if(NOT WIN32)
   add_executable(qsastime_testlib qsastime_testlib.c)
   target_link_libraries(qsastime_testlib qsastime)
endif(NOT WIN32)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi,

> On 2009-02-08 08:18-0800 Alan W. Irwin wrote:
> 
> If you have a 64-bit system (especially Mac OS X and Windows since I don't
> have access to those platforms), please give the above test a try. I suspect
> it will build and run out of the box on Mac OS X.  It's probable some
> additional work will be required to build the test on Windows. If it turns
> out such a build is not possible on Windows, you should bypass
> the build of qsastime_testlib in our CMake build system file,
> lib/qsastime/CMakeLists.txt, by modifying that build logic as follows:
> 
> if(NOT WIN32)
>    add_executable(qsastime_testlib qsastime_testlib.c)
>    target_link_libraries(qsastime_testlib qsastime)
> endif(NOT WIN32)
> 
> Alan
>

Compiling qsastime etc with MSVC 9 and cygwin gcc 3.4 showed some errors-

1. plplot-dev/lib/qsastime/qsastime.c:282: warning: assignment
   makes integer from pointer without a cast
   plplot-dev/lib/qsastime/qsastime.c:285: warning: assignment
   makes integer from pointer without a cast

   In both these cases, year should be dereferenced ie *year.
 

2. ..\..\..\..\lib\qsastime\qsastime_testlib.c(58) : warning C4244:   
   'return' : conversion from 'time_t' to 'int', possible loss of data

   I think  my_timegm is meant to be defined in line 44 as 
      time_t my_timegm(struct tm *tm) 

3. plplot-dev\lib\qsastime\qsastime_testlib.c(128) : warning C4700:
    uninitialized local variable 'secs1' used
   plplot-dev\lib\qsastime\qsastime_testlib.c(144) : warning C4700:
    uninitialized local variable 'secs1' used

   In both these cases secs1 should be sec1

4. qsastime_testlib cannot be built with MSVC 2008 as setenv and unsetenv 
    are not implemented. 

A patch for items 1-3 above is attached. However due to 4 the above changes
are untested. 


Kind regards


Terrence

On 2009-02-10 21:03-0000 trc wrote:

> Compiling qsastime etc with MSVC 9 and cygwin gcc 3.4 showed some errors-
>
> 1. plplot-dev/lib/qsastime/qsastime.c:282: warning: assignment
>   makes integer from pointer without a cast
>   plplot-dev/lib/qsastime/qsastime.c:285: warning: assignment
>   makes integer from pointer without a cast
>
>   In both these cases, year should be dereferenced ie *year.
>
>
> 2. ..\..\..\..\lib\qsastime\qsastime_testlib.c(58) : warning C4244:
>   'return' : conversion from 'time_t' to 'int', possible loss of data
>
>   I think  my_timegm is meant to be defined in line 44 as
>      time_t my_timegm(struct tm *tm)
>
> 3. plplot-dev\lib\qsastime\qsastime_testlib.c(128) : warning C4700:
>    uninitialized local variable 'secs1' used
>   plplot-dev\lib\qsastime\qsastime_testlib.c(144) : warning C4700:
>    uninitialized local variable 'secs1' used
>
>   In both these cases secs1 should be sec1
>
> A patch for items 1-3 above is attached.

I had caught one of those already (incorrectly using year rather than
*year), but I committed the rest of your patch as revision 9501.  I gave
credit in the commit message to Terrence Keats.  I hope that is your correct
last name.

It turns out (on my system at least) all bugs other than the *year problem
(which was fixed in a previous commit) have no effect on test1 results, but
these bugs would have caught up with me eventually for other tests so
thanks!

> [out of order] 4. qsastime_testlib cannot be built with MSVC 2008 as setenv and unsetenv
>    are not implemented.
>
> [so] the above changes
> are untested.

Is this a showstopper for MSVC 2008 or do you think you can find for that
platform (a) some library alternatives for setenv and unsetenv, (b) some
other alternative to set the time zone to zero temporarily which would make
mktime act like an inverse to gmtime, or (c) some other alternative that is
equivalent to the Linux timegm or the inverse of gmtime?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi Alan,

Alan W. Irwin wrote:
>
>> [out of order] 4. qsastime_testlib cannot be built with MSVC 2008 as 
>> setenv and unsetenv
>>    are not implemented.
>>
>> [so] the above changes
>> are untested.
> 
> Is this a showstopper for MSVC 2008 or do you think you can find for that
> platform (a) some library alternatives for setenv and unsetenv, (b) some
> other alternative to set the time zone to zero temporarily which would make
> mktime act like an inverse to gmtime, or (c) some other alternative that is
> equivalent to the Linux timegm or the inverse of gmtime?
> 


There are too many problems to make qsastime_testlib worthwhile on 32 bit Windows XP with MSVC 2008 (and earlier editions) even with 64 bit time_t values.

32 bit Windows XP / MSVC 2008 has extensions for 64 bit time_t values and a function  _mkgmtime64 for converting times a struct tm to 64 bit time_t. Unfortunately mkgmtime64 returns -1 for all times prior to 1/1/1970.

A further problem for qsastime_testlib is that the MSVC debug version of strftime throws an exception for years less than 0 or greater than 9999. 

For the record MSVC has the (unix) putenv function which can be used to implement setenv and unsetenv. However googling putenv suggests there could be problems with memory leaks and care has to be taken over ownership/lifetime of the environment variables. Further it is unclear how an environment variable is set to empty string. eg. 
   setenv("TZ","",1) -> putenv("TZ=")
This unsets TZ rather than setting it to an empty string.
 

Default 32 bit Cygwin compiles and links but has 32 bit time_t so testing is not done. I didn't investigate if there were 64bit time_t extensions.

Note my investigations were on a 32bit Windows XP system so this excludes 32 bit Vista and 64bit versions of XP and Vista.


Terrence

On 2009-02-14 16:05-0000 trc wrote:

> Hi Alan,
>
> Alan W. Irwin wrote:
>>
>>> [out of order] 4. qsastime_testlib cannot be built with MSVC 2008 as
>>> setenv and unsetenv
>>>    are not implemented.
>>>
>>> [so] the above changes
>>> are untested.
>>
>> Is this a showstopper for MSVC 2008 or do you think you can find for that
>> platform (a) some library alternatives for setenv and unsetenv, (b) some
>> other alternative to set the time zone to zero temporarily which would make
>> mktime act like an inverse to gmtime, or (c) some other alternative that is
>> equivalent to the Linux timegm or the inverse of gmtime?
>>
>
>

> There are too many problems to make qsastime_testlib worthwhile on 32 bit
Windows XP with MSVC 2008 (and earlier editions) even with 64 bit time_t
values.

> 32 bit Windows XP / MSVC 2008 has extensions for 64 bit time_t values and
a function _mkgmtime64 for converting times a struct tm to 64 bit time_t.
Unfortunately mkgmtime64 returns -1 for all times prior to 1/1/1970.

> A further problem for qsastime_testlib is that the MSVC debug version of
strftime throws an exception for years less than 0 or greater than 9999.

> For the record MSVC has the (unix) putenv function which can be used to
implement setenv and unsetenv. However googling putenv suggests there could
be problems with memory leaks and care has to be taken over
ownership/lifetime of the environment variables. Further it is unclear how
an environment variable is set to empty string. eg.

>   setenv("TZ","",1) -> putenv("TZ=")
> This unsets TZ rather than setting it to an empty string.
>

> Default 32 bit Cygwin compiles and links but has 32 bit time_t so testing
is not done. I didn't investigate if there were 64bit time_t extensions.

> Note my investigations were on a 32bit Windows XP system so this excludes
32 bit Vista and 64bit versions of XP and Vista.

Hi Terrence:

Thanks very much for these further investigations.

It sounds like _mkgmtime64 is the exact equivalent to the required timegm.
Too bad it doesn't work for your particular Windows version, but that
function is probably the first thing that should be investigated on other
Windows platform to see if the limitation on negative time_t values has been
removed.  It's possible it is not working for you because you have a 32-bit
system.  Certainly, Linux versions of timegm and gmtime are incredibly
limited on 32-bit hardware (time_t limited to just 32-bits).  I am not
surprised that Cygwin has the same issue on 32-bit hardware.

Further investigation of putenv might be worthwhile.  My guess is that
unsetting TZ is quite likely to make mktime act just like mkgmtime, but the
question is whether there are limitations in the 64-bit version of mktime.
Again, that may depend on whether the Windows hardware platform is 32-bit or
64-bit.

Of course, the purpose of qsastime_testlib is to test libqsastime for
extreme time ranges, but because of those extreme ranges you tend to run into
limitations of the testing platform's libraries as you have found out on
your 32-bit Windows platform, and as any 32-bit Linux user will also find
out.  Fortunately, I have found at least one platform (Linux 64-bit) where
qsastime_testlib works.  That is a most important result which gives me great
general confidence in libqsastime. For other platforms, testing over a
limited time range with qsastime_test, and taking account of the good Linux
64-bit results for qsastime_testlib is probably sufficient to give
confidence in libqsastime for those platforms as well.  However, it would be
nice if someone also finds a Mac OS X platform and Windows platform where
qsastime_testlib works as well just to make sure there are no
platform-dependent limitations built into libqsastime (note that is a
different and much more important issue than limitations in the test code)
for extreme time ranges.

My guess is both qsastime_test and qsastime_testlib will work fine on 64-bit
Mac OS X platforms. But I would like to see that confirmed. qsastime_test
should work on OS X 32-bit platforms.  qsastime_testlib might even work on
OS X 32-bit platforms if they have 64-bit time_t available.

Obviously, there are problems building and running qsastime_testlib on the
limited (32-bit XP) Windows platforms that have been tested so far.  If
64-bit and/or Vista Windows also have problems, then we can limit what is
tested in qsastime_testlib to make it work on Windows.  For example, it
would be easy enough to change the test code so the call to strftime was
skipped for Windows. Also, I have discussed off-list with Werner the
possibility of dropping one of the tests for windows so that my_timegm is
never called in that case.  We could also drop the gmtime call if that is
also problematic on windows for a wide range of times.  That still leaves us
with the extremely worthwhile and essential test of whether setFromUT and
breakDownMJD are inverses of each other for an extreme range of times on
Windows. However, I still have some hope that there are some Windows
platforms where the limitations on time functions for 32-bit XP that you
reported above have been removed so this dumbing down of the tests will not
be necessary for the windows case.

The current (revision 9531) status of libqsastime is all tests pass with
flying colours on 64-bit Linux, and I have no further changes planned for
setFromUT, breakDownMJD, or strfMJD or the comprehensive tests (which now
take 10 minutes of cpu time to do 100 million different calls of
testlib_broken_down_time and 74 million different calls of testlib_MJD) of
those functions.  I have heard privately from Tony Allen that he may have a
few more changes in mind for those functions.  That's fine since we have a
strong testing environment to make sure further changes do not introduce
errors, and this is a golden opportunity to get everything right for this
library before we start being restricted by backwards compatibility
concerns.

I now plan to start working on the wrapper functions mentioned in
README.qsastime_API.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hello Terrence,

I do not think it is possible to set an environment variable to an empty
string on Windows. This amounts to undefining it.

I have found the same problem with setenv() and unsetenv() on my
venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create
a workaround using putenv(), because right now building PLplot stops
on the QSAS test program.

Regards,

Arjen

On 2009-02-14 17:05, trc wrote:
> Hi Alan,
> 
> Alan W. Irwin wrote:
>>> [out of order] 4. qsastime_testlib cannot be built with MSVC 2008 as 
>>> setenv and unsetenv
>>>    are not implemented.
>>>
>>> [so] the above changes
>>> are untested.
>> Is this a showstopper for MSVC 2008 or do you think you can find for that
>> platform (a) some library alternatives for setenv and unsetenv, (b) some
>> other alternative to set the time zone to zero temporarily which would make
>> mktime act like an inverse to gmtime, or (c) some other alternative that is
>> equivalent to the Linux timegm or the inverse of gmtime?
>>
> 
> 
> There are too many problems to make qsastime_testlib worthwhile on 32 bit Windows XP with MSVC 2008 (and earlier editions) even with 64 bit time_t values.
> 
> 32 bit Windows XP / MSVC 2008 has extensions for 64 bit time_t values and a function  _mkgmtime64 for converting times a struct tm to 64 bit time_t. Unfortunately mkgmtime64 returns -1 for all times prior to 1/1/1970.
> 
> A further problem for qsastime_testlib is that the MSVC debug version of strftime throws an exception for years less than 0 or greater than 9999. 
> 
> For the record MSVC has the (unix) putenv function which can be used to implement setenv and unsetenv. However googling putenv suggests there could be problems with memory leaks and care has to be taken over ownership/lifetime of the environment variables. Further it is unclear how an environment variable is set to empty string. eg. 
>    setenv("TZ","",1) -> putenv("TZ=")
> This unsets TZ rather than setting it to an empty string.
>  
> 
> Default 32 bit Cygwin compiles and links but has 32 bit time_t so testing is not done. I didn't investigate if there were 64bit time_t extensions.
> 
> Note my investigations were on a 32bit Windows XP system so this excludes 32 bit Vista and 64bit versions of XP and Vista.
> 
> 
> Terrence
> 
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Hi,


Arjen Markus wrote:

> I have found the same problem with setenv() and unsetenv() on my
> venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create
> a workaround using putenv(), because right now building PLplot stops
> on the QSAS test program.
>

In case you haven't created the work round (and apologies for not sending it earlier) please find a limited patch for implementing setenv for MSVC. 
 
This patch does not use CMake to configure the optional code instead relying on Compiler and in source Macros for configuration.

With this patch MSVC 2008 version of qsastime produces 


sizeof(time_t) = 8
sizeof(int) = 4
0xffff
Test 01 of calendar dates in the vicinity of the JD epoch

Start of Julian proleptic inner test
input and output (strfMJD) date/time
-4717-01-01T12:00:00.000000000000000Z
-4717-01-01T12:00:00.0Z
setFromUT JD =    -1826.0000000000000000 days
Start of Gregorian proleptic inner test
input and output (strftime), and output (strfMJD) date/time
-4717-01-01T12:00:00.000000000000000Z
setFromUT secs_past_epoch = -211021243200 seconds
my_timegm secs_past_epoch = -1 seconds
delta secs_past_epoch = -567845695 seconds
test failed with inconsistency between setFromUT and my_timegm



Terrence

Hi Terrence,

with this patch in hand, I can concentrate on adding a test to the CMake 
files.

Thanks,

Arjen

On 2009-02-18 15:11, trc wrote:
> Hi,
> 
> 
> Arjen Markus wrote:
> 
>> I have found the same problem with setenv() and unsetenv() on my
>> venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create
>> a workaround using putenv(), because right now building PLplot stops
>> on the QSAS test program.
>>
> 
> In case you haven't created the work round (and apologies for not sending it earlier) please find a limited patch for implementing setenv for MSVC. 
>  
> This patch does not use CMake to configure the optional code instead relying on Compiler and in source Macros for configuration.
> 
> With this patch MSVC 2008 version of qsastime produces 
> 
> 
> sizeof(time_t) = 8
> sizeof(int) = 4
> 0xffff
> Test 01 of calendar dates in the vicinity of the JD epoch
> 
> Start of Julian proleptic inner test
> input and output (strfMJD) date/time
> -4717-01-01T12:00:00.000000000000000Z
> -4717-01-01T12:00:00.0Z
> setFromUT JD =    -1826.0000000000000000 days
> Start of Gregorian proleptic inner test
> input and output (strftime), and output (strfMJD) date/time
> -4717-01-01T12:00:00.000000000000000Z
> setFromUT secs_past_epoch = -211021243200 seconds
> my_timegm secs_past_epoch = -1 seconds
> delta secs_past_epoch = -567845695 seconds
> test failed with inconsistency between setFromUT and my_timegm
> 
> 
> 
> Terrence
> 
> 
>       


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

On 2009-02-18 14:11-0000 trc wrote:

> Hi,
>
>
> Arjen Markus wrote:
>
>> I have found the same problem with setenv() and unsetenv() on my
>> venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create
>> a workaround using putenv(), because right now building PLplot stops
>> on the QSAS test program.
>>
>
> In case you haven't created the work round (and apologies for not sending it earlier) please find a limited patch for implementing setenv for MSVC.
>
> This patch does not use CMake to configure the optional code instead relying on Compiler and in source Macros for configuration.
>

Thanks, Terrence, for this setenv patch for MSVC.

Arjen, I would appreciate it if you review this patch to make sure it works
for all Windows cases and then commit it.  That should at least allow the
windows build (originally broken by me, and sorry about that) to work again.
There is some urgency to the commit because some additional Windows users
beyond you and Werner are attempting to build from our svn version.

> With this patch MSVC 2008 version of qsastime[_testlib] produces

>
>
> sizeof(time_t) = 8
> sizeof(int) = 4
> 0xffff
> Test 01 of calendar dates in the vicinity of the JD epoch
>
> Start of Julian proleptic inner test
> input and output (strfMJD) date/time
> -4717-01-01T12:00:00.000000000000000Z
> -4717-01-01T12:00:00.0Z
> setFromUT JD =    -1826.0000000000000000 days
> Start of Gregorian proleptic inner test
> input and output (strftime), and output (strfMJD) date/time
> -4717-01-01T12:00:00.000000000000000Z

Comparison with qsastime_testlib.out_standard shows all is well up to
here except for the above 0xffff which I assume is a spin-off of trying
to put 0xffff on stdin for the programme on Windows rather than the
echo 0xffff | lib/qsastime/qsastime_testlib method that works on Linux.

> setFromUT secs_past_epoch = -211021243200 seconds

To double-check this calculation (which does not appear on
qsastime_testlib.out_standard since that Linux calculation had no errors),
MJD = JD - 2400000.5 so the Gregorian epoch JD (from
qsastime_testlib.out_standard since you didn't get that far) of -1788
corresponds to MJD = -2401788.5 days since the MJD epoch. But the Unix epoch
of 1970-01-01 has an MJD of 40587 so this corresponds to -2442375.5 days
since the Unix epoch or -211021243200.0 seconds since the Unix epoch which
confirms the above calculation.

> my_timegm secs_past_epoch = -1 seconds

That is the source of the error.  On your platform, my_timegm only works as
well as the C library mktime routine which currently claims that 4718-01-01
BCE (Gregorian proleptic calendar) is only 1 second before the Unix epoch of
1970-01-01.  So once your patch or something similar is applied, the next
step is to see if there are any Windows platforms where mktime gives a
correct result for years before the Unix epoch.

> delta secs_past_epoch = -567845695 seconds

This does not represent the difference of the two previous time_t values
like it should.  I have now fixed (revision 9549) the output formatting so
the resulting difference of time_t values reported here can have time_t
range rather than int range (which overflowed in this case giving the
bad delta secs_past_epoch result above).

In sum, the next step here is to get the patch tested, revised (if
necessary), and committed as a matter of some urgency since it makes the
windows build work again.  The next step after that is to try and find some
windows platform where mktime (and therefore my_timegm) works for epochs
before the Unix epoch.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi Alan,

I will take care of it tonight.

The test I have in mind is:
- Check if a program can be built using both setenv() and unsetenv()
- If not, then fall back on putenv() as in the patch

I assume that these functions come in pairs, so that it won't be
necessary to test them separately.

First priority: get it working again.

Regards,

Arjen


On 2009-02-18 20:25, Alan W. Irwin wrote:
> On 2009-02-18 14:11-0000 trc wrote:
> 
>> Hi,
>>
>>
>> Arjen Markus wrote:
>>
>>> I have found the same problem with setenv() and unsetenv() on my
>>> venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create
>>> a workaround using putenv(), because right now building PLplot stops
>>> on the QSAS test program.
>>>
>>
>> In case you haven't created the work round (and apologies for not 
>> sending it earlier) please find a limited patch for implementing 
>> setenv for MSVC.
>>
>> This patch does not use CMake to configure the optional code instead 
>> relying on Compiler and in source Macros for configuration.
>>
> 
> Thanks, Terrence, for this setenv patch for MSVC.
> 
> Arjen, I would appreciate it if you review this patch to make sure it works
> for all Windows cases and then commit it.  That should at least allow the
> windows build (originally broken by me, and sorry about that) to work 
> again.
> There is some urgency to the commit because some additional Windows users
> beyond you and Werner are attempting to build from our svn version.
> 
>> With this patch MSVC 2008 version of qsastime[_testlib] produces
> 
>>
>>
>> sizeof(time_t) = 8
>> sizeof(int) = 4
>> 0xffff
>> Test 01 of calendar dates in the vicinity of the JD epoch
>>
>> Start of Julian proleptic inner test
>> input and output (strfMJD) date/time
>> -4717-01-01T12:00:00.000000000000000Z
>> -4717-01-01T12:00:00.0Z
>> setFromUT JD =    -1826.0000000000000000 days
>> Start of Gregorian proleptic inner test
>> input and output (strftime), and output (strfMJD) date/time
>> -4717-01-01T12:00:00.000000000000000Z
> 
> Comparison with qsastime_testlib.out_standard shows all is well up to
> here except for the above 0xffff which I assume is a spin-off of trying
> to put 0xffff on stdin for the programme on Windows rather than the
> echo 0xffff | lib/qsastime/qsastime_testlib method that works on Linux.
> 
>> setFromUT secs_past_epoch = -211021243200 seconds
> 
> To double-check this calculation (which does not appear on
> qsastime_testlib.out_standard since that Linux calculation had no errors),
> MJD = JD - 2400000.5 so the Gregorian epoch JD (from
> qsastime_testlib.out_standard since you didn't get that far) of -1788
> corresponds to MJD = -2401788.5 days since the MJD epoch. But the Unix 
> epoch
> of 1970-01-01 has an MJD of 40587 so this corresponds to -2442375.5 days
> since the Unix epoch or -211021243200.0 seconds since the Unix epoch which
> confirms the above calculation.
> 
>> my_timegm secs_past_epoch = -1 seconds
> 
> That is the source of the error.  On your platform, my_timegm only works as
> well as the C library mktime routine which currently claims that 4718-01-01
> BCE (Gregorian proleptic calendar) is only 1 second before the Unix 
> epoch of
> 1970-01-01.  So once your patch or something similar is applied, the next
> step is to see if there are any Windows platforms where mktime gives a
> correct result for years before the Unix epoch.
> 
>> delta secs_past_epoch = -567845695 seconds
> 
> This does not represent the difference of the two previous time_t values
> like it should.  I have now fixed (revision 9549) the output formatting so
> the resulting difference of time_t values reported here can have time_t
> range rather than int range (which overflowed in this case giving the
> bad delta secs_past_epoch result above).
> 
> In sum, the next step here is to get the patch tested, revised (if
> necessary), and committed as a matter of some urgency since it makes the
> windows build work again.  The next step after that is to try and find some
> windows platform where mktime (and therefore my_timegm) works for epochs
> before the Unix epoch.
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________
> 


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Hi Alan,

my old MSVC compiler is complaining about a few things
with Terrence's patch - nothing I can not resolve, but
the worst is that the testlib program stops immediately:

sizeof(time_t) = 4
tests abandoned because time_t too small on this platform 
to run this programme

What is the way forward here? Will the qsastime library
fail altogether then? Output from qsastime_test does not
look bad (see below).

Regards,

Arjen


Start date/time components: 2004-1-23 13:39:  2.345678901
date/time components: 2004-1-23 13:39:  2.345678901

MJD = 53027, seconds =   49142.345678901
  MJD =   53027.5687771491
  JD = 2453028.0687771491

ISO string = '2004-01-23 13:39:02.3456789010'

strfMJD:ISO equiv:   '2004-01-23 13:39:02.345678901'
strfMJD:ISO equiv:  '2004-01-23T13:39:02.3456Z'
difference MJD (month/day) - MJD(doy) '0'

difference MJD (d-1, h+24) - MJD(d, h) '-8.42125e-017'

CDF epoch sec 63242084342345.680
from CDF ISO string (CDF epoch is accurate to msec only) = 
'2004-01-23T13:39:02.3456802368Z'
Day of week is/was Fri

ISO string = '2004-01-23 13:39:02.3456789010'

for 2004-01-23 13:39:02.3456789010, MJD = 53027, seconds = 
     49142.345679
ISO string = '2004-01-23T13:39:02.3456789010Z'

for 2004-01-23T13:39:02.3456789010Z, MJD = 53027, seconds 
=      49142.345679

Gregorian = '1752-09-15 00:39:02.3456789010'
1752-09-26T00:39:02.3456789010Z Julian = '1752-09-15 
00:39:02.3456789010' Gregorian, (give us back our 11 days)
chars 154 for
    strfMJD():
    --------
  'Fri Jan 23 13:39:02 UTC 2004'
  Fri Jan 23 13:39:02 2004
  01/23/04 2004-01-23
  023
  01:39:02 PM
  1074865142
  23-Jan-2004


   strftime(): (invalid before 1970)
    ------
  'Fri Jan 23 13:39:02 UTC 2004'
  01/23/04 13:39:02
  01/23/04 2004-01-23
  023
  01:39:02 PM
  %s not implemented
  23-Jan-2004


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

On 2009-02-19 19:48+0100 Arjen Markus wrote:

> Hi Alan,
>
> my old MSVC compiler is complaining about a few things
> with Terrence's patch - nothing I can not resolve, but
> the worst is that the testlib program stops immediately:
>
> sizeof(time_t) = 4
> tests abandoned because time_t too small on this platform to run this 
> programme
>
> What is the way forward here? Will the qsastime library
> fail altogether then? Output from qsastime_test does not
> look bad (see below).

That's the expected result on 32-bit hardware platforms.  You normally need
a 64-bit platform (or a rather sophisticated 32-bit platform with 64-bit
time_t's) to do this test.

I have changed that error message to be more informative.  A 32-bit time_t
is not adequate to represent the extremely large date ranges used for these
tests. Note, this is a fundamental limitation in the time_t argument of the
gmtime and mktime routines in the C library that are used to test
libqsastime in qsastime_testlib.  There is no such time_t size limitation in
libqsastime which is designed to work happily with 32-bit ints and 64-bit
doubles (the usual sizes on both 32-bit and 64-bit hardware).  So libqsatime
should be okay on your system for large date ranges. However, it would still
be nice to find a Windows system with 64-bit time_t's (for the C library
comparison routines) and the usual 32-bit ints, and 64-bit doubles that
gives a good result for qsastime_testlib.  That would be a useful
confirmation of the good results we have for that combination of sizes in
Linux.

Of course, the most important point is you have found a way to make windows
build again with your recent commit.  Thanks!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi Alan,

ah, that makes it clearer. So, on 32-bits platforms
we have time_t defined as a 4 bytes data type?
I have no easy access to 64-bits Windows, unfortunately,
so I can not test this.

(Something I ought to do is add a test for "long long int":
this is not supported by older C compilers and might lead
to incorrect results on 64-bits Windows ...)

Regards,

Arjen

On 2009-02-20 02:17, Alan W. Irwin wrote:
> On 2009-02-19 19:48+0100 Arjen Markus wrote:
> 
>> Hi Alan,
>>
>> my old MSVC compiler is complaining about a few things
>> with Terrence's patch - nothing I can not resolve, but
>> the worst is that the testlib program stops immediately:
>>
>> sizeof(time_t) = 4
>> tests abandoned because time_t too small on this platform to run this 
>> programme
>>
>> What is the way forward here? Will the qsastime library
>> fail altogether then? Output from qsastime_test does not
>> look bad (see below).
> 
> That's the expected result on 32-bit hardware platforms.  You normally need
> a 64-bit platform (or a rather sophisticated 32-bit platform with 64-bit
> time_t's) to do this test.
> 
> I have changed that error message to be more informative.  A 32-bit time_t
> is not adequate to represent the extremely large date ranges used for these
> tests. Note, this is a fundamental limitation in the time_t argument of the
> gmtime and mktime routines in the C library that are used to test
> libqsastime in qsastime_testlib.  There is no such time_t size 
> limitation in
> libqsastime which is designed to work happily with 32-bit ints and 64-bit
> doubles (the usual sizes on both 32-bit and 64-bit hardware).  So 
> libqsatime
> should be okay on your system for large date ranges. However, it would 
> still
> be nice to find a Windows system with 64-bit time_t's (for the C library
> comparison routines) and the usual 32-bit ints, and 64-bit doubles that
> gives a good result for qsastime_testlib.  That would be a useful
> confirmation of the good results we have for that combination of sizes in
> Linux.
> 
> Of course, the most important point is you have found a way to make windows
> build again with your recent commit.  Thanks!
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________
> 


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Hi,

Arjen Markus wrote:
> ah, that makes it clearer. So, on 32-bits platforms
> we have time_t defined as a 4 bytes data type?
> I have no easy access to 64-bits Windows, unfortunately,
> so I can not test this.

As usual its not straightforward - 

I am using Visual Studio Express 2008 (aka MSVC 9 **) and
32 bit Windows XP (SP3).  

This supports both 32 and 64bit time with the default being 64 bit time_t and associated functions. If the macro _USE_32BIT_TIME_T is defined 32 bit versions are used.

From MSDN documentation it looks as the above change to use 64 bit time_t as the default  was made in visual studio 2005 (aka MSVC8). 


Also for reference from the MSDN documentation -
The range of mktime64 and mkgmtime64 is from midnight, January 1, 1970, UTC to 23:59:59, December 31, 3000, UTC.
  


Kind regards


Terrence


** In previous posts I may have mixed this up and referred to if as MSVC 8

On 2009-02-20 14:17-0000 trc wrote:

> Also for reference from the MSDN documentation - The range of mktime64 and
mkgmtime64 is from midnight, January 1, 1970, UTC to 23:59:59, December 31,
3000, UTC.

That's what I don't understand. A 64-bit time_t allows you a theoretical
range of +/- 2^63 s = +/- 9 x 10^18 s = +/- 290 billion years.  Why go out
of your way to add code to limit this theoretical range so arbitrarily?  I
suppose you could argue that few need to know any details of time beyond
1000 years into the future, but some people are certainly interested in
those details in the (historical) past, and history did not start in 1970.

The Microsoft screw-up on this decision (and the almost-as-bad Linux screwup
of not providing a 64-bit time_t on 32-bit systems) means there will be more
customers for libqsastime so I guess I shouldn't whine too much. :-)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi,

qsastime_testlib.c doesn't compile with MinGW now, since the applied 
patch only considers the Visual C++ compiler. setenv isn't provided for 
MinGW as well, but putenv is. Look here:

http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/2754.html

So MinGW, must also be included in this patch, but then it's putenv and 
not _putenv, so we need to do more work here.

Regards,
Werner

Arjen Markus wrote:
> Hi Alan,
>
> my old MSVC compiler is complaining about a few things
> with Terrence's patch - nothing I can not resolve, but
> the worst is that the testlib program stops immediately:
>
> sizeof(time_t) = 4
> tests abandoned because time_t too small on this platform 
> to run this programme
>
> What is the way forward here? Will the qsastime library
> fail altogether then? Output from qsastime_test does not
> look bad (see below).
>
> Regards,
>
> Arjen
>
>
> Start date/time components: 2004-1-23 13:39:  2.345678901
> date/time components: 2004-1-23 13:39:  2.345678901
>
> MJD = 53027, seconds =   49142.345678901
>   MJD =   53027.5687771491
>   JD = 2453028.0687771491
>
> ISO string = '2004-01-23 13:39:02.3456789010'
>
> strfMJD:ISO equiv:   '2004-01-23 13:39:02.345678901'
> strfMJD:ISO equiv:  '2004-01-23T13:39:02.3456Z'
> difference MJD (month/day) - MJD(doy) '0'
>
> difference MJD (d-1, h+24) - MJD(d, h) '-8.42125e-017'
>
> CDF epoch sec 63242084342345.680
> from CDF ISO string (CDF epoch is accurate to msec only) = 
> '2004-01-23T13:39:02.3456802368Z'
> Day of week is/was Fri
>
> ISO string = '2004-01-23 13:39:02.3456789010'
>
> for 2004-01-23 13:39:02.3456789010, MJD = 53027, seconds = 
>      49142.345679
> ISO string = '2004-01-23T13:39:02.3456789010Z'
>
> for 2004-01-23T13:39:02.3456789010Z, MJD = 53027, seconds 
> =      49142.345679
>
> Gregorian = '1752-09-15 00:39:02.3456789010'
> 1752-09-26T00:39:02.3456789010Z Julian = '1752-09-15 
> 00:39:02.3456789010' Gregorian, (give us back our 11 days)
> chars 154 for
>     strfMJD():
>     --------
>   'Fri Jan 23 13:39:02 UTC 2004'
>   Fri Jan 23 13:39:02 2004
>   01/23/04 2004-01-23
>   023
>   01:39:02 PM
>   1074865142
>   23-Jan-2004
>
>
>    strftime(): (invalid before 1970)
>     ------
>   'Fri Jan 23 13:39:02 UTC 2004'
>   01/23/04 13:39:02
>   01/23/04 2004-01-23
>   023
>   01:39:02 PM
>   %s not implemented
>   23-Jan-2004
>
>
> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 
>
>  
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
> The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>   


-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

On 2009-02-22 22:03+0100 Werner Smekal wrote:

> Hi,
>
> qsastime_testlib.c doesn't compile with MinGW now, since the applied patch 
> only considers the Visual C++ compiler. setenv isn't provided for MinGW as 
> well, but putenv is. Look here:
>
> http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/2754.html
>
> So MinGW, must also be included in this patch, but then it's putenv and not 
> _putenv, so we need to do more work here.

This Windows build issue (admittedly first introduced by me) has been
hanging over our heads for much too long now so I have reduced its urgency
as follows: I have made (revision 9583) the build of qsastime_testlib
optional (with a default of QSASTIME_TESTLIB=OFF).

This still leaves the option open for our Windows developers to investigate
the Windows build issues and run-time issues for this test at their
leisure but does not interfere with Windows builds for the default case.

>From my point of view, the key question for the Windows developers is
whether there is _any_ Windows C library variant that has a good
implementations of time functions suitable for supplying a test comparison
with libqsastime results over a wide! (+/- 5 million years) date range.

I suspect the answer is "no".  If that is confirmed we should change the
CMake logic to always force QSASTIME_TESTLIB=OFF for the Windows case.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Hi Werner,

I will take care of that tonight. There are a good many things to take
care of and I was contemplating a way to avoid a separate test program
for each:
- long long int versus __int64
- setenv/unsetenv versus putenv or _putenv

I think I know how to deal with this, but it will take some
experimentation. (I assume that if setenv is defined, unsetenv is
defined as well ...)

Regards,

Arjen

On 2009-02-22 22:03, Werner Smekal wrote:
> Hi,
> 
> qsastime_testlib.c doesn't compile with MinGW now, since the applied 
> patch only considers the Visual C++ compiler. setenv isn't provided for 
> MinGW as well, but putenv is. Look here:
> 
> http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/2754.html
> 
> So MinGW, must also be included in this patch, but then it's putenv and 
> not _putenv, so we need to do more work here.
> 
> Regards,
> Werner
> 
> Arjen Markus wrote:
>> Hi Alan,
>>
>> my old MSVC compiler is complaining about a few things
>> with Terrence's patch - nothing I can not resolve, but
>> the worst is that the testlib program stops immediately:
>>
>> sizeof(time_t) = 4
>> tests abandoned because time_t too small on this platform to run this 
>> programme
>>
>> What is the way forward here? Will the qsastime library
>> fail altogether then? Output from qsastime_test does not
>> look bad (see below).
>>
>> Regards,
>>
>> Arjen
>>
>>
>> Start date/time components: 2004-1-23 13:39:  2.345678901
>> date/time components: 2004-1-23 13:39:  2.345678901
>>
>> MJD = 53027, seconds =   49142.345678901
>>   MJD =   53027.5687771491
>>   JD = 2453028.0687771491
>>
>> ISO string = '2004-01-23 13:39:02.3456789010'
>>
>> strfMJD:ISO equiv:   '2004-01-23 13:39:02.345678901'
>> strfMJD:ISO equiv:  '2004-01-23T13:39:02.3456Z'
>> difference MJD (month/day) - MJD(doy) '0'
>>
>> difference MJD (d-1, h+24) - MJD(d, h) '-8.42125e-017'
>>
>> CDF epoch sec 63242084342345.680
>> from CDF ISO string (CDF epoch is accurate to msec only) = 
>> '2004-01-23T13:39:02.3456802368Z'
>> Day of week is/was Fri
>>
>> ISO string = '2004-01-23 13:39:02.3456789010'
>>
>> for 2004-01-23 13:39:02.3456789010, MJD = 53027, seconds =      
>> 49142.345679
>> ISO string = '2004-01-23T13:39:02.3456789010Z'
>>
>> for 2004-01-23T13:39:02.3456789010Z, MJD = 53027, seconds =      
>> 49142.345679
>>
>> Gregorian = '1752-09-15 00:39:02.3456789010'
>> 1752-09-26T00:39:02.3456789010Z Julian = '1752-09-15 
>> 00:39:02.3456789010' Gregorian, (give us back our 11 days)
>> chars 154 for
>>     strfMJD():
>>     --------
>>   'Fri Jan 23 13:39:02 UTC 2004'
>>   Fri Jan 23 13:39:02 2004
>>   01/23/04 2004-01-23
>>   023
>>   01:39:02 PM
>>   1074865142
>>   23-Jan-2004
>>
>>
>>    strftime(): (invalid before 1970)
>>     ------
>>   'Fri Jan 23 13:39:02 UTC 2004'
>>   01/23/04 13:39:02
>>   01/23/04 2004-01-23
>>   023
>>   01:39:02 PM
>>   %s not implemented
>>   23-Jan-2004
>>
>>
>> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO 
>> and parts of Rijkswaterstaat have joined forces in a new independent 
>> institute for delta technology, Deltares. Deltares combines knowledge 
>> and experience in the field of water, soil and the subsurface. We 
>> provide innovative solutions to make living in deltas, coastal areas 
>> and river basins safe, clean and sustainable.
>>  
>>
>> DISCLAIMER: This message is intended exclusively for the addressee(s) 
>> and may contain confidential and privileged information. If you are 
>> not the intended recipient please notify the sender immediately and 
>> destroy this message. Unauthorized use, disclosure or copying of this 
>> message is strictly prohibited.
>> The foundation 'Stichting Deltares', which has its seat at Delft, The 
>> Netherlands, Commercial Registration Number 41146461, is not liable in 
>> any way whatsoever for consequences and/or damages resulting from the 
>> improper, incomplete and untimely dispatch, receipt and/or content of 
>> this e-mail.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Open Source Business Conference (OSBC), March 24-25, 2009, San 
>> Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the 
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source 
>> participation
>> -Receive a $600 discount off the registration fee with the source 
>> code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>   
> 
> 


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Alan

I think your approach is perfectly sensible. After all, the original  
motivation for building qsastime was to avoid the idiosynchracies  
(sp?) of C time handling. Now, of course, it will also handle times  
from the beginning to the end of time as we know it (more or less)  
which is a bonus!

Regards
Steve

-----------
Steve Schwartz
Space and Atmospheric Physics
Imperial College London
Tel 020 7594 7660

On 23 Feb 2009, at 03:34, "Alan W. Irwin" <irwin@...>  
wrote:

> On 2009-02-22 22:03+0100 Werner Smekal wrote:
>
>> Hi,
>>
>> qsastime_testlib.c doesn't compile with MinGW now, since the  
>> applied patch
>> only considers the Visual C++ compiler. setenv isn't provided for  
>> MinGW as
>> well, but putenv is. Look here:
>>
>> http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/2754.html
>>
>> So MinGW, must also be included in this patch, but then it's putenv  
>> and not
>> _putenv, so we need to do more work here.
>
> This Windows build issue (admittedly first introduced by me) has been
> hanging over our heads for much too long now so I have reduced its  
> urgency
> as follows: I have made (revision 9583) the build of qsastime_testlib
> optional (with a default of QSASTIME_TESTLIB=OFF).
>
> This still leaves the option open for our Windows developers to  
> investigate
> the Windows build issues and run-time issues for this test at their
> leisure but does not interfere with Windows builds for the default  
> case.
>
>> From my point of view, the key question for the Windows developers is
> whether there is _any_ Windows C library variant that has a good
> implementations of time functions suitable for supplying a test  
> comparison
> with libqsastime results over a wide! (+/- 5 million years) date  
> range.
>
> I suspect the answer is "no".  If that is confirmed we should change  
> the
> CMake logic to always force QSASTIME_TESTLIB=OFF for the Windows case.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and  
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state  
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting  
> software
> package (plplot.org); the libLASi project (unifont.org/lasi); the  
> Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San  
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the  
> Enterprise
> -Strategies to boost innovation and cut costs with open source  
> participation
> -Receive a $600 discount off the registration fee with the source  
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Alan,

I've just posted a comment to this bug (which I was about to report but
found you had already stumbled on the problem). I promised to attach a
file, but since I can't I'll attach them here.

Regards,
Steve

-- 
+-------------------------------------------------------------------+
Professor Steven J Schwartz        Phone: +44-(0)20-7594-7660
Head, Space & Atmospheric Physics  Fax:   +44-(0)20-7594-7772
The Blackett Laboratory            E-mail: s.schwartz@...
Imperial College London            Office: Huxley 6M67A 
London SW7 2AZ, U.K.               Web: http://www.sp.ph.ic.ac.uk/~sjs
+-------------------------------------------------------------------+

On 2010-10-02 19:05+0100 Steve Schwartz wrote:

> Alan,
>
> I've just posted a comment to this bug (which I was about to report but
> found you had already stumbled on the problem). I promised to attach a
> file, but since I can't I'll attach them here.

Hi Steve:

I suggest you look at gucharmap glyph results (whose individual glyphs
can be expanded to be even as large as your monitor's screen) to help
sort out _part_ of what is going on with TrueType font alignment. 
Some glyphs for the generic sans font (the one used by default by
PLplot) do seem to have perfect alignment such as the light diagonal
cross. That is why I use that symbol first in test_circle.py to test
the overall alignment of qt and cairo devices. Other symbols are
poorly aligned in gucharmap.  For example, there is a slight
misalignment of large circle which shows up in the first page of the
test_circle.py example.  The misalignment of asterisk is much worse as
can be seen in gucharmap and also pages two and three of the example.
I ascribe the Hershey font misalignment issues you have reported to a
similar cause since in general our Hershey font path is our gold
standard for being extremely well debugged for misalignment issues.
That conclusion is less certain for the ps misalignment issues for
Type 1 fonts that you have found, but I suggest you should ignore that
issue for now because the TrueType issue is much more important
(affects many more devices).

My TrueType misalignment bug report is related to the fact that the
subsequent pages of test_circle.py show _other_ methods of rendering
that asterisk don't give consistent alignment with pages 2 and 3.
(Actually the alignment is much better than for pages 2 and 3, but I
think that is two or more wrongs making a right since the misalignment
given in pages 2 and 3 is consistent with the misalignment shown by
gurcharmap.)

In sum, I think the alignment results shown for test_circle.py for
pages 1, 2, and 3 are correct because they agree with the gucharmap
(mis)alignment, but the subsequent pages of that example show some
gross alignment inconsistencies with pages 2 and 3. That result is
puzzling because all those different code paths have many parts which
are identical and the rendered result is also meant to be identical.
So there must be one or more bugs in those code paths exercised by
pages 4 and beyond.

Our next release cycle is going to be quite full for me since I will
be dealing with legend issues as well as possibly some other issues
(such as filling, gradient, and time improvements) I have been putting
off. So I would welcome your group's help in debugging that python
example to follow the various code paths involved to see why pages 4
and beyond produce vertical alignment of the asterisk which
is inconsistent with the vertical alignment shown by pages 2 and 3.
("gdb python examples/python/test_circle.py" should work since python
dynamically loads the PLplot library which in turn dynamically loads
the device.)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________