[Rd] Building R from source with the PGI compiler
Hello I would like to build R from source and use the PGI compiler, rather than the GCC compiler. I saw the instructions for the Intel compiler in the R Installation Manual, but I didn't see the PGI. I tried a few times without instructions, but without success. Any suggestions would be most welcome. Also, I hope this is the right group for the question. Sincerely, Erin -- Erin Hodgess Associate Professor Department of Mathematical and Statistics University of Houston - Downtown mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R from source with the PGI compiler
On 21/12/2017 01:03, Erin Hodgess wrote: Hello I would like to build R from source and use the PGI compiler, rather than the GCC compiler. On what platform? AFAIK we have only ever had reports on Linux. I saw the instructions for the Intel compiler in the R Installation Manual, but I didn't see the PGI. I tried a few times without instructions, but without success. Any suggestions would be most welcome. Also, I hope this is the right group for the question. It is. Earlier versions of the manual did contain info on using the PG(I) Linux compilers but as we had no reports for a long time, the probably-stale info was removed. It looks like the info was added in late 2005, so you could try grabbing R sources from, say, 2007. Sincerely, Erin -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wish List: base::source() + Add Execution Time Argument
Dear R Developers, Adding to source() base function a Timer which indicates the execution time of the source code would be a very well welcome feature, and in my opinion not difficult to implement as an additional funtion argument. The source(timing = TRUE) function shall execute internally the following code for each statement: old <- Sys.time() # get start time at the beginning of source() # source code # print elapsed time new <- Sys.time() - old # calculate difference print(new) # print in nice format Thank you. Kind regards, Juan Telleria [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about compiler warning flags
On 20/12/2017 6:52 PM, Duncan Murdoch wrote: On 20/12/2017 5:48 PM, Hadley Wickham wrote: On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley wrote: On 20/12/2017 17:42, Winston Chang wrote: On recent builds of R-devel, R CMD check gives a WARNING when some compiler warning flags are detected, such as -Werror, because they are non-portable. This appears to have been added in this commit: https://github.com/wch/r-source/commit/2e80059 That is not the canonical R sources. And your description seems wrong: there is now an _optional_ check controlled by an environment variable, primarily for CRAN checks. Are the canonical R sources made available in such a way that one can link to them? Yes, the sources are available. To link to revision 73909 of R on the trunk branch (which I think is the one referred to above), use https://svn.r-project.org/R/trunk/?r=73909 I'm not sure if there's an easy way to see the diff between that and 73908 (which is what the github link showed). After checking a bit online, it appears there are projects WebSVN, USVN and ViewVC that should do this. I don't know if anyone has set up views of the R repository with any of those. I've never used them, I just use local tools. In the past I used Windows-only TortoiseSVN (and it is still one of the most attractive features of Windows); now I use RStudio or command line svn. As you know, RStudio's interface is somewhat limited, and as far as I know it can't display features of remote repositories. I also don't know if there's a way to show the diff between commit N and N-1 in github if I only know N. I still don't know this. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish List: base::source() + Add Execution Time Argument
2017-12-21 12:46 GMT+01:00 Juan Telleria : > Dear R Developers, > > Adding to source() base function a Timer which indicates the execution time > of the source code would be a very well welcome feature, and in my opinion > not difficult to implement as an additional funtion argument. > > The source(timing = TRUE) function shall execute internally the following > code for each statement: > > old <- Sys.time() # get start time at the beginning of source() > # source code > # print elapsed time > new <- Sys.time() - old # calculate difference > print(new) # print in nice format system.time(source(...)) does what you want. Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish List: base::source() + Add Execution Time Argument
But by statement in the source file, I mean, for knowing during the execution how much time is taking, without having to wait till the end. 2017-12-21 13:06 GMT+01:00 Iñaki Úcar : > 2017-12-21 12:46 GMT+01:00 Juan Telleria : > > Dear R Developers, > > > > Adding to source() base function a Timer which indicates the execution > time > > of the source code would be a very well welcome feature, and in my > opinion > > not difficult to implement as an additional funtion argument. > > > > The source(timing = TRUE) function shall execute internally the following > > code for each statement: > > > > old <- Sys.time() # get start time at the beginning of source() > > # source code > > # print elapsed time > > new <- Sys.time() - old # calculate difference > > print(new) # print in nice format > > system.time(source(...)) does what you want. > > Iñaki > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish List: base::source() + Add Execution Time Argument
2017-12-21 15:05 GMT+01:00 Juan Telleria : > But by statement in the source file, I mean, for knowing during the > execution how much time is taking, without having to wait till the end. What's the ultimate purpose? Are you looking for a profiler (there are some of them on CRAN) or some kind of progress bar (something like the 'progress' package would be useful)? Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish List: base::source() + Add Execution Time Argument
I did not know "progress" package existed, thank you Iñaki. However, something like that would be nice to have by default in source(), just something to add to R's "wish list", so that everybody can benefit from it without extra-packages, as most of us I suppose we will spend all day simply doing Ctrl + Run :) Thank you, Juan 2017-12-21 15:20 GMT+01:00 Iñaki Úcar : > 2017-12-21 15:05 GMT+01:00 Juan Telleria : > > But by statement in the source file, I mean, for knowing during the > > execution how much time is taking, without having to wait till the end. > > What's the ultimate purpose? Are you looking for a profiler (there are > some of them on CRAN) or some kind of progress bar (something like the > 'progress' package would be useful)? > > Iñaki > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish List: base::source() + Add Execution Time Argument
Is source() the right place for this? It may be, but we've had customers who would like this sort of thing done for commands entered by hand. And there are those who want a description of any "non-triivial" objects created in .GlobalEnv by each expression, ... Do they need a way to wrap each expression evaluated in envir=.GlobalEnv with a function of their choice, one that would print times, datasets created, etc.? Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Dec 21, 2017 at 3:46 AM, Juan Telleria wrote: > Dear R Developers, > > Adding to source() base function a Timer which indicates the execution time > of the source code would be a very well welcome feature, and in my opinion > not difficult to implement as an additional funtion argument. > > The source(timing = TRUE) function shall execute internally the following > code for each statement: > > old <- Sys.time() # get start time at the beginning of source() > # source code > # print elapsed time > new <- Sys.time() - old # calculate difference > print(new) # print in nice format > > Thank you. > > Kind regards, > > Juan Telleria > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish List: base::source() + Add Execution Time Argument
R does provide the addTaskCallback / taskCallbackManager to run a callback function after every top level command. However there is not an equivalent interface that would be run _before_ each command, which would make it possible to time of top level calls and provide other execution measurements. On Thu, Dec 21, 2017 at 11:31 AM, William Dunlap via R-devel wrote: > Is source() the right place for this? It may be, but we've had customers > who would like > this sort of thing done for commands entered by hand. And there are those > who want > a description of any "non-triivial" objects created in .GlobalEnv by each > expression, ... > Do they need a way to wrap each expression evaluated in envir=.GlobalEnv > with a > function of their choice, one that would print times, datasets created, > etc.? > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Thu, Dec 21, 2017 at 3:46 AM, Juan Telleria wrote: > >> Dear R Developers, >> >> Adding to source() base function a Timer which indicates the execution time >> of the source code would be a very well welcome feature, and in my opinion >> not difficult to implement as an additional funtion argument. >> >> The source(timing = TRUE) function shall execute internally the following >> code for each statement: >> >> old <- Sys.time() # get start time at the beginning of source() >> # source code >> # print elapsed time >> new <- Sys.time() - old # calculate difference >> print(new) # print in nice format >> >> Thank you. >> >> Kind regards, >> >> Juan Telleria >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about compiler warning flags
>> On recent builds of R-devel, R CMD check gives a WARNING when some >> compiler warning flags are detected, such as -Werror, because they are >> non-portable. This appears to have been added in this commit: >>https://github.com/wch/r-source/commit/2e80059 > > That is not the canonical R sources. Yes, that is obvious. The main page for that repository says it is a mirror of the R sources, right at the top. I know that because I put the message there, and because I see it every time I visit the repository. If you have a good way of pointing people to the changes made in a commit with the canonical R sources, please let us know. I and many others would be happy to use it. > And your description seems wrong: > there is now an _optional_ check controlled by an environment variable, > primarily for CRAN checks. The check is "optional", but not for packages submitted to CRAN. >> I'm working on a package where these compiler warning flags are >> present in a Makefile generated by a configure script -- that is, the >> configure script detects whether the compiler supports these flags, >> and if so, puts them in the Makefile. (The configure script is for a >> third-party C library which is in a subdirectory of src/.) >> >> Because the flags are added only if the system supports them, there >> shouldn't be any worries about portability in practice. > > > Please read the explanation in the manual: there are serious concerns about > such flags which have bitten CRAN users several times. > > To take your example, you cannot know what -Werror does on all compilers > (past, present or future) where it is supported (and -W flags do do > different things on different compilers). On current gcc it does > >-Werror >Make all warnings into errors. > > and so its effect depends on what other flags are used (people typically use > -Wall, and most new versions of both gcc and clang add more warnings to > -Wall -- I read this week exactly such a discussion about the interaction of > -Werror with -Wtautological-constant-compare as part of -Wall in clang > trunk). > >> Is there a way to get R CMD check to not raise warnings in cases like >> this? I know I could modify the C library's configure.ac (which is >> used to generate the configure script) but I'd prefer to leave the >> library's code untouched if possible. > > You don't need to (and most likely should not) use the C[XX]FLAGS it > generates ... just use the flags which R passes to the package to use. It turns out that there isn't even a risk of these compiler flags being used -- I learned from of my colleagues that the troublesome compiler flags, like -Werror, never actually appear in the Makefile. The configure script prints out those compiler flags out when it checks for them, but in the end it creates a Makefile with the CFLAGS inherited from R. So there's no chance that the library would be compiled using those flags (unless R passed them along). His suggested workaround is to silence the output of the configure script. That also hides some useful information, but it does work for this issue. -Winston __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about compiler warning flags
On 21/12/2017 1:02 PM, Winston Chang wrote: On recent builds of R-devel, R CMD check gives a WARNING when some compiler warning flags are detected, such as -Werror, because they are non-portable. This appears to have been added in this commit: https://github.com/wch/r-source/commit/2e80059 That is not the canonical R sources. Yes, that is obvious. The main page for that repository says it is a mirror of the R sources, right at the top. I know that because I put the message there, and because I see it every time I visit the repository. If you have a good way of pointing people to the changes made in a commit with the canonical R sources, please let us know. I and many others would be happy to use it. The usual way is just to refer to the revision number, i.e. "This appears to have been added in rev 73909". People who don't have the sources checked out can see the diff on your Github mirror using https://github.com/wch/r-source/search?q="trunk@73909"&type=Commits and following the listed search hit. (Thanks to Thierry Onkelinx for helping me with this.) This only works for commits to the trunk. I guessed that something like https://github.com/wch/r-source/search?q="R-3-4-branch@73937"&type=Commits would work if the commit was to the 3.4 branch, but apparently not. I don't know how to find those commits. Presumably there's a way, but I don't know it. Another possibility is that someone could set up (or already has?) one of the web viewers (WebSVN, etc.) for the real repository. That would be better for those of us who are SVN users, but probably harder for Git users. Duncan Murdoch And your description seems wrong: there is now an _optional_ check controlled by an environment variable, primarily for CRAN checks. The check is "optional", but not for packages submitted to CRAN. I'm working on a package where these compiler warning flags are present in a Makefile generated by a configure script -- that is, the configure script detects whether the compiler supports these flags, and if so, puts them in the Makefile. (The configure script is for a third-party C library which is in a subdirectory of src/.) Because the flags are added only if the system supports them, there shouldn't be any worries about portability in practice. Please read the explanation in the manual: there are serious concerns about such flags which have bitten CRAN users several times. To take your example, you cannot know what -Werror does on all compilers (past, present or future) where it is supported (and -W flags do do different things on different compilers). On current gcc it does -Werror Make all warnings into errors. and so its effect depends on what other flags are used (people typically use -Wall, and most new versions of both gcc and clang add more warnings to -Wall -- I read this week exactly such a discussion about the interaction of -Werror with -Wtautological-constant-compare as part of -Wall in clang trunk). Is there a way to get R CMD check to not raise warnings in cases like this? I know I could modify the C library's configure.ac (which is used to generate the configure script) but I'd prefer to leave the library's code untouched if possible. You don't need to (and most likely should not) use the C[XX]FLAGS it generates ... just use the flags which R passes to the package to use. It turns out that there isn't even a risk of these compiler flags being used -- I learned from of my colleagues that the troublesome compiler flags, like -Werror, never actually appear in the Makefile. The configure script prints out those compiler flags out when it checks for them, but in the end it creates a Makefile with the CFLAGS inherited from R. So there's no chance that the library would be compiled using those flags (unless R passed them along). His suggested workaround is to silence the output of the configure script. That also hides some useful information, but it does work for this issue. -Winston __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about compiler warning flags
On 12/21/2017 01:02 PM, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059
That is not the canonical R sources.
Yes, that is obvious. The main page for that repository says it is a
mirror of the R sources, right at the top. I know that because I put
the message there, and because I see it every time I visit the
repository. If you have a good way of pointing people to the changes
made in a commit with the canonical R sources, please let us know. I
and many others would be happy to use it.
In case 'pointing to' is not to mean exclusively 'pointing a mouse at',
'a good way' can include typing at the console and living with the
merits and demerits of svn, and the question is not
rhetorical(probably FALSE on all accounts, but one never knows...)
Check out or update the source (linux, mac, or Windows)
svn co https://svn.r-project.org/R/trunk R-devel
cd R-devel
svn up
browse the commit history
svn log | less
and review the change
svn diff -c73909
Restrict by specifying a path
svn diff -c73909 src/library/tools/R/check.R
(I don't think one gets finer resolution, other than referencing the
line number in the diff)
View a range of revisions, e.g.,
svn diff -r73908:73909
And find commits associated with lines of code
svn annotate doc/manual/R-exts.texi | less
A quick google search (svn diff visual display) lead me to
svn diff --diff-cmd meld -c73909
for my platform, which pops up the diffs in a visual context.
Martin Morgan
And your description seems wrong:
there is now an _optional_ check controlled by an environment variable,
primarily for CRAN checks.
The check is "optional", but not for packages submitted to CRAN.
I'm working on a package where these compiler warning flags are
present in a Makefile generated by a configure script -- that is, the
configure script detects whether the compiler supports these flags,
and if so, puts them in the Makefile. (The configure script is for a
third-party C library which is in a subdirectory of src/.)
Because the flags are added only if the system supports them, there
shouldn't be any worries about portability in practice.
Please read the explanation in the manual: there are serious concerns about
such flags which have bitten CRAN users several times.
To take your example, you cannot know what -Werror does on all compilers
(past, present or future) where it is supported (and -W flags do do
different things on different compilers). On current gcc it does
-Werror
Make all warnings into errors.
and so its effect depends on what other flags are used (people typically use
-Wall, and most new versions of both gcc and clang add more warnings to
-Wall -- I read this week exactly such a discussion about the interaction of
-Werror with -Wtautological-constant-compare as part of -Wall in clang
trunk).
Is there a way to get R CMD check to not raise warnings in cases like
this? I know I could modify the C library's configure.ac (which is
used to generate the configure script) but I'd prefer to leave the
library's code untouched if possible.
You don't need to (and most likely should not) use the C[XX]FLAGS it
generates ... just use the flags which R passes to the package to use.
It turns out that there isn't even a risk of these compiler flags
being used -- I learned from of my colleagues that the troublesome
compiler flags, like -Werror, never actually appear in the Makefile.
The configure script prints out those compiler flags out when it
checks for them, but in the end it creates a Makefile with the CFLAGS
inherited from R. So there's no chance that the library would be
compiled using those flags (unless R passed them along).
His suggested workaround is to silence the output of the configure
script. That also hides some useful information, but it does work for
this issue.
-Winston
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
This email message may contain legally privileged and/or...{{dropped:2}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R from source with the PGI compiler
Hi, Erin. Please feel free to ignore this, but I'm curious: what is the advantage to using the PGI compiler? -- Mike On Wed, Dec 20, 2017 at 5:03 PM, Erin Hodgess wrote: > Hello > > I would like to build R from source and use the PGI compiler, rather than > the GCC compiler. > > I saw the instructions for the Intel compiler in the R Installation Manual, > but I didn't see the PGI. I tried a few times without instructions, but > without success. > > Any suggestions would be most welcome. Also, I hope this is the right > group for the question. > > Sincerely, > Erin > > > > -- > Erin Hodgess > Associate Professor > Department of Mathematical and Statistics > University of Houston - Downtown > mailto: erinm.hodg...@gmail.com > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R from source with the PGI compiler
Hello! I’m working on a supercomputer and will be tying into some FORTRAN programs. Those programs use OpenACC, which must be compiled with PGI. In case you are wondering, Why don’t I use C? I actually started with C and FORTRAN is faster. Thanks for listening, Erin On Thu, Dec 21, 2017 at 6:58 PM Michael Hannon wrote: > Hi, Erin. Please feel free to ignore this, but I'm curious: what is > the advantage to using the PGI compiler? > > -- Mike > > > On Wed, Dec 20, 2017 at 5:03 PM, Erin Hodgess > wrote: > > Hello > > > > I would like to build R from source and use the PGI compiler, rather than > > the GCC compiler. > > > > I saw the instructions for the Intel compiler in the R Installation > Manual, > > but I didn't see the PGI. I tried a few times without instructions, but > > without success. > > > > Any suggestions would be most welcome. Also, I hope this is the right > > group for the question. > > > > Sincerely, > > Erin > > > > > > > > -- > > Erin Hodgess > > Associate Professor > > Department of Mathematical and Statistics > > University of Houston - Downtown > > mailto: erinm.hodg...@gmail.com > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Erin Hodgess Associate Professor Department of Mathematical and Statistics University of Houston - Downtown mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
