On 08/23/2013 04:54 PM, Alan W. Irwin wrote:
> On 2013-08-23 15:08-0600 Orion Poplawski wrote:
>
>> So, I've updated plplot in (yet to be released) Fedora 20 to svn12479. This
>> contains the change of wid -> width for pen width. This is breaking my gdl
>> build because it is still trying to use
On Aug 23, 2013, at 3:54 PM, Alan W. Irwin wrote:
> On 2013-08-23 15:08-0600 Orion Poplawski wrote:
>
>> So, I've updated plplot in (yet to be released) Fedora 20 to svn12479. This
>> contains the change of wid -> width for pen width. This is breaking my gdl
>> build because it is still tryin
On 2013-08-23 15:08-0600 Orion Poplawski wrote:
> So, I've updated plplot in (yet to be released) Fedora 20 to svn12479. This
> contains the change of wid -> width for pen width. This is breaking my gdl
> build because it is still trying to use wid() which is all of a sudden gone.
> And now I ha
So, I've updated plplot in (yet to be released) Fedora 20 to svn12479. This
contains the change of wid -> width for pen width. This is breaking my gdl
build because it is still trying to use wid() which is all of a sudden gone.
And now I have nothing like a version number change to key this on
On 2009-04-30 14:32-0500 Maurice LeBrun wrote:
> On Thursday, April 30, 2009 at 19:48:40 (+0100) Andrew Ross writes:
> > I quite like your idea of something like 5.9.2+ though as it is simple.
>
> Just wanted to point out a potential downside.. if anyone does version number
> parsing & expects num
On Thursday, April 30, 2009 at 19:48:40 (+0100) Andrew Ross writes:
> I quite like your idea of something like 5.9.2+ though as it is simple.
Just wanted to point out a potential downside.. if anyone does version number
parsing & expects numeric fields throughout, their code will likely barf on
t
On 2009-04-30 19:52+0100 Andrew Ross wrote:
> On Thu, Apr 30, 2009 at 09:30:16AM -0700, Alan Irwin wrote:
>> On 2009-04-30 09:23-0600 Orion Poplawski wrote:
>>
>>> Time to bump version to 5.9.3 in svn?
>>
>> Good question.
>>
>> Normally, all version bumps (overall release version, library version
On Thu, Apr 30, 2009 at 09:30:16AM -0700, Alan Irwin wrote:
> On 2009-04-30 09:23-0600 Orion Poplawski wrote:
>
>> Time to bump version to 5.9.3 in svn?
>
> Good question.
>
> Normally, all version bumps (overall release version, library version
> numbers, etc.) occur as part of the release process
On Thu, Apr 30, 2009 at 09:30:16AM -0700, Alan Irwin wrote:
> On 2009-04-30 09:23-0600 Orion Poplawski wrote:
>
> > Time to bump version to 5.9.3 in svn?
>
> Good question.
>
> Normally, all version bumps (overall release version, library version
> numbers, etc.) occur as part of the release pro
On 2009-04-30 09:23-0600 Orion Poplawski wrote:
> Time to bump version to 5.9.3 in svn?
Good question.
Normally, all version bumps (overall release version, library version
numbers, etc.) occur as part of the release process (see
README.Release_Manager_Cookbook). So the overall version bump to 5
Time to bump version to 5.9.3 in svn?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
---
Here are the items on my ToDo list for time handling after this weekend's
release of PLplot. Most of these items have been mentioned before, but I
thought I should collect everything in one place, and the first two items
are entirely new.
* Change the libqsastime API. This has not been mentioned
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 bonu
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
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/mi
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 t
On 2009-02-20 14:17- 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 = +/
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
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 m
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 o
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 forw
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.
Firs
On 2009-02-18 14: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
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 M
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 th
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 put
On 2009-02-14 16: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 y
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) som
On 2009-02-10 21:03- 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
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 wo
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
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 o
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
> fin
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 examp
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 f
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
On 2009-02-05 20:23- 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 id
:
> Hi,
>
>
>
> - Original Message
> From: Alan W. Irwin
> To: PLplot development list
> 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 an
On Thu, 5 Feb 2009 12:54:51 + (GMT)
trc 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 ot
Hi,
- Original Message
From: Alan W. Irwin
To: PLplot development list
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.
> H
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
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 librar
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
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
On the miniscule chance that you all don't know about this, here is a
Slashdot posting from today about ITU-R considering eliminating leap
seconds (my rough interpretation). (The usual high degree of /.
chatter is present in the remarks.)
Jerry
http://science.slashdot.org/article.pl?sid=08/
Hi Alan,
On Sat, 2008-09-06 at 13:22 -0700, Alan W. Irwin wrote:
> I suggest we specify our continuous time variable as a TT Julian day
> number
Personally I think this is nearly as good, or bad, as any other choice
because it will suit some people and confuse others. I would like to
draw a disti
Hi Steve:
I agree with almost everything you have said. For example, I very much
agree with your general idea of keeping everything as simple as possible.
The one area where I think we need more discussion is the time scales we use
for our continuous and broken-down times.
On 2008-09-06 15:26+0
Hello Alan,
I think we're converging here. Certainly dispensing with leap seconds
removes nearly all the complications.
All the possible time systems (e.g., GPS, TAI, NASA CDF Epoch) differ
only by a constant offset and, as you point out, if the user wanted to
pretend that GPS was actually UTC (w
Hi Steve:
> But I would draw to you attention a real problem that lurks in this can
> of worms. Suppose you want to plot two minutes of data that contains a
> leap second [...]
I agree its a can of worms to display results in UTC for time intervals that
span leap seconds. Thanks for reminding me
Hello Alan,
On Tue, 2008-09-02 at 12:18 -0700, Alan W. Irwin wrote:
> I think we should deal properly with leap seconds because of the
> problem you
> mentioned above and also the problem that our fundamental time
> variable
> would then have a strange relationship with externally defined time
> s
On Sep 2, 2008, at 12:38 PM, Andrew Ross wrote:
> On Tue, Sep 02, 2008 at 02:03:25AM -0700, Jerry wrote:
>>
>> On Sep 1, 2008, at 4:10 PM, Alan W. Irwin wrote:
>>
>>> On 2008-09-01 14:58-0700 Jerry wrote:
>>>
Andrew,
Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
>>>
On Tue, Sep 02, 2008 at 02:03:25AM -0700, Jerry wrote:
>
> On Sep 1, 2008, at 4:10 PM, Alan W. Irwin wrote:
>
> > On 2008-09-01 14:58-0700 Jerry wrote:
> >
> >> Andrew,
> >>
> >> Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
> >> generate the same Postscript as the C example?
> >
On 2008-09-02 13:18+0100 Schwartz, Steven J wrote:
> We don't deal with leap seconds. As long as we use our own routines to get
from broken-down time to epoch time and back, the result is clean and
consistent, although this means we only allow a minute to have 60 seconds.
Thus a time series that a
lan W. Irwin
Cc: Schwartz, Steven J; PLplot development list
Subject: Re: [Plplot-devel] time
Steve, Alan,
I entirely agree that the only sane, cross-platform and cross-language
way of dealing with the timegm (and possible gmtime) problem is to add our
own implementation. This is relatively strai
On Sep 1, 2008, at 4:10 PM, Alan W. Irwin wrote:
> On 2008-09-01 14:58-0700 Jerry wrote:
>
>> Andrew,
>>
>> Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
>> generate the same Postscript as the C example?
>
> The current Ada example 29 code has
>
> xmin := 1133395200.0;
>
> (no und
Steve, Alan,
I entirely agree that the only sane, cross-platform and cross-language
way of dealing with the timegm (and possible gmtime) problem is to add our
own implementation. This is relatively straightfoward and I can see no
reason not to. The bigger question is whether we carry on using
s
Hi Steve:
Since this is a broader topic, I have changed the subject line.
On 2008-09-02 02:14+0100 Schwartz, Steven J wrote:
> Alan,
> Your approach in example 29 is to use the TZ environment variable to trick
your computer into thinking that it is in a UTC timezone. This doesn't work
on all pl
---+
From: [EMAIL PROTECTED] on behalf of Alan W. Irwin
Sent: Tue 02/09/2008 12:10 AM
To: Jerry
Cc: PLplot development list
Subject: Re: [Plplot-devel] Time calculation in Ada example 29
On 2008-09-01 14:58-0700 Jerry wrote:
> Andr
On 2008-09-01 14:58-0700 Jerry wrote:
> Andrew,
>
> Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
> generate the same Postscript as the C example?
The current Ada example 29 code has
xmin := 1133395200.0;
(no underscores), and yes, that hard-coded value gives identical results t
Andrew,
Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
generate the same Postscript as the C example? (I can't test this on
my machine because the C example doesn't work correctly, as I
discussed earlier.)
Jerry
On Sep 1, 2008, at 12:11 AM, Andrew Ross wrote:
>
> Jerry,
>
Jerry,
The problem is that Time_Of is in local time. The UK was on daylight
saving time on 1st Jan 1970, and so my reference is 1 hour out. Most
time zones with no DST in operation will give the correct value. I'd
overlook this possibility when I first wrote the C version. That's why
we had to ch
Andrew,
On my machine, in Ada example 29, the line
xmin := Long_Float(Time_Of(2005, 12, 1, 0.0) - Time_Of(1970, 1, 1,
0.0));
calculates a value of xmin of 1.1333952000E+09 which is the same
number that you hard-coded the value to recently. Does your machine
not calculate this same val
62 matches
Mail list logo
