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: Alan W. I. <Ala...@gm...> - 2019-07-31 18:50:08
|
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-07-30 21:53:09
|
P.S. @Brad: I should have also mentioned that the build script does the following inside the git repository: # For rebuilds *using a separate build tree*, "git status" reveals # ninja has a build bug where re2c modifies src/lexer.cc in the source # tree. So remove this source-code change so you are guaranteed to start # with a completely fresh source tree: git checkout -- src/lexer.cc Which works around a ninja source-tree contamination bug that needs fixing. 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-07-30 21:10:34
|
To the PLplot developers and Brad King: @Brad: I am including you in this discussion because I thought you might be interested in these good PLplot results with your fork of Ninja. @Developers: Ninja should be of interest to us as a back-end for CMake because ninja works on all platforms and has a reputation for being fast because of its design philosophy (which is to execute all the low-level build system stuff as quickly as possible while leaving all the complex decision making for builds to higher-level build system software such as CMake). And Brad King's fork of ninja is of interest to us because it fixes Fortran issues with the upstream version. I. Building, testing, and installing Brad King's fork of ninja. I attach a bash script to do that. It should be run as follows: ./king_ninja_git_build.sh v1.9.0.g99df1.kitware.dyndep-1.jobserver-1 Here are the extra messages (i.e., those without leading '[') that are generated by ninja_test The last one of these should be "passed". Raise [ulimit -n] above 1025 (currently 1024) to make this test go ninja: warning: -jN forced on command line; ignoring GNU make jobserver. passed @Brad: In response to that first message I tried ulimit -n 1026 (which worked according to ulimit -a), but then after that ninja_test failed with ninja: fatal: pipe: Too many open files and the only way to fix that was to go back to "ulimit -n 1024" I don't know the significance of the second message, but I thought you should be informed of it. II. PLplot testing of Brad's fork on ninja @Everybody: This is a preliminary test of PLplot because I found that the Java, Octave, and Ada components of PLplot did not work with ninja. I need to investigate further to decide whether these issues are due to our own language-support issues for Ada, build-system issues for all three components, and/or CMake/ninja issues. But for now I shut down those components with -DENABLE_java=OFF -DENABLE_octave=OFF -DENABLE_ada=OFF and under these conditions the times required to configure PLplot with cmake were as follows: -G"Ninja" real 0m8.732s user 0m6.867s sys 0m3.156s -G"Unix Makefiles" real 0m9.730s user 0m7.781s sys 0m3.134s ==> Significant configuration time advantage for Ninja Here were the times required to build the test_noninteractive target after each of the above clean configurations: -G"Ninja" software@merlin> time env PATH=/home/software/ninja/install-v1.9.0.g99df1.kitware.dyndep-1.jobserver-1/bin:$PATH ninja -j16 test_noninteractive >& test_noninteractive.out real 1m5.298s user 7m19.614s sys 0m47.019s -G"Unix Makefiles software@merlin> time (make -j16 test_noninteractive >& test_noninteractive.out) real 1m21.388s user 7m31.672s sys 0m58.231s ==> Significant run-time advantage for Ninja In both cases the resulting test_noninteractive.out file showed no obvious run-time issues and gave a clean difference report for the default svg device, e.g., c++ Missing examples : Differing graphical output : Missing stdout : Differing stdout : d Missing examples : Differing graphical output : Missing stdout : Differing stdout : fortran Missing examples : Differing graphical output : Missing stdout : Differing stdout : lua Missing examples : Differing graphical output : Missing stdout : Differing stdout : ocaml Missing examples : Differing graphical output : Missing stdout : Differing stdout : python Missing examples : Differing graphical output : Missing stdout : Differing stdout : tcl Missing examples : Differing graphical output : Missing stdout : Differing stdout : By the way, I haven't tested this, but apparently an even more significant speed advantage for Ninja is it reduces the CMake reconfiguration time when, for example, you have edited one PLplot file and wish to reconfigure/rebuild. So for now, I would advise all those that are not interested in the Java, Octave, or Ada components of PLplot to give the Brad King fork of ninja a try. In particular since ninja has been designed from the ground up to support parallel builds while parallel builds are an add-on for the GNU-make case it is likely you should get good parallel build results for ninja on the Cygwin and MSYS2 platforms where Arjen's experience is that parallel builds are not reliable on those two platforms for GNU-make. I haven't tried upstream ninja, but since Brad's fork of that software is designed to fix fortran issues, then I assume everything that worked above except the fortran component should work well if one of you prefers to try the upstream version of ninja. 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-07-27 10:48:23
|
On 2019-07-25 16:09-0700 Alan W. Irwin wrote: > [.... C]ompletely finishing this project will take much longer > than expected because of [...] complications with styling the swig directive > (*.i) files that occur in bindings/<language> where <language> is one > of java, python, lua, or octave [....] Those complications have finally been dealt with (see commit plplot-5.15.0-13-g2ec8daf88), and, as far as I know from my successful noninteractive and interactive tests on Linux, this commit completes the work of moving from uncrustify 0.60 to 0.69.0 to style our source code. However, the source code styling changes for this topic were quite intrusive so further testing of these style changes would be a good idea for non-Linux platforms. 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-07-26 03:31:55
|
On 2019-07-25 18:30-0700 Alan W. Irwin wrote: > For those interested in building uncrustify 0.69.0 from the git tag > (which should be all developers here who would like to run the bash > script scripts/style_source.sh to style their source-code updates > before committing those changes), I have attached my newly implemented > bash script for building uncrustify. (I have recently successfully > used this script to configure, build, install, and test uncrustify > 0.69.0 for myself with complete success.) > > Note this script has a number of useful comments about how to run the > script, how to tailor it for local conditions, and the details of the > git clone command that needs to be run just once (in the same > directory where you have placed this script) to get access to the git > version of the uncrustify source code *before the first time* you run > the script. P.S. I have configured gmail to *not* filter mail with their spam filtering application, and to deliver all email (regardless of whether gmail decides it is spam or ham) to my local computer using the getmail application on that computer. That application uses procmail to actually deliver the mail to my local inbox (following the general "Unix/Linux" philosophy that applications are designed to do just one thing well, and to hand off to another well-designed application to do some other step in a chain of steps.) And because of that procmail link in my input mail chain, I can use spam_bayes to filter for spam just in one place in that chain under my sole control. And this whole system works well so that very little spam gets into my inbox, and, for example, the bash script attachment came back to me from the SF mailing list without being stripped. However, I now recall others here do not have complete control of their spam filtering so the possibility exists that such filtering will silently strip out bash script attachments. So I resend that attachment in this e-mail in gzipped form. And, of course, if you have a spam filter somewhere in your input mail chain that strips out all attachments including gzipped ones, then it is time for you to either complain to those who are doing such complete stripping and/or gain sole control of your spam filtering so you to can enjoy use of such attachments. :-) 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-07-26 01:30:52
|
For those interested in building uncrustify 0.69.0 from the git tag (which should be all developers here who would like to run the bash script scripts/style_source.sh to style their source-code updates before committing those changes), I have attached my newly implemented bash script for building uncrustify. (I have recently successfully used this script to configure, build, install, and test uncrustify 0.69.0 for myself with complete success.) Note this script has a number of useful comments about how to run the script, how to tailor it for local conditions, and the details of the git clone command that needs to be run just once (in the same directory where you have placed this script) to get access to the git version of the uncrustify source code *before the first time* you run the script. 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-07-25 23:09:47
|
On 2019-07-24 01:40-0700 Alan W. Irwin wrote: > [...]so my current ETA for the above proposed commit is > late tomorrow (Wednesday) or so. Sorry, but completely finishing this project will take much longer than expected because of a complication with align_number_left (which I have dealt with) and complications with styling the swig directive (*.i) files that occur in bindings/<language> where <language> is one of java, python, lua, or octave (which I have not been able to completely deal with yet). See the plplot-5.15.0-10-g16d554223 commit message for the details concerning these complications. (Use the --name-status option on git log to insure you get a feel for the large number of files changed in this commit.) Although that commit skips styling the swig directive files, it is otherwise complete so you should now be able to use scripts/style_source.sh without issues on MSYS2 for either version (one built from the appropriate git tag, one built from the appropriate tarball) of uncrustify-0.69.0. Therefore, please go ahead and run that script on that platform for your version (built from the tarball) of uncrustify-0.69.0, and let me know whether that script runs without issues. Also because the source code changes included in plplot-5.15.0-10-g16d554223 are so intrusive it is important to make additional tests beyond my own strong Linux platform test on non-Linux platforms. So along with the tests you normally perform for MSVC please also try comprehensive testing on MSYS2 (at least for the non-interactive case) to confirm these extensive source code changes are not causing any trouble on that platform. The other issue, of course, is all these source code changes introduce conflicts for topic branches that have not been rebased to the lastest master branch. However, resolution of these conflicts should be entirely straightforward since "git diff --ignore-all-space" showed all the source code changes were simply whitespace changes. 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-07-24 10:41:43
|
Thanks Alan I have a commit ready to go that removes a plexit call if the .fnt hershey font files are missing for some reason. I'll wait for your uncrustify change then before I push it. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Alan W. Irwin <Ala...@gm...> Sent: Wednesday, July 24, 2019 9:40:16 AM To: Phil Rosenberg <p.d...@gm...> Cc: PLplot development list <plp...@li...> Subject: Re: [Plplot-devel] uncrustify msys2 Hi Phil: On 2019-07-23 18:44+0100 Phil Rosenberg wrote: > Hi > I just wanted to check if anyone on the list has used uncrustfy in > msys2 to run the style-source script? <aside> I am very happy to hear you are making progress with MSYS2, and I look forward to your comprehensive test reports for that platform.</aside>. > > I couldn't find an uncrustify package to install via pacman, so I > built it from source. However, when I run style_source.sh I get the > following error > > Detected uncrustify version = 'Uncrustify-0.69.0_f'. > This script only works with uncrustify 0.60. Out of inertia I have stuck with uncrustify 0.60 up to now, but it is obviously way past time to move to the latest version (0.69.0) so I have taken responsibility for making that change. One minor issue that I am currently looking at is the following (mild) warning message I encountered from the CMake-based build system for uncrustify: -- scripts/make_version.py exited with code 64: Unknown version control system in '/home/software/uncrustify/uncrustify-0.69.0'. As a fallback, version 'Uncrustify-0.69.0_f' will be used. Since the version string reported by you is 'Uncrustify-0.69.0_f' I assume your build has the same warning message. I am virtually positive that warning is due to us both building from the appropriate tarball rather than appropriate git tag, but I will know a lot more tomorrow (after getting some sleep) after I finish implementing a bash script to configure, build, install, and test from the appropriate git tag corresponding to the desired uncrustify version. (For git enthusiasts like me such a build is actually easier to do than a build from a tarball). But my guess at this stage is that script result will be the above minor issue will be fixed (since git is virtually certainly the version control system that their build system is looking for) and the uncrustify executable version string we both encountered with the tarball build of 'Uncrustify-0.69.0_f' will likely be replaced by 'Uncrustify-0.69.0'. But I will see about that version string tomorrow and see also the FIXME note below concerning that. Here is the PLplot commit message I have in mind for tomorrow (adapted from the git commit message when I updated from 0.58 to 0.60 ~5 years ago): Update from uncrustify version 0.60 to 0.69.0. This commit includes the following changes. 1. Update annotated configuration file using uncrustify --update-config-with-doc -c uncrustify.cfg > uncrustify-0.69.0.cfg mv uncrustify-0.69.0.cfg uncrustify.cfg 2. Update scripts/style_source.sh to change from 'uncrustify 0.60' for the allowed uncrustify version string to either 'Uncrustify-0.69.0' (built from appropriate git tag) or 'Uncrustify-0.69.0_f' (built from appropriate tarball) (FIXME if the git version of the build provides a version string different than 'Uncrustify-0.69.0') 3. Run that script to update the style of a large number of our source code files according to the uncrustify 0.69.0 rules. We ascribe these large number of whitespace changes to changes in the implementation (new features with default configuration, bug fixes, and/or introduced bugs) between uncrustify 0.60 and 0.69.0. Note that visual sampling of these changes didn't reveal any obvious style issues, and these changes also passed the test below: Tested by Alan W. Irwin <ai...@us...> on Linux (Debian Buster) by building the test_noninteractive target in the build tree and evaluating the result to demonstrate no build-time or run-time errors, and no issues with the SVG difference report. Finishing implementing the uncrustify build, install, and test script and all the above changes, tests, and test evaluations is obviously going to take me a while, but it all appears to be entirely straightforward so my current ETA for the above proposed commit is late tomorrow (Wednesday) or so. More then. 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-07-24 08:40:29
|
Hi Phil: On 2019-07-23 18:44+0100 Phil Rosenberg wrote: > Hi > I just wanted to check if anyone on the list has used uncrustfy in > msys2 to run the style-source script? <aside> I am very happy to hear you are making progress with MSYS2, and I look forward to your comprehensive test reports for that platform.</aside>. > > I couldn't find an uncrustify package to install via pacman, so I > built it from source. However, when I run style_source.sh I get the > following error > > Detected uncrustify version = 'Uncrustify-0.69.0_f'. > This script only works with uncrustify 0.60. Out of inertia I have stuck with uncrustify 0.60 up to now, but it is obviously way past time to move to the latest version (0.69.0) so I have taken responsibility for making that change. One minor issue that I am currently looking at is the following (mild) warning message I encountered from the CMake-based build system for uncrustify: -- scripts/make_version.py exited with code 64: Unknown version control system in '/home/software/uncrustify/uncrustify-0.69.0'. As a fallback, version 'Uncrustify-0.69.0_f' will be used. Since the version string reported by you is 'Uncrustify-0.69.0_f' I assume your build has the same warning message. I am virtually positive that warning is due to us both building from the appropriate tarball rather than appropriate git tag, but I will know a lot more tomorrow (after getting some sleep) after I finish implementing a bash script to configure, build, install, and test from the appropriate git tag corresponding to the desired uncrustify version. (For git enthusiasts like me such a build is actually easier to do than a build from a tarball). But my guess at this stage is that script result will be the above minor issue will be fixed (since git is virtually certainly the version control system that their build system is looking for) and the uncrustify executable version string we both encountered with the tarball build of 'Uncrustify-0.69.0_f' will likely be replaced by 'Uncrustify-0.69.0'. But I will see about that version string tomorrow and see also the FIXME note below concerning that. Here is the PLplot commit message I have in mind for tomorrow (adapted from the git commit message when I updated from 0.58 to 0.60 ~5 years ago): Update from uncrustify version 0.60 to 0.69.0. This commit includes the following changes. 1. Update annotated configuration file using uncrustify --update-config-with-doc -c uncrustify.cfg > uncrustify-0.69.0.cfg mv uncrustify-0.69.0.cfg uncrustify.cfg 2. Update scripts/style_source.sh to change from 'uncrustify 0.60' for the allowed uncrustify version string to either 'Uncrustify-0.69.0' (built from appropriate git tag) or 'Uncrustify-0.69.0_f' (built from appropriate tarball) (FIXME if the git version of the build provides a version string different than 'Uncrustify-0.69.0') 3. Run that script to update the style of a large number of our source code files according to the uncrustify 0.69.0 rules. We ascribe these large number of whitespace changes to changes in the implementation (new features with default configuration, bug fixes, and/or introduced bugs) between uncrustify 0.60 and 0.69.0. Note that visual sampling of these changes didn't reveal any obvious style issues, and these changes also passed the test below: Tested by Alan W. Irwin <ai...@us...> on Linux (Debian Buster) by building the test_noninteractive target in the build tree and evaluating the result to demonstrate no build-time or run-time errors, and no issues with the SVG difference report. Finishing implementing the uncrustify build, install, and test script and all the above changes, tests, and test evaluations is obviously going to take me a while, but it all appears to be entirely straightforward so my current ETA for the above proposed commit is late tomorrow (Wednesday) or so. More then. 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-07-23 17:44:59
|
Hi I just wanted to check if anyone on the list has used uncrustfy in msys2 to run the style-source script? I couldn't find an uncrustify package to install via pacman, so I built it from source. However, when I run style_source.sh I get the following error Detected uncrustify version = 'Uncrustify-0.69.0_f'. This script only works with uncrustify 0.60. Phil |
From: Arjen M. <Arj...@de...> - 2019-07-15 11:38:06
|
Hi Alan, Phil, -----Original Message----- From: Alan W. Irwin <Ala...@gm...> Sent: 13 July 2019 21:15 To: Phil Rosenberg <p.d...@gm...> Cc: PLplot development list <plp...@li...> Subject: Re: [Plplot-devel] CMake problem with hyphen in path On 2019-07-13 08:05-0000 Phil Rosenberg wrote: > Hi Alan > You may be right. > I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help. > > So whatever workload you thought it was, it is actually double! Actually there is at least one or two orders of magnitude more work according to my Linux tests if you consider dealing with this problem for all external free software libraries that PLplot depends on rather than just wxwidgets. And the results would depend on all external libraries (and CMake itself) dealing with blank in pathname issues correctly which some preliminary tests I have done appears to be far from the case. So the fundamental issue is PLplot has been responsible about its own internal source, build, and install tree blanks in pathname issues, but other free software has not been that responsible. And a large supplementary issue is that even if external software eventually becomes completely responsible about this case, there would still be a lot more to do on the PLplot side to make "space in external library prefix" case work properly for all external libraries. >>AM: FWIW, a check that the install directory does not include space would be inline with what a package like Anaconda for Python is doing on Windows. Instead of the more commonly used directory "C:\Program Files", it installs in "C:\ProgramData", to avoid the issue that packages do not take responsibility for spaces in directory names. PLplot might simply issue a warning if the user tries to use such names anyway. 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. <Ala...@gm...> - 2019-07-13 19:15:34
|
On 2019-07-13 08:05-0000 Phil Rosenberg wrote: > Hi Alan > You may be right. > I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help. > > So whatever workload you thought it was, it is actually double! Actually there is at least one or two orders of magnitude more work according to my Linux tests if you consider dealing with this problem for all external free software libraries that PLplot depends on rather than just wxwidgets. And the results would depend on all external libraries (and CMake itself) dealing with blank in pathname issues correctly which some preliminary tests I have done appears to be far from the case. So the fundamental issue is PLplot has been responsible about its own internal source, build, and install tree blanks in pathname issues, but other free software has not been that responsible. And a large supplementary issue is that even if external software eventually becomes completely responsible about this case, there would still be a lot more to do on the PLplot side to make "space in external library prefix" case work properly for all external libraries. > Would it be relatively straightforward to add a check, so if the user supplies an install or library/header path that contains " -" then we error out at that point? The problem with *complete* configuration-time detection of that case is that we would have to have reliable parsing to detect the difference between hyphenated/spaced pathnames as opposed to the " -" that delimits linker options. That said, we could easily warn against the case where "- " appears anywhere in the options string since that case is obviously not a linker option. If you agree, I will take responsibility for implementing such a check. But that check would obviously not guard against the case of, say, an -L option of the form -L/whatever -hyphen_pathname where "whatever -hyphen_pathname" was the complete pathname rather than "whatever" being the pathname with "-hyphen_pathname" being a separate linker option. And the check would only be available for the external wxwidgets library and all external libraries that use pkg-config. So to supplement that proposed incomplete configuration-time check I think we should create a prominent warning in our wiki for users not to use installation prefixes that contain spaces for external free software libraries. I emphasize spaces rather than hyphens here since it is the spaces that generate all the issues with or without hyphens according to my Linux tests. Also, most experienced Unix users would not try spaces in installed library prefixes, but some might do that so I think the warning should be a general one rather than Windows only. If you agree that wiki "no-space in external library prefixes" warning would be useful as well, would you take responsibility for updating the most fundamental PLplot build page in our wiki (whatever that is) to that effect? 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-07-13 08:05:33
|
Hi Alan You may be right. I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help. So whatever workload you thought it was, it is actually double! Would it be relatively straightforward to add a check, so if the user supplies an install or library/header path that contains " -" then we error out at that point? This way if anyone else hits this problem it would be very clear to the user what the problem is and how to fix it. I presume we can't check each library individually - or it would be easy to fix. But I am setting cmake_install_prefix to a path that is bad, so maybe that could be checked. I think there are other variables too. Link_directories and include_directories, any more? I'll set a workaround up on my computer by symlinking my usr directory from c:\usr or something. But it's a work computer and I'll need someone with admin rights to sort it for me next week. Phil Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Alan W. Irwin <Ala...@gm...> Sent: Saturday, July 13, 2019 6:42:20 AM To: Phil Rosenberg Cc: PLplot development list Subject: Re: CMake problem with hyphen in path On 2019-07-13 00:35+0100 Phil Rosenberg wrote: > There are no .pc files. I'm building on native windows with visual > studio (not with Cygwin or MSYS2) so there is no pkg-config. All > libraries get found with the findXXX.cmake modules. In this case it is > shapelib and wxwidgets libraries. > > On windows CMake basically hunts in certain locations for the libs and > headers. In this case it finds shapelib by checking in my > CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment > variable. [...] > Output > (original _link_flags_list) = debug;C:/Users/earpros/OneDrive - > University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib; [...] > (post regex replace _link_flags_list) = > debug;C:/Users/earpros/OneDrive;- University of > Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib; [...] Hi Phil: Thanks for the above detailed information which contradicted some of my assumptions (natch). However, I am frankly beginning to get cold feet about working much further on this topic since from my Linux test of the case where external libraries have blanks and hyphens in their installation prefixes, there are a huge bunch of issues we would have to deal with before that case worked, i.e., it would be a lot of work for little real gain. For example, my understanding is Windows installers typically give you a choice of any installation prefix you want. So wouldn't it be a lot easier to ask our Windows users to be careful of that choice, i.e., pick installation prefixes without blanks or hyphens? For example, MSYS2 allows users to choose any installation prefix they like. And I think they even recommend not choosing an installation prefix with spaces because of all the trouble that causes with free software. 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-07-13 05:42:34
|
On 2019-07-13 00:35+0100 Phil Rosenberg wrote: > There are no .pc files. I'm building on native windows with visual > studio (not with Cygwin or MSYS2) so there is no pkg-config. All > libraries get found with the findXXX.cmake modules. In this case it is > shapelib and wxwidgets libraries. > > On windows CMake basically hunts in certain locations for the libs and > headers. In this case it finds shapelib by checking in my > CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment > variable. [...] > Output > (original _link_flags_list) = debug;C:/Users/earpros/OneDrive - > University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib; [...] > (post regex replace _link_flags_list) = > debug;C:/Users/earpros/OneDrive;- University of > Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib; [...] Hi Phil: Thanks for the above detailed information which contradicted some of my assumptions (natch). However, I am frankly beginning to get cold feet about working much further on this topic since from my Linux test of the case where external libraries have blanks and hyphens in their installation prefixes, there are a huge bunch of issues we would have to deal with before that case worked, i.e., it would be a lot of work for little real gain. For example, my understanding is Windows installers typically give you a choice of any installation prefix you want. So wouldn't it be a lot easier to ask our Windows users to be careful of that choice, i.e., pick installation prefixes without blanks or hyphens? For example, MSYS2 allows users to choose any installation prefix they like. And I think they even recommend not choosing an installation prefix with spaces because of all the trouble that causes with free software. 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-07-12 23:35:45
|
cmake_link_flagsHi Alan There are no .pc files. I'm building on native windows with visual studio (not with Cygwin or MSYS2) so there is no pkg-config. All libraries get found with the findXXX.cmake modules. In this case it is shapelib and wxwidgets libraries. On windows CMake basically hunts in certain locations for the libs and headers. In this case it finds shapelib by checking in my CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment variable. However I have attached below, the value of _link_flag_list just before and just after the regex replace in cmake_link_flags Cmake code message("(original _link_flags_list) = ${_link_flags_in}") # Convert link flags to a list. Note some link flags are blank-delimited # (such as "-framework whatever") so preserve those by splitting into # separate list elements only if the next element starts with a hyphen. string(REGEX REPLACE " -" ";-" _link_flags_list "${_link_flags_in}") message("(post regex replace _link_flags_list) = ${_link_flags_list}") Output (original _link_flags_list) = debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30u.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30ud_core.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30u_core.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpngd.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpng.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiffd.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiff.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpegd.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpeg.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlibd.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlib.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexud.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexu.lib;debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpatd.lib;optimized;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32 (post regex replace _link_flags_list) = debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30u.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30ud_core.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30u_core.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpngd.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpng.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiffd.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiff.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpegd.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpeg.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlibd.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlib.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexud.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexu.lib;debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpatd.lib;optimized;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32 To be honest Alan, I'm not sure what differenc quoting will make. Won't the regex just ignore the quotes anyway? On Fri, 12 Jul 2019 at 20:55, Alan W. Irwin <Ala...@gm...> wrote: > > Oops, I sent this to the wrong list so I am correcting that now. > > On 2019-07-12 05:05-0700 Alan W. Irwin wrote: > > > I am virtually positive pkg-config has a way (likely with quotes) to > > properly distinguish between these two cases, but I am going to have > > to find what that is and adjust the above parsing logic accordingly > > for the general fix. > > Hi Phil: > > It turns out that the correct *.pc file syntax to handle blanks in > pathnames is to quote all -L and -I options, e.g., -L"whatever blank". > Could you send me all the *.pc files (wrapped in a tarball for my > convenience) for the external libraries used by PLplot that you have > installed with " - " in the pathname? Unless I am missing something > those *.pc files will have " - " embedded in every pathname mentioned > in those files. And if so, then I want to check that those pathnames are > all quoted correctly. > > 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-07-12 19:55:49
|
Oops, I sent this to the wrong list so I am correcting that now. On 2019-07-12 05:05-0700 Alan W. Irwin wrote: > I am virtually positive pkg-config has a way (likely with quotes) to > properly distinguish between these two cases, but I am going to have > to find what that is and adjust the above parsing logic accordingly > for the general fix. Hi Phil: It turns out that the correct *.pc file syntax to handle blanks in pathnames is to quote all -L and -I options, e.g., -L"whatever blank". Could you send me all the *.pc files (wrapped in a tarball for my convenience) for the external libraries used by PLplot that you have installed with " - " in the pathname? Unless I am missing something those *.pc files will have " - " embedded in every pathname mentioned in those files. And if so, then I want to check that those pathnames are all quoted correctly. 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-06-14 18:24:43
|
On 2019-06-14 13:10+0100 Phil Rosenberg wrote: > Just a note about MSVC, what are the ABI concerns you have? It is of > note that GCC for windows does not provide ABI forward compatibility > https://stackoverflow.com/a/23521099. My understanding is that MSVC's > C ABI is consistent across versions and I just did a quick google and > found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible. > https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/ My concern is gcc/g++ ABI changes fairly often between versions as noted in the stackoverflow link you provided. But as the link implied modern gcc/g++ does provide an option to allow users to specify some older ABI version. So that is what Arjen had to do some time ago when he ran into a MSYS2 library that was compiled with a dated gcc suite of compilers with an older ABI. That condition is caused by the fact it takes a while for Alex to to rebuild every library to be ABI consistent with the latest gcc suite of compilers provided by MSYS2 so with MSYS2 you do run into this temporary (until libraries are rebuilt) problem periodically whenever the gcc suite of compilers has an ABI change. Note, Arjen recently also ran into the opposite problem (MSYS2 compiler had older ABI than compiler used to build the MSYS2 libraries), but that was an artifact of him attempting to use an MSYS2 platform that was not consistently updated. In sum, if using gcc/g++ to be ABI safe you should always build PLplot with exactly the same version of that suite of compilers that are used to build the libraries from the distribution (Cygwin, MSYS2, Debian, etc.). And mixing MSVC-built PLplot with gcc-built libraries or vice versa is not a good idea. However, it sounds from your experience, that if you stick with MSVC that compiler suite ABI does not change very often with version allowing you to use downloaded or built free software libraries that are built with a fairly different MSVC version (but same ABI). > Interestingly it looks like Microsoft is also developing some sort of > open source library packaging system, called Vcpkg, to reduce the > existing pain of having to build all open source libraries from > scratch https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/. > Might be worth looking into. Had a quick scan down the list of > available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA > - JUST CHECKED AND SO IS PLPLOT!!! At version 5.13. That additional distribution of free software for Windows does sound like it is worth checking out. But the link you gave only provided a list of libraries so I am not sure whether the bash, cmp, diff, etc., Unix tools necessary for comprehensive testing are included or not. If so, then you have found a third free software distribution for Windows that generally provides what is available from MSYS2 and Cygwin. However, if not, in theory you can put the MSYS2 versions of those tools at the bottom of your PATH to allow comprehensive testing on the platform using nmake. But that workaround (which historically has worked once for Arjen when he was testing an MSVC environment with no free software libraries) makes testing life a bit tricky so you may want to just stick with pure MSYS2 instead. 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-06-14 12:10:53
|
Hi Alan, Jim, Arjen I will try and sort that submitted patch asap. I will also experiment with MSYS2 - I now have a windows laptop at work and need a linux-like system on there. I did intend to use the Ubuntu Bash on Windows System, but my IT dept seem to have blocked this - at least for now. So I may try MSYS2 ather than Cygwin. I would also like to get the wxWidgets driver sorted as you described. This is time limited unfortunately. Just a note about MSVC, what are the ABI concerns you have? It is of note that GCC for windows does not provide ABI forward compatibility https://stackoverflow.com/a/23521099. My understanding is that MSVC's C ABI is consistent across versions and I just did a quick google and found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible. https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/ Interestingly it looks like Microsoft is also developing some sort of open source library packaging system, called Vcpkg, to reduce the existing pain of having to build all open source libraries from scratch https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/. Might be worth looking into. Had a quick scan down the list of available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA - JUST CHECKED AND SO IS PLPLOT!!! At version 5.13. Phil On Thu, 13 Jun 2019 at 00:10, Alan W. Irwin <Ala...@gm...> wrote: > > On 2019-06-12 12:27-0700 Alan W. Irwin wrote: > > >> On 2019-06-11 17:29-0400 Jim Dishaw wrote: > >> I think the earliest version of windows we should > >> support is win7. Keeping XP support will be a challenge. > > > > According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in > > 2001, Microsoft > > quit fundamental support for it in 2014, and the percentage of Windows users > > who > > are still using it has dropped to ~2 per cent as of a few months ago. So > > yes, I am fine > > with us dropping XP support as well. > > I have just discovered my answer above did not go far enough because I > forgot XP was followed by Vista which was followed by Windows 7. From > <https://en.wikipedia.org/wiki/Windows_Vista> Vista share of the > Windows market is down to 0.5% while from > <https://en.wikipedia.org/wiki/Windows_7> the Windows 7 share is still > at 33% with both numbers sampled just a few months ago. So I agree we > should drop support for both XP AND Vista now so that the earliest > version we should support is Windows 7. > > 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 > __________________________ > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <Ala...@gm...> - 2019-06-13 21:54:01
|
On 2019-06-13 16:31-0000 Daniel Eliason wrote: > Hi Alan, > > Unfortunately I made mistakes in the commit messages of the patches - here they are again, but I edited the messages. The correct messages mention the "acc" parameter, and that artifacts appear when the "acc" parameter is set false. Hi Daniel: I am Ccing the plplot-devel list because other PLplot developers there may be interested in these changes. I have pushed (see <https://sourceforge.net/p/plplot/plplot/ci/9394d4358f9dc385d38e052311adfd5b557625f5/> and <https://sourceforge.net/p/plplot/plplot/ci/7cd47798470a816c083d4c706f3c2ff23272aff4/>) your two commits, and these two changes will become part of the next release of PLplot (currently planned in early December this year). I left the first commit (memcpy to memmove) exactly as it was because it is obviously a good change in general. However, it might interest you to know that this commit did not change results here at all (with or without a local change to make acc true both places in example 17). From this evidence on my platform (and also a hint in the man page that some platforms do this) I believe that memcpy is implemented on Debian as an alias of memmove, but from your results (as given by your spectacularly bad screenshots of example 17 results without your changes) that is obviously not the case for CentOS. I have modified your second ("commentary and style") commit as follows: * Styled your commit with our standard script. The net effect of this modification was to move to our desired "//" form of commentary. * Removed three of your changes where either it was obvious to me the the effect of your change would be to actually change the result or where I was not sure what the effect would be. The motivation for dropping those changes is I discovered that the effect of your unmodified commit changed results here, but that issue (for what purports to be a style and commentary change) disappeared when I dropped your 3 problematic changes. Please test the git master tip version from the SF git server yourself now, and if it turns out you actually need one or more of your 3 dropped changes, we can add another commit to that effect with an explanation why that further change is necessary. And if you have any other desired change you would like to make to PLplot, please contact me again directly (or ideally on the plplot-devel mailing list for the reason given above). Best wishes, 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-06-12 23:10:39
|
On 2019-06-12 12:27-0700 Alan W. Irwin wrote: >> On 2019-06-11 17:29-0400 Jim Dishaw wrote: >> I think the earliest version of windows we should >> support is win7. Keeping XP support will be a challenge. > > According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in > 2001, Microsoft > quit fundamental support for it in 2014, and the percentage of Windows users > who > are still using it has dropped to ~2 per cent as of a few months ago. So > yes, I am fine > with us dropping XP support as well. I have just discovered my answer above did not go far enough because I forgot XP was followed by Vista which was followed by Windows 7. From <https://en.wikipedia.org/wiki/Windows_Vista> Vista share of the Windows market is down to 0.5% while from <https://en.wikipedia.org/wiki/Windows_7> the Windows 7 share is still at 33% with both numbers sampled just a few months ago. So I agree we should drop support for both XP AND Vista now so that the earliest version we should support is Windows 7. 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-06-12 19:28:09
|
On 2019-06-11 17:29-0400 Jim Dishaw wrote: > I found this in my spam--sorry for the delay and sorry for too posting. I'll take a look at the list and work a plan of action. My quick read is that it should be doable. I think the earliest version of windows we should support is win7. Keeping XP support will be a challenge. Hi Jim: I hope you can figure out a way to tune up your spam filters so PLplot traffic is not interfered with. The spam filter I use is called [SpamBayes](http://spambayes.sourceforge.net), and it works well for me. In any case, I am glad you reviewed your spam folder and as a result we are now back in e-mail contact again. According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in 2001, Microsoft quit fundamental support for it in 2014, and the percentage of Windows users who are still using it has dropped to ~2 per cent as of a few months ago. So yes, I am fine with us dropping XP support as well. @Jim: I am glad to hear you think this agenda is doable for you during this release cycle (especially when not worrying about XP support). 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-06-04 02:25:07
|
This post is Windows-centric so it is principally directed to our developers with access to Windows (Arjen, Phil, and Jim). I have decided that the release of 5.16.0 should be near December 1st this year to stick close to the 6-month-long release cycle that worked so well for the 5.15.0 release. MinGW-w64/MSYS2 (MSYS2 for short), Cygwin, and MSVC are the three Windows platforms that are of interest to us, and I would like to summarize here some comments I have made before for each of these platforms since that information is so relevant to the Windows development plans for PLplot that I will be discussing below. * MSYS2. This is our primary Windows platform since it supplies most of the free software libraries in Windows native form (i.e., no link to msys2.dll that turns executables/libraries into non-native form) that provide PLplot with its power and *always* (since there is no X wrapper implemented for MSYS2) displays results efficiently using native Windows display functionality. Because of this capability interactive comprehensive testing on this platform should be reasonably quick, but nobody has actually tried that yet. On the other hand, for 5.15.0 Arjen supplied good noninteractive comprehensive test results (see <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>) for this platform which demonstrate its excellent quality (at least for the noninteractive case) for the needs of our Windows users. * Cygwin. This is a secondary platform for us because all Cygwin libraries are non-native (i.e., linked to cygwin.dll to give non-native behaviour) and some of its free software display libraries (IIRC wxwidgets is a definite example of this issue, and pango/cairo and Qt may also have the same display issue) have been packaged incorrectly (in my view) to perform their display via a slow/inefficient X wrapper for Windows display rather than the direct Windows display capability that is available for all of these free software display libraries. As a result, Arjen has found via one attempt in the past that *interactive* comprehensive testing on Cygwin is effectively impossible because the X-wrapped display functionality is so incredibly slow. * MSVC is generally a low priority for us since ABI issues limit what free software libraries can be used on this platform so as a result PLplot is quite weak on this platform. The exception, of course, is Phil has gotten our wxwidgets components to work with a wxwidgets library he downloaded? or built? on this platform that apparently was ABI compatible with the MSVC compiler. Also, in the past Arjen has had success adding both library power and bash power to this platform by putting MSYS2 libraries and bash on his PATH. But that mode is likely too complex for users so is only likely useful for the important comprehensive testing of this platform that can be done by knowledgeable PLplot developers. @Arjen, Phil, and Jim: I acknowledge all of you have told me in the past about your severe family and job time constraints that leaves very little time for PLplot, but having said that, I nevertheless assume all of you will still have at least some time to work on PLplot during this 6-month release cycle so during that precious limited time for PLplot you should set good priorities. Here are my ideas about what your individual PLplot priorities should be, but, of course, if you prefer other PLplot priorities for yourself during this next 6 months, please let me know what those are! @Arjen: Here are the priorities I believe you should have in reverse priority order. Of course, if you think these priorities should be reordered or there are more important ones that I forgot, please let me know. 1. Although Cygwin is of secondary importance some users do attempt to use PLplot on this platform. Therefore, I think your immediate priority for this release cycle should be to finish up your comprehensive testing efforts on Cygwin that you tried to complete before the 5.15.0 release. Time is of the essence (which is my motivation for giving this effort a high priority) since although you did not complete this effort in time for the 5.15.0 release, it is almost as good to complete it as soon as possible after the 5.15.0 release to reassure Windows users (with finalized results mentioned at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>) that at least noninteractive PLplot-5.15.0 is as good on Cygwin as it is on MSYS2. 2. Update all our MSYS2-related wiki pages based on your recent good experiences with this platform. I think this project will take advantage of your good English technical writing skills, and up-to-date wiki information will also be extremely useful in helping both Phil and Jim to get started with this platform (see their priorities below). 3. Be prepared (via at least one preliminary testing effort this summer) to "turn the crank" to replicate your current good MSYS2 comprehensive test just before we release 5.16.0 on or near December 1st. 4. Comprehensively test the MSVC platform? I put a question mark by that priority since this platform is not of primary importance to us. Nevertheless, just to remind you, you were able to create a good comprehensive test of this platform a long time ago by putting native MSYS2 libraries and MSYS2 bash on your PATH (to add PLplot power and especially bash testing power to the otherwise low-power MSVC platform), and it "would be nice" if you can replicate that good MSVC result again for 5.16.0. 5. Package PLplot on Cygwin?? This is an even lower "would be nice" priority. However, See remarks about why there is a need for this packaging effort that I recently made at <https://sourceforge.net/p/plplot/feature-requests/16/>. @Phil: Here are the priorities I believe you should have in reverse priority order. Of course, if you think these priorities should be reordered or there are more important ones that I forgot, please let me know. 1. Deal with <https://sourceforge.net/p/plplot/patches/34/>. 2. Become familiar with our primary Windows platform, MSYS2. You have already told me off-list that you would be willing to do this, and I think this release cycle would be an excellent time for you to achieve this goal not only for your own personal benefit (because this really is a powerful PLplot platform) but also to ease the testing burden carried by Arjen right now and also to eventually extend the scope of his current testing (i.e., by including interactive tests in the comprehensive test script that you run). See <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> for the details concerning testing PLplot including how to run the comprehensive test script. A very good source of information for the MSYS2 platform is <https://github.com/msys2/msys2/wiki> and links you can follow from there that should make it easy to install the basic version of this platform and enhance it by using the pacman installer to install all the native Windows libraries provided by MSYS2 that provide extra power to PLplot. For example, pango/cairo, Qt, and wxwidgets libraries already provide good noninteractive results (or have the potential to do so in the wxwidgets case, remember the wxpng device driver) and should potentially also provide rapid, high-quality interactive results for comprehensive tests. 3. This one is a cross-platform issue rather than just limited to Windows. Fix the wxwidgets device so that its display event loop checks to see whether the plot commands in the buffer have been extended and adds those plot commands to the display of the plot whenever such an extension occurs rather than waiting until the buffer of all plot commands for a given page is complete before running all those plot commands. This fundamental improvement for new wxwidgets should bring the new wxwidgets device in line with the old wxwidgets device as well as the wincairo (or xcairo on Linux) and qtwidget interactive devices. For all those other interactive device alternatives the -np (no pause) option works properly, and the 17th example displays like a video as the plot unfolds rather than just plotting the final plot for the page. (You should be able to prove this for yourself by trying the wincairo and qtwidget devices on MSYS2 for example 17). In sum, this fundamental change to the new wxwidgets device needs to be done before it can gain those same good -np and 17th example display results showed by the other interactive devices. 4. Help with packaging PLplot for MSYS2? Of course, Arjen could likely be able to do this instead of you, but it is a good way to take some of the load off him, and it should not be that big a burden for you since packaging on this platform is really simple. See my recent comments at <https://sourceforge.net/p/plplot/feature-requests/16/> concerning the importance of such binary packaging. I should add here that my old estimate of binary package use of PLplot (via the fraction of Debian users that used it actively each month on Debian) was very roughly 100000 users when you apply that fraction to an estimate of the free software desktops in the world while downloaders of our source code typically are only ~5000 per release according to SF statistics. So that comparison is quite rough, but the important point is binary package users of PLplot far outweigh those who build PLplot from source which is why I view binary packaging to be so important for PLplot. From the MSYS2 wiki reference above, you can discover that packaging for MSYS2 is really quite simple, and there is already a very good start on that at <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-plplot> to help you further. However, if you just look at the PKGBUILD file there you should notice some problematic configuration issues (relying on the gd library and associated png and jpeg device drivers that have been deprecated for a very long time, and dropping (!) the high-quality qt device driver that is working so well for Arjen). So once you are familiar with building PLplot on MSYS2, you should be able to give Alex (the primary MSYS2 developer and also the author of the PLplot package for that platform) some good advice (through patches to that PKGBUILD file and testing the effect of those changes on the plplot binary package results) about how to substantially improve that PLplot package. @Jim: Here are the priorities I believe you should have in reverse priority order. Of course, if you think these priorities should be reordered or there are more important ones that I forgot, please let me know. 1. Phil has already told me he is willing to give MSYS2 a try so I hope you are in as well during this release cycle. See topic 2. in my remarks to him. 2. Deal with <https://sourceforge.net/p/plplot/bugs/195/>. My feeling is there is a reasonable chance you can replicate this guy's Cygwin issue on MSYS2 (since MSYS2 is a fork of Cygwin), and if that proves to be the case, that should provide some essential help to your effort to fix this bug. 3. If the wingdi device is anything like my memory of the wingcc device results long ago when I was testing that device on Wine, it has problems with the -np option and example 17. See topic 3 in my remarks to Phil about a similar issue for the wxwidgets device and the MSYS2 interactive device comparisons he can use to discover the correct behaviour of all interactive devices. And if you verify this bug for wingdi on MSYS2, it would be great if you could also come up with a fix for it. But I would not bother with fixing wingcc in this regard since I hope we will be able to retire that device driver soon (see below). 4. Enhance the wingdi device so it can properly handle UTF-8 text? This is the obvious and long-discussed next step for this device that would allow us to permanently retire wingcc so I hope you have some time during this release cycle to finish off this topic. @ Arjen, Phil, and Jim: Don't take what I said too seriously above because my Windows experience is from quite a while ago on the Wine platform with MinGW/MSYS (as opposed to the modern alternative to that ancient platform, MinGW-w64/MSYS2). But I do hope to stir up some discussion from you three PLplot developers with access to Windows. So I am looking forward to your individual replies to my remarks above. 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-06-03 21:16:39
|
For the information of the PLplot developers, I have recently gone through all the open/pending support requests at <https://sourceforge.net/p/plplot/support-requests/> and changed the status to "closed" with a comment of "too old" for all the support requests that were more than two years old since I don't think any of those (two-years old or more!) support requests can possibly be relevant to modern PLplot. That triage left just 4 open/pending support requests where one of them was an obvious bug report which I moved to our bug reports, and the 3 remaining ones I have classified as pending since either the discussion of the support topic appears to be over, or we are waiting for more feedback from the originator of the support request. 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-06-02 02:04:45
|
Dear PLplot developers: I have now released 5.15.0. See my recent post to plplot-general for the details concerning that release. I wish to thank Arjen Markus for his important testing work on Windows and others here for their indirect contributions via bug reports, using the git master tip version to make sure it is always working for your particular needs, participating in development discussions, etc. Please take a critical look at plplot.org. That site has been regenerated and uploaded as part of the recent release process by me, and I have clicked on all links mentioned on the site to insure we have no dead links. However, I am pretty used to the site so I may be missing some obvious issue so if you take an independent look you may find something that needs changing. Of course, the freeze for pushing commits to SF is now over so I encourage you to mature your git topic branches and push those as well as push bug fixes as soon as possible in this new release cycle to maximize the time we can test such changes during this current release cycle which I currently plan will be something like 6 months long. Good luck with your PLplot development and testing during this new 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.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. <Ala...@gm...> - 2019-05-31 01:48:02
|
Here is the current status of the PLplot-5.15.0 release process. N.B. the freeze (with a few well-understood exceptions) on pushes of source code or build system changes will continue until this release process is completed. My apologies that some personal distractions delayed my further work on this release until today. However, today I did make some substantial progress which was to finalize (commit plplot-5.14.0-47-g4baf2b49a) the release notes for 5.15.0 based on my review of all the commit messages during this release cycle. All the rest of the steps in the release process should be largely mechanical, and you should be able to follow those on git as I do them. Therefore, I hope to release PLplot-5.15.0 in another day or two without further status reports like this one concerning how close I am to reaching that goal! :-) 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.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 __________________________ _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |