Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

On 2015-06-01 17:32-0400 Jim Dishaw wrote: >>> On May 31, 2015, at 9:32 PM, Alan W. Irwin >>> wrote: >>> The remaining warnings are >>> >>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function >>> ‘read_header’: >>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: wa

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

> On May 31, 2015, at 10:11 PM, Jim Dishaw wrote: > > Yep, I will take a look > > > >> On May 31, 2015, at 9:32 PM, Alan W. Irwin 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 haven't >>> touched the

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

Yep, I will take a look > On May 31, 2015, at 9:32 PM, Alan W. Irwin 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 haven't >> touched the plmeta files. I will leave these to Jim as I don't know >> that code

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

On 2015-05-31 22:06+0100 Phil Rosenberg wrote: > 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: I confirm you fix, and thanks! @Jim: The remaining warnings are /home/softw

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

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 wrote: > On 2015-05-31 18:59+0100 Phil Rosenberg wrote: > >> Hi Alan >> I've worked this out, th

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

On 2015-05-31 18:59+0100 Phil Rosenberg wrote: > 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 woul

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

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 warni

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

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 18:

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

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

Re: [Plplot-devel] Release status: call for comprehensive testing

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 question

Re: [Plplot-devel] Release status: last major uncertainty removed

I am happy to report that the epa_built "plplot_lite" comprehensive test on the MinGW/MSYS/Wine platform completed in 30 hours. One component of this test had to be repeated to get good results (see note (K) at ). That repeat

Re: [Plplot-devel] Release status: call for comprehensive testing

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 r

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

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 co

Re: [Plplot-devel] Release status: call for comprehensive testing

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 ~$ unam

Re: [Plplot-devel] Release status: call for comprehensive testing

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 s

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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 ge

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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 driver_info files (.dll files > are to be pick > u

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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 driver_info files (.dll files are to be pick up in PATH) and PLPLOT_HOME for support files: greg@Homerw

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

On 2015-04-04 21:27- Arjen Markus wrote: > I had to suppress the test_interactive part as well as the traditional build, > but then it finished all right. See the attached tgz-file for the details. I agree that limited Cygwin result looks good (other than the test_interactive and traditional

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

On 2015-04-04 19:34- Arjen Markus wrote: > 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:

Re: [Plplot-devel] Release status: call for comprehensive testing: 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 >

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

On 2015-04-04 15:31- Arjen Markus wrote: > Hi Alan, > > > >> -Original Message- >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] >> >> @Arjen, Phil, and Jim: >> >> As release manager, that latter possibility of a regression in comprehensive >> testing >> on the Cygwin platfo

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

Hi Alan, > -Original Message- > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] > > @Arjen, Phil, and Jim: > > As release manager, that latter possibility of a regression in comprehensive > testing > on the Cygwin platform really concerns me, and I ask at least one of you guys

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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 Cygw

[Plplot-devel] Release status: updated release notes

I have just (commit dadae4a) updated the 5.11.0 release notes (contained in the README.release file) based on skimming the commit messages for the ~500 commits we have done since the release of 5.10.0. Could everyone who made commits in this release cycle review these updated notes and commit addi

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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

Re: [Plplot-devel] Release status: call for comprehensive testing: MinGW-w64/MSYS2

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

[Plplot-devel] Release status: call for comprehensive testing: wxwidgets

I have just finished (once again) a complete test of wxwidgets for all our standard examples. I have reported the results (which are quite encouraging) at the (re-edited) https://sourceforge.net/p/plplot/bugs/151/. It's this bug report I will refer to in the release notes. Freeze and release pro

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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 wrote: > On 2015-04-02 22:57-0700 Greg Jung wrote: > >> This is a long-stan

[Plplot-devel] Release status: call for comprehensive testing: MinGW-w64/MSYS2

On 2015-04-02 22:57-0700 Greg Jung wrote: > > In each setup there are naturally missing pieces. >> From my perspective,I need only libplplot.dll, libplplotcxx.dll, > wingcc, svg, ps, null, Z, X, and maybe cairo devices, and wxwidget. If > a failure occurs because it isn't within this narrow requir

[Plplot-devel] Release status: call for comprehensive testing: Cygwin

On 2015-04-02 22:57-0700 Greg Jung wrote: > 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

Re: [Plplot-devel] Release status: call for comprehensive testing

] > Sent: Friday, April 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

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 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 y

Re: [Plplot-devel] Release status: call for comprehensive testing

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 me

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

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 wrote: > On 2015-03-31

Re: [Plplot-devel] Release status: call for comprehensive testing

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. O

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

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? The

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

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 a

Re: [Plplot-devel] Release status: call for comprehensive testing

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;

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

> On Mar 29, 2015, at 9:17 AM, Andrew Ross > 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 plP_eop() call. This results

Re: [Plplot-devel] Release status: call for comprehensive testing

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

Re: [Plplot-devel] Release status: call for comprehensive testing

Hi Greg: It's important our interchanges remain on list so others can benefit from them so please don't drop the list Cc from your replies. Thanks for all these test results. More below in context On 2015-03-28 16:27-0700 Greg Jung wrote: > HI Alan, > > I did use make all on that run, but pro

Re: [Plplot-devel] Release status: call for comprehensive testing

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 examp

Re: [Plplot-devel] Release status: call for comprehensive testing

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 >

Re: [Plplot-devel] Release status: call for comprehensive testing

On Thu, Mar 26, 2015 at 06:50:22PM -0700, Alan Irwin wrote: > On 2015-03-25 14:30-0700 Alan W. Irwin wrote: > > >> 2. Because of issues like the qt_example segfault that I have just > >> fixed, I have as yet been unable to complete a comprehensive test of > >> PLplot on Linux. Until I can get suc

[Plplot-devel] Release status: call for comprehensive testing

On 2015-03-25 14:30-0700 Alan W. Irwin wrote: >> 2. Because of issues like the qt_example segfault that I have just >> fixed, I have as yet been unable to complete a comprehensive test of >> PLplot on Linux. Until I can get such a clean test the possibility >> exists there are other such segfault

Re: [Plplot-devel] Release status

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 finish

Re: [Plplot-devel] Release status: another plend segfault and/or double free

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

Re: [Plplot-devel] Release status: need help with OLD_WXWIDGETS=ON option (fwd)

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 wi

Re: [Plplot-devel] Release status: another plend segfault and/or double free

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 11:57:20

[Plplot-devel] Release status

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). 2. Because of issues like the qt_example segfault that I have just fixe

Re: [Plplot-devel] Release status: another plend segfault and/or double free

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 man

Re: [Plplot-devel] Release status: another plend segfault and/or double free

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 t

Re: [Plplot-devel] Release status: another plend segfault and/or double free

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. Irwin

[Plplot-devel] Release status: another plend segfault and/or double free

Hi Andrew: I just discovered another issue which may be release critical. For the -DENABLE_DYNDRIVERS=OFF case (with everything else default so this issue occurs when qt_example is built against the system Qt4 libraries), the usual test_interactive target generated a glibc double free error messa

Re: [Plplot-devel] Release status

On Mar 19, 2015, at 12:57 PM, "Alan W. Irwin" wrote: > On 2015-03-19 09:23-0600 Orion Poplawski wrote: > >> On 03/19/2015 12:41 AM, Alan W. Irwin wrote: >>> On 2015-03-18 21:26-0600 Orion Poplawski wrote: >>> On 03/18/2015 08:41 PM, Alan W. Irwin wrote: > Here is where I think we are.

Re: [Plplot-devel] Release status

On 2015-03-19 09:23-0600 Orion Poplawski wrote: > On 03/19/2015 12:41 AM, Alan W. Irwin wrote: >> On 2015-03-18 21:26-0600 Orion Poplawski wrote: >> >>> On 03/18/2015 08:41 PM, Alan W. Irwin wrote: Here is where I think we are. >>> >>> The issues in Fedora land are: >>> >>> - The octave+swig+

[Plplot-devel] Release status

Here is where I think we are. The deep freeze is still in effect. I have given up on the possibility of fixing the plend problems this late in the release cycle which I thought might be a spin-off from Norm's xwin plend fix that was being discussed. We will also put off dealing with that xwin fi

Re: [Plplot-devel] Release status: epa_build: libharu and general release topics

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 top

Re: [Plplot-devel] Release status: request for release notes on plbuf and plmeta/plrender changes

On 2015-03-15 16:24-0400 Jim Dishaw wrote: > Release notes: > > An experimental plot metafile input function, plreadmetafile(), was > implemented to provide an integrated read/write capability into the core of > PLplot. In conjunction, the plmeta driver has been updated to support a > transiti

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

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 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 examining the c

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

Did we ever come to a resolution on this? > On Mar 13, 2015, at 3:10 PM, Jim Dishaw wrote: > > >> On Mar 13, 2015, at 2:34 PM, Phil Rosenberg 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. >>

[Plplot-devel] Release status: need help with OLD_WXWIDGETS=ON option

Hi Phil: I have implemented the OLD_WXWIDGETS option as of commit bae1161, but there is one remaining issue with it that I need your help to fix. The old wxwidgets device driver appears to work as well as ever for the -DOLD_WXWIDGETS=ON case, but if you build the wxwidgets and wxPLplotDemo target

Re: [Plplot-devel] Release status: request for release notes on plbuf and plmeta/plrender changes

Release notes: An experimental plot metafile input function, plreadmetafile(), was implemented to provide an integrated read/write capability into the core of PLplot. In conjunction, the plmeta driver has been updated to support a transition to a new format. A key change is storing the raw s

[Plplot-devel] Release status: Jim's release-related topics

Hi Jim: I finally pushed your DocBook patch (commit id 2ff8d66) which validated and built nicely. Thanks for that! I think that is the next-to-last release-related topic between us. So I believe that the only topic left between us that is release related is my request earlier today concerning p

[Plplot-devel] Release status: Java, D, Python warnings generated by doxygen parser

Hi Andrew: If I configure PLplot with -DBUILD_DOX_DOC=ON and run make build_doxygen the following warnings are generated. [...] /home/software/plplot/HEAD/plplot.git/bindings/java/PLCallbackCT.java:5: warning: Internal inconsistency: scope for class plplot::core::PLCallbackCT not found! /home

[Plplot-devel] Release status: request for release notes concerning wxwidgets changes

Hi Phil: Please add a paragraph to the release notes (README.release) concerning your wxwidgets changes. If you don't do it yourself, I plan to add to that description that the old version of wxwidgets is available as an alternative if the user specifies the -DOLD_WXWIDGETS=ON option. (I plan to

[Plplot-devel] Release status: request for release notes on plbuf and plmeta/plrender changes

Hi Jim: I am about to start working on the release notes (README.release) which currently are quite out of date. I plan to say something like many bugs were fixed (notably for plbuf), but if there is more to say than that about your plbuf changes, please send me a paragraph describing those chan

Re: [Plplot-devel] Release status: epa_build: pango/cairo build issues

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 http://sourceforge.net/p/mingw-w64/

Re: [Plplot-devel] Release status: epa_build: libharu and general release topics

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 An

[Plplot-devel] Release status: epa_build: libharu and general release topics

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: As of commit fac174e I have changed the CMake-based libharu bu

[Plplot-devel] Release status: epa_build: pango/cairo build issues

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 http://sourceforge.net/p/mingw-w64/bugs/396/) Hi Andrew: That thread implies the problem is caused

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

> On Mar 13, 2015, at 2:34 PM, Phil Rosenberg 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 so, I put tha

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

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,

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

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 add

[Plplot-devel] Release status: fix for plbuf resizing issue

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 plRemakePlot() during one of your fixes (afd73a98).

Re: [Plplot-devel] Release status: plmeta/plrender

On Mar 12, 2015, at 3:38 PM, "Alan W. Irwin" 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 -dev plmet

Re: [Plplot-devel] Release status: plmeta/plrender

> On Mar 12, 2015, at 6:08 PM, Alan W. Irwin 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 will happen unless

Re: [Plplot-devel] Release status: plmeta/plrender

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 "W

[Plplot-devel] Release status: exposing plhrsh

On 2015-03-12 11:13-0700 Alan W. Irwin wrote: > @Phil, Jim: > > The recent exposure of plhrsh is not complete and has visibility > issues for the shared library case. In all cases where a private > function like this needs to be exposed, you need a declaration in > include/plplotP.h using the PLD

[Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

To Phil: gcc is generating these warnings when building libplplot. Would you please take a look to see whether this is either a real uninitialized issue that needs to be fixed or a false alarm? /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function ‘read_header’: /home/software/plp

[Plplot-devel] Release status: plmeta/plrender

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 -dev plmeta -o test.plmeta utils/plrender test.plmeta -dev psc -o test2.psc There were no

Re: [Plplot-devel] Release status

On Mar 12, 2015, at 2:13 PM, "Alan W. Irwin" wrote: > On 2015-03-11 14:49-0700 Alan W. Irwin wrote: > >> Hi Phil: >> >> I just saw your one-line fix at >> . >> >> Does that really do the job? For example, I n

Re: [Plplot-devel] Release status

On 2015-03-11 14:49-0700 Alan W. Irwin wrote: > Hi Phil: > > I just saw your one-line fix at > . > > Does that really do the job? For example, I noticed earlier in that code > a test of pls->device rather than pls

Re: [Plplot-devel] Release status

> On Mar 12, 2015, at 7:06 AM, Phil Rosenberg 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 only a 5 minute

Re: [Plplot-devel] Release status

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 di

Re: [Plplot-devel] Release status

> > * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts > of the pie chart, but the other slices are fine. This isn't shown on Windows. Perhaps the cause is that both the lines and the fill are being saved to the buffer meaning the lines get rendered twice. This is just a guess thou

Re: [Plplot-devel] Release status

I made a fix for double line fill bug. Please see attached file double-line-fill-fix.patch Description: Binary data I noticed a different bug. If you don't resize a plot, pressing enter advances to the next page. After resizing a plot, it takes more than one key press to advance. I'm not

Re: [Plplot-devel] Release status

On Mar 11, 2015, at 6:49 AM, "Alan W. Irwin" wrote: > 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 (prett

Re: [Plplot-devel] Release status

On 2015-03-11 12:27-0700 Alan W. Irwin wrote: > I will now do my own git bisects to find when the zoom issue was > introduced and when the two-GUI issue was introduced. My apologies, but it turns out the two-GUI issue was a false alarm. The only explanation that seems reasonable is there must ha

Re: [Plplot-devel] Release status

On Mar 11, 2015, at 4:59 PM, Phil Rosenberg wrote: > Hi Alan > > A quick bit of stepping through my code has confirmed my suspicion > from below. In plfill_soft plP_draphy is called for each line of the > pattern and these lines are saved in the buffer, so basically writing > to buffer needs sw

Re: [Plplot-devel] Release status

Hi Phil: I just saw your one-line fix at . Does that really do the job? For example, I noticed earlier in that code a test of pls->device rather than pls->dev, but I am just looking at patterns with no deep under

Re: [Plplot-devel] Release status

On 2015-03-11 20:59- Phil Rosenberg wrote: > Hi Alan > > A quick bit of stepping through my code has confirmed my suspicion > from below. In plfill_soft plP_draphy is called for each line of the > pattern and these lines are saved in the buffer, so basically writing > to buffer needs switching

Re: [Plplot-devel] Release status

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 we

  1   2   >