You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(58) |
Nov
(95) |
Dec
(55) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(205) |
Feb
(106) |
Mar
(36) |
Apr
(25) |
May
(34) |
Jun
(36) |
Jul
(161) |
Aug
(66) |
Sep
(100) |
Oct
(62) |
Nov
(77) |
Dec
(172) |
2003 |
Jan
(101) |
Feb
(202) |
Mar
(191) |
Apr
(97) |
May
(27) |
Jun
(21) |
Jul
(16) |
Aug
(55) |
Sep
(155) |
Oct
(166) |
Nov
(19) |
Dec
(134) |
2004 |
Jan
(569) |
Feb
(367) |
Mar
(81) |
Apr
(62) |
May
(124) |
Jun
(77) |
Jul
(85) |
Aug
(80) |
Sep
(66) |
Oct
(42) |
Nov
(20) |
Dec
(133) |
2005 |
Jan
(192) |
Feb
(143) |
Mar
(183) |
Apr
(128) |
May
(136) |
Jun
(18) |
Jul
(22) |
Aug
(33) |
Sep
(20) |
Oct
(12) |
Nov
(80) |
Dec
(44) |
2006 |
Jan
(42) |
Feb
(38) |
Mar
(17) |
Apr
(112) |
May
(220) |
Jun
(67) |
Jul
(96) |
Aug
(214) |
Sep
(104) |
Oct
(67) |
Nov
(150) |
Dec
(103) |
2007 |
Jan
(111) |
Feb
(50) |
Mar
(113) |
Apr
(19) |
May
(32) |
Jun
(34) |
Jul
(61) |
Aug
(103) |
Sep
(75) |
Oct
(99) |
Nov
(102) |
Dec
(40) |
2008 |
Jan
(86) |
Feb
(56) |
Mar
(104) |
Apr
(50) |
May
(45) |
Jun
(64) |
Jul
(71) |
Aug
(147) |
Sep
(132) |
Oct
(176) |
Nov
(46) |
Dec
(136) |
2009 |
Jan
(159) |
Feb
(136) |
Mar
(188) |
Apr
(189) |
May
(166) |
Jun
(97) |
Jul
(160) |
Aug
(235) |
Sep
(163) |
Oct
(46) |
Nov
(99) |
Dec
(54) |
2010 |
Jan
(104) |
Feb
(121) |
Mar
(153) |
Apr
(75) |
May
(138) |
Jun
(63) |
Jul
(61) |
Aug
(27) |
Sep
(93) |
Oct
(63) |
Nov
(40) |
Dec
(102) |
2011 |
Jan
(52) |
Feb
(26) |
Mar
(61) |
Apr
(27) |
May
(33) |
Jun
(43) |
Jul
(37) |
Aug
(53) |
Sep
(58) |
Oct
(63) |
Nov
(67) |
Dec
(16) |
2012 |
Jan
(97) |
Feb
(34) |
Mar
(6) |
Apr
(18) |
May
(32) |
Jun
(9) |
Jul
(17) |
Aug
(78) |
Sep
(24) |
Oct
(101) |
Nov
(31) |
Dec
(7) |
2013 |
Jan
(44) |
Feb
(35) |
Mar
(59) |
Apr
(17) |
May
(29) |
Jun
(38) |
Jul
(48) |
Aug
(46) |
Sep
(74) |
Oct
(140) |
Nov
(94) |
Dec
(177) |
2014 |
Jan
(94) |
Feb
(74) |
Mar
(75) |
Apr
(63) |
May
(24) |
Jun
(1) |
Jul
(30) |
Aug
(112) |
Sep
(78) |
Oct
(137) |
Nov
(60) |
Dec
(17) |
2015 |
Jan
(128) |
Feb
(254) |
Mar
(273) |
Apr
(137) |
May
(181) |
Jun
(157) |
Jul
(83) |
Aug
(34) |
Sep
(26) |
Oct
(9) |
Nov
(24) |
Dec
(43) |
2016 |
Jan
(94) |
Feb
(77) |
Mar
(83) |
Apr
(19) |
May
(39) |
Jun
(1) |
Jul
(5) |
Aug
(10) |
Sep
(28) |
Oct
(34) |
Nov
(82) |
Dec
(301) |
2017 |
Jan
(53) |
Feb
(50) |
Mar
(11) |
Apr
(15) |
May
(23) |
Jun
(36) |
Jul
(84) |
Aug
(90) |
Sep
(35) |
Oct
(81) |
Nov
(13) |
Dec
(11) |
2018 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(4) |
Aug
(13) |
Sep
(31) |
Oct
(4) |
Nov
(25) |
Dec
(64) |
2019 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(13) |
Jun
(8) |
Jul
(16) |
Aug
(7) |
Sep
(27) |
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(9) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
|
2022 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
2023 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
From: Jim D. <ji...@di...> - 2019-09-15 02:04:09
|
I need to add comctl32.lib as one of the libraries when building Windows executables. Which cmake file should be modified such that the examples are built correctly? The wingdi driver needs that library. Thanks |
From: Alan W. I. <Ala...@gm...> - 2019-09-13 07:09:12
|
On 2019-09-12 17:59+0100 Phil Rosenberg wrote: > Hi Alan > I think I have found a problem with test-drv-info. I think it is > unaware of the CMake flag CMAKE_DEBUG_POSTFIX. I've started using > -DCMAKE_DEBUG_POSTFIX=d as part of my cmake commands to add d to the > end of all debug libraries. But this causes test-drv-info to report: > Could not open the driver module <module> > If I go onto the command line ant try running test-drv-info myself, > adding d to the module name, I get > Could not read symbol plD_DEVICE_INFO_<module>d in driver module <module>d > > Is it possible to pull the postfix into the test-drv-info source? It > would simply need concatenating at line 76 of test-drv-info.c Hi Phil: I have no objection to such a change so long as it is completely general (any postfix string of any length that the user has specified for any possible CMAKE_BUILD_TYPE). For example, it should work (to take an absurd example) if the user specifies -DCMAKE_BUILD_TYPE=Release -DCMAKE_RELEASE_POSTFIX="_my_release_version_of_this_library" and also, of course, the case that interests you -DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX="d" Please try the following change on line 176 of drivers/CMakeList.txt where CMake does the necessary concatanation: - "${WRITEABLE_TARGET}" ${SOURCE_ROOT_NAME} + "${WRITEABLE_TARGET}" ${SOURCE_ROOT_NAME}"${CMAKE_${CMAKE_BUILD_TYPE}_POSTFIX}" If that works for the two CMAKE_BUILD_TYPES and corresponding CMAKE...POSTFIX variables above, please go ahead and commit that change. Alan __________________________ Alan W. Irwin 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.org); 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: Phil R. <p.d...@gm...> - 2019-09-12 16:59:19
|
Hi Alan I think I have found a problem with test-drv-info. I think it is unaware of the CMake flag CMAKE_DEBUG_POSTFIX. I've started using -DCMAKE_DEBUG_POSTFIX=d as part of my cmake commands to add d to the end of all debug libraries. But this causes test-drv-info to report: Could not open the driver module <module> If I go onto the command line ant try running test-drv-info myself, adding d to the module name, I get Could not read symbol plD_DEVICE_INFO_<module>d in driver module <module>d Is it possible to pull the postfix into the test-drv-info source? It would simply need concatenating at line 76 of test-drv-info.c Phil |
From: Alan W. I. <Ala...@gm...> - 2019-09-12 15:49:20
|
On 2019-09-11 21:41-0400 Jim Dishaw wrote: > > >> On Sep 11, 2019, at 9:30 PM, Alan W. Irwin <Ala...@gm...> wrote: >> >> Hi Jim: >> >> My understanding is plbuf supports unicode-aware system fonts. But >> my recent test (for details of the test, see the commit message for the commit git-decribed >> as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes >> plbuf information to a file) and plrender (which I presume reads that information) is >> still using Hershey fonts! >> >> Could you please figure out a fix for this issue? >> > I’ll take a look at it this weekend. I think the font support may need to be cleaned up because there is a lot of duplicated code. Thanks for being willing to try to fix this and good luck with that effort! Alan __________________________ Alan W. Irwin 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.org); 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: Jim D. <ji...@di...> - 2019-09-12 02:01:13
|
> On Sep 11, 2019, at 9:30 PM, Alan W. Irwin <Ala...@gm...> wrote: > > Hi Jim: > > My understanding is plbuf supports unicode-aware system fonts. But > my recent test (for details of the test, see the commit message for the commit git-decribed > as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes > plbuf information to a file) and plrender (which I presume reads that information) is > still using Hershey fonts! > > Could you please figure out a fix for this issue? > I’ll take a look at it this weekend. I think the font support may need to be cleaned up because there is a lot of duplicated code. |
From: Alan W. I. <Ala...@gm...> - 2019-09-12 01:30:52
|
Hi Jim: My understanding is plbuf supports unicode-aware system fonts. But my recent test (for details of the test, see the commit message for the commit git-decribed as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes plbuf information to a file) and plrender (which I presume reads that information) is still using Hershey fonts! Could you please figure out a fix for this issue? Alan __________________________ Alan W. Irwin 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.org); 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: Phil R. <p.d...@gm...> - 2019-09-09 20:49:26
|
Here are a set of instructions that seem to work for me to build a set of dlls. I created a new user on my machine and a fresh directory structure and from this clean setup I got good build results. 1. Download wxWidgets-3.0.4 to C:\test\src\ and use 7zip to extract to a folder called wxWidgets-3.0.4 C:\test\src\wxWidgets-3.0.4 now contains files called configure, .gitattributes, etc 2. Open C:\test\src\wxWidgets-3.0.4\build\msw\wx_vc12.sln, I get asked about retargetting projects. I leave everything ticked and hit OK 3. Select DLL Debug and x64 configurations. Hit f7 to build. 4. Change DLL Debug to DLL Release and keep x64. Hit f7 to build again. 5. Add C:\test\bin;C:\test\src\wxWidgets-3.0.4\lib\vc_x64_dll; to the path variable. 6. Create a variable WXWIN with a value of C:\test\src\wxWidgets-3.0.4\ 7. Download plplot-5.15.0 to C:\test\src\ and use 7zip to extract to a folder called plplot-5.15.0. The folder C:\test\src\plplot-5.15.0 now contains the ABOUT and INSTALL files etc. 8. Start a developer command prompt for VS 2017 and execute these commands (if you started this already, close it and reopen to see the new environment variables) cd C:\test\src\plplot-5.15.0 mkdir build cd build set CXXFLAGS=/DUNICODE /D_UNICODE set CFLAGS=/DUNICODE /D_UNICODE cmake .. -G "Visual Studio 15 2017 Win64" -DCMAKE_DINSTALL_PREFIX="C:\test" -DCMAKE_DEBUG_POSTFIX=d NOTE THE DEBUG POSTFIX IS TO ENABLE RELEASE AND DEBUG LIBS TO INHABIT THE SAME DIRECTORY AS IT ADD d TO THE FILENAMES 9. Open the file C:\test\src\plplot-5.15.0\build\plplot.sln 10. Ensure Dubug and x64 configuration are selected. Right click the INSTALL project and select build. 11. Change to Release, sticking with x64 configuration. Right click the INSTALL project and select build. I have never built the examples in the share/plplot/examples directory. But Let me know how you get on with this setup. Phil On Mon, 9 Sep 2019 at 20:38, David Bergman <stu...@gm...> wrote: > No it is not. > > > On 9/9/2019 3:33 PM, Phil Rosenberg wrote: > > Is the directory containing your old dlls listed in your path variable. If > so, the old ones can be found by mistake and erroneously used. > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------ > *From:* stuntguitar1969 <stu...@gm...> > <stu...@gm...> > *Sent:* Monday, September 9, 2019 7:37:47 PM > *To:* Phil Rosenberg <p.d...@gm...> <p.d...@gm...>; > plp...@li... > <plp...@li...> > <plp...@li...> > *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved > external > > I will double check everything. Past issues in the thread have resolved > by rebuilding and making sure x64 is chosen everywhere. I cannot rule out > that something might be 32 bit but I tried to be thorough in the last build > and install of everything. I do have my old libs and dlls but they are in > a different dir which is not used in the project. I'll try the example > again just to be sure. > > > > Sent from my Verizon, Samsung Galaxy smartphone > > -------- Original message -------- > From: Phil Rosenberg <p.d...@gm...> <p.d...@gm...> > Date: 9/9/19 2:20 PM (GMT-05:00) > To: plp...@li..., David Bergman > <stu...@gm...> <stu...@gm...> > Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved > external > > Corrupt file error sounds like you are mixing 64 and 32 bit exes and dlls. > I think I've had that error with some libraries before and found that was > my mistake. > > Is your install bin directory on your path? Do you have any old dlls > somewhere that might be on your path? > > I usually use static libs. I used a dll version of wxwidgets about 6 > months ago, so I know things worked back then. But I'm back to using static > libs again. I will build a dll version of plplot this evening and send you > exactly the commands I used. > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------ > *From:* David Bergman <stu...@gm...> > <stu...@gm...> > *Sent:* Monday, September 9, 2019 6:31:00 PM > *To:* Phil Rosenberg <p.d...@gm...> <p.d...@gm...>; > plp...@li... > <plp...@li...> > <plp...@li...> > *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved > external > > > Phil, > > I've gotten a little further. I tried to run one of the examples building > a VS project and sln. Making sure everything was aligned w/r to he choice > x64 I got a corrupted file error. > > Error LNK1107 invalid or corrupt file: cannot read at 0x310 > plplotExamples C:\build-plplot-new-man\dll\csirocsa.dll 1 > > I am not sure what to do. Looking through some of the old blog posts of > the issues I had last year it seems that is was also an issue then. > > When you do your build were you able to get everything using the sln or > did you have to install at the command prompt too. That rings a bell and I > think I wound up using nmake. > > Can you confirm your build/install procedure and perhaps shed some light > on why csirocsa.dll would be corrupted? > > Thank you for your help. > > David > > > > On 9/7/2019 3:34 AM, Phil Rosenberg wrote: > > Hi David > Sounds like either one of the libs has been forgotten, or you are building > a 32bit exe and trying to link to the 64 bit libs you just built. > > Might be worth noting that I think the naming convention of the libs > changed at some point. They used to have a d suffix to indicate using > double precision. This has been dropped I think. So you might need to > update the lib names in your project. > > Phil > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------ > *From:* David Bergman <stu...@gm...> > <stu...@gm...> > *Sent:* Friday, September 6, 2019 9:20:57 PM > *To:* Phil Rosenberg <p.d...@gm...> <p.d...@gm...>; > plp...@li... > <plp...@li...> > <plp...@li...> > *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved > external > > > Phil, > > As per our last correspondence I had succeeded in getting the widgets > headers and drivers built when I changed from Win64 to no Win64. But I > still got an install error in the IDE (sent in a previous email). You had > suggested that perhaps I didn't build widgets using 64bit so I decided to > purge everything and start over. I built the widgets files using their sln > with x64 set. Then built plplot with cmake no problem and widgets was > declared ON as expected. Using the IDE and the sln to INSTALL led to > hanging and errors three times in a row. After the 3rd time I just looked > in the folders and figured if I can find everything I might be okay. My > recollection is that this happened last time too (back in 2017). > > The example I was trying to run was a simple one of my own that plotted > various 3-dim mesh surfaces. > > I did not try to build the official plplot examples yet. Perhaps I should > try that first. > > I don't know if what I've written is helpful in helping you help me get it > working. > > David > > > > On 9/6/2019 3:44 PM, Phil Rosenberg wrote: > > > Is this building the examples? Sounds like the libs are not being linked > to properly. > > Did you get past the wxwidgets problem? > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------ > *From:* David Bergman <stu...@gm...> > <stu...@gm...> > *Sent:* Friday, September 6, 2019 6:17:59 PM > *To:* plp...@li... > <plp...@li...> > <plp...@li...> > *Subject:* [Plplot-general] Problem with LNK2019 error unresolved external > > All, > > I have made some progress with building and installing the new plplot > with a new wxwidets using VS 2017. > > I still have not gone past the install process in the IDE w/o an error > but I seem to have all the headers and dll I need (though I'm not sure > if they are corrupted). > > At present I've decided to move forward with what I have and try a > simple example I wrote that worked with my previous config. > > I get unresolved externals, 14 to be exact. Basically every plplot > function I call seems to cause this. A few example are provided. > > plAlloc2dGrid > > and all the plstream functions like box3, col0, font, etc. > > Typically what I cause this it's due to a function declaration in a > class that is not defined elsewhere. > > It "seems like" my new build has the same files as the old one and the > projects are comparable (with only diffs being the location of the new > folders). > > Thanks in advance for your help. > > David > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > > -- > David Bergman > David R Bergman Music LLC > "Have Guitar Will Travel" > Morristown NJ > 551...@gm... > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> > > -- > David Bergman > David R Bergman Music LLC > "Have Guitar Will Travel" > Morristown NJ > 551...@gm... > > -- > David Bergman > David R Bergman Music LLC > "Have Guitar Will Travel" > Morristown NJ > 551...@gm... > > |
From: Alan W. I. <Ala...@gm...> - 2019-09-07 09:52:22
|
On 2019-09-07 16:46+0930 Jonathan Woithe wrote: > Hi Alan > > On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote: >> As someone here with a large familiarity with Qt, I would appreciate >> you letting me know if you forsee any trouble with this overall plan >> to remove our Qt4 support. And comments on this plan from the other >> PLplot developers here are also encouraged. > > Depending on the timing between the versions which make up the plan, I > suspect this will be fine. FYI Slackware does not (yet) ship Qt5 (there are > various reasons for this, the discussion of which is outside the scope of > this thread). There is a third-party source of Qt5 for Slackware though > which users can install if they have a need for Qt5. > > Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable > under a standard Slackware installation unless the Qt5 packages from the > AlienBob repository are installed. The other option (which I'm personally > *really* hoping for) is that Qt5 ships in Slackware by that time. If this > happens, the yet to be released Slackware 15 will be the first Slackware > version to ship Qt5 as part of the distribution. > > Given the low number of users of plplot on Slackware I don't believe your > plan should be changed as a result of the above information, especially > since there is a viable workaround. I mention it only for completeness so > people are aware of the possible impact and the steps needed to circumvent > it. Hi Jonathan: Thanks for this information about the current lack of Qt5 on official Slackware. My gut feeling is Qt4 has become dated and Qt5 is its worthy successor. Therefore, I would be surprised if this lack of Qt5 on Slackware persists much longer, i.e., I think it is likely you will get your wish sooner rather than later. But if that doesn't happen for some reason, PLplot-5.18.0 would still be usable on official Slackware if a user decided not to use the workaround you mentioned above. Of course, Qt-related components of PLplot such as the devices provided by our "qt" device driver would be automatically dropped by our build system when it did not find Qt5, but other excellent choices for devices such as those provided by our "cairo" device driver would still be available (assuming our build system finds on Slackware the Pango and Cairo libraries upon which our "cairo" device driver depends). By the way, Slackware was my very first Linux distribution (in 1996 on a pentium-133). Happy days! Alan __________________________ Alan W. Irwin 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.org); 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. <Ala...@gm...> - 2019-09-07 07:23:25
|
On 2019-09-06 21:33-0400 Hazen Babcock wrote: > >> >> @Hazen: In light of the smoke binding issue we should discuss this >> still tentative roadmap further. >> >> That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed >> when we drop support for Qt4 because [smoke is not available for >> Qt5](https://news.ycombinator.com/item?id=20636312). You apparently >> implemented the PLplot smoke binding because that binding was needed >> by another independent project of yours. > > No problem, go ahead and remove the smoke bindings. Hi Hazen: Thanks for that clarification. As a result, the timing of the roadmap for removing everything to do with Qt4 (including our smoke and pyqt4 bindings) from PLplot is much more certain and now reads as follows: Revised roadmap: * PLplot-5.17.0. Officially deprecate everything in PLplot that is related to Qt4 in our release notes and also mention there the planned dropping of everything in PLplot that is related to Qt4 in PLplot-5.18.0. Despite those planned remarks in the release notes, the only change from the Qt-related build system logic for 5.16.0 that has just been committed will be a deprecation warning to the user when they specify -DPLPLOT_USE_QT5=OFF. * PLplot-5.18.0. Drop everything in PLplot that is related to Qt4. That essentially means removing all logic stanzas in our build system that are currently only exercised when -DPLPLOT_USE_QT5=OFF. The removal of our smoke binding and our pyqt4 binding (only available when -DPLPLOT_USE_QT5=OFF) will be part of this change. The result of this change should be a substantial simplification of our build system. Also, our current lack of testing of the -DPLPLOT_USE_QT5=OFF case (because I don't have time to test both -DPLPLOT_USE_QT5=ON and -DPLPLOT_USE_QT5=OFF) obviously will no longer be a concern after this change. Alan __________________________ Alan W. Irwin 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.org); 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: Jonathan W. <jw...@ju...> - 2019-09-07 07:16:35
|
Hi Alan On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote: > As someone here with a large familiarity with Qt, I would appreciate > you letting me know if you forsee any trouble with this overall plan > to remove our Qt4 support. And comments on this plan from the other > PLplot developers here are also encouraged. Depending on the timing between the versions which make up the plan, I suspect this will be fine. FYI Slackware does not (yet) ship Qt5 (there are various reasons for this, the discussion of which is outside the scope of this thread). There is a third-party source of Qt5 for Slackware though which users can install if they have a need for Qt5. Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable under a standard Slackware installation unless the Qt5 packages from the AlienBob repository are installed. The other option (which I'm personally *really* hoping for) is that Qt5 ships in Slackware by that time. If this happens, the yet to be released Slackware 15 will be the first Slackware version to ship Qt5 as part of the distribution. Given the low number of users of plplot on Slackware I don't believe your plan should be changed as a result of the above information, especially since there is a viable workaround. I mention it only for completeness so people are aware of the possible impact and the steps needed to circumvent it. Regards jonathan |
From: Hazen B. <hba...@ma...> - 2019-09-07 01:34:13
|
> > @Hazen: In light of the smoke binding issue we should discuss this > still tentative roadmap further. > > That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed > when we drop support for Qt4 because [smoke is not available for > Qt5](https://news.ycombinator.com/item?id=20636312). You apparently > implemented the PLplot smoke binding because that binding was needed > by another independent project of yours. No problem, go ahead and remove the smoke bindings. -Hazen |
From: Alan W. I. <Ala...@gm...> - 2019-09-06 23:56:40
|
On 2019-09-02 13:36-0700 Alan W. Irwin wrote: > Hi António: > > Your fix of the serious Qt5 font configuration bug for PLplot made our > Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results > for the first time ever. So ever since that release it has been on my > mind to greatly reduce the complexity of our build-system *and* > testing of our Qt and PyQt components by only supporting Qt5 (i.e., > dropping our support for Qt4). > > The current build-system situation is Qt4 is looked for first, but if > it is not found Qt5 is used as a backup with the exception that Qt5 is > forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to > OFF). So my proposed plan to reach the above goal with minimum > disruption for users is the following: > > * PLplot-5.16.0. Use the exact same build system logic except that 4 > and 5 are swapped. That is Qt5 is looked for first, but if it is > not found Qt4 is used as a backup with the exception that Qt4 is > forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to > OFF). Warn in the release notes of this change and the > corresponding replacement of the PLPLOT_USE_QT5 option with > PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4 > support in the next release and remove it in the next release > after that. > To Hazen and António: @António: Thanks for your support (in a different post) for my preliminary roadmap for dropping Qt4. @Both: In the event, the above "5.16.0" step was much easier than the intrusive change I described above. Instead, all I essentially did was to change the default value for PLPLOT_USE_QT5 from OFF to ON. (See the Qt-related change in the new (commit 24d0bdf70) version of README.release for the details.) Revised rest of the roadmap. * PLplot-5.17.0. Officially deprecate Qt4 in the release notes and also say we intend to drop it for 5.18.0 there. The only change from the above build system logic is an additional deprecation warning to the user when they specify -DPLPLOT_USE_QT5=OFF and no fall back to Qt5 if Qt4 cannot be found. * PLplot-5.18.0 (or whenever we decide to pull the plug on Qt4 support considering the smoke issue below). Completely remove support for Qt4 (which will finally achieve the desired build-system and test simplifications which is the fundamental motivation for this change). @Hazen: In light of the smoke binding issue we should discuss this still tentative roadmap further. That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed when we drop support for Qt4 because [smoke is not available for Qt5](https://news.ycombinator.com/item?id=20636312). You apparently implemented the PLplot smoke binding because that binding was needed by another independent project of yours. Assuming you do want to develop a Qt5-based binding which would satisfy the needs of your independent project in the same way the your current Smoke Qt4-based binding does, from the "history lesson" in the above URL it appears one possible way forward for Qt5 bindings of any kind is [Shiboken](https://wiki.qt.io/Qt_for_Python/Shiboken). For example, Shiboken is used to implement pyside2 (python binding for Qt5), but I have no clue how difficult it would be for you to replace your smoke binding with a corresponding Shiboken binding. Anyhow, please let me know whether you plan to replace the above smoke binding once it is removed as part of dropping our Qt4 support. And your input on the timing of dropping our Qt4 support is needed as well. By the way, when that support is dropped our pyqt4 binding will have to be removed as well, but that should not be an issue at least for now since our current pyqt5 binding seems to work OK. But that pyqt5 binding does depend on the external pyqt5 project which depends on another external project (sip). So our pyqt5 binding will become vulnerable if either the external projects pyqt5 or sip becomes unmaintained. The above pyside2 project is a recent competitor to pyqt5. And contrary to the expectations of the above 2017 discussion, pyside2 has been released and is apparently going strong. (For example, Debian Buster has many pyside2 packages and the necessary shiboken packages to support pyside2.) Therefore, if you were interested, I would encourage you to implement a pyside2 binding and pyside2_example corresponding to pyqt5_example just in case it turns out that external pyqt5 of sip ever goes the same way that smoke has gone. Alan __________________________ Alan W. Irwin 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.org); 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...> - 2019-09-03 07:37:53
|
Hi Alan, I have the first results from this exercise. I will send the details in an off-list message, but the short story is that CMake seems to choke on generating the makefiles when support for D is included. From my inspection of the output files the reason for the failure is not at all clear. The D bindings are turned on but then CMake tells me something went wrong during the last stage, writing the actual makefiles. Regards, Arjen -----Original Message----- From: Alan W. Irwin <Ala...@gm...> Sent: 02 September 2019 12:27 To: Arjen Markus <Arj...@de...> Cc: Takeshi Enomoto <ten...@us...>; PLplot development list <Plp...@li...> Subject: RE: [Plplot-devel] D language support topic On 2019-09-02 07:47-0000 Arjen Markus wrote: > Hi Alan, > > I will have a look at this - I have built CMake before, that should not be a problem 😊. I have no experience, however, with the D compiler you mention. Hi Arjen: Thanks for your willingness to do the requested test_d tests on MSYS2 with dmd. The results of those tests should help me to get our CMake D language support working correctly for the Windows-dmd case for both test_d and PLplot. Alan > > -----Original Message----- > From: Alan W. Irwin <Ala...@gm...> > Sent: 01 September 2019 01:40 > To: Takeshi Enomoto <ten...@us...>; Arjen Markus > <Arj...@de...>; PLplot development list > <Plp...@li...> > Subject: Re: [Plplot-devel] D language support topic > > To Takeshi and Arjen: > > I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this > topic to the PLplot master branch at SourceForge. This new D language > support (see README.release for details) works perfectly on Linux (all > comprehensive tests have passed perfectly on my Debian Buster > platform), and I hope Takeshi (who contributed part of the changes > that have gone into this push) would be willing to test this new D > language support for PLplot on the MacPorts platform and Arjen on the > MSYS2 platform. > > @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts. > But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly. > > @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.html&data=02%7C01%7C%7C109db2fc5d8c42715d0308d72f90094d%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637030167988327359&sdata=ZWqaEu0F4OLFU0m6yjhdjTn%2FuyI3KvPd1WUdGKGGdaI%3D&reserved=0). > I would appreciate you testing our new D language support on MSYS2 with that compiler. > As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself. > > Alan > __________________________ > Alan W. Irwin > > 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.org); 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 > __________________________ > 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. > __________________________ Alan W. Irwin 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.org); 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 __________________________ 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: António R. T. <ar...@gm...> - 2019-09-02 20:53:12
|
Hi Allan, I really think that is safe to remove qt4 support. Sooner or later qt4 will not be available by default in a normal linux distribution. So I agree with your proposed roadmap. cheers, On Mon, Sep 2, 2019 at 9:36 PM Alan W. Irwin <Ala...@gm...> wrote: > Hi António: > > Your fix of the serious Qt5 font configuration bug for PLplot made our > Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results > for the first time ever. So ever since that release it has been on my > mind to greatly reduce the complexity of our build-system *and* > testing of our Qt and PyQt components by only supporting Qt5 (i.e., > dropping our support for Qt4). > > The current build-system situation is Qt4 is looked for first, but if > it is not found Qt5 is used as a backup with the exception that Qt5 is > forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to > OFF). So my proposed plan to reach the above goal with minimum > disruption for users is the following: > > * PLplot-5.16.0. Use the exact same build system logic except that 4 > and 5 are swapped. That is Qt5 is looked for first, but if it is > not found Qt4 is used as a backup with the exception that Qt4 is > forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to > OFF). Warn in the release notes of this change and the > corresponding replacement of the PLPLOT_USE_QT5 option with > PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4 > support in the next release and remove it in the next release > after that. > > * PLplot-5.17.0. Deprecate Qt4, i.e., use it as a fall back from > Qt5 *only* if the users sets -DPLPLOT_QT4=ON. Warn in the release > notes of > this change and also warn we plan to remove support for Qt4 in > the next release. > > * PLplot-5.18.0. Completely remove support for Qt4 which will finally > achieve the > desired simplifications mentioned above. > > As someone here with a large familiarity with Qt, I would appreciate > you letting me know if you forsee any trouble with this overall plan > to remove our Qt4 support. And comments on this plan from the other > PLplot developers here are also encouraged. > > I will likely implement the 5.16.0 part of the above plan late this > week if there are no strong disagreements expressed here in the > next several days. > > Alan > __________________________ > Alan W. Irwin > > 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.org); 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 > __________________________ > -- António Rodrigues Tomé Universidade da Beira Interior Instituto D. Luís (lab associado) email address: ar...@gm... ar...@ub... http://www.researcherid.com/rid/A-5681-2013 |
From: Alan W. I. <Ala...@gm...> - 2019-09-02 20:36:43
|
Hi António: Your fix of the serious Qt5 font configuration bug for PLplot made our Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results for the first time ever. So ever since that release it has been on my mind to greatly reduce the complexity of our build-system *and* testing of our Qt and PyQt components by only supporting Qt5 (i.e., dropping our support for Qt4). The current build-system situation is Qt4 is looked for first, but if it is not found Qt5 is used as a backup with the exception that Qt5 is forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to OFF). So my proposed plan to reach the above goal with minimum disruption for users is the following: * PLplot-5.16.0. Use the exact same build system logic except that 4 and 5 are swapped. That is Qt5 is looked for first, but if it is not found Qt4 is used as a backup with the exception that Qt4 is forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to OFF). Warn in the release notes of this change and the corresponding replacement of the PLPLOT_USE_QT5 option with PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4 support in the next release and remove it in the next release after that. * PLplot-5.17.0. Deprecate Qt4, i.e., use it as a fall back from Qt5 *only* if the users sets -DPLPLOT_QT4=ON. Warn in the release notes of this change and also warn we plan to remove support for Qt4 in the next release. * PLplot-5.18.0. Completely remove support for Qt4 which will finally achieve the desired simplifications mentioned above. As someone here with a large familiarity with Qt, I would appreciate you letting me know if you forsee any trouble with this overall plan to remove our Qt4 support. And comments on this plan from the other PLplot developers here are also encouraged. I will likely implement the 5.16.0 part of the above plan late this week if there are no strong disagreements expressed here in the next several days. Alan __________________________ Alan W. Irwin 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.org); 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...> - 2019-09-02 12:20:06
|
Hi Alan, I will have a look at this - I have built CMake before, that should not be a problem 😊. I have no experience, however, with the D compiler you mention. Regards, Arjen -----Original Message----- From: Alan W. Irwin <Ala...@gm...> Sent: 01 September 2019 01:40 To: Takeshi Enomoto <ten...@us...>; Arjen Markus <Arj...@de...>; PLplot development list <Plp...@li...> Subject: Re: [Plplot-devel] D language support topic To Takeshi and Arjen: I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge. This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the MSYS2 platform. @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts. But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly. @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.html&data=02%7C01%7C%7Ca962fd3984664e88519308d72e6c7d4b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637028915813958706&sdata=Q5GbOISrDsA%2Fyxn16s2s4FeEor02in2aGUIFKRSkRLA%3D&reserved=0). I would appreciate you testing our new D language support on MSYS2 with that compiler. As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself. Alan __________________________ Alan W. Irwin 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.org); 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 __________________________ 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. <Ala...@gm...> - 2019-09-02 10:26:46
|
On 2019-09-02 07:47-0000 Arjen Markus wrote: > Hi Alan, > > I will have a look at this - I have built CMake before, that should not be a problem 😊. I have no experience, however, with the D compiler you mention. Hi Arjen: Thanks for your willingness to do the requested test_d tests on MSYS2 with dmd. The results of those tests should help me to get our CMake D language support working correctly for the Windows-dmd case for both test_d and PLplot. Alan > > -----Original Message----- > From: Alan W. Irwin <Ala...@gm...> > Sent: 01 September 2019 01:40 > To: Takeshi Enomoto <ten...@us...>; Arjen Markus <Arj...@de...>; PLplot development list <Plp...@li...> > Subject: Re: [Plplot-devel] D language support topic > > To Takeshi and Arjen: > > I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge. This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the > MSYS2 platform. > > @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts. > But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly. > > @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.html&data=02%7C01%7C%7Ca962fd3984664e88519308d72e6c7d4b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637028915813958706&sdata=Q5GbOISrDsA%2Fyxn16s2s4FeEor02in2aGUIFKRSkRLA%3D&reserved=0). > I would appreciate you testing our new D language support on MSYS2 with that compiler. > As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself. > > Alan > __________________________ > Alan W. Irwin > > 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.org); 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 > __________________________ > 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. > __________________________ Alan W. Irwin 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.org); 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: Takeshi E. <ta...@ma...> - 2019-09-01 07:07:35
|
Dear Alan, Thank you for you message. I confirmed that all the updated D examples are built successfully including x16d with current plplot-5.15.0 +dmd variant. I will wait for the update (increment of the version number) to test with the MacPorts build system. Note that among D compilers, dmd has the better support in MacPorts. gdc is outdated and doesn't work well with plplot. gcc9 does not yet provide gdc. Nobody is interested in maintaining ldc port yet. Regards, Takeshi |
From: Alan W. I. <Ala...@gm...> - 2019-08-31 23:39:45
|
To Takeshi and Arjen: I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge. This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the MSYS2 platform. @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts. But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly. @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://dlang.org/download.html). I would appreciate you testing our new D language support on MSYS2 with that compiler. As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself. Alan __________________________ Alan W. Irwin 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.org); 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. <Ala...@gm...> - 2019-08-28 21:59:40
|
This topic is being rapidly matured. The current status for the remaining work to be done is as follows: * Implement a simple standalone "test_d" project (in cmake/test_d) which is designed to allow rapid testing of D language support (that has been updated from the cmake-d project) for all available D compilers on all platforms with a simplified (compared to the PLplot project) comprehensive test script. This work is almost completed. For example, the simplified test script for test_d gives perfect results on my Debian Buster=Stable platform for gdc, ldc, and dmd. However, there is a bit more to do to finish the work on this test_d project. * Replace our ancient fork of CMakeD with a modern fork of cmake-d. This work is almost completed. * Fix any issues for our traditional (Makefile + pkg-config) build of the installed examples for both dmd and ldc without compromising the good gdc results we currently have for that particular build system. Once this is done the comprehensive test of the PLplot project itself (which includes tests of this traditional build system) should work properly for all three D compilers for the first time ever. An important caveat for the above good CMake language support results for ldc and dmd is those depend on a small fix to CMake general language support which I have applied to my own locally built version of CMake. Brad King is currently shepherding this fix through the [mostly automatic process](https://gitlab.kitware.com/cmake/cmake/merge_requests/3747) to make this fix part of a future CMake release. The current estimate is this fix should get into the CMake-3.16.0 release (likely due out in November), but [see this discussion](https://gitlab.kitware.com/cmake/cmake/issues/19631), this CMake fix is also available right now as a [simple patch that should apply to any recent version of CMake source code](https://gitlab.kitware.com/cmake/cmake/uploads/92e4545dc691a0760a52656acaea9607/0001-linking-Support-language-specific-variants-of-CMAKE_.patch.gz). In sum, in comparison to my last status report for this topic, I am much closer to reaching the goal that comprehensive testing for both test_d and PLplot itself is working correctly on Debian Buster for all three D compilers. More later.... Alan __________________________ Alan W. Irwin 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.org); 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. <Ala...@gm...> - 2019-08-17 17:49:24
|
On 2019-08-14 18:29-0700 Alan W. Irwin wrote: > So replacing our ancient fork of CMakeD with a modern fork of cmake-d > currently looks like the proper way forward. However, before implementing > that I need to do more comparisons between the two CMake D language > support projects for dmd, and assuming I can get dmd to work correctly > for our needs for cmake-d using modest changes to cmake-d, I also need > to try out ldc (not available for our ancient fork of CMakeD) using > cmake-d. The current status is I am making good progress with bug fixes for the cmake-d D language support so that it works for our needs. So for example, I have gotten dmd to work well enough for our CMake-based core build of the D binding and examples on Debian Buster (for a dmd compiler I built for myself since Debian does not package that compiler) that I was able to build the D binding and compile (but not yet link because of at least one remaining issue with cmake-d) all the (updated) D examples with dmd. The results of that dmd compilation of the examples confirmed all of the example fixes (other than x16d.d) that Takeshi Enomoto donated via our patch tracker, and I was also able to solve the remaining dmd compilation errors (which occurred only for x16d.d). My plan for maturing this topic before I push it to master includes the following general steps: * Fix the remaining cmake-d issues for the dmd compiler (as far as I know there is only one such issue left which is the current bad linking of the D examples). And confirm this cmake-d change does not compromise the current good cmake-d results with the gdc compiler. * Fix any cmake-d issues with the ldc compiler without compromising the good gdc results and the (now) good dmd results. * Fix any issues for our traditional (Makefile + pkg-config) build of the installed examples for both dmd and ldc without compromising the good gdc results we currently have for that particular build system. * Replace our ancient fork of CMakeD with a modern fork of cmake-d. In other words, all the above steps will be done with external (patched) cmake-d, and this step will integrate that patched version into PLplot source code for the convenience of our users. The test of whether this topic has truly been matured will continue to be our comprehensive test script (which tests our three build systems for all our library and device variants) should produce perfect results for D for each D compiler (gdc, dmd, and ldc). More later.... Alan __________________________ Alan W. Irwin 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.org); 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. <Ala...@gm...> - 2019-08-15 01:29:48
|
Some essential background information for this post is "D" is an interesting and distinct computer language that is a re-engineered version of C++. Presumably because of all the programmer interest in "D", there are three well-known D compilers with free software licenses. They are 1. dmd (the fundamental D compiler from "Digital Mars" which effectively sets the D syntax standards); 2. ldc (a D compiler with dmd front-end [the part of the compiler that transforms D syntax to a language-independent intermediate representation] and LLVM back-end); and 3. gdc (the GNU-implemented D compiler which has its own unique front-end and gcc backend). My own Debian Buster platform gives me access to official ldc and gdc packages, and I have built a working dmd on that platform from the Digital Mars source code for that compiler. So I think with some work all developers here with access to Unix platforms and an interest in "D" should be able to gain access to all three compilers. The D compiler choice is more limited on Windows. For example, there are no official packages for ldc and gdc on Cygwin or MSYS2 so I suspect both compilers would need a lot of work before they worked on Windows. However, dmd is apparently available for all Windows platforms as a free download from Digital Mars so developers here who are limited to just Windows platforms can still try out our D binding and examples once I make dmd one of the compilers that are correctly supported for the PLplot needs by our CMake D language support logic. I started this development topic a few days ago in response to <https://sourceforge.net/p/plplot/patches/35/> where the poster's commentary indicated the installed D examples would not traditionally compile with dmd, and his substantial patch to the source code for the D examples fixed all such issues except for x16d (where his issue for that example may have been due to the differences between the gdc-built plplotdmd library that was presumably installed and the dmd-built examples). I have since been able to update our D examples (on a private topic branch which I plan to push in due course) with that patch and show that gdc D compiler was able to compile and run those updated examples without run-time or diff-report issues in our build tree. So that (examples that now work locally for me with gdc and externally for someone else with dmd) is a promising start to this topic, but to finish it I want to generalize our CMake D language support logic and overall logic so that the ldc and dmd D compilers work as well for me as the gdc compiler currently does for our 3 different D builds (the CMake-based build of our D binding and examples, the CMake-based build of our installed D examples that are linked to our installed D binding, and the traditional (Makefile + pkg-config) build of our installed D examples that are linked to our installed D binding). Our current CMake D language support (located in cmake/modules/language_support/cmake) was forked by Werner Smekal from the (now defunct) CMakeD project in 2009. My comprehensive tests show our fork does support gdc well on Linux (except for some known limitations such as being forced to use a static version of the plplotdmd library). Our fork does have dmd support which might have been tested by Werner in 2009, but I don't think anyone has tested it since with dmd. Our fork has no support for ldc. Our changes to the 2009 version of CMakeD have been fairly small but significant, but since then there have been other more substantial changes and forks of that project culminating with the cmake-d project at <https://github.com/dcarp/cmake-d> which continues to be actively developed. Note that project advertises that it supports all three of dmd, ldc, and gdc. That ldc support is just not available with our fork of CMakeD, and I think it is quite likely (modulo a few modest changes like the rpath one below) that cmake-d has better support for dmd than our fork. So I tried gdc with cmake-d language support (accessed externally), and I ran into an rpath issue which should easily be fixed (since our fork of CMakeD does handle rpath well) but which I temporarily worked around with LD_LIBRARY_PATH. They results of that experiment were perfect (no run-time or diff report issues with the updated D examples). So replacing our ancient fork of CMakeD with a modern fork of cmake-d currently looks like the proper way forward. However, before implementing that I need to do more comparisons between the two CMake D language support projects for dmd, and assuming I can get dmd to work correctly for our needs for cmake-d using modest changes to cmake-d, I also need to try out lcd (not available for our ancient fork of CMakeD) using cmake-d. More later. Alan __________________________ Alan W. Irwin 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.org); 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. <Ala...@gm...> - 2019-08-09 08:45:59
|
On 2019-08-06 13:18+0100 Phil Rosenberg wrote: > Sorry, my last email wasn't sent to the list - see below. > > I think I have found the solution, by changing the shebang to python2 > rather than python. > > I'm going to commit this change as it is a change that only affects us > developers. Alan - if you could test to check it works on your linux > system, that would be great. Hi Phil: Sorry for my own delay in answering you which was caused by gmail troubles (started by a bad recovery) that has finally been straightened out yesterday (Thursday) after 5 days of no gmail access for me. Glad you found a solution for the scripts/convert_comment.py issue. That's a good solution in the short term but unfortunately not in the long term. The problem is Python2 is near its end of life (see, for example, the discussion in <https://lwn.net/Articles/756628/>). And in any case very likely due to anticipation by Python developers of that end of life, my experience is Python2 is buggy and not as well supported as Python3. So in any case I planned to deprecate the PLplot Python2 support soon and remove it completely fairly soon after. So I will need to generalize your above solution for the Python3 case. [The essential documentation for this general solution](https://portingguide.readthedocs.io/en/latest/exceptions.html) shows there are both "except" and "raise" differences in Python2 versus Python3 syntax for handling exceptions. Furthermore, there are a number of different places in our Python code where we use "except" and "raise", and apparently they are all currently implemented in Python2 syntax (as you discovered for the case of the raise command in scripts/convert_comment.py). My plan for dealing with this issue is to change all "except" and "raise" Python commands to Python3 syntax only (this will include scripts/convert_comment.py and therefore changing your shebang from python2 to python3 and testing that change works here under python3) and deprecation of Python2 (meaning users will have to go out of their way to specify -DPL_DEPRECATED_PYTHON=ON in order to still access Python2). This planned deprecation in the current release cycle should propagate to the forthcoming 5.16.0 release, and the further plan is to remove Python2 completely early in the next release cycle that will lead to 5.17.0. If you or anyone else here has concerns about any aspect of the above general plans (but especially the timing of the Python2 deprecation and/or removal), please let me know soon. Alan > > On Tue, 6 Aug 2019 at 12:50, Phil Rosenberg <p.d...@gm...> wrote: >> >> Hi Alan >> The error message I gave is the complete error message, there is no >> output of the line variable. This, combined with the fact that the >> carat is pointing to the end of the line of python code, made me think >> this was a syntax error in the python code itself. >> >> When I opened convert_comment.py in visual studio, the error >> highlighting underlined all instances of raise RuntimeError. Hovering >> the mouse over displayed the following error >> >> invalid syntax, only exception value is allowed in 3.x >> >> Googling this error lead me to >> https://stackoverflow.com/questions/34463087/valid-syntax-in-both-python-2-x-and-3-x-for-raising-exception >> >> So I think, basically the syntax for raise has changed between 2.x and >> 3.x and for whatever reason, on my system the script is being executed >> using 3.x >> >> Any fix suggestions? I don't really know python at all. >> >> Phil >> >> On Wed, 31 Jul 2019 at 19:49, Alan W. Irwin <Ala...@gm...> wrote: >>> >>> On 2019-07-31 12:44+0100 Phil Rosenberg wrote: >>> >>>> Thanks Alan >>>> I've just tried again with the style_source script, but I'm hitting >>>> another problem. I now get the error: >>>> >>>> File "scripts/convert_comment.py", line 72 >>>> raise RuntimeError, "Cannot interpret trailing character(s) after >>>> */ for this line" >>>> ^ >>>> SyntaxError: invalid syntax >>>> ERROR: scripts/convert_comment.py failed for file plplot_config.h.in >>>> >>>> >>>> Any suggestions? I have both python 2 and 3 installed. >>> >>> That error message comes from this logic in scripts/convert_comment.py >>> which hasn't been changed (from git blame -w) since 2010. >>> >>> # Note trailing "\n" has not (yet) been removed from line so >>> # that the next to last character is at position len(line) - 3. >>> if end_comment >=0 and end_comment != len(line) - 3: >>> if ifsingleline and start_comment >=0: >>> # Skip most further processing for a line with embedded >>> # comments outside of multiline blocks of comments. >>> start_comment = -1 >>> end_comment = -1 >>> else: >>> sys.stderr.write(line) >>> raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line" >>> >>> So that error message should have included the results from sys.stderr.write(line) >>> from the line in plplot_config.h.in that is stored in the Python "line" variable >>> that appears to be causing this python logic problem. >>> >>> The usual interpretation of this error message is you have commentary >>> in plplot_config.h.in which is not in legitimate form. For example, >>> you might have forgotten the trailing "*/" on a comment. So I would >>> test that possibility by attempting to build the plplot target before >>> styling, which would necessarily attempt to compile the configured >>> plplot_config.h. >>> >>> However, if that "easy" answer is not the correct one, please send the >>> complete error message including the output of the Python "line" variable >>> that is causing the issue. >>> >>> Of course, the above Python logic only works if there are no >>> line-ending issues in Python, i.e., the Python "line" variable >>> contains a string that is terminated simply by \n rather than >>> \r\n. And note that by git default plplot_config.h.in will have \r\n >>> line endings on MSYS2. But the discussion in >>> <https://stackoverflow.com/questions/10785131/line-endings-in-python> >>> seems to imply that on Python automatically converts all \r and \r\n >>> line endings for text files to \n. Also, my impression is you have >>> exercised the above scripts/convert_comment.py logic from 2010 with no >>> issues in the past on Cygwin (where again, the checked out >>> plplot_config.h.in should have \r\n line endings.) So I would only >>> look at this potential line ending issue (by dumping out each raw byte >>> of the above line) only as a last resort (i.e., only if the line that >>> is causing this error compiles with no issues). >>> >>> Alan >>> __________________________ >>> Alan W. Irwin >>> >>> 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.org); 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 >>> __________________________ > __________________________ Alan W. Irwin 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.org); 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: Phil R. <p.d...@gm...> - 2019-08-06 12:18:39
|
Sorry, my last email wasn't sent to the list - see below. I think I have found the solution, by changing the shebang to python2 rather than python. I'm going to commit this change as it is a change that only affects us developers. Alan - if you could test to check it works on your linux system, that would be great. On Tue, 6 Aug 2019 at 12:50, Phil Rosenberg <p.d...@gm...> wrote: > > Hi Alan > The error message I gave is the complete error message, there is no > output of the line variable. This, combined with the fact that the > carat is pointing to the end of the line of python code, made me think > this was a syntax error in the python code itself. > > When I opened convert_comment.py in visual studio, the error > highlighting underlined all instances of raise RuntimeError. Hovering > the mouse over displayed the following error > > invalid syntax, only exception value is allowed in 3.x > > Googling this error lead me to > https://stackoverflow.com/questions/34463087/valid-syntax-in-both-python-2-x-and-3-x-for-raising-exception > > So I think, basically the syntax for raise has changed between 2.x and > 3.x and for whatever reason, on my system the script is being executed > using 3.x > > Any fix suggestions? I don't really know python at all. > > Phil > > On Wed, 31 Jul 2019 at 19:49, Alan W. Irwin <Ala...@gm...> wrote: > > > > On 2019-07-31 12:44+0100 Phil Rosenberg wrote: > > > > > Thanks Alan > > > I've just tried again with the style_source script, but I'm hitting > > > another problem. I now get the error: > > > > > > File "scripts/convert_comment.py", line 72 > > > raise RuntimeError, "Cannot interpret trailing character(s) after > > > */ for this line" > > > ^ > > > SyntaxError: invalid syntax > > > ERROR: scripts/convert_comment.py failed for file plplot_config.h.in > > > > > > > > > Any suggestions? I have both python 2 and 3 installed. > > > > That error message comes from this logic in scripts/convert_comment.py > > which hasn't been changed (from git blame -w) since 2010. > > > > # Note trailing "\n" has not (yet) been removed from line so > > # that the next to last character is at position len(line) - 3. > > if end_comment >=0 and end_comment != len(line) - 3: > > if ifsingleline and start_comment >=0: > > # Skip most further processing for a line with embedded > > # comments outside of multiline blocks of comments. > > start_comment = -1 > > end_comment = -1 > > else: > > sys.stderr.write(line) > > raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line" > > > > So that error message should have included the results from sys.stderr.write(line) > > from the line in plplot_config.h.in that is stored in the Python "line" variable > > that appears to be causing this python logic problem. > > > > The usual interpretation of this error message is you have commentary > > in plplot_config.h.in which is not in legitimate form. For example, > > you might have forgotten the trailing "*/" on a comment. So I would > > test that possibility by attempting to build the plplot target before > > styling, which would necessarily attempt to compile the configured > > plplot_config.h. > > > > However, if that "easy" answer is not the correct one, please send the > > complete error message including the output of the Python "line" variable > > that is causing the issue. > > > > Of course, the above Python logic only works if there are no > > line-ending issues in Python, i.e., the Python "line" variable > > contains a string that is terminated simply by \n rather than > > \r\n. And note that by git default plplot_config.h.in will have \r\n > > line endings on MSYS2. But the discussion in > > <https://stackoverflow.com/questions/10785131/line-endings-in-python> > > seems to imply that on Python automatically converts all \r and \r\n > > line endings for text files to \n. Also, my impression is you have > > exercised the above scripts/convert_comment.py logic from 2010 with no > > issues in the past on Cygwin (where again, the checked out > > plplot_config.h.in should have \r\n line endings.) So I would only > > look at this potential line ending issue (by dumping out each raw byte > > of the above line) only as a last resort (i.e., only if the line that > > is causing this error compiles with no issues). > > > > Alan > > __________________________ > > Alan W. Irwin > > > > 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.org); 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. <Ala...@gm...> - 2019-08-01 07:21:28
|
Hi Phil: There are a number of unresolved topics between us including getting styling and comprehensive testing to work on MSYS2 and to fix up the remaining "interactive" errors for the wxwidgets device (e.g., making examples 17 and 20 display "interactively" like they currently do for xwin). But this post is about yet another unresolved topic between us concerning the steps necessary to finish up all but the tedious final editing work (which I can take responsibility for) on your PLplot exception handling topic. If I remember the status of that topic correctly, you got your setjmp/longjmp C exception handling to work well in a proof-of-concept way with at least one public API function providing the TRY and CATCH blocks with plexit changed to throw exceptions with THROW. Assuming that summary is correct as far as it goes, can you comment on whether you handled the problem of one public API function calling one or more other public API functions? (plbox calling plaxes is a trivial example of this, but there are many more such examples.) In other words, can you propagate the exception introduced by plexit back through one or more public API calls until you reach the first public API call in the chain that has been called by an external library or app? Assuming the solution to that propagation problem is straightforward (or has been implemented already) are all the remaining steps simply editing ones, e.g., putting the appropriate TRY and CATCH blocks of code at the start of each public API function and replacing all calls to exit by calls to plexit? If so, I would be willing to do those necessary editing steps and conclude this project by merging all our combined work (in a private topic branch shared between us) to the master branch. But I don't know how much effort it will take you to get to the stage with this topic where I can take over by finishing it that way. I also don't know whether you think your work on this topic is higher or lower priority than your work on the other unresolved PLplot topics I have mentioned above. So please let me know what your PLplot priorities are so I have some idea what to expect from you by the time 5.16.0 is released (which should ideally occur before December 1st, i.e., we are already roughly one third of the way through the current release cycle). Alan __________________________ Alan W. Irwin 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.org); 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 __________________________ |