On May 31, 2015, at 10:11 PM, Jim Dishaw j...@dishaw.org wrote:
Yep, I will take a look
On May 31, 2015, at 9:32 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-05-31 22:06+0100 Phil Rosenberg wrote:
Hi Alan
You should now find that the plbuf.c warning is gone. I
On 2015-06-01 17:32-0400 Jim Dishaw wrote:
On May 31, 2015, at 9:32 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
The remaining warnings are
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
‘read_header’:
Hi Alan
I'm attacking my to do list. Do you still get these warnings? I just
looked and the line 1309 no longer makes sense in terms of a reference
to cmd so I guess the code has changed since then. I don't get any
unallocated variable warnings for plbuf in VC++ so perhaps someone
else fixed this
Hi Alan
I've worked this out, the line in question is in a function called
with the possibly uninitialized variable.
I'm writing the code now to double check everything although the only
case where we could get an uninitialized variable would be for a
corrupted buffer.
Phil
On 31 May 2015 at
Hi Alan
You should now find that the plbuf.c warning is gone. I haven't
touched the plmeta files. I will leave these to Jim as I don't know
that code well.
Phil
On 31 May 2015 at 20:14, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-05-31 18:59+0100 Phil Rosenberg wrote:
Hi Alan
I've
On 2015-05-31 18:33+0100 Phil Rosenberg wrote:
Hi Alan
I'm attacking my to do list. Do you still get these warnings? I just
looked and the line 1309 no longer makes sense in terms of a reference
to cmd so I guess the code has changed since then. I don't get any
unallocated variable warnings
On 2015-04-10 21:54+0100 Andrew Ross wrote:
Hazen,
That's interesting, and at odds with my tests a week or so back on Kubuntu
14.10. Can you confirm which flavour and version of Ubuntu you are using?
Also, I assume this is with Qt4 and not Qt5?
Hi Andrew:
The answers to your questions
On 04/10/2015 09:06 PM, Alan W. Irwin wrote:
On 2015-04-10 12:29-0400 Hazen Babcock wrote:
That's a fairly sparse but still acceptable comprehensive test result
for
this release, but to start the next release cycle properly I strongly
encourage everybody here to learn to run the
Hazen,
That's interesting, and at odds with my tests a week or so back on Kubuntu
14.10. Can you confirm which flavour and version of Ubuntu you are using?
Also, I assume this is with Qt4 and not Qt5?
Andrew
On Fri, Apr 10, 2015 at 12:29:15PM -0400, Hazen Babcock wrote:
That's a fairly
On 04/10/2015 04:54 PM, Andrew Ross wrote:
Hazen,
That's interesting, and at odds with my tests a week or so back on Kubuntu
14.10. Can you confirm which flavour and version of Ubuntu you are using?
Also, I assume this is with Qt4 and not Qt5?
Andrew,
This is what I have:
hb ~$ uname -a
On 2015-04-10 12:29-0400 Hazen Babcock wrote:
That's a fairly sparse but still acceptable comprehensive test result for
this release, but to start the next release cycle properly I strongly
encourage everybody here to learn to run the
scripts/comprehensive_test.sh bash script to completion
On 2015-04-10 21:54+0100 Andrew Ross wrote:
[Hazen's poor qt result is] at odds with my tests a week or so back on Kubuntu
14.10.
Hi Andrew:
Could you please report the details of those good comprehensive test
results at
https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports
On 2015-04-05 01:17-0700 Alan W. Irwin wrote:
On 2015-04-04 23:11-0700 Greg Jung wrote:
afaict these environment variables are essential for plots:
PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
PLPLOT_HOME=/usr/local/share/plplot5.10.0/
DRV_DIR for dynamic loading, to get the
Hi Alan, Greg,
-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
@Greg: You have much more experience with Cygwin than I do (since my actual
experience is zero). Nevertheless, historically there has been lots of
warnings on
the CMake list that Cygwin
Hi Alan,
-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
Sent: Saturday, April 04, 2015 9:04 PM
To: Arjen Markus
Cc: Greg Jung; Phil Rosenberg; Jim Dishaw; PLplot development list
Subject: RE: Release status: call for comprehensive testing: Cygwin
Hi
03, 2015 7:57 AM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Release status: call for comprehensive testing
This is a long-standing cygwin warning, CMake no longer defines WIN32 on
Cygwin!
for those rip-van-winkles coming back to cygwin and somehow wanting
WIN32
In Cygwin, I do use the cygwin cmake; but it isn't distributed by
cygwin, I built it from source. At one point I tried the windows
cmake from cygwin and it failed miserably.
On Fri, Apr 3, 2015 at 12:20 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
On 2015-04-02 22:57-0700 Greg Jung wrote:
The cmake I specify for MSYS is a vanilla cmake downloaded from
cmake.org; I use this because all of my other CMakes use scripts I
modified.
Cmake for Msys needs to use msys make, not mingw32-make; otherwise you
want to do a mingw build which involves hiding sh from the PATH,
using CMD.exe, etc.
On 2015-04-03 14:06-0700 Greg Jung wrote:
In Cygwin, I do use the cygwin cmake; but it isn't distributed by
cygwin, I built it from source. At one point I tried the windows
cmake from cygwin and it failed miserably.
@Greg:
Thanks for that clarification. I agree that cmake built on Cygwin
This is a long-standing cygwin warning, CMake no longer defines WIN32
on Cygwin!
for those rip-van-winkles coming back to cygwin and somehow wanting
WIN32 to be defined.
I am very familar with the possible quirks that can arise with Cmake;
if there is a systemic failure
it generally blows up in
On 2015-03-30 12:42-0700 Alan W. Irwin wrote:
There is a big warning in plplot-cygwin/output_tree/cmake.out (for
version 3.0.1) about CMake no longer defines WIN32 on Cygwin!
Hi Greg:
I believe I have now found the source of that warning message which is
(according to cmake mailing list
Hi Alan,
-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
@Arjen and Phil, will both of you please look at the cygwin.tgz attachment?
There is a big warning in plplot-cygwin/output_tree/cmake.out (for version
3.0.1)
about CMake no longer defines WIN32
Hi Alan,
@Arjen and Phil, will both of you please look at the cygwin.tgz attachment?
There is a big warning in plplot-cygwin/output_tree/cmake.out (for version
3.0.1)
about CMake no longer defines WIN32 on Cygwin! Have either of you run into
this
issue for CMake on Cygwin? There is
On 2015-03-31 09:33- Arjen Markus wrote:
Hi Alan,
@Arjen and Phil, will both of you please look at the cygwin.tgz attachment?
There is a big warning in plplot-cygwin/output_tree/cmake.out (for version
3.0.1)
about CMake no longer defines WIN32 on Cygwin! Have either of you run into
On 2015-03-31 11:05-0700 Greg Jung wrote:
Here is tarball og the output directory from recent fully-completed
Suse-13.2 test.
I did terminate interactive testing at the end, by killing windows,
the strip chart was going very slow. But the wx Viewers looked great.
Hi Greg:
Thanks very much
On 2015-03-31 09:31-0700 Alan W. Irwin wrote:
Hi Arjen:
Gack. I am really glad you found this bug in setting the -DUSINGDLL
compile flag for libplplotqt source files (and also for smoke
bindings) for the static library case. This bug was caused by a commit made
by me back in 2013. One of
Here is tarball og the output directory from recent fully-completed
Suse-13.2 test.
I did terminate interactive testing at the end, by killing windows,
the strip chart was going very slow. But the wx Viewers looked great.
On Tue, Mar 31, 2015 at 9:31 AM, Alan W. Irwin
Mingw/msys:
Because I have cmake modified to look in /usr/local
and such for libraries and such (not a good idea, I know now), I added
the option --cmake_command to the script and used
--cmake_command=/d/path-to-cmake/bin/cmake.exe and the make completed
ok but the ctest
hung at example/c/x00c;
On 2015-03-30 12:14-0700 Alan W. Irwin wrote:
On 2015-03-30 10:40-0700 Greg Jung wrote:
Here are gzipped- tar files sent separately because the list
filters may kill the message altogether.
Our mailing list does not kill tarballs in my experience. So to test
that in this case, I am
On 2015-03-26 18:50-0700 Alan W. Irwin wrote:
With commit id 5f6e28f I finally have been able to complete
scripts/comprehensive_test.sh on Linux without issues which removes
the last known regression compared to 5.10.0 for this release which is
a much-desired result.
My next steps are [1]
On Mar 29, 2015, at 9:17 AM, Andrew Ross andrewr...@users.sourceforge.net
wrote:
Also -np to prevent pausing between
pages doesn't work. This is not a major issue, but is a slight pain when
running the automatic tests.
Andrew
I believe this bug might be related to the extra
On Sat, Mar 28, 2015 at 05:41:12PM -0700, Alan Irwin wrote:
On 2015-03-28 21:40- Andrew Ross wrote:
I use 2.2.1 as well but with additional patches applied.
See cmake/epa_build/libharu/CMakeLists.txt for how to locate those
patches.
Most of those are to install a CMake-based build
On 2015-03-28 22:20-0700 Alan W. Irwin wrote:
Also, when you report back again, will you please always specify the
scripts/comprehensive_test.sh options you used in every different
platform case? The easiest way to do that is to always include
everything output from the script rather than
On Sat, Mar 28, 2015 at 09:07:46PM +, Andrew Ross wrote:
Alan,
For me with Ubuntu 14.10 (Utopic Unicorn) scripts/comprehensive_test.sh
fails. Compile all goes fine, but the test of the C examples with the pdf
driver fails at example 24 with
ERROR: error_no=1050, detail_no=0
ERROR
On 2015-03-28 21:40- Andrew Ross wrote:
On Sat, Mar 28, 2015 at 09:07:46PM +, Andrew Ross wrote:
Alan,
For me with Ubuntu 14.10 (Utopic Unicorn) scripts/comprehensive_test.sh
fails. Compile all goes fine, but the test of the C examples with the pdf
driver fails at example 24 with
On 2015-03-25 15:39- Phil Rosenberg wrote:
Hi Alan
I have pushed that fix. There was also a problem on resize that caused
a hang due to re-entrancy in the event loop which I have fixed too.
There is also a problem with rendering the wxPLplotDemo whereby there
are sections of the window
On 2015-03-21 11:57-0700 Alan W. Irwin wrote:
Hi Andrew:
I have now (commit fa0c879) solved this release-critical regression.
The crux of the problem is redundant linking of qt_example to both
plplot (which contained all of the code in plplotqt for this
ENABLE_DYNDRIVERS=NO case) and
On 2015-03-21 12:29-0700 Alan W. Irwin wrote:
Just to summarize where we stand there are several open-ended issues
blocking the release.
1. I am in the middle of a hunt for plend memory management issues caused by
redundant
library linking (see previous post to Andrew).
I have finished
Alan,
Thanks for the update. I'm glad you managed to track it down. I'd held of
delving into this as you seemed to have it under control. I'm also
slightly surprised at the linker not being more intelligent here.
Certainly something we need to be wary of.
Andrew
On Sat, Mar 21, 2015 at
Hi Andrew:
I have now (commit fa0c879) solved this release-critical regression.
The crux of the problem is redundant linking of qt_example to both
plplot (which contained all of the code in plplotqt for this
ENABLE_DYNDRIVERS=NO case) and plplotqt. examples/c++/qt_example had no severe
memory
On 2015-03-19 14:38-0700 Alan W. Irwin wrote:
Hi Andrew (again):
I just discovered this issue was a regression compared to 5.10.0. So
I will git bisect it to see which commit first created this issue, and
get back to you at that point if I cannot figure out the problem
introduced by that
Hi Andrew (again):
I just discovered this issue was a regression compared to 5.10.0. So
I will git bisect it to see which commit first created this issue, and
get back to you at that point if I cannot figure out the problem
introduced by that commit.
Alan
__
Alan W.
Hi Alan,
-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
Sent: Saturday, March 14, 2015 1:19 AM
To: Andrew Ross
Cc: PLplot development list
Subject: [Plplot-devel] Release status: epa_build: libharu and general
release topics
@ Arjen: If there is
On 2015-03-15 20:03-0400 Jim Dishaw wrote:
Did we ever come to a resolution on this?
On Mar 13, 2015, at 3:10 PM, Jim Dishaw j...@dishaw.org wrote:
The plP_eop() call, for some reason, results in extra keypresses
needed to advance to the next page. I thought I knew the reason, but
after
On Fri, Mar 13, 2015 at 12:23:56PM -0700, Alan Irwin wrote:
On 2015-03-13 10:26-0700 Alan W. Irwin wrote:
On 2015-03-13 10:19- Andrew Ross wrote:
1) The cairo build fails (seems to be due to a bug in cairo build scripts
exposed in gcc-4.9.0 - see
On Fri, Mar 13, 2015 at 05:19:02PM -0700, Alan Irwin wrote:
On 2015-03-13 10:26-0700 Alan W. Irwin wrote:
On 2015-03-13 10:19- Andrew Ross wrote:
2) The libharu build succeeds, but the hpdf_pdfa.h include file is not
installed so the plplot build of the pdf driver fails.
Hi Andrew:
On Mar 13, 2015, at 2:34 PM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
Hi Jim Alan
Firstly I'm not in front of a pc right now so I'm doing function names from
memory. Apologies if they are wrong.
Are you talking about the call to plP_eop() that is in the plreplot()
function?
If
Hi Jim Alan
Firstly I'm not in front of a pc right now so I'm doing function names from
memory. Apologies if they are wrong.
Are you talking about the call to plP_eop() that is in the plreplot() function?
If so, I put that there. The reason is that when creating the first page from a
buffer,
On 2015-03-13 10:59-0700 Alan W. Irwin wrote:
On 2015-03-13 11:10-0400 Jim Dishaw wrote:
Alan,
I noticed a bug that occurs when resizing a plot. Every time a plot
is resized, an extra key press is required to advance the page. The
problem appears to be a pop_eop() that was added in
On Mar 12, 2015, at 3:38 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
Hi Jim:
Here are the results of a simple test I tried with -DPLD_plmeta=ON
# Build what is relevant
make plrender
make plmeta
make x01c
make ps
# Test
examples/c/x01c -dev psc -o test1.psc
examples/c/x01c
On Mar 12, 2015, at 7:06 AM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
This thread is becoming a bit unwieldy, but I will try to answer below
@Jim
I had already written and tested a fix for the hatchings and have just
committed it, sorry if you spent time on this.
No problem. It was
On Mar 12, 2015, at 2:13 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-03-11 14:49-0700 Alan W. Irwin wrote:
Hi Phil:
I just saw your one-line fix at
http://sourceforge.net/p/plplot/plplot/ci/4e93f99a84a5c72d253c8791f813400ba2f46ff6.
Does that really do the job? For
On 2015-03-11 14:49-0700 Alan W. Irwin wrote:
Hi Phil:
I just saw your one-line fix at
http://sourceforge.net/p/plplot/plplot/ci/4e93f99a84a5c72d253c8791f813400ba2f46ff6.
Does that really do the job? For example, I noticed earlier in that code
a test of pls-device rather than pls-dev, but
Hi Jim:
Could you clarify the purpose of the -mfi and -mfo options
and the plreadmetafile routine?
It appears the options simply set metafile input and output file names without
doing anything else contrary to their self documentation in src/plargs.c
of Read the specified PLplot metafile and
This thread is becoming a bit unwieldy, but I will try to answer below
@Jim
I had already written and tested a fix for the hatchings and have just
committed it, sorry if you spent time on this.
Regarding the plhrsh issue, my build is fine - although it is a
static build, so perhaps that is the
On Mar 12, 2015, at 6:08 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
Hi Jim:
Could you clarify the purpose of the -mfi and -mfo options
and the plreadmetafile routine?
-mfi sets the file name that plreadmetafile will use if one is not otherwise
specified by the caller. Nothing
Hi Alan
Thanks for the screenshots. Comments below
On 11 March 2015 at 18:31, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-03-11 13:01- Phil Rosenberg wrote:
* Example 13; extra lines in Maurice, Vince, and Rafael parts
of the pie chart, but the other slices are fine.
This
Phil,
Try reading http://wiki.tcl.tk/1829 for the tk problem. It suggests an
issue with your X security which you probably want to investigate anyway.
For me things just work with Ubuntu. Though I should perhaps be more
precise that it is Kubuntu (with KDE as the window manager) that I use
On Wed, Mar 11, 2015 at 02:30:04PM -0700, Alan Irwin wrote:
Phil said:
Hi Alan
Unfortunately you can probably ignore that email.
On my work centos machine I tried running an example under the xwin
device - thinking that a buffer problem would be likely to show up
there as well as in
Phil said:
I didn't mean interactivity wouldn't happen, just that an attached
model of how this will be done won't happen. wxWidgets just isn't
really built to be run from within a library. Although apparently it
can be done, but it is an edge case. I made some attempt at it about a
year ago,
Phil said:
Hi Alan
Unfortunately you can probably ignore that email.
On my work centos machine I tried running an example under the xwin
device - thinking that a buffer problem would be likely to show up
there as well as in the tk device. I then got just a black window and
a hang. Moving back
Hi Alan
Unfortunately you can probably ignore that email.
On my work centos machine I tried running an example under the xwin
device - thinking that a buffer problem would be likely to show up
there as well as in the tk device. I then got just a black window and
a hang. Moving back in time I
On 2015-03-11 11:33- Arjen Markus wrote:
I just ran all the examples with the wingcc device under Cygwin (of
course after having retrieved the latest version from git and building
Plplot again) and as far as I can tell everything is looking fine. At
the very least there are no strange gaps
On 2015-03-11 12:32- Arjen Markus wrote:
Hi Phil,
The message is due to a security problem in the X server if you use
the default security settings. I know of it but I do not have a handy
receipe to solve it. Tk's send command allows you to send any command
to the X host, which is why
On 2015-03-10 21:41- Phil Rosenberg wrote:
Hi Alan and Jim
Right, well Jim's patch series is committed and I have just made one
more additional commit regarding the buffer which I think now gives us
a buffer which is (pretty close to, if not completely) bug free!!! Or
at the very least
Hi Alan
Sorry I only just spotted your email.
I have just made a commit, but it was technically a bug fix (or at
least half of it was), but I won't make any further commits.
Phil
On 11 March 2015 at 10:49, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-03-10 21:41- Phil Rosenberg
Hi Alan,
-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
Sent: Wednesday, March 11, 2015 11:49 AM
To: Andrew Ross; Phil Rosenberg; Jim Dishaw
Cc: PLplot development list
Subject: Re: [Plplot-devel] Release status
@Arjen:
Just in case you remember how
[mailto:ir...@beluga.phys.uvic.ca]
Sent: Wednesday, March 11, 2015 11:49 AM
To: Andrew Ross; Phil Rosenberg; Jim Dishaw
Cc: PLplot development list
Subject: Re: [Plplot-devel] Release status
@Arjen:
Just in case you remember how well wingcc rendered before, I would
appreciate you
double-checking
To: Arjen Markus
Cc: Alan W. Irwin; Andrew Ross; Jim Dishaw; PLplot development list
Subject: Re: [Plplot-devel] Release status
I've just tested the tk device over my lunch break. I don't get the tk driver
on my
windows build, just ntk.
On my work Cento machine and my home Ubuntu machine
Dishaw
Cc: PLplot development list
Subject: Re: [Plplot-devel] Release status
@Arjen:
Just in case you remember how well wingcc rendered before, I would
appreciate you
double-checking how wingcc renders now.
I just ran all the examples with the wingcc device under Cygwin (of course
after
I can now put my hands up and say the regression was me. At least on
my Centos machine running the xwin driver results in a blank window
and a hang until I checkout before this commit
commit 1e402417c1f3e87c391fe428f936153c2a10e8cc
Author: Phil Rosenberg p.d.rosenb...@gmail.com
Date: Fri Feb 27
Hi Alan and Jim
Right, well Jim's patch series is committed and I have just made one
more additional commit regarding the buffer which I think now gives us
a buffer which is (pretty close to, if not completely) bug free!!! Or
at the very least it is sufficient to allow the wxWidgets driver to
Hi Phil:
From all your commits last week it appears you are continuing to make
progress on fixing the wxwidgets bugs, but I have no idea how much
more (if anything) you want to do before release. Also, I rely on you
to evaluate Jim's Saturday patch series to decide which of his commits
should be
Hi Alan
(1) Bad abort operation for the Unkown error which causes
substantial memory managment issues.
(2) Error message itself needs a spelling change: Unkown -- Unknown
(3) regression for -geometry option
(4) regression of an added surface pattern artifact for example 8
Issue (4) is
Hi Alan
Here is a status update on wxWidgets, but the headline is that I now
feel that the wxWidgets driver is at an appropriate stage for release.
The issues that still exist are on trello, so you can view them is you
want. However I now think that the new driver is of generally the same
On 9 March 2015 at 20:43, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
Hi Phil:
One thing I failed to cover in my prior post this morning is it sounds
like you have one more round of plbuf changes you would like to commit
to master (probably including some or all commits from Jim's series)
Please take a look at his patch series he sent this weekend. One of those
patches
apparently was to fix a wxwidgets issue so part/all of that series may
be exactly what you need, but I am leaving it to you to evaluate which
of his commits should be applied to master now, and which should
On 2015-03-09 12:22- Phil Rosenberg wrote:
Hi Alan
Here is a status update on wxWidgets, but the headline is that I now
feel that the wxWidgets driver is at an appropriate stage for release.
That is excellent news indeed!
I still have lots on my PLplot agenda so the headline from my
Hi Phil:
One thing I failed to cover in my prior post this morning is it sounds
like you have one more round of plbuf changes you would like to commit
to master (probably including some or all commits from Jim's series)
before release. That is fine, but you should also aim to put plbuf
changes
Hi Phil:
Your latest commit (f6dcf09703 = Fixed reentrant behaviour in
wxPLViewer...) mostly works. For example, it builds without
issues, and examples 1 and 4 (the first two run by the
test_c_wxwidgets target) appear to work at run-time with
no obvious issues. However, example 8 now has a
Thanks for the heads up Alan, especially the Valgrind output and the
reproduction method. Very handy!
Regardign the surface pattern artefacts. I had already spotted them
and x08.1 is on the trello page. It appears to be a bad antiaiasing
issue or rounding issue, basically adjacent polygons don't
To add to that regarding wxWidgets
The current master branch with wxWidgets still has some issues that I
would not be happy releasing. Most importantly is how we go about
selecting whether to use a user wxDC or use the wxPLViewer. After
Friday's discussion I have added a plsdevdata function which
On 2015-03-02 09:33- Phil Rosenberg wrote:
[]But the take home message unfortunately is that the
wxWidgets driver isn't ready yet.
Hi Phil:
If it is any consolation, my comprehensive testing and other
pre-release items I have to do are in similar shape. Also, note that
once Jim's new
83 matches
Mail list logo
