Menu
▾
▴
plplot-devel
|
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: 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-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-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: 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 01:30:52
Attachments:
git_build.sh
|
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-26 03:31:55
Attachments:
git_build.sh.gz
|
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-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: 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 > > __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X