From: Alan W. I. <ir...@be...> - 2013-08-29 16:38:27
|
I think everyone here will agree that the release of plplot-5.9.10 is long overdue (plplot-5.9.9 was released almost two years ago). To address that issue does anybody have strong objections (typically due to work in progress that cannot be completed by that date) to releasing 5.9.10 on September 28th? I have heard off-list from Hez that he should be able to bring the OCaml examples 16 and 33 (the ones that use plcolorbar) into consistency with the C examples on that kind of time scale. I am currently addressing the issue of the pllegend and plcolorbar doxygen and docbook documentation, and should be done with that small documentation project by tomorrow. The only other issue I am aware of that potentially could affect the release schedule is the plcolorbar propagation effort required in the Ada case which is complicated by Jerry being out of contact for the next week and his known difficulties with actually building PLplot these days on his Mac OS X platform. However, if it turns out that Jerry cannot meet a September 28th deadline, then I feel we should not delay the release for the Ada plcolorbar issues and instead make a subsequent release a month or so after he has dealt with the Ada plcolorbar issues. One remaining practical issue is we don't have an official release manager at the moment. I have attempted to contact Andrew off list about the possibility of him taking on that role but he has not responded yet. But if September 28th is not convenient for him, and nobody else wants to take on this responsibility, then I am willing to take on that release manager role myself (likely at the expense of effort spent testing of PLplot on the Wine platform). So unless someone actually does have some PLplot development on the go that justifies delaying the release, I think you can pretty much count on September 28th being the release 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Andrew R. <and...@us...> - 2013-09-06 08:44:20
|
Alan, Sorry for coming to this rather late - I've been tied up with other things. I entirely support you in pressing for a release. This would fix a number of outstanding issues with the Debian packages and bring us back upto date. September 28th seems a reasonable timeframe. I'm sorry I probably won't have time to act as release manager this time round, but I'll try to crack on with more testing and in particular resolve the outstanding issues with the D language and plcolorbar. This just leaves Ada and Ocaml in need of bringing back into line. If Jerry struggles to fit in fixing Ada I'll try and take a look at that too. I also want to give Alan's recent documentation changes a thorough test. We need the release notes bring up to date, so if everyone could contribute to that it would be good. Thanks Alan for pushing us all into this. Andrew On Thursday 29 Aug 2013 09:38:18 Alan W. Irwin wrote: > I think everyone here will agree that the release of plplot-5.9.10 is > long overdue (plplot-5.9.9 was released almost two years ago). To > address that issue does anybody have strong objections (typically due > to work in progress that cannot be completed by that date) to > releasing 5.9.10 on September 28th? > > I have heard off-list from Hez that he should be able to bring the > OCaml examples 16 and 33 (the ones that use plcolorbar) into > consistency with the C examples on that kind of time scale. I am > currently addressing the issue of the pllegend and plcolorbar doxygen > and docbook documentation, and should be done with that small > documentation project by tomorrow. The only other issue I am aware of > that potentially could affect the release schedule is the plcolorbar > propagation effort required in the Ada case which is complicated by > Jerry being out of contact for the next week and his known > difficulties with actually building PLplot these days on his Mac OS X > platform. However, if it turns out that Jerry cannot meet a September > 28th deadline, then I feel we should not delay the release for the Ada > plcolorbar issues and instead make a subsequent release a month or so > after he has dealt with the Ada plcolorbar issues. > > One remaining practical issue is we don't have an official release > manager at the moment. I have attempted to contact Andrew off list > about the possibility of him taking on that role but he has not > responded yet. But if September 28th is not convenient for him, and > nobody else wants to take on this responsibility, then I am willing to > take on that release manager role myself (likely at the expense of > effort spent testing of PLplot on the Wine platform). So unless > someone actually does have some PLplot development on the go that > justifies delaying the release, I think you can pretty much count on > September 28th being the release 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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 > __________________________ > > ---------------------------------------------------------------------------- > -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2013-09-06 15:51:32
|
On 2013-09-06 09:17+0100 Andrew Ross wrote: > > Alan, > > Sorry for coming to this rather late - I've been tied up with other things. I > entirely support you in pressing for a release. This would fix a number of > outstanding issues with the Debian packages and bring us back upto date. > September 28th seems a reasonable timeframe. I'm sorry I probably won't have > time to act as release manager this time round, but I'll try to crack on with > more testing and in particular resolve the outstanding issues with the D > language and plcolorbar. This just leaves Ada and Ocaml in need of bringing > back into line. If Jerry struggles to fit in fixing Ada I'll try and take a look > at that too. I also want to give Alan's recent documentation changes a > thorough test. We need the release notes bring up to date, so if everyone > could contribute to that it would be good. Hi Andrew: I will take responsibility for the September 28th release then (3 weeks and a day from today!), and the rest of your plans prior to that release sound good. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2013-09-06 10:11:28
|
Hi, in an effort to pick up the Cygwin work again, I have updated my installation and now could successfully install Cairo and friends. And CMake recognises it. But in the make step things fall apart: In a file rpcdce.h, included by rpc.h and windows.h (the latter in cairo.c) the compiler complains about a bunch of typedefs. To make a long and tedious story short, it complains about the name of an argument in these function typedefs: "Status". If I change that to something like XXStatus, the error messages disappear. I am not aware of a specific meaning or a reserved status (sorry, no pun intended) for "Status". Is it a reserved word, indeed? Can anyone shed light on this? (This happens in header files that belong to Cygwin, so it is not a PLplot issue perse - it just appears with PLplot and Cairo.) Regards, Arjen 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...> - 2013-09-06 13:18:03
|
On Friday 06 Sep 2013 12:11:08 Arjen Markus wrote: > Hi, > > in an effort to pick up the Cygwin work again, I have > updated my installation and now could successfully install > Cairo and friends. And CMake recognises it. > > But in the make step things fall apart: > > In a file rpcdce.h, included by rpc.h and windows.h (the > latter in cairo.c) the compiler complains about a bunch of > typedefs. To make a long and tedious story short, it > complains about the name of an argument in these function > typedefs: "Status". > > If I change that to something like XXStatus, the error > messages disappear. I am not aware of a specific meaning > or a reserved status (sorry, no pun intended) for > "Status". Is it a reserved word, indeed? Can anyone shed > light on this? > > (This happens in header files that belong to Cygwin, so it > is not a PLplot issue perse - it just appears with PLplot > and Cairo.) Arjen, I'm pretty sure this is not a reserved keyword in C and I've not had problems so it must be something specific to Cygwin. >From a quick google search it looks like this thread might be relevant? http://cygwin.1069669.n5.nabble.com/Another-issue-with-CLANG-td95346.html Problem in this case seems to come from mixing windows native and X11 headers. Both define Status differently. There are a number of other google hits with similar problems. Andrew |
From: Arjen M. <arj...@de...> - 2013-09-06 13:35:27
|
Hi Andrew, yes, this is exactly the sort of error I get. I think that a convenient solution is to change the order of inclusion. I will try that ... yes, that solved the compiler issue. Now the linker is complaining about a few missing symbols (SetBkColor and ExtTextOutA). Solving these problems is the next step. Thanks, Arjen On Fri, 06 Sep 2013 14:18 +0100 Andrew Ross <and...@us...> wrote: > On Friday 06 Sep 2013 12:11:08 Arjen Markus wrote: >> Hi, >> >> in an effort to pick up the Cygwin work again, I have >> updated my installation and now could successfully >>install >> Cairo and friends. And CMake recognises it. >> >> But in the make step things fall apart: >> >> In a file rpcdce.h, included by rpc.h and windows.h (the >> latter in cairo.c) the compiler complains about a bunch >>of >> typedefs. To make a long and tedious story short, it >> complains about the name of an argument in these >>function >> typedefs: "Status". >> >> If I change that to something like XXStatus, the error >> messages disappear. I am not aware of a specific meaning >> or a reserved status (sorry, no pun intended) for >> "Status". Is it a reserved word, indeed? Can anyone shed >> light on this? >> >> (This happens in header files that belong to Cygwin, so >>it >> is not a PLplot issue perse - it just appears with >>PLplot >> and Cairo.) > > Arjen, > > I'm pretty sure this is not a reserved keyword in C and >I've not had problems > so it must be something specific to Cygwin. > >From a quick google search it looks like this thread >might be relevant? > > http://cygwin.1069669.n5.nabble.com/Another-issue-with-CLANG-td95346.html > > Problem in this case seems to come from mixing windows >native and X11 headers. > Both define Status differently. There are a number of >other google hits with > similar problems. > > Andrew > 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...> - 2013-09-06 18:00:01
|
Well, I missed one undefined routine: cairo_win32_surface_create. It is simply not in the cairo libraries that I installed via the Cygwin install program. So I have left out the wincairo device and then it all worked. Well, almost. I get warnings from pango: (process:5988): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' (process:5988): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' and the resulting pdf/png/... files contain empty boxes rather than readable characters. As I could not find a way to install fonts specifically for pango, I have posted a question on the Cygwin list. Hopefully I have formulated it generally enough so that non-PLplot-savvy members of that mailing list understand what trouble I have ;). Regards, Arjen On Fri, 06 Sep 2013 15:35:05 +0200 "Arjen Markus" <arj...@de...> wrote: > Hi Andrew, > > yes, this is exactly the sort of error I get. > I think that a convenient solution is to change the >order > of inclusion. I will try that ... yes, that solved the > compiler issue. > > Now the linker is complaining about a few missing >symbols > (SetBkColor and ExtTextOutA). Solving these problems is > the next step. > > Thanks, > > Arjen > > > > On Fri, 06 Sep 2013 14:18 +0100 > Andrew Ross <and...@us...> wrote: >> On Friday 06 Sep 2013 12:11:08 Arjen Markus wrote: >>> Hi, >>> >>> in an effort to pick up the Cygwin work again, I have >>> updated my installation and now could successfully >>>install >>> Cairo and friends. And CMake recognises it. >>> >>> But in the make step things fall apart: >>> >>> In a file rpcdce.h, included by rpc.h and windows.h (the >>> latter in cairo.c) the compiler complains about a bunch >>>of >>> typedefs. To make a long and tedious story short, it >>> complains about the name of an argument in these >>>function >>> typedefs: "Status". >>> >>> If I change that to something like XXStatus, the error >>> messages disappear. I am not aware of a specific meaning >>> or a reserved status (sorry, no pun intended) for >>> "Status". Is it a reserved word, indeed? Can anyone shed >>> light on this? >>> >>> (This happens in header files that belong to Cygwin, so >>>it >>> is not a PLplot issue perse - it just appears with >>>PLplot >>> and Cairo.) >> >> Arjen, >> >> I'm pretty sure this is not a reserved keyword in C and >>I've not had problems >> so it must be something specific to Cygwin. >> >>From a quick google search it looks like this thread >>might be relevant? >> >> http://cygwin.1069669.n5.nabble.com/Another-issue-with-CLANG-td95346.html >> >> Problem in this case seems to come from mixing windows >>native and X11 headers. >> Both define Status differently. There are a number of >>other google hits with >> similar problems. >> >> Andrew >> > > > > > 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. > > > > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, >SQL 2012, more! > Discover the easy way to master current and previous >Microsoft technologies > and advance your career. Get an incredible 1,500+ hours >of step-by-step > tutorial videos with LearnDevNow. Subscribe today and >save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > 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...> - 2013-09-06 18:50:43
|
On 2013-09-06 19:59+0200 Arjen Markus wrote: > Well, I missed one undefined routine: > cairo_win32_surface_create. It is simply not in the cairo > libraries that I installed via the Cygwin install program. > So I have left out the wincairo device and then it all > worked. > > Well, almost. I get warnings from pango: > > (process:5988): Pango-WARNING **: failed to choose a font, > expect ugly output. engine-type='PangoRenderFc', > script='common' > > (process:5988): Pango-WARNING **: failed to choose a font, > expect ugly output. engine-type='PangoRenderFc', > script='latin' > > and the resulting pdf/png/... files contain empty boxes > rather than readable characters. > > As I could not find a way to install fonts specifically > for pango, I have posted a question on the Cygwin list. > Hopefully I have formulated it generally enough so that > non-PLplot-savvy members of that mailing list understand > what trouble I have ;). Do you have the Cygwin fontconfig package installed? I am pretty sure that package would be essential for fonts to work properly with pango/cairo and the cairo device driver. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Orion P. <or...@co...> - 2013-09-07 03:26:04
|
On 08/29/2013 10:38 AM, Alan W. Irwin wrote: > I think everyone here will agree that the release of plplot-5.9.10 is > long overdue (plplot-5.9.9 was released almost two years ago). To > address that issue does anybody have strong objections (typically due > to work in progress that cannot be completed by that date) to > releasing 5.9.10 on September 28th? That would be great. Plenty of time to get it into F20. http://fedoraproject.org/wiki/Releases/20/Schedule -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Arjen M. <arj...@de...> - 2013-09-07 08:16:00
|
Hi Alan, On Fri, 6 Sep 2013 11:50:35 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > > Do you have the Cygwin fontconfig package installed? I >am pretty sure > that package would be essential for fonts to work >properly with > pango/cairo and the cairo device driver. > That did the trick indeed! Good thing too, because the Cygwin list does not seem to like my posts. I found out however that the current cairo libraties are missing a routine which makes it impossible to build the wincairo device: cairo_win32_surface_create. For the moment I will therefore exclude that device. Regards, Arjen 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...> - 2013-09-07 16:28:15
|
Hi Alan, encouraged by the success with cairo/pango I had a closer look at the Python and Java problems: - Python could not be enabled because Numpy could not be loaded. This turned out to be a problem with lapack_lite.dll. This DLL depends on cyglapack-0.dll, but that is installed in a different directory than most others. By adding /usr/lib/lapack to the PATH, I was able to convince CMake that all was all right for Python. The tests are 100% clean. - I wish I could say the same for Java. I tried several things, but nothing worked. (Copying "gcj.exe" to "javac.exe" helped a bit, but now CMake complains about "jar".) So that bit still requires work. Anyway I will add these observations to the release notes. Regards, Arjen 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...> - 2013-09-07 17:53:14
|
On 2013-09-07 18:27+0200 Arjen Markus wrote: > The tests [exclusive of Java] are 100% clean. To follow up on this Cygwin success with the cairo devices, I have a series of questions and comments for you. What do the "test_noninteractive" results look like? For example, after running that target gv examples/x??c.pdfcairo should produce some good looking results for ?? = 24, 26, and 33. You should substitute your favorite command-line pdf viewer instead of gv if you haven't installed gv on Cygwin. And similarly for pngcairo, pscairo, if you have access to PNG or PostScript viewers. The epscairo device produces familied results (a separate encapsulated PostScript file with appropriate bounding box for each separate page of each example) so in that case the file names are examples/x24c01.epscairo, examples/x26c01.epscairo, examples/x26c02.epscairo, etc. It's a shame that the pango/cairo set of libraries for Cygwin does not currently provide support for the wincairo device, but I suspect that is likely to change in the future (that capability was a relatively late addition to the cairo library which may just not be available on Cygwin yet). Anyhow, I would re-test that situation each time a new version of cairo became available on Cygwin. Is the xcairo device available to you instead when you install the X development libraries for Cygwin? If so, I would try examples/c/x??c.exe -dev xcairo where ?? takes on the above values to make sure it works. Did your good test results also include the test_interactive target? That target should exercise all interactive devices (such as xcairo if that is available) that you have built. I am glad you got Python to work since that is a really important computer language for scientists. I suspect Java is equally important for other groups, but if some quick attempts to fix Java language support on Cygwin do not work, I would set it aside for now and move on to getting the qt devices to work (which requires installation of the Qt4 development packages). That would be just as important a breakthrough as you have just had with the cairo devices. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Chris M. <dev...@gm...> - 2013-09-07 18:39:46
|
It is exciting seeing the progress with cygwin. I'll try to set up a local svn and git it another try. As for the wincairo device failure, I wouldn't worry about it. Builds for cygwin *should* look like a unix install and not mswindows. Even, if it might be possible to trick an install to support both, it is pretty difficult to sustain configuration-wise. --Chris On Sat, Sep 7, 2013 at 4:15 AM, Arjen Markus <arj...@de...> wrote: > Hi Alan, > > On Fri, 6 Sep 2013 11:50:35 -0700 (PDT) > "Alan W. Irwin" <ir...@be...> wrote: > >> >> Do you have the Cygwin fontconfig package installed? I >>am pretty sure >> that package would be essential for fonts to work >>properly with >> pango/cairo and the cairo device driver. >> > > That did the trick indeed! Good thing too, because the > Cygwin list does not seem to like my posts. > > I found out however that the current cairo libraties are > missing a routine which makes it impossible to build the > wincairo device: cairo_win32_surface_create. For the > moment I will therefore exclude that device. > > Regards, > > Arjen > > > > 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. > > > > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@de...> - 2013-09-07 19:23:31
|
Hi Chris, On Sat, 7 Sep 2013 14:39:38 -0400 Chris Marshall <dev...@gm...> wrote: > It is exciting seeing the progress with cygwin. I'll >try to set > up a local svn and git it another try. As for the >wincairo > device failure, I wouldn't worry about it. Builds for >cygwin > *should* look like a unix install and not mswindows. > Even, if it might be possible to trick an install to >support > both, it is pretty difficult to sustain >configuration-wise. > Oh, there are plenty of complications to worry about :). It is just that it is easier to run a Windows-native device when testing or viewing than starting X Window and then letting a program draw into that. The wingcc device does work under Cygwin, by the way. Like Alan says, the next big step could indeed be Qt. I will report back on the progress with that big chunk of functionality. (To satisfy Alan's curiosity: so far tests with individual examples have shown nice results, both pdf and png.) Regards, Arjen 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...> - 2013-09-07 19:24:32
|
On 2013-09-07 14:39-0400 Chris Marshall wrote: > It is exciting seeing the progress with cygwin. I'll try to set > up a local svn and git it another try. As for the wincairo > device failure, I wouldn't worry about it. Builds for cygwin > *should* look like a unix install and not mswindows. > Even, if it might be possible to trick an install to support > both, it is pretty difficult to sustain configuration-wise. @Chris: I agree that the Cygwin developer attitude does seem to be to make Cygwin as Unix-like as possible so you may well be right that they have deliberately packaged cairo without the cairo_win32_surface_create capability. @Arjen: If you can get in contact with the Cygwin cairo packager and he confirms that is what they are going to do for the forseeable future, then I suggest the following change to simplify the Boolean logic we are currently using which is if (not(win32 or cygwin) or cygwin), then drop wincairo to the much simpler form (since we already have a single CMake variable to represent win32 and not cygwin) if (not(win32 and not cygwin)) then drop wincairo I am pretty sure you like math puzzles so if it is not obvious to you that those two Boolean constructs are equivalent, then I encourage you to try the truth table exercise (which is what I had to do) to prove it. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2013-09-09 07:00:17
|
Hi Alan, Chris, here is my report on Cygwin On 2013-09-07 19:53, Alan W. Irwin wrote: > > What do the "test_noninteractive" results look like? For example, > after running that target > > gv examples/x??c.pdfcairo > > should produce some good looking results for ?? = 24, 26, and 33. You > should substitute your favorite command-line pdf viewer instead of gv > if you haven't installed gv on Cygwin. And similarly for pngcairo, > pscairo, if you have access to PNG or PostScript viewers. The > epscairo device produces familied results (a separate encapsulated > PostScript file with appropriate bounding box for each separate page > of each example) so in that case the file names are > examples/x24c01.epscairo, examples/x26c01.epscairo, > examples/x26c02.epscairo, etc. > Yes, the pictures contained in these files look nice, no problem there. Even the fonts look quite okay - for instance the "peace" flag is filled with all the fonts we expect, with no more to be selected for installation than "fontconfig". > It's a shame that the pango/cairo set of libraries for Cygwin does not > currently provide support for the wincairo device, but I suspect that is > likely to change in the future (that capability was a relatively > late addition to the cairo library which may just not be available on > Cygwin yet). Anyhow, I would re-test that situation each time a new > version of cairo became available on Cygwin. > I had one answer so far - that Cygwin is supposed to be UNIX on Windows, so why would I expect a Windows-specific functionality like that? We'll see what other answers come forth. > Is the xcairo device available to you instead when you install the X > development libraries for Cygwin? If so, I would try > > examples/c/x??c.exe -dev xcairo > > where ?? takes on the above values to make sure it works. > I have an X Window installation available: - the xwin device looks fairly nice (the fonts are as always rather wriggly) - the xcairo device produces samller graphs for some reason and it does not take the -display command line argument (whereas the xwin device does). Something to be repaired, I'd say. I had to use the DISPLAY environment variable instead. (I do not have a window manager running yet, so the windows are created full-screen) > Did your good test results also include the test_interactive target? > That target should exercise all interactive devices (such as xcairo if > that is available) that you have built. > The non-interactive tests were almost as clean as possible. There was one difference with example 23: the text file for this example contains the address "0x8000000:L" instead of "0x8000000" (so an extra L). I have no idea where that comes from. > I am glad you got Python to work since that is a really important > computer language for scientists. I suspect Java is equally important > for other groups, but if some quick attempts to fix Java language > support on Cygwin do not work, I would set it aside for now and move > on to getting the qt devices to work (which requires installation of > the Qt4 development packages). That would be just as important a > breakthrough as you have just had with the cairo devices. > Now we come to the disappointing part: Qt4 will not currently work on Cygwin, I am afraid. Here are the details: - I installed all the things Qt4 I could find in the set-up, but the essential program qmake.exe was still missing. - Then I had a bright idea: build it from the source code. This was not a smooth road: - At some point during the compilation a constant QT_OPEN_LARGEFILE turned out to be missing for the Cygwin platform. I found the likely place it should have been defined and repaired the source code. - That made the build procedure happy enough to continue building all manner of libraries and examples, or at least prepare that. - The stumbling block - and for me the showstopper was this message: error: 'gtk_init_abi_check' is not a member of 'QtGtkStylePrivate' - It caused the build process to stop and similarly the installation process. - While I could make a guess at the solution for the first problem, this one is beyond my ability to repair. I have no idea whether it is at all a necessary part of Qt4 or not. So I gave up on Qt4 for the moment. I will report this on the Cygwin list. Perhaps I should ask about the Java problem on CMake, as it looks more of a CMake-problem than a Cygwin-problem. Regards, Arjen 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...> - 2013-09-09 10:04:37
|
Arjen, I can't comment on most of this, but... On Monday 09 Sep 2013 08:59:58 Arjen Markus wrote: > > > Did your good test results also include the test_interactive target? > > That target should exercise all interactive devices (such as xcairo if > > that is available) that you have built. > > The non-interactive tests were almost as clean as possible. There was > one difference with example 23: the text file for this example contains > the address "0x8000000:L" instead of "0x8000000" (so an extra L). I have > no idea where that comes from. This is with python? It's just a 32-bit / 64-bit issue. Python doesn't seem to do unsigned ints so on 32-bit systems the 32 bit unsigned int becomes a 64-bit long, hence the L appended. On 64-bit systems int is 64-bit anyway so there isn't a problem. We've seen this on other platforms and I've not found an easy way round it, but it is only a minor issue and only relevant for our test suite so I'm not too worried. Andrew |
From: Arjen M. <arj...@de...> - 2013-09-09 10:32:56
|
Hi Andrew, On 2013-09-09 12:04, Andrew Ross wrote: > Arjen, > > I can't comment on most of this, but... > > On Monday 09 Sep 2013 08:59:58 Arjen Markus wrote: >>> Did your good test results also include the test_interactive target? >>> That target should exercise all interactive devices (such as xcairo if >>> that is available) that you have built. >> The non-interactive tests were almost as clean as possible. There was >> one difference with example 23: the text file for this example contains >> the address "0x8000000:L" instead of "0x8000000" (so an extra L). I have >> no idea where that comes from. > > This is with python? It's just a 32-bit / 64-bit issue. Python doesn't seem to > do unsigned ints so on 32-bit systems the 32 bit unsigned int becomes a 64-bit > long, hence the L appended. On 64-bit systems int is 64-bit anyway so there > isn't a problem. We've seen this on other platforms and I've not found an easy > way round it, but it is only a minor issue and only relevant for our test > suite so I'm not too worried. > Yes, I was surprised myself. At a first glance I thought there was something amiss with the PostScript output, but that looked completely okay. It was only this one letter that differed in the text output. Not at all relevant, but for an automatic comparison a nuisance. Regards, Arjen 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...> - 2013-09-09 16:44:59
|
On 2013-09-09 08:59+0200 Arjen Markus wrote: > I have an X Window installation available: > - the xwin device looks fairly nice (the fonts are as always rather > wriggly) > - the xcairo device produces samller graphs for some reason and it > does not take the -display command line argument (whereas the xwin > device does). Something to be repaired, I'd say. I had to use the > DISPLAY environment variable instead. > > (I do not have a window manager running yet, so the windows are created > full-screen) > >> Did your good test results also include the test_interactive target? >> That target should exercise all interactive devices (such as xcairo if >> that is available) that you have built. >> > > The non-interactive tests were almost as clean as possible. Do you get similar good results for the test_interactive (as opposed to test_noninteractive) target? Warning... this target is a bit of a pain to run because you have to do some clicking (or hitting return) on the GUI's to move through some of the examples. But for completeness you should run it (using make test_interactive >& test_interactive.out to capture most error/warning messages in test_interactive.out) because it exercises a different set of devices (the interactive devices rather than the file devices exercised by the the test_noninteractive target). >> I am glad you got Python to work since that is a really important >> computer language for scientists. I suspect Java is equally important >> for other groups, but if some quick attempts to fix Java language >> support on Cygwin do not work, I would set it aside for now and move >> on to getting the qt devices to work (which requires installation of >> the Qt4 development packages). That would be just as important a >> breakthrough as you have just had with the cairo devices. >> > > Now we come to the disappointing part: > Qt4 will not currently work on Cygwin, I am afraid. At least this initial issue should be easy to overcome. > Here are the details: > - I installed all the things Qt4 I could find in the set-up, but the > essential program qmake.exe was still missing. qmake.exe (which I agree is absolutely essential) is contained in the development form of the Qt4 libraries. To find the appropriate package names, look at http://cygwin.com/packages and use the regex search box there. Just now I used that search box to check for qmake.exe, and I got three hits: x86/libQtCore4-devel/libQtCore4-devel-4.8.4-1 x86/libQtCore4-devel/libQtCore4-devel-4.8.4-2 x86/libqt3-devel/libqt3-devel-3.3.8b-12 I am virtually positive you will want to install libQtCore4-devel-4.8.4-2 (assuming you have already installed the 4.8.4-2 version of Qt libraries including libQtCore4-4.8.4-2). 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2013-09-09 18:51:49
|
On 2013-09-09 08:59+0200 Arjen Markus wrote: > - the xcairo device produces samller graphs for some reason and it > does not take the -display command line argument (whereas the xwin > device does). Something to be repaired, I'd say. I had to use the > DISPLAY environment variable instead. > > (I do not have a window manager running yet, so the windows are created > full-screen) Just to give some quick background, src/plargs.c shows the -display option is implemented using the same code as the -o option so like that option it sets pls->FileName to whatever string (e.g., ":0.0") the user specifies after -display. Then the xwin.c code uses pls->FileName (if set) to set the display. @Hazen: would you be able to do something similar for the xcairo device comfortably before the release date on September 28th? It appears to me that "Display" in drivers/cairo.c is set to NULL to start with so it might be trivial to use pls->FileName instead. However, there are a number of uses of "Display" in drivers/cairo.c so someone more familiar with that code than I am should implement this "would be nice" feature for the xcairo device. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Andrew R. <and...@us...> - 2013-09-09 22:34:59
|
On Monday 09 Sep 2013 11:51:41 Alan W. Irwin wrote: > On 2013-09-09 08:59+0200 Arjen Markus wrote: > > - the xcairo device produces samller graphs for some reason and it > > > > does not take the -display command line argument (whereas the xwin > > device does). Something to be repaired, I'd say. I had to use the > > DISPLAY environment variable instead. > > > > (I do not have a window manager running yet, so the windows are created > > full-screen) > > Just to give some quick background, src/plargs.c shows the -display > option is implemented using the same code as the -o option so like > that option it sets pls->FileName to whatever string (e.g., ":0.0") > the user specifies after -display. Then the xwin.c code uses > pls->FileName (if set) to set the display. > > @Hazen: would you be able to do something similar for the xcairo device > comfortably before the release date on September 28th? > > It appears to me that "Display" in drivers/cairo.c is set to NULL to > start with so it might be trivial to use pls->FileName instead. > However, there are a number of uses of "Display" in drivers/cairo.c so > someone more familiar with that code than I am should implement this > "would be nice" feature for the xcairo device. Hazen - Don't worry, I've done it. Essentially a 1-line fix. I've also changed the code so failure to open the display will exit plplot immediately. The old behaviour led to a crash if an invalid display was set. Arjen - Please check this works for you. Andrew |
From: Arjen M. <Arj...@de...> - 2013-09-10 14:48:38
|
Hi Andrew, Alan, Great, I will try this as soon as I have everything working again (I have a new laptop which needs to be set up) Regards, Arjen -----Original Message----- From: Andrew Ross [mailto:and...@us...] Sent: Tuesday, September 10, 2013 12:35 AM To: plp...@li... Subject: Re: [Plplot-devel] Getting -display to work for xcairo On Monday 09 Sep 2013 11:51:41 Alan W. Irwin wrote: > On 2013-09-09 08:59+0200 Arjen Markus wrote: > > - the xcairo device produces samller graphs for some reason and it > > > > does not take the -display command line argument (whereas the xwin > > device does). Something to be repaired, I'd say. I had to use the > > DISPLAY environment variable instead. > > > > (I do not have a window manager running yet, so the windows are > > created > > full-screen) > > Just to give some quick background, src/plargs.c shows the -display > option is implemented using the same code as the -o option so like > that option it sets pls->FileName to whatever string (e.g., ":0.0") > the user specifies after -display. Then the xwin.c code uses > pls->FileName (if set) to set the display. > > @Hazen: would you be able to do something similar for the xcairo > device comfortably before the release date on September 28th? > > It appears to me that "Display" in drivers/cairo.c is set to NULL to > start with so it might be trivial to use pls->FileName instead. > However, there are a number of uses of "Display" in drivers/cairo.c so > someone more familiar with that code than I am should implement this > "would be nice" feature for the xcairo device. Hazen - Don't worry, I've done it. Essentially a 1-line fix. I've also changed the code so failure to open the display will exit plplot immediately. The old behaviour led to a crash if an invalid display was set. Arjen - Please check this works for you. Andrew ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel 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...> - 2013-09-16 11:55:21
|
Hello all, -----Original Message----- From: Alan W. Irwin [mailto:ir...@be...] qmake.exe (which I agree is absolutely essential) is contained in the development form of the Qt4 libraries. To find the appropriate package names, look at http://cygwin.com/packages and use the regex search box there. Just now I used that search box to check for qmake.exe, and I got three hits: x86/libQtCore4-devel/libQtCore4-devel-4.8.4-1 x86/libQtCore4-devel/libQtCore4-devel-4.8.4-2 x86/libqt3-devel/libqt3-devel-3.3.8b-12 I am virtually positive you will want to install libQtCore4-devel-4.8.4-2 (assuming you have already installed the 4.8.4-2 version of Qt libraries including libQtCore4-4.8.4-2). Alan ---- I have installed the development libraries and now I do have a qmake.exe plus a lot of other Qt-related items. CMake recognises it and turns on the Qt device drivers. I had to turn off the svgqt device though, as there is no QSVGgenerator header file in my present installation. However, in the process of achieving this I had to install libtool and libltdl and that has now turned up another issue. The cairo driver causes a problem when building the driver information: [ 20%] Built target test_qt_dyndriver Scanning dependencies of target test_cairo_dyndriver [ 21%] Generating test_dyndrivers_dir/cairo.driver_info Could not open driver module cairo libltdl error: %1 is not a valid Win32 application. drivers/CMakeFiles/test_cairo_dyndriver.dir/build.make:55: recipe for target `drivers/test_dyndrivers_dir/cairo.driver_info' failed make[2]: *** [drivers/test_dyndrivers_dir/cairo.driver_info] Error 1 CMakeFiles/Makefile2:2654: recipe for target `drivers/CMakeFiles/test_cairo_dyndriver.dir/all' failed make[1]: *** [drivers/CMakeFiles/test_cairo_dyndriver.dir/all] Error 2 Makefile:146: recipe for target `all' failed make: *** [all] Error 2 I will continue to search for the cause (some DLL missing?), but this is the status so far. Regards, Arjen 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...> - 2013-09-16 15:07:14
|
On 2013-09-16 11:55-0000 Arjen Markus wrote: > I have installed the development libraries and now I do have a qmake.exe plus a lot of other Qt-related items. CMake recognises it and turns on the Qt device drivers. I had to turn off the svgqt device though, as there is no QSVGgenerator header file in my present installation. Things appear to be moving quite rapidly for Cygwin. If you check the http://cygwin.com/packages search box for qmake.exe, the package found is libQtCore4-devel-4.8.5-1, i.e., you should upgrade your present installation so that all Qt packages are version 4.8.5-1. Furthermore, a search for qsvggenerator.h finds libQtSvg4-devel-4.8.5-1. So if you follow the upgrade of all your Qt packages to version 4.8.5-1 with an installation of libQtSvg4-devel-4.8.5-1, then the PLplot svgqt device (which is actually a pretty important device since it produces human-readable files which are useful not only for plotting vector graphics but also for debugging purposes) should become available. > However, in the process of achieving this I had to install libtool and libltdl and that has now turned up another issue. The cairo driver causes a problem when building the driver information: > > [ 20%] Built target test_qt_dyndriver That is excellent news that test_qt_dyndriver built without issues. That and the other good results for test_<driver_name>_dyndriver that you presumably get means that your new libltdl is probably working OK in general, but that needs to be confirmed using the test_noninteractive target (see below). > Scanning dependencies of target test_cairo_dyndriver > [ 21%] Generating test_dyndrivers_dir/cairo.driver_info > Could not open driver module cairo > libltdl error: %1 is not a valid Win32 application. > drivers/CMakeFiles/test_cairo_dyndriver.dir/build.make:55: recipe for target `drivers/test_dyndrivers_dir/cairo.driver_info' failed > make[2]: *** [drivers/test_dyndrivers_dir/cairo.driver_info] Error 1 > CMakeFiles/Makefile2:2654: recipe for target `drivers/CMakeFiles/test_cairo_dyndriver.dir/all' failed > make[1]: *** [drivers/CMakeFiles/test_cairo_dyndriver.dir/all] Error 2 > Makefile:146: recipe for target `all' failed > make: *** [all] Error 2 > > I will continue to search for the cause (some DLL missing?), but this is the status so far. I suggest you might want to drop cairo temporarily and push ahead with full tests (test_noninteractive target) of all other PLplot components including qt just to confirm all is well with the noninteractive devices (except for the cairo ones) and also the new libltdl. Then move back to cairo and do the usual build-system debugging steps to find out what the issue might be with the cairo device driver. Those steps are to use the VERBOSE=1 option to find out the relevant linking command and the relevant run-time test that failed. Then running those exact same commands by hand to verify the issue and ultimately change the link command to fix it. Then modifying the build system to follow whatever fix you found worked when running everything by hand. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2013-09-16 18:53:43
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Monday, September 16, 2013 5:07 PM > To: Arjen Markus > Cc: plp...@li... > Subject: Re: [Plplot-devel] Cygwin - for the next release? > > On 2013-09-16 11:55-0000 Arjen Markus wrote: > > > I have installed the development libraries and now I do have a > qmake.exe plus a lot of other Qt-related items. CMake recognises it and turns on the > Qt device drivers. I had to turn off the svgqt device though, as there is no > QSVGgenerator header file in my present installation. > > Things appear to be moving quite rapidly for Cygwin. If you check the > http://cygwin.com/packages search box for qmake.exe, the package found is > libQtCore4-devel-4.8.5-1, i.e., you should upgrade your present installation so that all > Qt packages are version 4.8.5-1. Furthermore, a search for qsvggenerator.h finds > libQtSvg4-devel-4.8.5-1. So if you follow the upgrade of all your Qt packages to > version 4.8.5-1 with an installation of libQtSvg4-devel-4.8.5-1, then the PLplot svgqt > device (which is actually a pretty important device since it produces human-readable > files which are useful not only for plotting vector graphics but also for debugging > purposes) should become available. Ah, yes, that stuff was in a separate library. Looking for "svg" brought up two Qt4 packages that hold it. > > > However, in the process of achieving this I had to install libtool > and libltdl and that has now turned up another issue. The cairo driver causes a > problem when building the driver information: > > > > > [ 20%] Built target test_qt_dyndriver > > That is excellent news that test_qt_dyndriver built without issues. > That and the other good results for test_<driver_name>_dyndriver that you > presumably get means that your new libltdl is probably working OK in general, but > that needs to be confirmed using the test_noninteractive target (see below). > Yes, several other device drivers were loaded successfully. I have not run the test_noninteractive target yet. (That is running right now) > > Scanning dependencies of target test_cairo_dyndriver [ 21%] Generating > > test_dyndrivers_dir/cairo.driver_info > > Could not open driver module cairo > > libltdl error: %1 is not a valid Win32 application. > > drivers/CMakeFiles/test_cairo_dyndriver.dir/build.make:55: recipe for > > target `drivers/test_dyndrivers_dir/cairo.driver_info' failed > > make[2]: *** [drivers/test_dyndrivers_dir/cairo.driver_info] Error 1 > > CMakeFiles/Makefile2:2654: recipe for target > > `drivers/CMakeFiles/test_cairo_dyndriver.dir/all' failed > > make[1]: *** [drivers/CMakeFiles/test_cairo_dyndriver.dir/all] Error 2 > > Makefile:146: recipe for target `all' failed > > make: *** [all] Error 2 > > > > I will continue to search for the cause (some DLL missing?), but this is the status > so far. > > I suggest you might want to drop cairo temporarily and push ahead with full tests > (test_noninteractive target) of all other PLplot components including qt just to confirm > all is well with the noninteractive devices (except for the cairo ones) and also the new > libltdl. Then move back to cairo and do the usual build-system debugging steps to > find out what the issue might be with the cairo device driver. Those steps are to use > the VERBOSE=1 option to find out the relevant linking command and the relevant > run-time test that failed. Then running those exact same commands by hand to > verify the issue and ultimately change the link command to fix it. Then modifying the > build system to follow whatever fix you found worked when running everything by > hand. > Turning off the cairo devices made the build process succeed and ... eh presto! We have Qt4 on Cygwin. Just a few minor oddities: - The X Window device is extraordinarily slow - normally the four plots of example 1 are shown immediately, but now I saw each line segment being drawn. I do not know where this coming from. - The extqt device caused a segmentation fault after printing the message that you need to call plsetqtdev() before plinit(). I have no idea what this external device is, I assumed it would be X Window. I can not check Andrew's update for the cairo device (the DISPLAY name) yet, as I had to turn that off. If I turn off the dynamic drivers that ought to be okay again. Regards, Arjen 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. |