On Aug 23, 2013, at 3:54 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca 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
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 wid()
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 have
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 (see
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
numbers,
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
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 numeric
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
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
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:
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
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
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 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
On 2009-02-19 19:48+0100 Arjen Markus wrote:
Hi Alan,
my old MSVC compiler is complaining about a few things
with Terrence's patch - nothing I can not resolve, but
the worst is that the testlib program stops immediately:
sizeof(time_t) = 4
tests abandoned because time_t too small on this
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
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.
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 you think you can find for
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
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
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
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
Hi,
- Original Message
From: Alan W. Irwin ir...@beluga.phys.uvic.ca
To: PLplot development list Plplot-devel@lists.sourceforge.net
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
On Thu, 5 Feb 2009 12:54:51 + (GMT)
trc keats73-plp...@yahoo.co.uk 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
,
- Original Message
From: Alan W. Irwin ir...@beluga.phys.uvic.ca
To: PLplot development list Plplot-devel@lists.sourceforge.net
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
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 library
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
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
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
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
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
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?
The current Ada
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
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
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,
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:
Andrew,
Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
generate the same
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
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
40 matches
Mail list logo
