Re: [Rd] Offer zip builds

[Duncan Murdoch]

On 01/06/2019 11:02 p.m., Steven Penny wrote:

If you go here:

https://cran.cnr.berkeley.edu/bin/windows/base

you see EXE installers for Windows. This contrasts with other programming
languages that offer both an executable installer and ZIP files that can be
extracted and run. For example Go:


We did offer both zips and an installer until 2001 or 2002.  It was 
decided then that it wasn't worth the trouble of offering both.


I don't recall anyone asking for the zip in the 17 years after that 
change, until now (though I haven't been paying attention lately, since 
I retired from building the binaries a couple of years ago).


If you think it's worthwhile to do it, then I don't think anyone would 
object if you went ahead and did so.


Duncan Murdoch

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

[Rd] Trivial error in documentation

[David Scott]

This must have been there for a while>

In the datasets package, the help for airquality says:

A data frame with 154 observations on 6 variables.

But:

> str(airquality)
'data.frame':    153 obs. of  6 variables:
 $ Ozone  : int  41 36 12 18 NA 28 23 19 8 NA ...
 $ Solar.R: int  190 118 149 313 NA NA 299 99 19 194 ...
 $ Wind   : num  7.4 8 12.6 11.5 14.3 14.9 8.6 13.8 20.1 8.6 ...
 $ Temp   : int  67 72 74 62 56 66 65 59 61 69 ...
 $ Month  : int  5 5 5 5 5 5 5 5 5 5 ...
 $ Day    : int  1 2 3 4 5 6 7 8 9 10 ...

Regards

David Scott


--
_
David Scott Department of Statistics
The University of Auckland, PB 92019
Auckland 1142,NEW ZEALAND
Phone: +64 9 923 5055, or +64 9 373 7599 ext 85055
Email:  d.sc...@auckland.ac.nz,  Fax: +64 9 373 7018

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

Re: [Rd] Offer zip builds

[Marc Schwartz via R-devel]

> On Jun 3, 2019, at 6:31 PM, Steven Penny  wrote:
> 
> On Mon, Jun 3, 2019 at 4:11 PM Marc Schwartz wrote:
>> I have not tried it, but if that is the case here, you may be able to use the
>> normal R binary installer, but adjust the default install options when
>> prompted, allowing you to customize the install location and other 
>> parameters,
>> that may be suitable in the absence of Admin rights.
>> 
>> Prior statements, not official, would suggest that R Core is not likely to
>> assist in providing official options for useRs to circumvent OS security
>> restrictions.
> 
> Theres nothing nefarious here. It would allow people to use the R environment
> without running an installer. If someone is a new user they may want to try
> R out, and installers can be invasive as they commonly:
> 
> - copy files to install dir
> - copy files to profile dir
> - set registry entries
> - set environment variables
> - set start menu entries
> 
> and historically uninstallers have a bad record of reverting these changes.
> should not put this burden upon new users or even having them resort to 
> virtual
> machine to avoid items above. having a ZIP file allows new users to run the
> R environment, then if they like it perhaps they can run the installer going
> forward. Are you familiar with Windows? As everything I am describing hasnt
> changed in at least 20 years.
> 
> I dont have a criticism of the R installer, I have not run tests to be able to
> determine if its well behaved or not. Its the *not knowing* that is the issue.
> With Windows, every installer could be perceived as a "black box".


Hi,

I am on macOS primarily, albeit, I have run both Windows and Linux routinely in 
years past.

That being said, these days, I do run Windows 10 under a Parallels VM on macOS, 
as I have a single commercial application that I need to run for clients now 
and then, and it sadly only runs on a real Windows install (e.g. not with Wine).

To your points:

The R for Windows FAQ does provide some information on installing R as a 
non-Admin:

  
https://cran.r-project.org/bin/windows/base/rw-FAQ.html#How-do-I-install-R-for-Windows_003f

as well as Registry change related information:

  
https://cran.r-project.org/bin/windows/base/rw-FAQ.html#Does-R-use-the-Registry_003f

There is also information on running from external media:

 
https://cran.r-project.org/bin/windows/base/rw-FAQ.html#Can-I-run-R-from-a-CD-or-USB-drive_003f

and uninstalling:

  
https://cran.r-project.org/bin/windows/base/rw-FAQ.html#How-do-I-UNinstall-R_003f


In addition, the R-Admin manual provides information on the Inno Setup 
installer:

  
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Building-the-Inno-Setup-installer
  
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-Inno-Setup-installer

which leads you to:

  http://jrsoftware.org/isinfo.php

and shows that Inno Setup is, like R, fully open source, hence reviewable and 
not a black box, any more than R itself is. That should not be a surprise...

While I understand the use case you describe, it is, as I noted initially, up 
to R Core to be willing to provide an official release of a ZIP based 
installation. Unless you can make the case to them to expend the finite 
resources that they have to support this as part of each version release 
process, in light of the prior discussions, it is not clear that this appears 
to be a priority.

Again, I do not speak for them.

Otherwise, it falls to the community to volunteer to engage in that activity 
and fulfill the need.

Regards,

Marc

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

Re: [Rd] Offer zip builds

[Marc Schwartz via R-devel]

> On Jun 3, 2019, at 4:40 PM, Abby Spurdle  wrote:
> 
>> If you go here:
>> https://cran.cnr.berkeley.edu/bin/windows/base
>> you see EXE installers for Windows. This contrasts with other programming
>> languages that offer both an executable installer and ZIP files that can
> be
>> extracted and run
> 
> Are you suggesting that R should do the same?
> If so, I second that, excellent idea.
> (However, gzip preferred).
> 
> I've had significant problems with the Windows installer.
> I've never had significant problems with zip files.
> Also, I assuming that the zip approach would be easier for systems
> administrators.
> However, I'm not a systems administrator...
> 
> 
> Abs


Hi,

First, I do not speak for R Core, who would, in the end, be responsible for 
offering something official here.

Second, prior discussions on this topic have generally pointed to:

  https://sourceforge.net/projects/rportable/

as one source for a portable version of R, albeit, with some dependencies (e.g. 
PortableApps framework)

That being said, again, based upon prior discussions on this topic, the typical 
reason for needing a ZIP archive of an R installation, is to circumvent Windows 
OS security restrictions, whereby a useR does not have the requisite Admin 
rights to install R via the default installer.

Thus, you can presumably download a ZIP of an R installation, unzip it in a 
location of your choosing, whereby you can then execute/run the R .exe binary. 
If you can't do that, then a ZIP will not be helpful to you.

I have not tried it, but if that is the case here, you may be able to use the 
normal R binary installer, but adjust the default install options when 
prompted, allowing you to customize the install location and other parameters, 
that may be suitable in the absence of Admin rights.

Prior statements, not official, would suggest that R Core is not likely to 
assist in providing official options for useRs to circumvent OS security 
restrictions.

Regards,

Marc Schwartz

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

Re: [Rd] Offer zip builds

[Abby Spurdle]

> If you go here:
> https://cran.cnr.berkeley.edu/bin/windows/base
> you see EXE installers for Windows. This contrasts with other programming
> languages that offer both an executable installer and ZIP files that can
be
> extracted and run

Are you suggesting that R should do the same?
If so, I second that, excellent idea.
(However, gzip preferred).

I've had significant problems with the Windows installer.
I've never had significant problems with zip files.
Also, I assuming that the zip approach would be easier for systems
administrators.
However, I'm not a systems administrator...


Abs

[[alternative HTML version deleted]]

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

Re: [Rd] stopifnot

[Martin Maechler]

> Suharto Anggono Suharto Anggono 
> on Thu, 30 May 2019 14:45:22 + writes:
> Suharto Anggono Suharto Anggono 
> on Thu, 30 May 2019 14:45:22 + writes:

> Here is a patch to function 'stopifnot' that adds 'evaluated' argument 
and makes 'exprs' argument in 'stopifnot' like 'exprs' argument in 
'withAutoprint'.

> --- stop.R2019-05-30 14:01:15.282197286 +
> +++ stop_new.R2019-05-30 14:01:51.372187466 +

[..]

Thank you, Suharto.

I've looked at the patch and tested it a bit, and also (re)read
your April 15 remarks (cited below).  I now agree that my hacks to
enable dealing with "language objects" (typically class
'expression')  'exprs' has remained hackish and hence not
working in all cases,  and that it may be a better idea to add
a new logical argument (as in other functions) which has to be
"switched" and then leads somewhat simpler and more robust code.

OTOH, of course, this is an API change would typically not go into the R
3.6.x series ... and I have no idea if it would affect much more
than R's own tests/reg-tests-* ...

Even though the argument name 'evaluated' was chosen for
withAutoprint(), I don't find it a very good name anymore, and -
if the change should happen - would probably prefer something
like 'is.language' or 'expr.is.language' or similar..

Could we get any other readers' opinions ?

Martin

> 
> On Mon, 15/4/19, Suharto Anggono Suharto Anggono 
 wrote:

> Subject: Re: [Rd] stopifnot
> To: "Martin Maechler" 
> Cc: r-devel@r-project.org
> Date: Monday, 15 April, 2019, 2:56 AM
 
> Also, in current definition of function 'stopifnot' in R 3.6.0 beta or R 
devel, for 'cl' if 'exprs' is specified, there a case with comment "the *name* 
of an expression". The intent is allowing
> stopifnot(exprs = ee) ,
> where variable 'ee' holds an expression object, to work on the expression 
object.

> It is not quite right to use eval(exprs) . It fails when 'stopifnot' is 
called inside a function, like
> f <- function(ee) stopifnot(exprs = ee)
> f(expression())

> But, how about local=FALSE case? Should the following work?
> f <- function(ee) stopifnot(exprs = ee, local = FALSE)
> f(expression())

> But, why bother making it work, while it is undocumented that 'exprs' 
argument in 'stopifnot' can be an expression? Well, yes, expectation may be set 
from the name "exprs" itself or from argument 'exprs' in function 'source' or 
'withAutoprint'. Function 'withAutoprint' may be the closest match.

> Function 'withAutoprint' has 'evaluated' argument that controls whether 
work is on value of  'exprs' or on 'exprs' as given. I like the approach.

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

Re: [Rd] Possible bug in formatC

[Martin Maechler]

> Randy Cragun 
> on Thu, 30 May 2019 00:26:38 -0400 writes:

> I do not know if this is a bug or a case of improper
> documentation. The documentation for formatC() implies
> that the difference between the options format="f" and
> format="g" is that with "g", scientific format is
> sometimes used. There is another difference between them
> that is not mentioned in the
> documentation. drop0trailing=FALSE is ignored when format
> is set to "g" unless flag contains "#" (this is the
> documented behavior for format="fg").  For instance, the
> first line below return " 2.5", whereas the second returns
> the expected "2.50".

> formatC(2.50, format="g", digits=3, drop0trailing=F)
> formatC(2.50, format="g", digits=3, drop0trailing=F, flag="#")

Well, you have a point that this behavior is not documented in
details (and I assume the text reference "Kernighan and Richie"
is less available for the typical R users than in 1995...)

However, formatC() has been unchanged like that for close to 20
years, so we will most probably not change the function's behavior.

Notice that   drop0trailing=FALSE  is really the default
(and format="g" is also the default for non-character / non-integer numbers).

The design of formatC(*) for numbers has entailed to default to
format="g" which drops trailing zeros most of the time
[whereas the format = "f" does not, unless drop0trailing=TRUE is set.]

Lastly, note that 2.50 and 2.5 are exactly identical as R
numbers; so, your two examples above are identical to the much shorter

   formatC(2.5, digits=3)
   formatC(2.5, digits=3, flag="#")

If you want "extraneous" trailing zeros, the "f" format is your
friend most of the time anyway:

> t(sapply(1:8, function(D) formatC(c(2.5,pi), format="f", digits= D)))
 [,1] [,2]
[1,] "2.5""3.1"   
[2,] "2.50"   "3.14"  
[3,] "2.500"  "3.142" 
[4,] "2.5000" "3.1416"
[5,] "2.5""3.14159"   
[6,] "2.50"   "3.141593"  
[7,] "2.500"  "3.1415927" 
[8,] "2.5000" "3.14159265"
> 

I will add more information to the formatC()  help
page, notably not only mentioning but explaining most of the
'flag's that are available typically(*).

Thank you for raising the issue.

Martin Maechler
ETH Zurich and R Core Team

--
*) as formatC() interfaces to the OS C library, some of the
   availability and meaning of 'flags' is platform dependent.



> --
> sessionInfo():

> R version 3.5.3 (2019-03-11) Platform:
> x86_64-w64-mingw32/x64 (64-bit) Running under: Windows >=
> 8 x64 (build 9200)

> Matrix products: default

> locale: [1] LC_COLLATE=English_United States.1252
> LC_CTYPE=English_United States.1252 [3]
> LC_MONETARY=English_United States.1252 LC_NUMERIC=C

> [5] LC_TIME=English_United States.1252

> attached base packages: [1] stats graphics grDevices utils
> datasets methods base

> loaded via a namespace (and not attached): [1]
> compiler_3.5.3 tools_3.5.3

> __
> 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] rgl install for R 3.7

[Koenker, Roger W]

Many thanks,  I couldn’t find the right way to convince R that freetype was 
installed in /opt/X11 but installing it
from http://mac.r-project.org/libs/ into /usr/local worked immediately without 
any change in my Makevars file.


Roger Koenker
r.koen...@ucl.ac.uk
Department of Economics, UCL
London  WC1H 0AX.


On Jun 2, 2019, at 7:42 PM, Prof Brian Ripley 
mailto:rip...@stats.ox.ac.uk>> wrote:

On 02/06/2019 16:28, Koenker, Roger W wrote:
I’ve installed R 3.7.0 on a new laptop running macos 10.14.5 and have managed 
to get most of my usual packages

I presume 'R 3.7.0' is R-devel: it is not released and may never be released 
under that version.

to compile from source with a ~/.R/Makevars file that looks like this:
CC=/usr/local/clang8/bin/clang
CXX=/usr/local/clang8/bin/clang++
LDFLAGS=-L/usr/local/clang8/lib
CPPFLAGS=-I/usr/local/clang8/include -I/opt/X11/include/freetype2

I suspect you don't want the second: if you have pkg-config it should find 
include paths for you.

FC=/usr/local/gfortran/bin/gfortran
FLIBS=-L/usr/local/gfortran/lib -lgfortran
As usual, the last challenge seems to be to get rgl installed.  Compilation 
_seems_ to go
smoothly, but I now see:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object 
'/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so':
  
dlopen(/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so,
 6): Symbol not found: _FT_Attach_File
  Referenced from: 
/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so

Perhaps you should show the linking line.  A similar setup works for me:

configure: Darwin, so ensuring /opt/X11/bin is at the head of the PATH...
checking for pkg-config... yes
...

Do you have pkg-config (it is not a standard part of macOS, but is available on 
SU's site -- see the R-admin manual)?  You may need to set its path: for rgl I 
used

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

(which should be the default) but for a few packages (Cairo gdtools rsvg)

PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

/usr/local/clang8/bin/clang++ -std=gnu++11 -dynamiclib 
-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module 
-multiply_defined suppress -L/Users/ripley/R/R-devel/lib 
-L/usr/local/clang8/lib -L/usr/local/lib -o rgl.so ABCLineSet.o BBoxDeco.o 
Background.o ClipPlane.o Color.o Disposable.o Light.o LineSet.o LineStripSet.o 
Material.o NULLgui.o PlaneSet.o PointSet.o PrimitiveSet.o RenderContext.o 
Shape.o SphereMesh.o SphereSet.o SpriteSet.o String.o Surface.o TextSet.o 
Texture.o Viewpoint.o api.o assert.o callbacks.o device.o devicemanager.o fps.o 
ftgl.o geom.o gl2ps.o glErrors.o glgui.o gui.o init.o par3d.o pixmap.o 
platform.o pretty.o render.o rglmath.o rglview.o scene.o select.o subscene.o 
win32gui.o win32lib.o x11gui.o x11lib.o -lGLU -lGL -framework GLKit -framework 
OpenGL -dylib_file 
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
 -L/usr/local/lib -lpng16 -L/usr/X11/lib -lX11 -L/usr/local/lib -lfreetype 
-L/Users/ripley/R/R-devel/lib -lR -Wl,-framework -Wl,CoreFoundation

so that is statically linking libfreetype from /usr/local/lib and installed 
from https://mac.r-project.org/libs/freetype-2.5.5-darwin.13-x86_64.tar.gz . 
And that provides a freetype2.pc file, so

% pkg-config freetype2 --cflags
-I/usr/local/include/freetype2 -I/usr/local/include/libpng16
% pkg-config freetype2 --libs
-L/usr/local/lib -lfreetype



There is a comment somewhat after this about rgl requiring XQuartz, but I have  
XQuartz 2.7.11 so I don’t
think that this is the problem.  Apparently, there is still a freetype problem, 
however I’m out of my depth at this
point.   Any suggestions would be most welcome.
Roger Koenker
Honorary Professor
Department of Economics, UCL
London  WC1H 0AX.


--
Brian D. Ripley,  
rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford


[[alternative HTML version deleted]]

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