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. ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
