Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Kevin Coombes

Here's the short answer:  Whatever you used to do should still work.

I started this thread, not knowing that it was going to get sucked into 
a whirlpool on the fringes of an operating system religious war.  My 
sincerest apologies to everyone who has gotten confused as a consequence.


I only ran into problem because I installed R 3.0 and Rtools 3.0 on a 
new machine, and accidentally put Rtools in a different location from 
where it used to reside on the machines I used for R 2.whatever.  And so 
the scripts I used to build packages no longer worked because the path 
was wrong. If you can avoid doing something silly like that, then your 
old methods for building and maintaining packages should work the same 
way they always did.


On 4/21/2013 8:22 PM, steven mosher wrote:

Well, color me confused as heck. I've upgraded to R 3.0 so that I can bring
my packages up to date, but the instructions surrounding Rtools30 are not a
model of clarity.


On Sun, Apr 21, 2013 at 4:04 PM, Gabor Grothendieck 
wrote:
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson 
wrote:

I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc.  It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.

EXAMPLE WITH .Rprofile:

## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path <- unlist(strsplit(Sys.getenv("PATH"), ";"));
path <- c("C:\\Rtools\\bin", "C:\\Rtools\\gcc-4.6.3\\bin", path);
Sys.setenv("PATH"=paste(unique(path), collapse=";"));

## DISABLED:
x:\> R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'

## ENABLED:
x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -I"C:/PROGRA~1/R/R-3.0.0patched/include" -DNDEBUG [...]
[...]
* DONE (matrixStats)


EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH="C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}"

x:\> R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
=> fails

x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
=> works

As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH.  This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally.  That would certainly lower the barriers for newcomers to
install packages from source that need compilation.  Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.

/Henrik

PS. Hadley, is this what you meant when you wrote "Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *.", or those approaches are only when you call 'R CMD'
from the R prompt?  I believe the latter, but I just want to make sure
I didn't miss something.

That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features.  Also, because R.bat locates R
itself it can be useful even if you are not doing development.  On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.

__
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 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread steven mosher
Well, color me confused as heck. I've upgraded to R 3.0 so that I can bring
my packages up to date, but the instructions surrounding Rtools30 are not a
model of clarity.


On Sun, Apr 21, 2013 at 4:04 PM, Gabor Grothendieck  wrote:

> On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson 
> wrote:
> > I (as well) keep a specific Rsetup.bat file for launching Windows
> > cmd.exe with the proper PATH etc setup for build R packages etc.  It's
> > only after this thread I gave it a second thought; you can indeed
> > temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
> > processed at the very beginning when calling 'R CMD ...'.
> >
> > EXAMPLE WITH .Rprofile:
> >
> > ## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
> > path <- unlist(strsplit(Sys.getenv("PATH"), ";"));
> > path <- c("C:\\Rtools\\bin", "C:\\Rtools\\gcc-4.6.3\\bin", path);
> > Sys.setenv("PATH"=paste(unique(path), collapse=";"));
> >
> > ## DISABLED:
> > x:\> R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
> > * installing to library 'C:/Users/hb/R/win-library/3.0'
> > * installing *source* package 'matrixStats' ...
> > ** libs
> > *** arch - i386
> > ERROR: compilation failed for package 'matrixStats'
> > * removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
> >
> > ## ENABLED:
> > x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
> > * installing to library 'C:/Users/hb/R/win-library/3.0'
> > * installing *source* package 'matrixStats' ...
> > ** libs
> > *** arch - i386
> > gcc -m32 -I"C:/PROGRA~1/R/R-3.0.0patched/include" -DNDEBUG [...]
> > [...]
> > * DONE (matrixStats)
> >
> >
> > EXAMPLE WITH .Renviron:
> > ## ~/.Renviron (e.g. C:/User/foo/.Renviron):
> > # Backslashes are preserved iff put within quotes
> > PATH="C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}"
> >
> > x:\> R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
> > => fails
> >
> > x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
> > => works
> >
> > As long as R is on the PATH, the above either of the approaches
> > removes the need to add Rtools to the PATH via a BAT file and it won't
> > clutter up your PATH.  This begs the question (as somewhat already
> > proposed), instead of users/developers doing this manually, would it
> > be possible to have 'R CMD ...' to locate add Rtools to the PATH
> > internally.  That would certainly lower the barriers for newcomers to
> > install packages from source that need compilation.  Obviously, this
> > doesn't make the tools (e.g. make) in Rtools available outside of R,
> > it does not allow you to build R itself from source, but it does cover
> > the very common use cases of calling 'R CMD build/INSTALL/check/...'.
> >
> > /Henrik
> >
> > PS. Hadley, is this what you meant when you wrote "Better solutions
> > (e.g. Rstudio and devtools) temporarily set the path on when you're
> > calling R CMD *.", or those approaches are only when you call 'R CMD'
> > from the R prompt?  I believe the latter, but I just want to make sure
> > I didn't miss something.
>
> That seems like a reasonable approach although the code shown does
> entail more setup and ongoing maintenance by the user than R.bat which
> does not require that the user edit any files and additionally locates
> R itself and has many other features.  Also, because R.bat locates R
> itself it can be useful even if you are not doing development.  On the
> other hand if you are looking to do development strictly from within R
> then devtools is already developed.
>
> __
> 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] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Gabor Grothendieck
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson  wrote:
> I (as well) keep a specific Rsetup.bat file for launching Windows
> cmd.exe with the proper PATH etc setup for build R packages etc.  It's
> only after this thread I gave it a second thought; you can indeed
> temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
> processed at the very beginning when calling 'R CMD ...'.
>
> EXAMPLE WITH .Rprofile:
>
> ## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
> path <- unlist(strsplit(Sys.getenv("PATH"), ";"));
> path <- c("C:\\Rtools\\bin", "C:\\Rtools\\gcc-4.6.3\\bin", path);
> Sys.setenv("PATH"=paste(unique(path), collapse=";"));
>
> ## DISABLED:
> x:\> R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
> * installing to library 'C:/Users/hb/R/win-library/3.0'
> * installing *source* package 'matrixStats' ...
> ** libs
> *** arch - i386
> ERROR: compilation failed for package 'matrixStats'
> * removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
>
> ## ENABLED:
> x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
> * installing to library 'C:/Users/hb/R/win-library/3.0'
> * installing *source* package 'matrixStats' ...
> ** libs
> *** arch - i386
> gcc -m32 -I"C:/PROGRA~1/R/R-3.0.0patched/include" -DNDEBUG [...]
> [...]
> * DONE (matrixStats)
>
>
> EXAMPLE WITH .Renviron:
> ## ~/.Renviron (e.g. C:/User/foo/.Renviron):
> # Backslashes are preserved iff put within quotes
> PATH="C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}"
>
> x:\> R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
> => fails
>
> x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
> => works
>
> As long as R is on the PATH, the above either of the approaches
> removes the need to add Rtools to the PATH via a BAT file and it won't
> clutter up your PATH.  This begs the question (as somewhat already
> proposed), instead of users/developers doing this manually, would it
> be possible to have 'R CMD ...' to locate add Rtools to the PATH
> internally.  That would certainly lower the barriers for newcomers to
> install packages from source that need compilation.  Obviously, this
> doesn't make the tools (e.g. make) in Rtools available outside of R,
> it does not allow you to build R itself from source, but it does cover
> the very common use cases of calling 'R CMD build/INSTALL/check/...'.
>
> /Henrik
>
> PS. Hadley, is this what you meant when you wrote "Better solutions
> (e.g. Rstudio and devtools) temporarily set the path on when you're
> calling R CMD *.", or those approaches are only when you call 'R CMD'
> from the R prompt?  I believe the latter, but I just want to make sure
> I didn't miss something.

That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features.  Also, because R.bat locates R
itself it can be useful even if you are not doing development.  On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Hadley Wickham
> PS. Hadley, is this what you meant when you wrote "Better solutions
> (e.g. Rstudio and devtools) temporarily set the path on when you're
> calling R CMD *.", or those approaches are only when you call 'R CMD'
> from the R prompt?  I believe the latter, but I just want to make sure
> I didn't miss something.

Well both devtools and RStudio allow you to do package development
without leaving R, so neither do anything to your path when you're not
using them.

In teaching windows users to develop R packages, I found the use of
the command line to be a substantial road-block, and if you can
develop packages without leaving R, why not?

Hadley

--
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Henrik Bengtsson
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc.  It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.

EXAMPLE WITH .Rprofile:

## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path <- unlist(strsplit(Sys.getenv("PATH"), ";"));
path <- c("C:\\Rtools\\bin", "C:\\Rtools\\gcc-4.6.3\\bin", path);
Sys.setenv("PATH"=paste(unique(path), collapse=";"));

## DISABLED:
x:\> R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'

## ENABLED:
x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -I"C:/PROGRA~1/R/R-3.0.0patched/include" -DNDEBUG [...]
[...]
* DONE (matrixStats)


EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH="C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}"

x:\> R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
=> fails

x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
=> works

As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH.  This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally.  That would certainly lower the barriers for newcomers to
install packages from source that need compilation.  Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.

/Henrik

PS. Hadley, is this what you meant when you wrote "Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *.", or those approaches are only when you call 'R CMD'
from the R prompt?  I believe the latter, but I just want to make sure
I didn't miss something.



On Sun, Apr 21, 2013 at 11:02 AM, Gabor Grothendieck
 wrote:
> On Sun, Apr 21, 2013 at 12:57 PM, Hadley Wickham  wrote:
> Because it can conflict with other Windows software unless you add a
> layer over it.  What other popular software that runs on Windows has
> these problems?  I can't think of any.  The closest I can come up with
> was that for a short time after git was ported to Windows it would
> change the font of the Windows console but there was an immediate hue
> and cry about it having no business messing with the rest of Windows
> and it was quickly rectified.

 I don't understand: unless you modify settings in the default install,
 Rtools *does not* affect other windows software in any way.
>>>
>>> If its the case that it now works from the cmd line without setting
>>> the Rtools path before issuing R CMD ... that would be great. If so it
>>> must have occurred silently at some point since I have spent hours in
>>> past years trying to track down why another program I was using did
>>> not work only to discover that it was Rtools.  Surely this was also
>>> your own understanding since devtools, maintains an Rtools path
>>> database which ought to be unnecessary if R is able to find Rtools
>>> itself.
>>
>> I think we are having a failure of communication: Rtools does not set
>> the path, so that you must do so, every time you use it. There is no
>> other way to prevent it from interfering from some other windows
>> software, except by tightly confining the scope in which it enters the
>> path. When I first starting working with Rtools, I thought this was a
>> terribly frustrating decision - why didn't the default installer
>> always put rtools on the path? But now I see it's the only way - it
>> avoids conflicts with other software, and without that default there'd
>> be no way to have multiple versions of rtools installed. That said, I
>> think the logic that Rstudio and devtools uses to find rtools would
>> have been helpful to include in base R, but that's not so important
>> now that it's available in a package. (And if any big change was made,
>> I'd probably argue it'd be better just to always bundle rtools with R
>> on windows - I think it's a key part of the philosophy of R that users
>> can easily become developers. But there are obviously other
>> considerations.)
>>
>> To clarify, the rtools database in devtools does not contain a list of
>> locations of rtools, but the directories inside of an rtools
>> installation that need to be avail

Re: [Rd] vignettes: problems with PDF compaction

2013-04-21 Thread Michael Friendly
On 4/21/2013 1:47 PM, Uwe Ligges wrote:
>> Since vignettes are re-built from sources and then installed into
>> inst/doc, I don't see why
>> PDF compaction cannot be run as part of the build process. That is, if
>> R CMD check --as-cran detects a problem, shouldn't there be some 
>> option for
>> R CMD build that would run gs+qpdf to correct it?
>
> Yes, see
>
> R CMD build --help
>
>
> that tells you
>
>   --compact-vignettes=  try to compact PDF files under inst/doc:
> "no" (default), "qpdf", "gs", "gs+qpdf", "both"
I meant that perhaps R-Forge and CRAN could *automatically* do the 
compaction.

I *do* run R CMD build on my machine with options
--compact-vignettes=qpdf --keep-empty-dirs --resave-data

giving the log info:

* checking for file 'C:/Documents/workspace/heplots/DESCRIPTION' ... OK
* preparing 'heplots':
* checking DESCRIPTION meta-information ... OK
* installing the package to re-build vignettes
* creating vignettes ... OK
* compacting vignettes and other PDF files
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* looking to see if a 'data/datalist' file should be added
* re-saving image files
* building 'heplots_1.0-9.tar.gz'

However:
(a) the heplots_1.0-9.tar.gz source package is built outside of the 
workspace source tree I sync with R-Forge
(b) when I examine the heplots_1.0-9.tar.gz source package, the file 
heplots/inst/doc/HE-examples has
not been modified in size.
So, I still don't know how to correct this on my end.

-- 
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University  Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele StreetWeb:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Gabor Grothendieck
On Sun, Apr 21, 2013 at 1:48 PM, Prof J C Nash (U30A)  wrote:
>
> While as a Linux user who has not so far been banished to Winland I have not
> experienced this problem, it seems to be the type of issue where a "how to",
> for example, on the R Wiki, would be helpful. Moreover, surely this is a
> name conflict on different platforms, so possibly a list of these in a
> related location would also be useful. I have been struggling unsuccessfully
> to remember one that bit me recently when I did have to help a Windows user.
> It was not a major disaster, but more of a large sucking sound of time being
> wasted figuring out something that was just a shade more than trivial.
>
> If there are folk who can get this started, do include me in an off-list
> copy and I'll be willing to test/edit wiki material.

The bottom line is that the conflicting executables are find and sort.
 Its best to not put Rtools on your path and its probably simplest
just to use R.bat or Rpathset.bat from my batchfiles
(http://batchfiles.googlecode.com) if you are doing it from the cmd
line or Hadley's devtools (install.packages("devtools")) if you are
working from within R.  Also Rcpp has a workaround built into it as
well which would be applicable when using C++ in conjunction with that
package.

Although this is annoying and can lead to extremely hard to detect
errors if you don't know about it the R Windows environment is
actually quite nice. otherwise  You get a GUI and most of the packages
come as binaries so you don't have to build anything to use packages
off CRAN in almost all cases.

--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Gabor Grothendieck
On Sun, Apr 21, 2013 at 12:57 PM, Hadley Wickham  wrote:
 Because it can conflict with other Windows software unless you add a
 layer over it.  What other popular software that runs on Windows has
 these problems?  I can't think of any.  The closest I can come up with
 was that for a short time after git was ported to Windows it would
 change the font of the Windows console but there was an immediate hue
 and cry about it having no business messing with the rest of Windows
 and it was quickly rectified.
>>>
>>> I don't understand: unless you modify settings in the default install,
>>> Rtools *does not* affect other windows software in any way.
>>
>> If its the case that it now works from the cmd line without setting
>> the Rtools path before issuing R CMD ... that would be great. If so it
>> must have occurred silently at some point since I have spent hours in
>> past years trying to track down why another program I was using did
>> not work only to discover that it was Rtools.  Surely this was also
>> your own understanding since devtools, maintains an Rtools path
>> database which ought to be unnecessary if R is able to find Rtools
>> itself.
>
> I think we are having a failure of communication: Rtools does not set
> the path, so that you must do so, every time you use it. There is no
> other way to prevent it from interfering from some other windows
> software, except by tightly confining the scope in which it enters the
> path. When I first starting working with Rtools, I thought this was a
> terribly frustrating decision - why didn't the default installer
> always put rtools on the path? But now I see it's the only way - it
> avoids conflicts with other software, and without that default there'd
> be no way to have multiple versions of rtools installed. That said, I
> think the logic that Rstudio and devtools uses to find rtools would
> have been helpful to include in base R, but that's not so important
> now that it's available in a package. (And if any big change was made,
> I'd probably argue it'd be better just to always bundle rtools with R
> on windows - I think it's a key part of the philosophy of R that users
> can easily become developers. But there are obviously other
> considerations.)
>
> To clarify, the rtools database in devtools does not contain a list of
> locations of rtools, but the directories inside of an rtools
> installation that need to be available on the path. This list has
> changed over time as the tools needed by R have changed. I don't see
> any way of avoiding that (except perhaps by storing those in the
> registry, but regardless there's no way to go back in time and fix old
> decisions). Devtools (following the logic of rstudio) looks in a
> number of places to find rtools, first looking in the path and then in
> the registry, and takes considerable care to ensure that the versions
> of R and rtools match (another reason why the database is necessary).

Yes, that is what I thought until you seemed to be saying otherwise
but it seems we just misunderstood each  other and, in fact,  no one
disputes the need to put Rtools on the path nor that it conflicts with
other Windows programs and potentially causes other programs on your
PC not to work.  In fact that was one of the motivations I had for
developing the batchfiles as I once spent hours tracking down a
problem due to Rtools.

Also I understand that the devtools database uses relative paths and
wasn't faulting devtools for this but only pointing out that the
database's existence was a consequence of the need to set up the paths
in the first place which is what we were discussing - not devtools.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Prof J C Nash (U30A)


While as a Linux user who has not so far been banished to Winland I have 
not experienced this problem, it seems to be the type of issue where a 
"how to", for example, on the R Wiki, would be helpful. Moreover, surely 
this is a name conflict on different platforms, so possibly a list of 
these in a related location would also be useful. I have been struggling 
unsuccessfully to remember one that bit me recently when I did have to 
help a Windows user. It was not a major disaster, but more of a large 
sucking sound of time being wasted figuring out something that was just 
a shade more than trivial.


If there are folk who can get this started, do include me in an off-list 
copy and I'll be willing to test/edit wiki material.


JN

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] vignettes: problems with PDF compaction

2013-04-21 Thread Uwe Ligges



On 21.04.2013 19:28, Michael Friendly wrote:

[Env: OS: Win Xp; R 2.15.2; IDE: eclipse/StatET]

Each time I update my heplots package, I get warnings from R CMD check
on R-Forge,

* checking sizes of PDF files under ‘inst/doc’ ... WARNING
   ‘gs+qpdf’ made some significant size reductions:
  compacted ‘HE-examples.pdf’ from 739Kb to 366Kb

and upon submission to CRAN, a message from maintainers:

On CRAN now: but again there were warnings about significant size
reductions in PDF compaction, which should really be fixed on your end.

however, I am unable to find what to do to fix this on my end. In my
package directory,
I have the vignette sources all under vignettes/, with copies of the
.pdf and .Rnw
under inst/doc for historical reasons. [Q: can I now safely delete the
copies under
inst/doc ?]

inst/doc/
HE-examples.pdf
HE-examples.Rnw
vignettes/
HE-examples.pdf
HE-examples.Rnw
HE-examples.bib
fig/
...

I have qpdf installed:
 > Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"c:\\Rtools\\bin\\qpdf.exe"
 >

but, if I try to run it on the vignettes/HE-examples.pdf file, nothing
happens:

 >
tools::compactPDF("C:/Documents/workspace/heplots/vignettes/HE-examples.pdf")

 >

Since vignettes are re-built from sources and then installed into
inst/doc, I don't see why
PDF compaction cannot be run as part of the build process. That is, if
R CMD check --as-cran detects a problem, shouldn't there be some option for
R CMD build that would run gs+qpdf to correct it?


Yes, see

R CMD build --help


that tells you

  --compact-vignettes=  try to compact PDF files under inst/doc:
"no" (default), "qpdf", "gs", "gs+qpdf", "both"


Best,
Uwe Ligges




The idea of vignettes for R packages is a good thing, but, this problem
(and others with vignettes) discourages me from using vignettes in
packages, a bad thing.



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] vignettes: problems with PDF compaction

2013-04-21 Thread Michael Friendly

[Env: OS: Win Xp; R 2.15.2; IDE: eclipse/StatET]

Each time I update my heplots package, I get warnings from R CMD check
on R-Forge,

* checking sizes of PDF files under ‘inst/doc’ ... WARNING
  ‘gs+qpdf’ made some significant size reductions:
 compacted ‘HE-examples.pdf’ from 739Kb to 366Kb

and upon submission to CRAN, a message from maintainers:

On CRAN now: but again there were warnings about significant size
reductions in PDF compaction, which should really be fixed on your end.

however, I am unable to find what to do to fix this on my end. In my 
package directory,
I have the vignette sources all under vignettes/, with copies of the 
.pdf and .Rnw
under inst/doc for historical reasons. [Q: can I now safely delete the 
copies under

inst/doc ?]

inst/doc/
HE-examples.pdf
HE-examples.Rnw
vignettes/
HE-examples.pdf
HE-examples.Rnw
HE-examples.bib
fig/
...

I have qpdf installed:
> Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"c:\\Rtools\\bin\\qpdf.exe"
>

but, if I try to run it on the vignettes/HE-examples.pdf file, nothing 
happens:


> 
tools::compactPDF("C:/Documents/workspace/heplots/vignettes/HE-examples.pdf")

>

Since vignettes are re-built from sources and then installed into 
inst/doc, I don't see why

PDF compaction cannot be run as part of the build process. That is, if
R CMD check --as-cran detects a problem, shouldn't there be some option for
R CMD build that would run gs+qpdf to correct it?

The idea of vignettes for R packages is a good thing, but, this problem 
(and others with vignettes) discourages me from using vignettes in 
packages, a bad thing.


--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University  Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele StreetWeb:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Hadley Wickham
>>> Because it can conflict with other Windows software unless you add a
>>> layer over it.  What other popular software that runs on Windows has
>>> these problems?  I can't think of any.  The closest I can come up with
>>> was that for a short time after git was ported to Windows it would
>>> change the font of the Windows console but there was an immediate hue
>>> and cry about it having no business messing with the rest of Windows
>>> and it was quickly rectified.
>>
>> I don't understand: unless you modify settings in the default install,
>> Rtools *does not* affect other windows software in any way.
>
> If its the case that it now works from the cmd line without setting
> the Rtools path before issuing R CMD ... that would be great. If so it
> must have occurred silently at some point since I have spent hours in
> past years trying to track down why another program I was using did
> not work only to discover that it was Rtools.  Surely this was also
> your own understanding since devtools, maintains an Rtools path
> database which ought to be unnecessary if R is able to find Rtools
> itself.

I think we are having a failure of communication: Rtools does not set
the path, so that you must do so, every time you use it. There is no
other way to prevent it from interfering from some other windows
software, except by tightly confining the scope in which it enters the
path. When I first starting working with Rtools, I thought this was a
terribly frustrating decision - why didn't the default installer
always put rtools on the path? But now I see it's the only way - it
avoids conflicts with other software, and without that default there'd
be no way to have multiple versions of rtools installed. That said, I
think the logic that Rstudio and devtools uses to find rtools would
have been helpful to include in base R, but that's not so important
now that it's available in a package. (And if any big change was made,
I'd probably argue it'd be better just to always bundle rtools with R
on windows - I think it's a key part of the philosophy of R that users
can easily become developers. But there are obviously other
considerations.)

To clarify, the rtools database in devtools does not contain a list of
locations of rtools, but the directories inside of an rtools
installation that need to be available on the path. This list has
changed over time as the tools needed by R have changed. I don't see
any way of avoiding that (except perhaps by storing those in the
registry, but regardless there's no way to go back in time and fix old
decisions). Devtools (following the logic of rstudio) looks in a
number of places to find rtools, first looking in the path and then in
the registry, and takes considerable care to ensure that the versions
of R and rtools match (another reason why the database is necessary).

Hadley

--
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Gabor Grothendieck
On Sun, Apr 21, 2013 at 9:49 AM, Hadley Wickham  wrote:
>> Because it can conflict with other Windows software unless you add a
>> layer over it.  What other popular software that runs on Windows has
>> these problems?  I can't think of any.  The closest I can come up with
>> was that for a short time after git was ported to Windows it would
>> change the font of the Windows console but there was an immediate hue
>> and cry about it having no business messing with the rest of Windows
>> and it was quickly rectified.
>
> I don't understand: unless you modify settings in the default install,
> Rtools *does not* affect other windows software in any way.
>

If its the case that it now works from the cmd line without setting
the Rtools path before issuing R CMD ... that would be great. If so it
must have occurred silently at some point since I have spent hours in
past years trying to track down why another program I was using did
not work only to discover that it was Rtools.  Surely this was also
your own understanding since devtools, maintains an Rtools path
database which ought to be unnecessary if R is able to find Rtools
itself.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Hadley Wickham
> Because it can conflict with other Windows software unless you add a
> layer over it.  What other popular software that runs on Windows has
> these problems?  I can't think of any.  The closest I can come up with
> was that for a short time after git was ported to Windows it would
> change the font of the Windows console but there was an immediate hue
> and cry about it having no business messing with the rest of Windows
> and it was quickly rectified.

I don't understand: unless you modify settings in the default install,
Rtools *does not* affect other windows software in any way.

Hadley

--
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Gabor Grothendieck
On Sun, Apr 21, 2013 at 8:18 AM, Hadley Wickham  wrote:
>> The problem is that if you don't just use the PC for running R but use
>> it to run other programs too then any program and that utilizes
>> Windows batch scripts making use of find.exe or sort.exe likely won't
>> work if Rtools is on your path.
>>
>> The fact that devtools, batchfiles and Rcpp have workarounds mitigates
>> it somewhat but the problem should be fixed so it works out-of-the-box
>> once and for all.
>
> I guess I don't see the advantage of that approach (except perhaps for
> simplicity), compared to using the registry to store path information
> and then using environmental variables to set it when needed. It would
> be nice if Rtools didn't override existing windows executables, in the
> same way it would be nice if windows worked like linux out of the box.
> But since it doesn't, and since in general adding more and more
> directories to the path makes it more and more likely for some
> conflict to arise, I think Rtools current approach is very reasonable.

Because it can conflict with other Windows software unless you add a
layer over it.  What other popular software that runs on Windows has
these problems?  I can't think of any.  The closest I can come up with
was that for a short time after git was ported to Windows it would
change the font of the Windows console but there was an immediate hue
and cry about it having no business messing with the rest of Windows
and it was quickly rectified.

Accepting these infelicities just gets one onto a slippery slope.  For
example, as far as I know devtools and Rcpp don't have any current
problems but that could easily change in the future since they keep
databases of Rtools configurations which must be manually updated by
their developers as Rtools evolves -- if Rtools changes they could
stop working for periods of time until new versions are produced.
R.bat in batchfiles was just re-written this year so it is a bit more
robust to such changes but even it would have to be modified if the
changes in Rtools were of sufficient magnitude.  I don't blame these
tools for this but surely this is a symptom that something is
fundamentally wrong with the entire approach since the tight coupling
of what should be independent modules results in the need for ongoing
maintenance.

Some good work was done to rid R and Rtools of dependence on perl but
this effort should not stop there and needs to continue in order to
reduce and eliminate the dependence on third party tools that cause
problems.

(By the way, regarding registry values and environment variables,
R.bat in batchfiles will look at the registry and at environment
variables but it will work even if no registry values or environment
variables have been set by the user provided one uses standard
locations for R and Rtools.  That is, in fact, how I run my own
configuration on Windows.)

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

2013-04-21 Thread Hadley Wickham
> The problem is that if you don't just use the PC for running R but use
> it to run other programs too then any program and that utilizes
> Windows batch scripts making use of find.exe or sort.exe likely won't
> work if Rtools is on your path.
>
> The fact that devtools, batchfiles and Rcpp have workarounds mitigates
> it somewhat but the problem should be fixed so it works out-of-the-box
> once and for all.

I guess I don't see the advantage of that approach (except perhaps for
simplicity), compared to using the registry to store path information
and then using environmental variables to set it when needed. It would
be nice if Rtools didn't override existing windows executables, in the
same way it would be nice if windows worked like linux out of the box.
But since it doesn't, and since in general adding more and more
directories to the path makes it more and more likely for some
conflict to arise, I think Rtools current approach is very reasonable.

Hadley

--
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel