[Rd] A rep_each function

[Richard Cotton]

The rep function is very versatile, but that versatility comes at a
cost: it takes a bit of effort to learn (and remember) its syntax.
This is a problem, since rep is one of the first functions many
beginners will come across.  Of the three main uses of rep, two have
simpler alternatives.

rep(x, times = ) has rep.int
rep(x, length.out  = ) has rep_len

I think that a rep_each function would be a worthy addition for the
third use case

rep(x, each = )

(It might also be worth having rep_times as a synonym for rep.int.)

While this could go in a package, since one of its main benefits is to
help beginners, I feel it ought to go in base R.

Before I submit this as a feature request, I thought I'd check here to
see if there was any enthusiasm.  Does rep_len sound useful to you?

-- 
Regards,
Richie

Learning R 
4dpiecharts.com

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

[Rd] Makevars clean target not in action?

[Randy Lai]

Hi, developers

When I run `R CMD INSTALL --clean my_package`, only the .o files and the .so 
file are removed, however, they were deleted not because of the clean target 
defined in Makevars.
The clean target was indeed not executed.

I have the following simple Marvars to show that clean target is not 
functioning.

Makevars
-

all: foo $(SHLIB)

clean: 
rm -f *.o $(SHLIB)
rm -f b

foo:
touch b


After I run ``R CMD INSTALL --clean my_package``, the file `b` is still there.

Any thought?

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

Re: [Rd] Docker versus Vagrant for reproducability - was: The case for freezing CRAN

[Bennet Fauber]

Vagrant and packer look like the could be useful to developers,
especially when testing, as they make it relatively painless to
'reinstall' a machine to a (mostly) known state.  I find that, no
matter how hard I try, there always seem to be a few keystrokes that
don't make it into the changelog, and recreating from scratch is how I
find them.  Thanks for pointing them out.

I would weigh in on the side of those who are against 'freezing' CRAN.
 The notion of having an R package repository that is frozen is a fine
one, and I would probably support such a thing and find it useful, but
that's not, to my mind, what CRAN is.  CRAN is an open place for
people to put their packages where others can get at them, while they
are under active development and after.  I don't think it a good idea
to make it into something else.

'Freezing it' also seems a bit misguided, as that would freeze it,
warts and all.  Something along the lines of the RHEL or LTS idea,
where perhaps major.minor versions of things are essentially frozen,
but security and bug patches continue seems more right-minded.  Strict
replicability is best done with VM images, though I suppose one should
also put a 'This image packed on ', along with a list of
ingredients, on any VM image.  It probably should be the
responsibility of the researcher to look after their research, if it
isn't already, so the onus of freezing should be there, not at CRAN.

With respect to X, NX is quite nice, though I've had mixed success
with the older, open-source server not always seeming to work.  The
commercial one is free, but limited to two users.  I've used the
classic VNC (in several flavors, which depends on your linux distro)
with ssh tunnels, where you ssh to a text screen, tunneling the port
you want X over, then manually start an Xvnc session.  You can
disconnect from the VNC session and reconnect later and the session
will be running.  NX is essentially the same thing, except it handles
the details of the ssh tunnel for you.  With both, graphical
performance is much, much better than tunneling X directly.

-- bennet
=
HPC Software Support
University of Michigan

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

Re: [Rd] A rep_each function

[Hervé Pagès]

Hi,

On 03/23/2014 05:42 AM, Richard Cotton wrote:

The rep function is very versatile, but that versatility comes at a
cost: it takes a bit of effort to learn (and remember) its syntax.
This is a problem, since rep is one of the first functions many
beginners will come across.  Of the three main uses of rep, two have
simpler alternatives.

rep(x, times = ) has rep.int
rep(x, length.out  = ) has rep_len

I think that a rep_each function would be a worthy addition for the
third use case

rep(x, each = )

(It might also be worth having rep_times as a synonym for rep.int.)


I agree that rep_times() would be a much better name. Because rep.int()
looks like an S3 method for rep(), 'R CMD check' emits the following
NOTE on the BiocGenerics package (where rep.int() is turned into an
S4 generic):

  * checking Rd \usage sections ... NOTE
  S3 methods shown with full name in documentation object 'rep':
‘rep.int’

  The \usage entries for S3 methods should use the \method markup and not
  their full name.
  See the chapter ‘Writing R documentation files’ in the ‘Writing R
  Extensions’ manual.

Cheers,
H.



While this could go in a package, since one of its main benefits is to
help beginners, I feel it ought to go in base R.

Before I submit this as a feature request, I thought I'd check here to
see if there was any enthusiasm.  Does rep_len sound useful to you?



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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