From: Alan W. I. <ir...@be...> - 2009-01-30 18:52:50
|
The QSAS team lead by Steve Schwartz have donated time-handling software to PLplot under the LGPL license today. I will be involved with the integration of this software into PLplot, and from prior discussions I believe Andrew will be involved as well. The new time capabilities for PLplot that we have planned based on this donated software should greatly enhance PLplot's ability to deal with plots that involve time in a platform-independent way. On behalf of the PLplot developers, I thank the QSAS team for their donation. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2009-02-01 12:50:31
|
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.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2009-02-02 20:51:04
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-02-05 06:27:59
|
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 __________________________ |
From: trc <kea...@ya...> - 2009-02-05 12:55:03
Attachments:
plplot.9455.patch.gz
|
Hi, ----- Original Message ---- From: Alan W. Irwin <ir...@be...> To: PLplot development list <Plp...@li...> 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 |
From: Arjen M. <arj...@de...> - 2009-02-05 18:44:48
|
On Thu, 5 Feb 2009 12:54:51 +0000 (GMT) trc <kea...@ya...> 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. |
From: Andrew R. <and...@us...> - 2009-02-05 20:23:17
|
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 <ir...@be...> > To: PLplot development list <Plp...@li...> > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2009-02-08 00:47:34
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-02-08 16:18:57
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-02-10 08:42:10
|
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 __________________________ |
From: trc <kea...@ya...> - 2009-02-10 21:03:35
Attachments:
plplot-9498.patch
|
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 |
From: Alan W. I. <ir...@be...> - 2009-02-10 22:46:16
|
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 __________________________ |
From: trc <kea...@ya...> - 2009-02-14 16:05:14
|
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 |
From: Alan W. I. <ir...@be...> - 2009-02-16 19:33:51
|
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 __________________________ |
From: Arjen M. <arj...@de...> - 2009-02-18 08:32:27
|
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 > Plp...@li... > 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. |
From: trc <kea...@ya...> - 2009-02-18 14:12:01
Attachments:
add_msvc_setenv.patch
|
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 |
From: Arjen M. <arj...@de...> - 2009-02-18 14:16:06
|
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. |
From: Alan W. I. <ir...@be...> - 2009-02-18 19:25:10
|
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 __________________________ |
From: Arjen M. <arj...@de...> - 2009-02-19 07:45:20
|
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. |
From: Arjen M. <arj...@de...> - 2009-02-19 18:48:44
|
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. |
From: Werner S. <sm...@ia...> - 2009-02-22 21:03:19
|
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 > Plp...@li... > 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: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-02-23 07:50:30
|
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 >> Plp...@li... >> 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. |
From: Werner S. <sm...@ia...> - 2009-02-08 20:30:33
|
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: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2009-02-05 20:50:24
|
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 __________________________ |
From: Jerry <lan...@qw...> - 2009-02-09 00:50:05
|
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 |