Re: [Rd] Archive policy and Rcpp?

[Marc Schwartz via R-devel]

Hi Dominick,

While somebody from CRAN might eventually reply here, your query is actually OT 
for R-Devel, which has been, since circa 2015, focused on more technical code 
development (e.g. C/C++/FORTRAN, etc.) and core R development issues, rather 
than on CRAN and package development related topics.

A better option for questions on package development/CRAN related topics would 
be to post to R-Package-Devel:

  https://stat.ethz.ch/mailman/listinfo/r-package-devel

or perhaps better yet in this specific case, directly to the CRAN folks at 
c...@r-project.org.

FWIW, my read of the CRAN policy at:

  https://cran.r-project.org/web/packages/policies.html

would suggest that there is an expectation that older versions of packages are 
"archived in perpetuity".

Regards,

Marc Schwartz
R-Devel Co-Admin


On April 10, 2023 at 10:23:09 AM, Dominick Samperi (djsamp...@gmail.com 
(mailto:djsamp...@gmail.com)) wrote:

> It appears that my archived packages Rcpp and RcppTemplate have
> been removed at CRAN, yet they appeared in the CRAN archives
> until recently.
>
> What is the CRAN policy on archives and removal?
>
> Thanks,
> Dominick
>
> [[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] Making headers self-contained for static analysis

[Marc Schwartz via R-devel]

Hi,

There are a limited number of MIME file types that are accepted through the 
list server, with plain text being one. Even though a patch file should be 
plain text, it is possible that your mail client may not have set the correct 
MIME type for your patch file attachment. If so, that would explain why it was 
filtered from the list.

For future reference, if you change the file extension to ".txt" and then 
attach it, that should get picked up as plain text and get through the list 
server filters.

Regards,

Marc Schwartz
R-Devel Co-Admin


On March 16, 2023 at 2:32:39 PM, Lionel Henry via R-devel 
(r-devel@r-project.org (mailto:r-devel@r-project.org)) wrote:

> People have let me know that the attachment didn't make it through.
> Do patches get filtered out?
>
> Please find it there:
> https://github.com/lionel-/r-svn/commit/e3de56798b1321a3fa8688a42bbb73d763b78024.patch
>
> I'm also happy to post it on the bugzilla if that makes sense.
>
> Best,
> Lionel
>
> On 3/16/23, Lionel Henry wrote:
> > Hello,
> >
> > I started using clangd to get better static analysis and code
> > refactoring tooling with the R sources (using eglot-mode in Emacs, it
> > just works once you've generated a `compile_commands.json` file with
> > `bear make all`). I noticed that the static analyser can't understand
> > several header files because these are not self-contained. So I went
> > through all .h files and inserted the missing includes, cf the
> > attached patch.
> >
> > Making the headers self-contained has consequences for the .c or .cpp
> > files that include them. In the case of C files, the only downside I
> > see is that it might cause users to accidentally rely on indirect
> > inclusion of standard headers, instead of directly including the
> > header to make the dependency explicit as would be good practice.
> > This doesn't seem like a big deal compared to the benefits of enabling
> > static analysis.
> >
> > However in the case of C++ that's more problematic. We don't want to
> > include the C headers because that would pollute the global namespace
> > and users might prefer to import the missing symbols (`size_t` and
> > `FILE`) selectively. Also that wouldn't help static analysis within
> > the header files since the analysers use the C path. So I have guarded
> > inclusion of standard C headers behing a `__cplusplus` check.
> >
> > If that makes sense, would R core consider applying the attached patch
> > to the R sources?
> >
> > Best,
> > Lionel
> >
>
> __
> 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] End of Support Date of Version 3 of “R”

[Marc Schwartz via R-devel]

Hi,

R's software development life cycle is documented here:

  https://www.r-project.org/doc/R-SDLC.pdf

This is available via the Certification link, under Documentation, on the main 
R Project web page:

  https://www.r-project.org

Section 4.4 of the document, on page 10, covers the release cycles, and section 
4.6, on page 11, covers maintenance, support and retirement.

Section 4.6 includes the following text at the end of that section on page 12:

"The x.y.0 releases are maintained via a series of x.y.z patch releases. At a 
new x.y.0 version of R, the prior version is retired from formal support. R 
Core’s efforts are then focused on the new Release (and the on-going 
Development) version. No further development, bug fixes or patches are made 
available for the retired versions. Thus there is always only one current 
version of R. However, the SVN repository will allow older release branches to 
be reopened, should the need arise."


Version 4.0.0 of R was released on April 24, 2020, thus ending formal support 
for version 3.x.x, with the last 3.x.x version being 3.6.3, which was released 
on February 29, 2020.

Regards,

Marc Schwartz


On February 15, 2023 at 10:21:26 AM, Eric Bernard (eric.berna...@michelin.com 
(mailto:eric.berna...@michelin.com)) wrote:

>
> Hello !
>
> Good day.
>
> I'd like to know what is the End of Support Date of Version 3 of R.
>
> Thanks for your answer.
>
> Have a good day.
>
> Best Regards
>
> Eric Bernard
> DCTI/BS/EC
>
> Cordialement.
>
> Eric Bernard
> Michelin
> DCTI/BS/EC
>
>
> [[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-Forge http link redirection setup busted

[Marc Schwartz via R-devel]

Hi,

Only you can unsubscribe yourself.

Please visit:

https://stat.ethz.ch/mailman/options/r-devel

where you can unsubscribe from this list and if needed, get a password 
reminder, after entering your email address.

Regards,

Marc Schwartz 


> On Jul 19, 2021, at 5:30 PM, Arlene Battishill  
> wrote:
> 
> 
> Please unsubscribe me.
> 
>> On Mon, Jul 19, 2021 at 5:15 PM Spencer Graves  
>> wrote:
>> 
>> 
>> On 7/19/21 3:36 PM, Marc Schwartz via R-devel wrote:
>> > Dirk,
>> > 
>> > I have not use R-Forge in years, but on the main page 
>> > (https://r-forge.r-project.org), just before the blue "Latest News" box, 
>> > it shows:
>> > 
>> > "If you experience any problems or need help you can submit a support 
>> > request to the R-Forge team or write an email to r-fo...@r-project.org."
>> > 
>> > I have copied that e-mail address here. The URL for the support request 
>> > form requires a login to R-Forge to access.
>> > 
>> > Also, there appears to be a top level project associated with the 
>> > R-Forge Admins here:
>> > 
>> >https://r-forge.r-project.org/projects/site/
>> > 
>> > with references to the project members in the upper right hand corner.
>> > 
>> > No activity from the Admins there since December 2020, from what I can 
>> > tell...
>> 
>> 
>>   I encourage anyone still trying to use R-Forge to migrate to 
>> GitHub. 
>>   I migrated in 2019 after having many problems with changes not 
>> triggering checks and getting messages like, "there is no package called 
>> 'Matrix'".  There was a discussion on r-package-de...@r-project.org in 
>> January and February of this year on how to do that.  That thread could 
>> probably help anyone interested in doing this.
>> 
>> 
>>   Spencer Graves
>> 
>> > 
>> > Regards,
>> > 
>> > Marc Schwartz
>> > 
>> > 
>> > Dirk Eddelbuettel wrote on 7/19/21 4:03 PM:
>> >>
>> >> (Sorry for posting here but the top-level r-forge page does not make 
>> >> it all
>> >> that clear where to contact its admins.)
>> >>
>> >> When an old-style 'http' URL at r-forge is resolved / redirected to 
>> >> 'https',
>> >> it is corrupted and the redirect breaks.  That required a package 
>> >> re-upload
>> >> for me a few days ago (as the CRAN url checker is unhappy about a 
>> >> borked URL)
>> >> and you can see it live too e.g. via
>> >>
>> >>
>> >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>> >>
>> >> and going to 'rcpp-devel archives' where the hover URL is (note 'http')
>> >>
>> >>http://lists.r-forge.r-project.org/pipermail/rcpp-devel/
>> >>
>> >> which when followed 'naively' drops the / between .org and pipermail and
>> >> gets a 404
>> >>
>> >>https://lists.r-forge.r-project.orgpipermail/rcpp-devel/
>> >>
>> >> Reinjecting the missing / helps as
>> >>
>> >>https://lists.r-forge.r-project.org/pipermail/rcpp-devel/
>> >>
>> >> works fine.  This is likely a typo / error in the redirection setup of 
>> >> the
>> >> web server.
>> >>
>> >> I would be very grateful if someone could pass this on to whoever 
>> >> looks after
>> >> r-forge these days.
>> >>
>> >> Best,  Dirk
>> >>
>> > 
>> > __
>> > 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

[[alternative HTML version deleted]]

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

Re: [Rd] R-Forge http link redirection setup busted

[Marc Schwartz via R-devel]

Dirk,

I have not use R-Forge in years, but on the main page 
(https://r-forge.r-project.org), just before the blue "Latest News" box, 
it shows:


"If you experience any problems or need help you can submit a support 
request to the R-Forge team or write an email to r-fo...@r-project.org."


I have copied that e-mail address here. The URL for the support request 
form requires a login to R-Forge to access.


Also, there appears to be a top level project associated with the 
R-Forge Admins here:


  https://r-forge.r-project.org/projects/site/

with references to the project members in the upper right hand corner.

No activity from the Admins there since December 2020, from what I can 
tell...


Regards,

Marc Schwartz


Dirk Eddelbuettel wrote on 7/19/21 4:03 PM:


(Sorry for posting here but the top-level r-forge page does not make it all
that clear where to contact its admins.)

When an old-style 'http' URL at r-forge is resolved / redirected to 'https',
it is corrupted and the redirect breaks.  That required a package re-upload
for me a few days ago (as the CRAN url checker is unhappy about a borked URL)
and you can see it live too e.g. via

   https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

and going to 'rcpp-devel archives' where the hover URL is (note 'http')

   http://lists.r-forge.r-project.org/pipermail/rcpp-devel/

which when followed 'naively' drops the / between .org and pipermail and
gets a 404

   https://lists.r-forge.r-project.orgpipermail/rcpp-devel/

Reinjecting the missing / helps as

   https://lists.r-forge.r-project.org/pipermail/rcpp-devel/

works fine.  This is likely a typo / error in the redirection setup of the
web server.

I would be very grateful if someone could pass this on to whoever looks after
r-forge these days.

Best,  Dirk



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

Re: [Rd] subset argument in nls() and possibly other functions

[Marc Schwartz via R-devel]

Hi John,

In scanning some of the more popular model functions (e.g. lm(), glm(), 
lme(), coxph(), etc.), none seem to provide examples of the use of the 
'subset' argument, even though it is documented for them.


That being said, there is some old (2003) documentation by Prof Ripley here:

https://developer.r-project.org/model-fitting-functions.html

that may be helpful, and where the link to the lm() function source code 
on the above page should be:


  https://svn.r-project.org/R/trunk/src/library/stats/R/lm.R

Within that source file, you might want to focus upon the 
model.frame.lm() function, the basic form which is used internally in 
many (most?, all?) of the typical model related functions in R to create 
the internal data frame from the specified formula, that is then used to 
create the model.


There is a parallel model.frame.glm() function for glm() here:

https://svn.r-project.org/R/trunk/src/library/stats/R/glm.R

There is also a 2003 paper by Thomas Lumley on non-standard evaluation 
that may be helpful:


https://developer.r-project.org/nonstandard-eval.pdf

The help for the generic ?model.frame has the following text for the 
'subset' argument:


"a specification of the rows to be used: defaults to all rows. This can 
be any valid indexing vector (see|[.data.frame 
<http://127.0.0.1:13384/library/stats/help/[.data.frame>|) for the rows 
of|data|or if that is not supplied, a data frame made up of the 
variables used in|formula|."


I cannot recall off-hand, using the 'subset' argument myself in ~20 
years of using R, but do seem to recall some old discussions on the 
e-mail lists, which I cannot seem to locate at present. A search via 
rseek.org may yield some benefit.


Regards,

Marc Schwartz


J C Nash wrote on 7/13/21 7:21 PM:

In mentoring and participating in a Google Summer of Code project "Improvements to 
nls()",
I've not found examples of use of the "subset" argument in the call to nls(). 
Moreover,
in searching through the source code for the various functions related to 
nls(), I can't
seem to find where subset is used, but a simple example, included below, 
indicates it works.
Three approaches all seem to give the same results.

Can someone point to documentation or code so we can make sure we get our 
revised programs
to work properly? The aim is to make them more maintainable and provide 
maintainer documentation,
along with some improved functionality. We seem, for example, to already be 
able to offer
analytic derivatives where they are feasible, and should be able to add 
Marquardt-Levenberg
stabilization as an option.

Note that this "subset" does not seem to be the "subset()" function of R.

John Nash

# CroucherSubset.R -- https://walkingrandomly.com/?p=5254

xdata = c(-2,-1.64,-1.33,-0.7,0,0.45,1.2,1.64,2.32,2.9)
ydata = 
c(0.699369,0.700462,0.695354,1.03905,1.97389,2.41143,1.91091,0.919576,-0.730975,-1.42001)
Cform <- ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata)
Cstart<-list(p1=1,p2=0.2)
Cdata<-data.frame(xdata, ydata)
Csubset<-1:8 # just first 8 points

# Original problem - no subset
fit0 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Cdata, 
start=list(p1=1,p2=.2))
summary(fit0)

# via subset argument
fit1 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Cdata, 
start=list(p1=1,p2=.2), subset=Csubset)
summary(fit1)

# via explicit subsetting
Csdata <- Cdata[Csubset, ]
Csdata
fit2 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Csdata, 
start=list(p1=1,p2=.2))
summary(fit2)

# via weights -- seems to give correct observation count if zeros not recognized
wts <- c(rep(1,8), rep(0,2))
fit3 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Cdata, 
weights=wts, start=list(p1=1,p2=.2))
summary(fit3)

__
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

[Rd] Status of "**" operator

[Marc Schwartz via R-devel]

Hi All,

I was just sent some older R code from circa 2004, which contains the 
use of the "**" operator, which is parsed as "^".


From looking at ?"**", I see the following in the Note section:

"** is translated in the parser to ^, but this was undocumented for many 
years. It appears as an index entry in Becker et al (1988), pointing to 
the help for Deprecated but is not actually mentioned on that page. Even 
though it had been deprecated in S for 20 years, it was still accepted 
in R in 2008."



In using R 4.1.0:

> 2**3
[1] 8

the operator is still accepted in 2021.

Thus, has there been any discussion regarding the deprecation of this 
operator, or should the help file at least be updated to reflect the 
status in 2021?


Thanks,

Marc Schwartz

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

[Rd] power.prop.test() documentation question

[Marc Schwartz via R-devel]

Hi All,

Based upon a discussion on power/sample size calculations on another, non-R 
related, list, some light bulbs went on regarding the assumptions of what type 
of statistical test is going to be used with various power/sample size 
calculators/functions for proportions. In some cases, this is clearly stated, 
in others, it is not.

In the case of power.prop.test() and comparing outputs against other 
calculators, there appears to be an implied presumption that an un-corrected 
chi-square test will be used, as opposed to a corrected chi-square or Fisher 
Exact Test (FET), in the 2x2 case. Sample sizes for the un-corrected chi-square 
will generally be smaller than either the corrected chi-square or the FET, 
given similar inputs, where the latter two, not surprisingly given their common 
conservative bias, will yield similar sample size results. 

This is not explicitly documented in ?power.prop.test, though it is in some 
other applications, as noted above. 

As a particular example from the other discussions, using p1 = 0.142, p2 = 
0.266, with power = 0.8 and sig.level = 0.05, power.prop.test() yields a sample 
size of ~165 per group. Other calculators that presume either a corrected 
chi-square or the FET, yield ~180 per group. 

I raise this issue, as should one use the function to calculate a prospective 
sample size for a study, and then actually use a corrected chi-square to 
analyze the data, per routine use and/or a formal analysis plan, the power of 
that test will be lower than that which was presumed for the a priori 
calculation. It may not make a big difference in some proportion of the cases 
relative to p <= alpha, but given the idiosyncrasies of the observed data at 
the end of the study, along with the effective loss of some power, it may very 
well be relevant to the results and their strict interpretation. It may also 
impact, to some extent, the a priori planning for the study, relative to the 
needed target sample size, budgeting and other considerations for a study 
sponsor.

Is there any logic in adding some notes to ?power.prop.test, to indicate the 
implied presumption of the use of an un-corrected chi-square test? 

Thanks for any comments, including telling me that I need more caffeine and to 
increase my oxygen uptake...

Regards,

Marc Schwartz

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

Re: [Rd] Error in unsplit() with tibbles

[Marc Schwartz via R-devel]

Hi,

Peter, thanks for the clarification.


Mario, I was not looking to debate the pros and cons of each environment, 
simply to point out that expecting mutually compatible functionality is not 
generalizable, especially when third party authors can make structural changes 
to their objects over time, that can then make them incompatible with base R 
functions, even if they may be today.

That is a key basis for third party packages offering specific class methods, 
whether S3 or S4, for object classes that are unique to their packages. That 
approach provides the obvious level of transparency.

For the tidyverse folks to offer a variant of split() and unsplit() that have 
specific methods for tibbles would seem entirely reasonable, presuming that 
they don't have a philosophical barrier to doing so, in deference to other 
approaches that do conform to their preferred function syntax.

Regards,

Marc


> On Nov 21, 2020, at 12:04 PM, Mario Annau  wrote:
> 
> Cool - thank you Peter!
> 
> @Marc: This is really not a tidyverse vs base-R debate and I personally think 
> that they should both work together for most parts. The common environment is 
> still R. But just to give you the full picture I also filed a bug for tibbles 
> (https://github.com/tidyverse/tibble/issues/829 
> <https://github.com/tidyverse/tibble/issues/829>). With these two fixes I 
> think that split/unsplit would work for tibbles and users (like me) just 
> don't have to care in which "environments" they are working in.
> 
> Cheers,
> Mario
> 
> 
> On Sat, 21 Nov 2020 at 17:54, Peter Dalgaard  <mailto:pda...@gmail.com>> wrote:
> I get the sentiment, but this is really just bad coding (on my own part, I 
> suspect), so we might as well just fix it...
> 
> -pd
> 
> > On 21 Nov 2020, at 17:42 , Marc Schwartz via R-devel  > <mailto:r-devel@r-project.org>> wrote:
> > 
> > 
> >> On Nov 21, 2020, at 10:55 AM, Mario Annau  >> <mailto:mario.an...@gmail.com>> wrote:
> >> 
> >> Hello,
> >> 
> >> using the `unsplit()` function with tibbles currently leads to the
> >> following error:
> >> 
> >>> mtcars_tb <- as_tibble(mtcars, rownames = NULL)
> >>> s <- split(mtcars_tb, mtcars_tb$gear)
> >>> unsplit(s, mtcars_tb$gear)
> >> Error: Must subset rows with a valid subscript vector.
> >> ℹ Logical subscripts must match the size of the indexed input.
> >> x Input has size 15 but subscript `rep(NA, len)` has size 32.
> >> Run `rlang::last_error()` to see where the error occurred.
> >> 
> >> Tibble seems to (rightly) complain, that a logical vector has been used for
> >> subsetting which does not have the same length as the data.frame (rows).
> >> Since `NA` is a logical value, the subset should be changed to
> >> `NA_integer_` in `unsplit()`:
> >> 
> >>> unsplit
> >> function (value, f, drop = FALSE)
> >> {
> >>   len <- length(if (is.list(f)) f[[1L]] else f)
> >>   if (is.data.frame(value[[1L]])) {
> >>   x <- value[[1L]][rep(*NA_integer_*, len), , drop = FALSE]
> >>   rownames(x) <- unsplit(lapply(value, rownames), f, drop = drop)
> >>   }
> >>   else x <- value[[1L]][rep(NA, len)]
> >>   split(x, f, drop = drop) <- value
> >>   x
> >> }
> >> 
> >> Cheers,
> >> Mario
> > 
> > 
> > Hi,
> > 
> > Perhaps I am missing something, but if you are using objects, like tibbles, 
> > that are intended to be part of another environment, in this case the 
> > tidyverse, why would you not use functions to manipulate these objects that 
> > were specifically created in the other environment?
> > 
> > I don't use the tidyverse, but it seems to me that to expect base R 
> > functions to work with objects not created in base R, is problematic, even 
> > though, perhaps by coincidence, they may work without adverse effects, as 
> > appears to be the case with split(). 
> > 
> > In other words, you should not, in reality, have had an a priori 
> > expectation that split() would work with a tibble either.
> > 
> > Rather than modifying the base R functions, like unsplit(), as you are 
> > suggesting, to be compatible with these third party objects, the burden 
> > should either be on you to use relevant tidyverse functions, or on the 
> > authors of the tidyverse to provide relevant class methods to provide that 
> > functionality.
> > 
> > Regards,
> > 
> > Marc Schwartz
> > 

[[alternative HTML version deleted]]

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

Re: [Rd] Error in unsplit() with tibbles

[Marc Schwartz via R-devel]

> On Nov 21, 2020, at 10:55 AM, Mario Annau  wrote:
> 
> Hello,
> 
> using the `unsplit()` function with tibbles currently leads to the
> following error:
> 
>> mtcars_tb <- as_tibble(mtcars, rownames = NULL)
>> s <- split(mtcars_tb, mtcars_tb$gear)
>> unsplit(s, mtcars_tb$gear)
> Error: Must subset rows with a valid subscript vector.
> ℹ Logical subscripts must match the size of the indexed input.
> x Input has size 15 but subscript `rep(NA, len)` has size 32.
> Run `rlang::last_error()` to see where the error occurred.
> 
> Tibble seems to (rightly) complain, that a logical vector has been used for
> subsetting which does not have the same length as the data.frame (rows).
> Since `NA` is a logical value, the subset should be changed to
> `NA_integer_` in `unsplit()`:
> 
>> unsplit
> function (value, f, drop = FALSE)
> {
>len <- length(if (is.list(f)) f[[1L]] else f)
>if (is.data.frame(value[[1L]])) {
>x <- value[[1L]][rep(*NA_integer_*, len), , drop = FALSE]
>rownames(x) <- unsplit(lapply(value, rownames), f, drop = drop)
>}
>else x <- value[[1L]][rep(NA, len)]
>split(x, f, drop = drop) <- value
>x
> }
> 
> Cheers,
> Mario


Hi,

Perhaps I am missing something, but if you are using objects, like tibbles, 
that are intended to be part of another environment, in this case the 
tidyverse, why would you not use functions to manipulate these objects that 
were specifically created in the other environment?

I don't use the tidyverse, but it seems to me that to expect base R functions 
to work with objects not created in base R, is problematic, even though, 
perhaps by coincidence, they may work without adverse effects, as appears to be 
the case with split(). 

In other words, you should not, in reality, have had an a priori expectation 
that split() would work with a tibble either.

Rather than modifying the base R functions, like unsplit(), as you are 
suggesting, to be compatible with these third party objects, the burden should 
either be on you to use relevant tidyverse functions, or on the authors of the 
tidyverse to provide relevant class methods to provide that functionality.

Regards,

Marc Schwartz

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

Hi Uwe,

Thanks for taking the time to reply.

Would you be willing to clarify/confirm the current situation regarding the 
hosting of non-FOSS packages on CRAN, such as those with ACM or Creative 
Commons license variants that have non-commercial use restrictions? 

These are presently included in the license.db file.

Are these on CRAN now because they are acceptable under the current policy, or 
are they on CRAN now, as Duncan posited, because they were acceptable under 
older policies and it would be disruptive to remove them now?

Thanks,

Marc


> On Oct 23, 2020, at 8:57 AM, Uwe Ligges  
> wrote:
> 
> I do not want to make many general comments about licenses in public, as this 
> is a very difficult matter and I am not a lawyer.
> 
> But let me cite from the CRAN policies:
> 
> "Packages with licenses not listed at 
> https://svn.r-project.org/R/trunk/share/licenses/license.db will generally 
> not be accepted. "
> 
> Further, I see in the discussions that you talked about depending on a 
> software with a non-FOSS license. The CRAN team's point of view, for short, 
> is:
> A package with a FOSS license cannot strictly depend on a package/software 
> that is non-FOSS. Obviously, the FOSS package cannot be used under its own 
> license conditions in that case.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> On 23.10.2020 14:25, Ege Rubak wrote:
>> Hi all,
>> My two cents are below Marc's summary here:
>> On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
>>> Right now, the interpretation, without further clarification from
>>> CRAN, would be, it is ok for a package to be on CRAN with license
>>> based usage restrictions included (e.g. for non-commercial use), but
>>> a package on CRAN, irrespective of it's own license, cannot
>>> "interact" with other packages that do have restrictions...which
>>> seems inconsistent.
>> It depends a bit what is meant by "interact". Years ago `spatstat` used
>> `gpclib` with a non-commercial license to do polygonal operations. The
>> solution was to list `gpclib` in `Suggests` and require the user to
>> make an active choice to use this piece of software with a warning
>> about non-commercial use. I find this to be an OK solution in lack of
>> completely free alternatives. These days `gpclib` is still on CRAN and
>> only has reverse `Suggests` and `Enhances`, so that seems fairly
>> consistent.
>> In the long run this was unsatisfatory and our specific problem was
>> solved by Adrian Baddeley by making the `polyclip` package.
>> Kind regards,
>> Ege
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 23, 2020, at 8:25 AM, Ege Rubak  wrote:
> 
> Hi all,
> 
> My two cents are below Marc's summary here:
> 
> On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
>> Right now, the interpretation, without further clarification from
>> CRAN, would be, it is ok for a package to be on CRAN with license
>> based usage restrictions included (e.g. for non-commercial use), but
>> a package on CRAN, irrespective of it's own license, cannot
>> "interact" with other packages that do have restrictions...which
>> seems inconsistent.
> 
> It depends a bit what is meant by "interact". Years ago `spatstat` used
> `gpclib` with a non-commercial license to do polygonal operations. The
> solution was to list `gpclib` in `Suggests` and require the user to
> make an active choice to use this piece of software with a warning
> about non-commercial use. I find this to be an OK solution in lack of
> completely free alternatives. These days `gpclib` is still on CRAN and
> only has reverse `Suggests` and `Enhances`, so that seems fairly
> consistent.
> 
> In the long run this was unsatisfatory and our specific problem was
> solved by Adrian Baddeley by making the `polyclip` package.
> 
> Kind regards,
> Ege


Hi Ege,

The use of "Suggests" may be the relevant difference here. My use of the word 
"interact" was focused on the text in the CRAN policy that I quoted in my 
initial reply:

"Such packages are not permitted to require (e.g., by specifying in ‘Depends’, 
‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package or external 
software which restricts users or usage."

As Duncan noted in his reply, there may be time based differences that are 
relevant here, if the CRAN policy had changed at some point, and there was, in 
effect, a grand-fathering of older packages that perhaps would not be accepted 
today under the current policy.

Regards,

Marc

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

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi Uwe,

Thanks for your reply.

I appreciate all of the efforts by the CRAN team here.

Regards,

Marc


> On Oct 23, 2020, at 8:47 AM, Uwe Ligges  
> wrote:
> 
> Windows binaries may be delayed these days, but they are generated in a bunch 
> R-flavour-wise. They typical delay after a source package publication should 
> be less then 72 hours ideally.
> 
> Best,
> Uwe
> 
> On 23.10.2020 14:05, Marc Schwartz wrote:
>> Hi All,
>> Just a quick note to indicate that one of the two Windows binaries for the 
>> package appeared overnight (EDT). Not sure if this experience is 
>> representative for others, or just a temporary bump in the road.
>> Regards,
>> Marc
>>> On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:
>>> 
>>> Hi All,
>>> 
>>> Just thought that I would check to see if there are any known issues/delays 
>>> for CRAN in creating R release and devel binaries for Windows for updated 
>>> packages.
>>> 
>>> It has been four days since I submitted an update and the other binaries 
>>> were created within a couple of days. The two Windows binaries are the only 
>>> outstanding updates pending.
>>> 
>>> Thanks!
>>> 
>>> Marc Schwartz
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi All,

Just a quick note to indicate that one of the two Windows binaries for the 
package appeared overnight (EDT). Not sure if this experience is representative 
for others, or just a temporary bump in the road.

Regards,

Marc


> On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:
> 
> Hi All,
> 
> Just thought that I would check to see if there are any known issues/delays 
> for CRAN in creating R release and devel binaries for Windows for updated 
> packages.
> 
> It has been four days since I submitted an update and the other binaries were 
> created within a couple of days. The two Windows binaries are the only 
> outstanding updates pending.
> 
> Thanks!
> 
> Marc Schwartz

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

On Oct 22, 2020, at 3:47 PM, Duncan Murdoch  wrote:
> 
> On 22/10/2020 12:56 p.m., Marc Schwartz wrote:
>>> On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  
>>> wrote:
>>> 
>>> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
>>>>> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
>>>>> 
>>>>> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes 
>>>>>  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I am developing a package and getting a NOTE from R CMD check about 
>>>>>> licenses and ultimate dependencies on a restrictive license, which I 
>>>>>> can't figure out how to fix.
>>>>>> 
>>>>>> My package imports flowCore, which has an Artistic-2.0 license.
>>>>>> But flowCore imports cytolib, which has a license from the Fred 
>>>>>> Hutchinson Cancer Center that prohibits commercial use.
>>>>>> 
>>>>>> I tried using the same license as flowCore, but still get the NOTE. Does 
>>>>>> anyone know which licenses can be used to be compatible with the Fred 
>>>>>> Hutch license? Or can I just do what flowCore apparently does and ignore 
>>>>>> the NOTE?
>>>>>> 
>>>>>> Thanks,
>>>>>>  Kevin
>>>>> 
>>>>> 
>>>>> Hi Kevin,
>>>>> 
>>>>> I have not looked at BioC's licensing requirements, but presumably, they 
>>>>> are ok with the non-commercial use restrictions placed on users of 
>>>>> cytolib, thus also on flowCore.
>>>>> 
>>>>> If you want your package to be on CRAN, those restrictions on users are 
>>>>> not allowed by CRAN's policy:
>>>>> 
>>>>> https://cran.r-project.org/web/packages/policies.html
>>>>> 
>>>>> "Such packages are not permitted to require (e.g., by specifying in 
>>>>> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a 
>>>>> package or external software which restricts users or usage."
>>>>> 
>>>>> 
>>>>> Thus, you would seem to need to make a decision on hosting your package 
>>>>> on CRAN, but without the need to import from flowCore/cytolib, or 
>>>>> consider hosting your package on BioC, with the attendant restrictions on 
>>>>> commercial use.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Marc Schwartz
>>>> Well
>>>> Now that I look at:
>>>>   https://svn.r-project.org/R/trunk/share/licenses/license.db
>>>> there are a few licenses listed there that do place restrictions on 
>>>> commercial use.
>>>> These include some Creative Commons Non-Commercial use variants and the 
>>>> ACM license.
>>>> Is the license DB file out of date, or is there an apparent conflict with 
>>>> the CRAN policy that I quoted above?
>>>> Anyone with an ability to comment?
>>> 
>>> Presumably CRAN would not accept the non-FOSS licenses that are listed in 
>>> license.db, but R could still do computations on them, as described in 
>>> ?library in the "Licenses" section.
>>> 
>>> Duncan Murdoch
>> Duncan,
>> That is a reasonable distinction.
>> However, upon searching CRAN with available.packages(), I came up with a 
>> list of packages that do include Non-Commercial restrictions, including CC 
>> BY-NC* and ACM licenses. There may be others that I missed visually scanning 
>> the output.
>> There also appear to be some conflicts/inconsistencies with the 
>> 'License_restricts_use' field entry and the 'License' field in some cases, 
>> where, for example, most that have "CC BY-NC-SA 4.0" as the license, have 
>> "NA" as the entry for restricted use, rather than "yes".
>> I am not going to list them here, as I don't want to pick on any particular 
>> package, but this does seem to point to an inconsistency between packages 
>> that are hosted on CRAN and the articulated policy...
> 
> Perhaps those packages were accepted before this became a policy, and now 
> that others depend on them, it would be too disruptive to remove them, and 
> users are warned via the 'License_restricts_use' field entry. Why does it 
> sometimes contain errors?  That I don't know, other than blaming it on 
> Murphy's Law.
> 
> Duncan Murdoch


Hi Duncan,

That seems a reasonable scenario.

Right now, the interpretation, without further clarification from CRAN, would 
be, it is ok for a package to be on CRAN with license based usage restrictions 
included (e.g. for non-commercial use), but a package on CRAN, irrespective of 
it's own license, cannot "interact" with other packages that do have 
restrictions...which seems inconsistent.

Back to the original question by Kevin, this would now seem to be even more 
confusing...

Kevin, you may need to send an e-mail to cran-submissi...@r-project.org 
<mailto:cran-submissi...@r-project.org> on the issue with your package, to get 
clarification on the current policy and recommendations for resolution. You 
might even want to include this thread (but don't cc: this list), so that they 
are aware, if not already, of the issues raised here.

If you do, please post back with an update.

Regards,

Marc


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  wrote:
> 
> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
>>> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
>>> 
>>> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes  
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I am developing a package and getting a NOTE from R CMD check about 
>>>> licenses and ultimate dependencies on a restrictive license, which I can't 
>>>> figure out how to fix.
>>>> 
>>>> My package imports flowCore, which has an Artistic-2.0 license.
>>>> But flowCore imports cytolib, which has a license from the Fred Hutchinson 
>>>> Cancer Center that prohibits commercial use.
>>>> 
>>>> I tried using the same license as flowCore, but still get the NOTE. Does 
>>>> anyone know which licenses can be used to be compatible with the Fred 
>>>> Hutch license? Or can I just do what flowCore apparently does and ignore 
>>>> the NOTE?
>>>> 
>>>> Thanks,
>>>>  Kevin
>>> 
>>> 
>>> Hi Kevin,
>>> 
>>> I have not looked at BioC's licensing requirements, but presumably, they 
>>> are ok with the non-commercial use restrictions placed on users of cytolib, 
>>> thus also on flowCore.
>>> 
>>> If you want your package to be on CRAN, those restrictions on users are not 
>>> allowed by CRAN's policy:
>>> 
>>> https://cran.r-project.org/web/packages/policies.html
>>> 
>>> "Such packages are not permitted to require (e.g., by specifying in 
>>> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a 
>>> package or external software which restricts users or usage."
>>> 
>>> 
>>> Thus, you would seem to need to make a decision on hosting your package on 
>>> CRAN, but without the need to import from flowCore/cytolib, or consider 
>>> hosting your package on BioC, with the attendant restrictions on commercial 
>>> use.
>>> 
>>> Regards,
>>> 
>>> Marc Schwartz
>> Well
>> Now that I look at:
>>   https://svn.r-project.org/R/trunk/share/licenses/license.db
>> there are a few licenses listed there that do place restrictions on 
>> commercial use.
>> These include some Creative Commons Non-Commercial use variants and the ACM 
>> license.
>> Is the license DB file out of date, or is there an apparent conflict with 
>> the CRAN policy that I quoted above?
>> Anyone with an ability to comment?
> 
> Presumably CRAN would not accept the non-FOSS licenses that are listed in 
> license.db, but R could still do computations on them, as described in 
> ?library in the "Licenses" section.
> 
> Duncan Murdoch


Duncan,

That is a reasonable distinction.

However, upon searching CRAN with available.packages(), I came up with a list 
of packages that do include Non-Commercial restrictions, including CC BY-NC* 
and ACM licenses. There may be others that I missed visually scanning the 
output.

There also appear to be some conflicts/inconsistencies with the 
'License_restricts_use' field entry and the 'License' field in some cases, 
where, for example, most that have "CC BY-NC-SA 4.0" as the license, have "NA" 
as the entry for restricted use, rather than "yes".

I am not going to list them here, as I don't want to pick on any particular 
package, but this does seem to point to an inconsistency between packages that 
are hosted on CRAN and the articulated policy...

Regards,

Marc

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
> 
> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes  
> wrote:
>> 
>> Hi,
>> 
>> I am developing a package and getting a NOTE from R CMD check about licenses 
>> and ultimate dependencies on a restrictive license, which I can't figure out 
>> how to fix.
>> 
>> My package imports flowCore, which has an Artistic-2.0 license.
>> But flowCore imports cytolib, which has a license from the Fred Hutchinson 
>> Cancer Center that prohibits commercial use.
>> 
>> I tried using the same license as flowCore, but still get the NOTE. Does 
>> anyone know which licenses can be used to be compatible with the Fred Hutch 
>> license? Or can I just do what flowCore apparently does and ignore the NOTE?
>> 
>> Thanks,
>>  Kevin
> 
> 
> Hi Kevin,
> 
> I have not looked at BioC's licensing requirements, but presumably, they are 
> ok with the non-commercial use restrictions placed on users of cytolib, thus 
> also on flowCore.
> 
> If you want your package to be on CRAN, those restrictions on users are not 
> allowed by CRAN's policy:
> 
> https://cran.r-project.org/web/packages/policies.html
> 
> "Such packages are not permitted to require (e.g., by specifying in 
> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package 
> or external software which restricts users or usage."
> 
> 
> Thus, you would seem to need to make a decision on hosting your package on 
> CRAN, but without the need to import from flowCore/cytolib, or consider 
> hosting your package on BioC, with the attendant restrictions on commercial 
> use.
> 
> Regards,
> 
> Marc Schwartz


Well

Now that I look at:

  https://svn.r-project.org/R/trunk/share/licenses/license.db

there are a few licenses listed there that do place restrictions on commercial 
use.

These include some Creative Commons Non-Commercial use variants and the ACM 
license.

Is the license DB file out of date, or is there an apparent conflict with the 
CRAN policy that I quoted above?

Anyone with an ability to comment?

Regards,

Marc

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes  
wrote:
> 
> Hi,
> 
> I am developing a package and getting a NOTE from R CMD check about licenses 
> and ultimate dependencies on a restrictive license, which I can't figure out 
> how to fix.
> 
> My package imports flowCore, which has an Artistic-2.0 license.
> But flowCore imports cytolib, which has a license from the Fred Hutchinson 
> Cancer Center that prohibits commercial use.
> 
> I tried using the same license as flowCore, but still get the NOTE. Does 
> anyone know which licenses can be used to be compatible with the Fred Hutch 
> license? Or can I just do what flowCore apparently does and ignore the NOTE?
> 
> Thanks,
>   Kevin


Hi Kevin,

I have not looked at BioC's licensing requirements, but presumably, they are ok 
with the non-commercial use restrictions placed on users of cytolib, thus also 
on flowCore.

If you want your package to be on CRAN, those restrictions on users are not 
allowed by CRAN's policy:

https://cran.r-project.org/web/packages/policies.html

"Such packages are not permitted to require (e.g., by specifying in ‘Depends’, 
‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package or external 
software which restricts users or usage."


Thus, you would seem to need to make a decision on hosting your package on 
CRAN, but without the need to import from flowCore/cytolib, or consider hosting 
your package on BioC, with the attendant restrictions on commercial use.

Regards,

Marc Schwartz

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

[R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi All,

Just thought that I would check to see if there are any known issues/delays for 
CRAN in creating R release and devel binaries for Windows for updated packages.

It has been four days since I submitted an update and the other binaries were 
created within a couple of days. The two Windows binaries are the only 
outstanding updates pending.

Thanks!

Marc Schwartz

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

Re: [Rd] Hard memory limit of 16GB under Windows?

[Marc Schwartz via R-devel]

Hi Samuel,

You may already be aware, but if not, RStudio has their own support mechanisms 
here:

  https://support.rstudio.com/hc/en-us

If this does turn out to be RStudio specific, you may wish to check there for 
additional insights.

Regards,

Marc Schwartz


> On Apr 7, 2020, at 10:24 AM, Tomas Kalibera  wrote:
> 
> Hi Samuel,
> 
> please also have a look at ?memory.limit. You can set this limit at R 
> startup. It is in megabytes. Maybe R Studio sets it at runtime.
> 
> Best
> Tomas
> 
> On 4/7/20 3:57 PM, Samuel Granjeaud IR/Inserm wrote:
>> Hi Tomas,
>> 
>> Many thanks for your answer.
>> 
>> Here is a copy of a fresh session under RStudio, and after a copy under Rgui.
>> Strangely enough the result of memory.limit() is not the same. Without your 
>> question I would not have looked to RGui, being used to work with RStudio.
>> 
>> The value under RGui sounds to correspond to the total RAM of the computer. 
>> It makes me noticing that the value is in MB.
>> 
>> The value under Rstudio was so huge (1.759219e+13) that I just interpreted 
>> it as GB. But I was totally wrong. So in fact I don't know what it refers 
>> to. The documentation says "For a 64-bit versions of R under 64-bit Windows 
>> the limit is currently 8Tb.", but it looks like being 16TB, which my 
>> computer don't have of course.
>> 
>> I still have to understand why my colleague has a problem of memory 
>> allocation (cannot allocate vector of size 12.6 Gb).
>> 
>> Sorry for the wrong interpretation, but thanks for the help,
>> Samuel
>> 
>> --- RStudio
>> 
>> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
>> Copyright (C) 2020 The R Foundation for Statistical Computing
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> 
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>> 
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>> 
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>> 
>> > memory.limit()
>> [1] 1.759219e+13
>> > sessionInfo()
>> R version 3.6.3 (2020-02-29)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 18363)
>> 
>> Matrix products: default
>> 
>> locale:
>> [1] LC_COLLATE=French_France.1252  LC_CTYPE=French_France.1252 
>> LC_MONETARY=French_France.1252 LC_NUMERIC=C
>> [5] LC_TIME=French_France.1252
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_3.6.3 tools_3.6.3
>> >
>> 
>> --- RGui
>> 
>> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
>> Copyright (C) 2020 The R Foundation for Statistical Computing
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> 
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>> 
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>> 
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>> 
>> > ls()
>> character(0)
>> > memory.limit()
>> [1] 32627
>> > sessionInfo()
>> R version 3.6.3 (2020-02-29)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 18363)
>> 
>> Matrix products: default
>> 
>> locale:
>> [1] LC_COLLATE=French_France.1252  LC_CTYPE=French_France.1252 
>> LC_MONETARY=French_France.1252
>> [4] LC_NUMERIC=C   LC_TIME=French_France.1252
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_3.6.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] findInterval Documentation Suggestion

[Marc Schwartz via R-devel]

> On Mar 6, 2020, at 9:17 AM, brodie gaslam via R-devel  
> wrote:
> 
>> On Friday, March 6, 2020, 8:56:54 AM EST, Martin Maechler 
>>  wrote: 
> 
>> Note that the  * -> LaTex -> PDF rendered version looks a bitnicer.
> 
> Ah yes, that does indeed look quite a bit nicer.
> 
>> I wrote the function and that help page originally.
> 
> And thank you for doing so. It is a wonderful function.
> (0 sarcasm here).
> 
>> For that reason, replacing the well defined precise
>> inequality-based definition by *much* less precise English prosa
>> is out of the question.
> 
> I figured that might be an issue.  Would you be open to 
> providing a prose translation, but putting that in the 
> details? If so, it would be useful to get feedback on 
> what parts of the prose I proposed are imprecise enough 
> to be incorrect/incomplete for some corner case.
> 
> Finally, would it make sense to move this discussion to
> bugzilla?
> 
> Best,
> 
> Brodie.


Hi,

Just to put forth an alternative to modifying the existing, precise content 
that Martin wrote, in many cases, that content can be reasonably supplemented 
by the addition of specific examples and perhaps concise comments, that 
demonstrate what, otherwise, may be surprising behavior.

If Brodie can construct one or more such examples that might provide additional 
insights, then perhaps they can be considered for inclusion in the help file, 
such that meeting both goals of not compromising the language that Martin has 
contributed, while expanding comprehension, can be achieved.

Regards,

Marc Schwartz

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

Re: [R-pkg-devel] Internet security software?

[Marc Schwartz]

> On Feb 24, 2020, at 4:49 PM, Spencer Graves 
>  wrote:
> 
> Hello, All:
> 
> 
>   What antivirus / internet security software do you use and recommend?
> 
> 
>   I've used Bitdefender for years.  However, I've been encountering an 
> increasing number of problems with software I've used for years.  Some of my 
> problems disappear when I turn off parts of Bitdefender.  However, I've been 
> unable to use RStudio on my Windows 7 computer since early last November.  
> Also, when I turn off certain features of Bitdefender, "R CMD build sos" 
> (with sos cloned from "https://github.com/sbgraves237/sos;) completes in a 
> few minutes.  With Bitdefender configured normally, "R CMD build sos" stops 
> without warning on "* creating vignettes".  I've left it for days like that 
> without it moving beyond that point.  No error message but also no progress.
> 
> 
>   Rather than doing a web search for alternative internet security 
> software, I thought I'd ask you all:  If some of you have had similar 
> problems with other antivirus / internet security software, I think I'd be 
> more likely to hear it from you than from a web search.  Some of my problems 
> may not be due to Bitdefender, but I know that some are, and Bitdefender tech 
> support answers the phone but fails to fix these problems.
> 
> 
>   Thanks,
>   Spencer Graves


Spencer,

FWIW, I also use BitDefender on macOS, and have for a number of years, even 
though macOS has built-in features. I selected BitDefender because of minimal 
system overhead and high detection ratings.

I also use Malwarebytes for periodic scans as a second tier.

The key and really only issue that I have had with BitDefender is the Safe 
Files feature, which has a tendency to lock down folder trees, and which can be 
very nuanced in terms of the day to day operational impact. 

Under the premise of "The missing shall not be compromised due to security", a 
paradigm that I learned back in the 90s in an apropos setting, I long ago 
disabled the Safe Files feature in BitDefender, and have not had an issue since.

I am going to presume that the behavior on Windows is going to be similar. So 
if disabling the Safe Files feature, presuming that you have it enabled, is an 
option that you can consider, I would try that approach initially.

Regards,

Marc Schwartz

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

Re: [Rd] as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!

[Marc Schwartz via R-devel]

> On Jan 14, 2020, at 3:29 PM, Abby Spurdle  wrote:
> 
>> I do want to entice people to have a long look beyond closed
>> source OS into the world of Free Software where not only R is
>> FOSS (Free and Open Source Software) but (all / almost) all the
>> tools you use are of that same spirit.
> 
> And while everyone is talking about operating systems...
> 
> Recently, I tried to install R on Fedora.
> However, it only gave me the option of downloading and installing R
> 3.6.1, when the current release is/was R 3.6.2.
> I decided to wait, and may try again later, over the next week.
> 
> Is it possible for things to be free *and* simple?

Abby,

Which version of Fedora are you on?

The Fedora RPM build system for R:

  https://koji.fedoraproject.org/koji/packageinfo?packageID=1230

would seem to suggest that R 3.6.2 may not be available for Fedora 29 or 
earlier, which is not a surprise, given the rapid update cycle used on Fedora.

R 3.6.2 is available for Fedora 30, 31 and 32 per the above page.

If you are on Fedora >=30, you might check your yum repo to see if it has been 
properly updated.

Otherwise, if you are on Fedora <=29, you should think about updating your 
Fedora installation.

You may or may not be aware that there is a dedicated list for R on Fedora/RHEL 
and derivatives:

  https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Tom Callaway, who is the RH/Fedora maintainer for R is on that list, so you can 
pose queries to him via that list for any issues with R on Fedora.

Regards,

Marc Schwartz

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

Re: [Rd] mean

[Marc Schwartz via R-devel]

Peter,

Thanks for the reply.

If that were the case, then should not the following be allowed to work with 
ordered factors?

> median(factor(c("1", "2", "3"), ordered = TRUE))
Error in median.default(factor(c("1", "2", "3"), ordered = TRUE)) : 
  need numeric data

At least on the surface, if you can lexically order a character vector:

> median(c("red", "blue", "green"))
[1] "green"

you can also order a factor, or ordered factor, and if the number of elements 
is odd, return a median value.

Regards,

Marc


> On Jan 9, 2020, at 10:46 AM, peter dalgaard  wrote:
> 
> I think median() behaves as designed: As long as the argument can be ordered, 
> the "middle observation" makes sense, except when the middle falls between 
> two categories, and you can't define and average of the two candidates for a 
> median.
> 
> The "sick man" would seem to be var(). Notice that it is also inconsistent 
> with cov():
> 
>> cov(c("1","2","3","4"),c("1","2","3","4") )
> Error in cov(c("1", "2", "3", "4"), c("1", "2", "3", "4")) : 
>  is.numeric(x) || is.logical(x) is not TRUE
>> var(c("1","2","3","4"),c("1","2","3","4") )
> [1] 1.67
> 
> -pd
> 
> 
>> On 9 Jan 2020, at 14:49 , Marc Schwartz via R-devel  
>> wrote:
>> 
>> Jean-Luc,
>> 
>> Please keep the communications on the list, for the benefit of others, now 
>> and in the future, via the list archive. I am adding r-devel back here.
>> 
>> I can't speak to the rationale in some of these cases. As I noted, it may be 
>> (is likely) due to differing authors over time, and there may have been 
>> relevant use cases at the time that the code was written, resulting in the 
>> various checks. Presumably, the additional checks were not incorporated into 
>> the other functions to enforce a level of consistency.
>> 
>> We will need to wait for someone from R Core to comment.
>> 
>> Regards,
>> 
>> Marc
>> 
>>> On Jan 9, 2020, at 8:34 AM, Lipatz Jean-Luc  
>>> wrote:
>>> 
>>> Ok, inconstencies.
>>> 
>>> The last test you wrote is a bit strange. I agree that it is useful to warn 
>>> about a computation that have no sense in the case of factors. But why 
>>> testing data;frames? If you go that way using random structures, you can 
>>> also try :
>>> 
>>>> median(list(1,2),list(3,4),list(4,5))
>>> Error in if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x))) 
>>> return(x[FALSE][NA]) : 
>>> l'argument n'est pas interprétable comme une valeur logique
>>> De plus : Warning message:
>>> In if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x))) 
>>> return(x[FALSE][NA]) :
>>> la condition a une longueur > 1 et seul le premier élément est utilisé
>>> 
>>> giving a message which, despite of his length, doesn't really explain the 
>>> reason of the error.
>>> 
>>> Why not a test on arguments like?
>>> if (!is.numeric(x)) 
>>>stop("need numeric data")
>>> 
>>> 
>>> -Message d'origine-
>>> De : Marc Schwartz  
>>> Envoyé : jeudi 9 janvier 2020 14:19
>>> À : Lipatz Jean-Luc 
>>> Cc : R-Devel 
>>> Objet : Re: [Rd] mean
>>> 
>>> 
>>>> On Jan 9, 2020, at 7:40 AM, Lipatz Jean-Luc  
>>>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> Is there a reason for the following behaviour?
>>>>> mean(c("1","2","3"))
>>>> [1] NA
>>>> Warning message:
>>>> In mean.default(c("1", "2", "3")) :
>>>> l'argument n'est ni numérique, ni logique : renvoi de NA
>>>> 
>>>> But:
>>>>> var(c("1","2","3"))
>>>> [1] 1
>>>> 
>>>> And also:
>>>>> median(c("1","2","3"))
>>>> [1] "2"
>>>> 
>>>> But:
>>>>> quantile(c("1","2","3"),p=.5)
>>>> Error in (1 - h) * qs[i] : 
>>>> argument non numérique pour un opérateur binaire
>>>> 
>>>> It sounds like a lack of symet

Re: [Rd] mean

[Marc Schwartz via R-devel]

Jean-Luc,

Please keep the communications on the list, for the benefit of others, now and 
in the future, via the list archive. I am adding r-devel back here.

I can't speak to the rationale in some of these cases. As I noted, it may be 
(is likely) due to differing authors over time, and there may have been 
relevant use cases at the time that the code was written, resulting in the 
various checks. Presumably, the additional checks were not incorporated into 
the other functions to enforce a level of consistency.

We will need to wait for someone from R Core to comment.

Regards,

Marc

> On Jan 9, 2020, at 8:34 AM, Lipatz Jean-Luc  wrote:
> 
> Ok, inconstencies.
> 
> The last test you wrote is a bit strange. I agree that it is useful to warn 
> about a computation that have no sense in the case of factors. But why 
> testing data;frames? If you go that way using random structures, you can also 
> try :
> 
>> median(list(1,2),list(3,4),list(4,5))
> Error in if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x))) 
> return(x[FALSE][NA]) : 
>  l'argument n'est pas interprétable comme une valeur logique
> De plus : Warning message:
> In if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x))) return(x[FALSE][NA]) :
>  la condition a une longueur > 1 et seul le premier élément est utilisé
> 
> giving a message which, despite of his length, doesn't really explain the 
> reason of the error.
> 
> Why not a test on arguments like?
>  if (!is.numeric(x)) 
>      stop("need numeric data")
> 
> 
> -Message d'origine-
> De : Marc Schwartz  
> Envoyé : jeudi 9 janvier 2020 14:19
> À : Lipatz Jean-Luc 
> Cc : R-Devel 
> Objet : Re: [Rd] mean
> 
> 
>> On Jan 9, 2020, at 7:40 AM, Lipatz Jean-Luc  wrote:
>> 
>> Hello,
>> 
>> Is there a reason for the following behaviour?
>>> mean(c("1","2","3"))
>> [1] NA
>> Warning message:
>> In mean.default(c("1", "2", "3")) :
>> l'argument n'est ni numérique, ni logique : renvoi de NA
>> 
>> But:
>>> var(c("1","2","3"))
>> [1] 1
>> 
>> And also:
>>> median(c("1","2","3"))
>> [1] "2"
>> 
>> But:
>>> quantile(c("1","2","3"),p=.5)
>> Error in (1 - h) * qs[i] : 
>> argument non numérique pour un opérateur binaire
>> 
>> It sounds like a lack of symetry. 
>> Best regards.
>> 
>> 
>> Jean-Luc LIPATZ
>> Insee - Direction générale
>> Responsable de la coordination sur le développement de R et la mise en 
>> oeuvre d'alternatives à SAS
> 
> 
> Hi,
> 
> It would appear, whether by design or just inconsistent implementations, 
> perhaps by different authors over time, that the checks for whether or not 
> the input vector is numeric differ across the functions.
> 
> A further inconsistency is for median(), where:
> 
>> median(c("1", "2", "3", "4"))
> [1] NA
> Warning message:
> In mean.default(sort(x, partial = half + 0L:1L)[half + 0L:1L]) :
>  argument is not numeric or logical: returning NA
> 
> as a result of there being 4 elements, rather than 3, and the internal checks 
> in the code, where in the case of the input vector having an even number of 
> elements, mean() is used:
> 
>if (n%%2L == 1L) 
>sort(x, partial = half)[half]
>else mean(sort(x, partial = half + 0L:1L)[half + 0L:1L])
> 
> 
> Similarly:
> 
>> median(factor(c("1", "2", "3")))
> Error in median.default(factor(c("1", "2", "3"))) : need numeric data
> 
> because the input vector is a factor, rather than character, and the initial 
> check has:
> 
>  if (is.factor(x) || is.data.frame(x)) 
>  stop("need numeric data")
> 
> 
> Regards,
> 
> Marc Schwartz
> 
> 

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

Re: [Rd] mean

[Marc Schwartz via R-devel]

> On Jan 9, 2020, at 7:40 AM, Lipatz Jean-Luc  wrote:
> 
> Hello,
> 
> Is there a reason for the following behaviour?
>> mean(c("1","2","3"))
> [1] NA
> Warning message:
> In mean.default(c("1", "2", "3")) :
>  l'argument n'est ni numérique, ni logique : renvoi de NA
> 
> But:
>> var(c("1","2","3"))
> [1] 1
> 
> And also:
>> median(c("1","2","3"))
> [1] "2"
> 
> But:
>> quantile(c("1","2","3"),p=.5)
> Error in (1 - h) * qs[i] : 
>  argument non numérique pour un opérateur binaire
> 
> It sounds like a lack of symetry. 
> Best regards.
> 
> 
> Jean-Luc LIPATZ
> Insee - Direction générale
> Responsable de la coordination sur le développement de R et la mise en oeuvre 
> d'alternatives à SAS


Hi,

It would appear, whether by design or just inconsistent implementations, 
perhaps by different authors over time, that the checks for whether or not the 
input vector is numeric differ across the functions.

A further inconsistency is for median(), where:

> median(c("1", "2", "3", "4"))
[1] NA
Warning message:
In mean.default(sort(x, partial = half + 0L:1L)[half + 0L:1L]) :
  argument is not numeric or logical: returning NA

as a result of there being 4 elements, rather than 3, and the internal checks 
in the code, where in the case of the input vector having an even number of 
elements, mean() is used:

if (n%%2L == 1L) 
sort(x, partial = half)[half]
else mean(sort(x, partial = half + 0L:1L)[half + 0L:1L])


Similarly:

> median(factor(c("1", "2", "3")))
Error in median.default(factor(c("1", "2", "3"))) : need numeric data

because the input vector is a factor, rather than character, and the initial 
check has:

  if (is.factor(x) || is.data.frame(x)) 
  stop("need numeric data")


Regards,

Marc Schwartz

__
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] survival changes

[Marc Schwartz via R-devel]

s and useRs as 
may be apropos. Perhaps post reminders to R-Help at relevant time points in 
advance as you approach the formal deprecation and release of the updated 
package.


Terry, if you have not used it yet and/or are not aware of it, take a look at 
?Deprecated in base:

  https://stat.ethz.ch/R-manual/R-devel/library/base/html/Deprecated.html

which is helpful in setting up a deprecation process. If you Google 
"deprecating functions in R", there are numerous examples/flows of use and the 
associated processes, since the help page does not contain any examples at 
present.

Regards,

Marc Schwartz

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

Re: [Rd] prettyNum digits=0 not compatible with scientific notation

[Marc Schwartz via R-devel]

> On Mar 22, 2019, at 7:25 PM, peter dalgaard  wrote:
> 
> 
> 
>> On 22 Mar 2019, at 18:07 , Martin Maechler  
>> wrote:
>> 
>> gives (on Linux R 3.5.3, Fedora 28)
>> 
>>  d=10 d=7  d=2  d=1 d=0   
>> [1,] "123456" "123456" "123456" "1e+05" "%#4.0-1e"
>> [2,] "12345.6""12345.6""12346"  "12346" "%#4.0-1e"
>> [3,] "1234.56""1234.56""1235"   "1235"  "1235"
>> [4,] "123.456""123.456""123""123"   "123" 
>> [5,] "12.3456""12.3456""12" "12""12"  
>> [6,] "1.23456""1.23456""1.2""1" "1"   
>> [7,] "0.123456"   "0.123456"   "0.12"   "0.1"   "0"   
>> [8,] "0.0123456"  "0.0123456"  "0.012"  "0.01"  "0"   
>> [9,] "0.00123456" "0.00123456" "0.0012" "0.001" "0"   
>> 
>> but probably looks better on Mac
> 
> 
> Yes (3.5.1 though)
> 
>> nn <- 123456*10^(0:-8); dd <- c(10, 7, 2:0); names(dd) <- paste0("d=",dd)
>> sapply(dd, function(dig) sapply(nn, format, digits=dig))
>  d=10 d=7  d=2  d=1 d=0 
> [1,] "123456" "123456" "123456" "1e+05" "1.e+05"
> [2,] "12345.6""12345.6""12346"  "12346" "1.e+04"
> [3,] "1234.56""1234.56""1235"   "1235"  "1235"  
> [4,] "123.456""123.456""123""123"   "123"   
> [5,] "12.3456""12.3456""12" "12""12"
> [6,] "1.23456""1.23456""1.2""1" "1" 
> [7,] "0.123456"   "0.123456"   "0.12"   "0.1"   "0" 
> [8,] "0.0123456"  "0.0123456"  "0.012"  "0.01"  "0" 
> [9,] "0.00123456" "0.00123456" "0.0012" "0.001" "0"  
> 


Here is 3.5.3 on macOS:

> nn <- 123456*10^(0:-8); dd <- c(10, 7, 2:0); names(dd) <- paste0("d=",dd)
> sapply(dd, function(dig) sapply(nn, format, digits=dig))
  d=10 d=7  d=2  d=1 d=0 
 [1,] "123456" "123456" "123456" "1e+05" "1.e+05"
 [2,] "12345.6""12345.6""12346"  "12346" "1.e+04"
 [3,] "1234.56""1234.56""1235"   "1235"  "1235"  
 [4,] "123.456""123.456""123""123"   "123"   
 [5,] "12.3456""12.3456""12" "12""12"
 [6,] "1.23456""1.23456""1.2""1" "1" 
 [7,] "0.123456"   "0.123456"   "0.12"   "0.1"   "0" 
 [8,] "0.0123456"  "0.0123456"  "0.012"  "0.01"  "0" 
 [9,] "0.00123456" "0.00123456" "0.0012" "0.001" "0" 


Regards,

Marc Schwartz

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

[Rd] Proposed patch for ?Extract

[Marc Schwartz via R-devel]

Hi,

In follow up to the thread on R-Help yesterday:

  https://stat.ethz.ch/pipermail/r-help/2019-February/461725.html

I am attaching a proposed patch against the trunk version of Extract.Rd, with 
wording added to the "Matrices and arrays" section, to note that indexing these 
object by factors behaves in a manner consistent with vectors.

Regards,

Marc Schwartz

--- ExtractORIG.Rd  2019-02-21 08:17:47.0 -0500
+++ ExtractMOD.Rd   2019-02-21 08:23:35.0 -0500
@@ -151,6 +151,9 @@
   indices can be numeric, logical, character, empty or even factor.
   An empty index (a comma separated blank) indicates that all entries in
   that dimension are selected.
+  As with vectors, indexing by factors is equivalent to indexing by the
+  numeric codes (see \code{\link{factor}}) and not by the character
+  values which are printed (for which use \code{[as.character(i)]}).
   The argument \code{drop} applies to this form of indexing.
 
   A third form of indexing is via a numeric matrix with the one column


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

Re: [Rd] compairing doubles

[Marc Schwartz via R-devel]

> On Aug 31, 2018, at 9:36 AM, Iñaki Ucar  wrote:
> 
> El vie., 31 ago. 2018 a las 15:10, Felix Ernst
> () escribió:
>> 
>> Dear all,
>> 
>> I a bit unsure, whether this qualifies as a bug, but it is definitly a 
>> strange behaviour. That why I wanted to discuss it.
>> 
>> With the following function, I want to test for evenly space numbers, 
>> starting from anywhere.
>> 
>> .is_continous_evenly_spaced <- function(n){
>>  if(length(n) < 2) return(FALSE)
>>  n <- n[order(n)]
>>  n <- n - min(n)
>>  step <- n[2] - n[1]
>>  test <- seq(from = min(n), to = max(n), by = step)
>>  if(length(n) == length(test) &&
>> all(n == test)){
>>return(TRUE)
>>  }
>>  return(FALSE)
>> }
>> 
>>> .is_continous_evenly_spaced(c(1,2,3,4))
>> [1] TRUE
>>> .is_continous_evenly_spaced(c(1,3,4,5))
>> [1] FALSE
>>> .is_continous_evenly_spaced(c(1,1.1,1.2,1.3))
>> [1] FALSE
>> 
>> I expect the result for 1 and 2, but not for 3. Upon Investigation it turns 
>> out, that n == test is TRUE for every pair, but not for the pair of 0.2.
>> 
>> The types reported are always double, however n[2] == 0.1 reports FALSE as 
>> well.
>> 
>> The whole problem is solved by switching from all(n == test) to 
>> all(as.character(n) == as.character(test)). However that is weird, isn’t it?
>> 
>> Does this work as intended? Thanks for any help, advise and suggestions in 
>> advance.
> 
> I guess this has something to do with how the sequence is built and
> the inherent error of floating point arithmetic. In fact, if you
> return test minus n, you'll get:
> 
> [1] 0.00e+00 0.00e+00 2.220446e-16 0.00e+00
> 
> and the error gets bigger when you continue the sequence; e.g., this
> is for c(1, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7):
> 
> [1] 0.00e+00 0.00e+00 2.220446e-16 2.220446e-16 4.440892e-16
> [6] 4.440892e-16 4.440892e-16 0.00e+00
> 
> So, independently of this is considered a bug or not, instead of
> 
> length(n) == length(test) && all(n == test)
> 
> I would use the following condition:
> 
> isTRUE(all.equal(n, test))
> 
> Iñaki
> 
>> 
>> Best regards,
>> Felix


Hi,

This is essentially FAQ 7.31:

  
https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
 
<https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f>

Review that and the references therein to gain some insights into binary 
representations of floating point numbers.

Rather than the more complicated code you have above, try the following:

evenlyspaced <- function(x) {
  gaps <- diff(sort(x))
  all(gaps[-1] == gaps[1])
}

Note the use of ?diff:

> diff(c(1, 2, 3, 4))
[1] 1 1 1

> diff(c(1, 3, 4, 5))
[1] 2 1 1

> diff(c(1, 1.1, 1.2, 1.3))
[1] 0.1 0.1 0.1

However, in reality, due to the floating point representation issues noted 
above:

> print(diff(c(1, 1.1, 1.2, 1.3)), 20)
[1] 0.100088818 0.099866773
[3] 0.100088818

So the differences between the numbers are not exactly 0.1.

Using the function above, you get:

> evenlyspaced(c(1, 2, 3, 4))
[1] TRUE

> evenlyspaced(c(1, 3, 4, 5))
[1] FALSE

> evenlyspaced(c(1, 1.1, 1.2, 1.3))
[1] FALSE

As has been noted, if you want the gap comparison to be based upon some margin 
of error, use ?all.equal rather than the explicit equals comparison that I have 
in the function above. Something along the lines of:

evenlyspaced <- function(x) {
  gaps <- diff(sort(x))
  all(sapply(gaps[-1], function(x) all.equal(x, gaps[1])))
}

On which case, you now get:

evenlyspaced(c(1, 1.1, 1.2, 1.3))
[1] TRUE


Regards,

Marc Schwartz


[[alternative HTML version deleted]]

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

Re: [Rd] Where does L come from?

[Marc Schwartz via R-devel]

On Aug 25, 2018, at 9:26 AM, Hadley Wickham  wrote:
> 
> Hi all,
> 
> Would someone mind pointing to me to the inspiration for the use of
> the L suffix to mean "integer"?  This is obviously hard to google for,
> and the R language definition
> (https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Constants)
> is silent.
> 
> Hadley


The link you have above, does reference the use of 'L', but not the derivation.

There is a thread on R-Help from 2012 ("Difference between 10 and 10L"), where 
Prof. Ripley addresses the issue in response to Bill Dunlap and the OP:

  https://stat.ethz.ch/pipermail/r-help/2012-May/311771.html

In searching, I also found the following thread on SO:

  https://stackoverflow.com/questions/22191324/clarification-of-l-in-r/22192378

which had a link to the R-Help thread above and others.

Regards,

Marc Schwartz

__
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

[Marc Schwartz]

Hi,

See inline below.


> On Dec 22, 2017, at 9:12 AM, Martin Maechler  
> wrote:
> 
>> Duncan Murdoch 
>>on Thu, 21 Dec 2017 14:23:13 -0500 writes:
> 
>> 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"=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"=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
> 
> As you know I had setup (the first few versions of) the svn at
>  https://svn.r-project.org/
> 
> at the time, I wanted to keep that machine protected as much as
> possible and had decided not to install any other apache
> modules and svn - niceties just such that the server would run
> minimal services and hence would be minimally vulnerable.
> 
> The times have changed though and I will look into adding WebSVN
> to svn.r-project.org  as one of the  first things in 2018.
> 
> Martin Maechler


Martin,

Just to play a bit of a devil's advocate here, WebSVN has not been 
updated/maintained since June of 2011, so is a number of years old at this 
point. That should raise some reasonable concerns over bugs, security issues 
and related matters.

To put that in perspective, the last update to WebSVN was around the time that 
R 2.13.1 was released.

That general pattern, of SVN clients not being actively maintained, seems to be 
consistent across a number of the web based (and even browser plugin based) SVN 
clients, which may in turn, be an indication of the general shift to Git in 
recent years, much as the shift from CVS to SVN occurred years ago.

In researching other SVN clients, the few that still seem to be actively 
maintained are typically dedicated desktop clients/GUIs, that in some cases are 
closed source and/or are OS specific.

One of the few web based SVN clients that still seems to be actively maintained 
is Trac (https://trac.edgewall.org), however it is under a modified BSD 
license, which may raise some issues and from what I can tell, may be more 
complicated in terms of set up, since it also supports bug tracking, wiki and 
other functionality. As with any such application, there would be ongoing 
maintenance issues as well.

I am not advocating any particular solution. I just want to point out potential 
issues with WebSVN and raise for discussion, what options may make sense to 
consider, based upon how many folks might actually use such "live" web based 
functionality versus remote SVN access via a desktop client, which is certainly 
an option, since they won't have write access anyway. 

Also, a number of the Git desktop clients also support Git SVN 
(https://git-scm.com/docs/git-svn), for compatibility, which offers Git users 
an alternative to using a dedicated desktop SVN client.

Regards,

Marc


> 
>>> 
 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 

Re: [R-pkg-devel] Exited with status -1073741819.

[Marc Schwartz]

Rampal,

One additional thought here.

Since you reference RTools in your initial post, I presume that this is 
occurring on Windows, though not sure which version.

Have you tried to build the package using the WinBuilder site provided by Uwe?

If not, go here:

  https://win-builder.r-project.org

and request a build of the package using R-Devel.

See if any warnings/errors are picked up there. If not, then that would seem to 
reinforce the notion that there is something going on locally on your system.

Also, unless I missed it, you did not indicate which version of R-Devel you are 
running or where you obtained it. Did you get it from:

  https://cran.r-project.org/bin/windows/base/rdevel.html

?

Regards,

Marc


> On Nov 29, 2017, at 8:22 AM, Rampal S. Etienne  
> wrote:
> 
> Dear Marc, Martin, Dason,
> 
> I agree that the status number is not very informative, but neither is:
> "Package does not build". The point is that I have no clue what is going
> on, and was just hoping that someone might have seen the exit status
> number before.
> 
> I have done a clean install as suggested but still it won't work with
> R-devel, but it does with R-3.4.2.
> 
> I don't see how my setup is special in any way. It never caused me any
> problems until installing the latest R-devel. What are the changes in
> the latest R-devel that affect the building of packages?
> 
> Cheers, Rampal
> 
> 
> 
> On 29-11-2017 11:16, Martin Maechler wrote:
>>> Rampal S Etienne 
>>>on Wed, 29 Nov 2017 09:19:29 +0100 writes:
>>> Dear Dason,
>>> I don't get this error, but it crashes anyway. 
>> 
>> and you don't show what "crashes" means here.
>> (and yes, Dason is right: The RStudio status number in the
>> 'Subject' is not really useful)
>> 
>>> I've that if I use the
>>> stable version of R (3.4.2) I do NOT get the error anymore, so I assume
>>> there is something wrong with the current R-devel.
>> 
>>> Regards,
>>> Rampal Etienne
>> 
>> OTOH, the CRAN checks of your package run without any problem
>> with all 5 versions of R-devel there :
>> 
>>  https://cran.r-project.org/web/checks/check_results_SADISA.html
>> 
>> so it may rather be something specific to your setup ??
>> 
>> Martin Maechler
>> 
>> 
>>> On 29-11-2017 0:36, Dason Kurkiewicz wrote:
 Do you get the same error if you try to build on the command line
 outside of RStudio?
 
 On Nov 28, 2017 3:51 PM, "Rampal Etienne" > wrote:
 
 Dear all,
 
 I updated RStudio, Rtools and R-devel, and then I tried to build a
 package in RStudio that I had been able to build before without
 any problems. But now I got the following error:
 
 Updating SADISA documentatiob
 Loading SADISA
 Exited with status -1073741819.
 
 That's all. What is this exit status? I can still build other
 packages, so it does not happen all the time. I can use "Load all"
 and all functions sseem to work fine.
 
 Any suggestions?
 
 Kind regards, Rampal Etienne

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

Re: [Rd] Un-informative Error in re-building vignettes

[Marc Schwartz]

> On Nov 29, 2017, at 10:25 AM, Toby Hocking <tdho...@gmail.com> wrote:
> 
> I am getting the following on CRAN windows and winbuilder
> https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/penaltyLearning-00check.html
> 
> Apparently there is an error in re-building vignettes, but I do not have
> any idea what it is, because all that is listed is three dots (...). Is
> this a bug in R CMD check?
> 
> If not, the only solution I can think of is removing the vignette entirely.
> Any other ideas?
> 
>   - checking re-building of vignette outputs ... [11s] WARNING
>   Error in re-building vignettes:
> ...
>   - checking PDF version of manual ... OK


Hi,

First, generally CRAN package building related issues should be posted to 
R-Package-Devel, not here:

  https://stat.ethz.ch/mailman/listinfo/r-package-devel 
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>

Second, you might want to review the full CRAN build report for your package, 
which reports more information across several builds:

https://cran.r-project.org/web/checks/check_results_penaltyLearning.html 
<https://cran.r-project.org/web/checks/check_results_penaltyLearning.html>

Regards,

Marc Schwartz



[[alternative HTML version deleted]]

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

Re: [Rd] Proposed Patch for poly.Rd

[Marc Schwartz]

> On Jul 13, 2017, at 5:07 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
> 
> 
>> On Jul 13, 2017, at 3:37 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
>> 
>> 
>>> On Jul 13, 2017, at 3:22 PM, Duncan Murdoch <murdoch.dun...@gmail.com> 
>>> wrote:
>>> 
>>> On 13/07/2017 4:08 PM, Marc Schwartz wrote:
>>>> Hi All,
>>>> 
>>>> As per the discussion today on R-Help:
>>>> 
>>>> https://stat.ethz.ch/pipermail/r-help/2017-July/448132.html
>>>> 
>>>> I am attaching a proposed patch for poly.Rd to provide clarifying wording 
>>>> relative to naming the 'degree' argument explicitly, in the case where the 
>>>> 'x' argument is a matrix, rather than a vector.
>>>> 
>>>> This is based upon the svn trunk version of poly.Rd.
>>> 
>>> I don't think this is the right fix.  The use of the unnamed 2nd arg as 
>>> degree happens whether the first arg is a matrix or not.
>>> 
>>> I didn't read the whole thread in detail, but it appears there's a bug 
>>> somewhere, in the report or in the poly() code or in the plsr() code. That 
>>> bug should be reported on the bug list if it turns out to be in base R, and 
>>> to the package maintainer if it is in plsr().
>>> 
>>> Duncan Murdoch
>> 
>> 
>> Duncan,
>> 
>> Thanks for your reply. You only really need to read that last post in the 
>> thread linked to above.
>> 
>> I won't deny the possibility of a bug in poly(), relative to the handling of 
>> 'x' as a matrix. The behavior occurs in the poly() function in a pure stand 
>> alone fashion, without the need for plsr():
>> 
>> x1 <- runif(20)
>> x2 <- runif(20)
>> mx <- cbind(x1, x2)
>> 
> 
> 
> 
> Duncan,
> 
> Tracing through the code for poly() using debug once with:
> 
>  poly(mx, 2)
> 
> and then with:
> 
>  poly(mx, degree = 2)
> 
> there is a difference in the transformation of 'mx' internally by the use of:
> 
> if (is.matrix(x)) {
>m <- unclass(as.data.frame(cbind(x, ...)))
>return(do.call(polym, c(m, degree = degree, raw = raw, list(coefs = 
> coefs
> }
> 
> 
> In the first case, 'mx' ends up being transformed to:
> 
> Browse[2]> m
> $x1
> [1] 0.99056941 0.13953093 0.38965567 0.35353514 0.90838486 0.97552474
> [7] 0.01135743 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
> [13] 0.31333549 0.97488211 0.54952630 0.71747157 0.31164777 0.81694822
> [19] 0.58641410 0.08858699
> 
> $x2
> [1] 0.6628658 0.9221436 0.3162418 0.8494452 0.4665010 0.3403719
> [7] 0.4040692 0.4916650 0.9091161 0.2956006 0.3454689 0.3331070
> [13] 0.8788974 0.5614636 0.7794396 0.2304009 0.6566537 0.6875646
> [19] 0.5110733 0.4122336
> 
> $V3
> [1] 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
> 
> attr(,"row.names")
> [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20
> 
> Thus, when do.call() is used, m$V3 is passed as the 'x' argument on the third 
> iteration, essentially resulting in:
> 
>> polym(rep(2, 20), degree = 2)
> Error in poly(dots[[1L]], degree, raw = raw, simple = raw && nd > 1) : 
> 'degree' must be less than number of unique points
> 
> 
> Note also that in this case, 'dots', which is the result of using list(...) 
> on the initial call, is:
> 
> Browse[2]> dots
> [[1]]
> [1] 2
> 
> 
> In the second case:
> 
> Browse[2]> m
> $x1
> [1] 0.99056941 0.13953093 0.38965567 0.35353514 0.90838486 0.97552474
> [7] 0.01135743 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
> [13] 0.31333549 0.97488211 0.54952630 0.71747157 0.31164777 0.81694822
> [19] 0.58641410 0.08858699
> 
> $x2
> [1] 0.6628658 0.9221436 0.3162418 0.8494452 0.4665010 0.3403719
> [7] 0.4040692 0.4916650 0.9091161 0.2956006 0.3454689 0.3331070
> [13] 0.8788974 0.5614636 0.7794396 0.2304009 0.6566537 0.6875646
> [19] 0.5110733 0.4122336
> 
> attr(,"row.names")
> [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20
> 
> 
> So, there is no m$V3.
> 
> Note also that 'dots' ends up being:
> 
> Browse[2]> dots
> list()
> 
> 
> In both cases, 'degree' is indeed 2, but the result of 'list(...)' on the 
> initial function call is quite different.
> 
> So, I may be hypo-caffeinated, but if there is a bug here, it may be due to 
> the way in which cbind() is being called in the code above, where the three 
> dots are being used?
> 
> I can replicate the presumably correct behavior by using:
> 
>  m <- unclass(as

Re: [Rd] Proposed Patch for poly.Rd

[Marc Schwartz]

> On Jul 13, 2017, at 3:37 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
> 
> 
>> On Jul 13, 2017, at 3:22 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
>> 
>> On 13/07/2017 4:08 PM, Marc Schwartz wrote:
>>> Hi All,
>>> 
>>> As per the discussion today on R-Help:
>>> 
>>> https://stat.ethz.ch/pipermail/r-help/2017-July/448132.html
>>> 
>>> I am attaching a proposed patch for poly.Rd to provide clarifying wording 
>>> relative to naming the 'degree' argument explicitly, in the case where the 
>>> 'x' argument is a matrix, rather than a vector.
>>> 
>>> This is based upon the svn trunk version of poly.Rd.
>> 
>> I don't think this is the right fix.  The use of the unnamed 2nd arg as 
>> degree happens whether the first arg is a matrix or not.
>> 
>> I didn't read the whole thread in detail, but it appears there's a bug 
>> somewhere, in the report or in the poly() code or in the plsr() code. That 
>> bug should be reported on the bug list if it turns out to be in base R, and 
>> to the package maintainer if it is in plsr().
>> 
>> Duncan Murdoch
> 
> 
> Duncan,
> 
> Thanks for your reply. You only really need to read that last post in the 
> thread linked to above.
> 
> I won't deny the possibility of a bug in poly(), relative to the handling of 
> 'x' as a matrix. The behavior occurs in the poly() function in a pure stand 
> alone fashion, without the need for plsr():
> 
> x1 <- runif(20)
> x2 <- runif(20)
> mx <- cbind(x1, x2)
> 



Duncan,

Tracing through the code for poly() using debug once with:

  poly(mx, 2)

and then with:

  poly(mx, degree = 2)

there is a difference in the transformation of 'mx' internally by the use of:

if (is.matrix(x)) {
m <- unclass(as.data.frame(cbind(x, ...)))
return(do.call(polym, c(m, degree = degree, raw = raw, list(coefs = 
coefs
}


In the first case, 'mx' ends up being transformed to:

Browse[2]> m
$x1
 [1] 0.99056941 0.13953093 0.38965567 0.35353514 0.90838486 0.97552474
 [7] 0.01135743 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
[13] 0.31333549 0.97488211 0.54952630 0.71747157 0.31164777 0.81694822
[19] 0.58641410 0.08858699

$x2
 [1] 0.6628658 0.9221436 0.3162418 0.8494452 0.4665010 0.3403719
 [7] 0.4040692 0.4916650 0.9091161 0.2956006 0.3454689 0.3331070
[13] 0.8788974 0.5614636 0.7794396 0.2304009 0.6566537 0.6875646
[19] 0.5110733 0.4122336

$V3
 [1] 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

attr(,"row.names")
 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20

Thus, when do.call() is used, m$V3 is passed as the 'x' argument on the third 
iteration, essentially resulting in:

> polym(rep(2, 20), degree = 2)
Error in poly(dots[[1L]], degree, raw = raw, simple = raw && nd > 1) : 
 'degree' must be less than number of unique points


Note also that in this case, 'dots', which is the result of using list(...) on 
the initial call, is:

Browse[2]> dots
[[1]]
[1] 2


In the second case:

Browse[2]> m
$x1
 [1] 0.99056941 0.13953093 0.38965567 0.35353514 0.90838486 0.97552474
 [7] 0.01135743 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
[13] 0.31333549 0.97488211 0.54952630 0.71747157 0.31164777 0.81694822
[19] 0.58641410 0.08858699

$x2
 [1] 0.6628658 0.9221436 0.3162418 0.8494452 0.4665010 0.3403719
 [7] 0.4040692 0.4916650 0.9091161 0.2956006 0.3454689 0.3331070
[13] 0.8788974 0.5614636 0.7794396 0.2304009 0.6566537 0.6875646
[19] 0.5110733 0.4122336

attr(,"row.names")
 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20


So, there is no m$V3.

Note also that 'dots' ends up being:

Browse[2]> dots
list()


In both cases, 'degree' is indeed 2, but the result of 'list(...)' on the 
initial function call is quite different.

So, I may be hypo-caffeinated, but if there is a bug here, it may be due to the 
way in which cbind() is being called in the code above, where the three dots 
are being used?

I can replicate the presumably correct behavior by using:

  m <- unclass(as.data.frame(cbind(x)))

instead of:

  m <- unclass(as.data.frame(cbind(x, ...)))

But I am not sure if removing the three dots in the cbind() call may have other 
unintended consequences.

Regards,

Marc

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

Re: [Rd] Proposed Patch for poly.Rd

[Marc Schwartz]

> On Jul 13, 2017, at 3:22 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
> 
> On 13/07/2017 4:08 PM, Marc Schwartz wrote:
>> Hi All,
>> 
>> As per the discussion today on R-Help:
>> 
>>  https://stat.ethz.ch/pipermail/r-help/2017-July/448132.html
>> 
>> I am attaching a proposed patch for poly.Rd to provide clarifying wording 
>> relative to naming the 'degree' argument explicitly, in the case where the 
>> 'x' argument is a matrix, rather than a vector.
>> 
>> This is based upon the svn trunk version of poly.Rd.
> 
> I don't think this is the right fix.  The use of the unnamed 2nd arg as 
> degree happens whether the first arg is a matrix or not.
> 
> I didn't read the whole thread in detail, but it appears there's a bug 
> somewhere, in the report or in the poly() code or in the plsr() code. That 
> bug should be reported on the bug list if it turns out to be in base R, and 
> to the package maintainer if it is in plsr().
> 
> Duncan Murdoch


Duncan,

Thanks for your reply. You only really need to read that last post in the 
thread linked to above.

I won't deny the possibility of a bug in poly(), relative to the handling of 
'x' as a matrix. The behavior occurs in the poly() function in a pure stand 
alone fashion, without the need for plsr():

x1 <- runif(20)
x2 <- runif(20)
mx <- cbind(x1, x2)

> poly(mx, 2)
Error in poly(dots[[i]], degree, raw = raw, simple = raw) : 
  'degree' must be less than number of unique points

The above error occurs because of the way in which 'mx' is transformed 
internally in poly(), as per the R-Help post I linked to above.


Compare that to:

> poly(mx, degree = 2)
  1.0  2.0 0.1  1.1 0.2
 [1,] -0.11175349 -0.112802655  0.34729146 -0.038811031  0.29371194
 [2,]  0.27620511 -0.102592711  0.27672559  0.076433023  0.10192546
 [3,]  0.31709686 -0.000822981 -0.06017089 -0.01908 -0.20283645
 [4,] -0.05873472 -0.213373684  0.26314361 -0.015455666  0.07009778
 [5,] -0.17389885  0.046175314  0.08393899 -0.014596893 -0.19610518
 [6,] -0.07143282 -0.192226574  0.12931566 -0.009237383 -0.15572309
 [7,] -0.20924410  0.156380030 -0.38783860  0.081152937  0.46977236
 [8,]  0.09192574 -0.322960534 -0.13012298 -0.011961651 -0.13946871
 [9,] -0.08030862 -0.176345544 -0.11855987  0.009521379 -0.15294790
[10,]  0.26551532 -0.126030940 -0.09225246 -0.024494442 -0.17918115
[11,] -0.16961102  0.033781845  0.23980484 -0.040673544  0.01924080
[12,] -0.23503411  0.245845222  0.37898576 -0.089074579  0.39427472
[13,]  0.44343189  0.434902694  0.19305658  0.085607445 -0.06804699
[14,] -0.16429372  0.018706099 -0.04315970  0.007090868 -0.21166328
[15,]  0.04616179 -0.317237087 -0.09818924 -0.004532591 -0.17379927
[16,] -0.20148531  0.130959507 -0.32805340  0.066097939  0.27578123
[17,] -0.25585213  0.323634018 -0.34406268  0.088029169  0.32460950
[18,] -0.21168308  0.164513794 -0.10037452  0.021247587 -0.17173927
[19,]  0.41817752  0.333143463 -0.04018127 -0.016802902 -0.21294380
[20,]  0.08481772 -0.323649275 -0.16929688 -0.014359375 -0.08495871
attr(,"degree")
[1] 1 2 1 2 2
attr(,"coefs")
attr(,"coefs")[[1]]
attr(,"coefs")[[1]]$alpha
[1] 0.3596862 0.5799695

attr(,"coefs")[[1]]$norm2
[1]  1.00 20.00  1.898620  0.109334


attr(,"coefs")[[2]]
attr(,"coefs")[[2]]$alpha
[1] 0.5123548 0.5290189

attr(,"coefs")[[2]]$norm2
[1]  1.000 20.000  1.5765605  0.1255148


attr(,"class")
[1] "poly"   "matrix"



Thoughts?

Regards,

Marc

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

Re: [Rd] Are you considering the possibility of partnership?

[Marc Schwartz]

Hi All,

Just an FYI, that the sender's e-mail was set up last week to auto-discard for 
R-Devel and their reply below to R-Devel was filtered in that manner.

Unfortunately, it would seem that they also targeted some other specific 
accounts as well. 

As Spencer notes, I would add their e-mail address to any spam filters folks 
may be using.

Regards,

Marc


> On Jul 3, 2017, at 7:07 AM, Spencer Graves  
> wrote:
> 
> 
> 
> On 2017-07-03 2:02 PM, Uwe Ligges wrote:
>> Plese stop this.
> 
> 
>  People who reply to spammers only invite more spam.  The only way I know 
> to defeat them is to get software to block them.  The anti-spam software I 
> have is not great but is better than nothing.
> 
> 
>  Spencer
> 
>> 
>> Best,
>> Uwe Ligges
>> 
>> 
>> 
>> On 03.07.2017 11:29, Keira Cohen wrote:
>>> Hi,
>>> 
>>> I've sent you partnership offer via e-mail several days ago. Did you
>>> receive it? Are you interested in placing ads on your site?
>>> 
>>> 
>>> Best regards,
>>> Keira
>>> 
>>> On Fri, Jun 30, 2017 at 11:10 AM, Keira Cohen  wrote:
>>> 
 Hi,
 
 did you receive my mail about ad placements? If so it would be great to
 get a feedback from you.
 
 
 Best regards,
 Keira
 
 On Wed, Jun 28, 2017 at 11:54 AM, Keira Cohen 
 wrote:
 
> Hi,
> I'm software developer and I think it might be great to advertise my
> software on your web site. If you are interested in partnership please
> contact me at any time.
> 
> Best regards,
> Keira
> 
 
 
>>> 
>>>[[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

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

Re: [Rd] SUGGESTION: R Base Packages

[Marc Schwartz]

> On May 18, 2017, at 2:18 AM, TELLERIA RUIZ DE AGUIRRE, JUAN 
> <jtelle...@external.gamesacorp.com> wrote:
> 
> Thank you Frederick for your comments:
> 
> They are really well justified.
> 
>> I think a "forum" or bulletin board system would be a detraction from the 
>> project and a distraction for the project leaders. Users have Stack Exchange 
>> - it's better than any forum we could create, and it 
>> takes care of itself.
> 
> An excellent idea would be to add in the R Project Webpage a link to RSeek, 
> in order to put all together. This can be done in a fast and easy way.


Hi,

It is already there, in two places:

  https://www.r-project.org/search.html

and 

   https://www.r-project.org/help.html

both of those accessible from the navigation menu on the left side of the home 
page under "Search" and "Getting Help".

Regards,

Marc Schwartz


> 
>> I too was annoyed by the state of the bug reporting system when I first 
>> started using R, and that was even before automatic account creation was 
>> disabled. I think the situation could be improved. 
>> I don't think it's a huge burden to tell bug reporters to ask for an account 
>> via the R-devel mailing list. But from what I can see the bug tracker 
>> doesn't make it clear that this has to be done. We should at 
>> least post a message on the main page explaining how people can create an 
>> account. This would be less work than what Juan is suggesting, but I think 
>> sufficient for our needs.
> 
> Yes, clarifying in the RProject webpage that accounts could be requested for 
> bug reporting in Bugzilla would be a great news, but it shall be really good 
> justified.
> 
>> I think this is a terrible idea. I've only been using R for a few years and 
>> while I find these "tidyverse" packages interesting and use them on 
>> occasion, I've also concluded that they change too quickly to 
>> be used in code that I want to stay working for a long time. They are 
>> largely based on experimental concepts. Being able to change and evolve is 
>> part of the strength of these packages. So I think putting 
>> them in the R Base distribution would be bad for all parties.
> 
> Totally agree.
> 
>> I think the R project web page looks great. It's simple and it loads quickly 
>> and doesn't try to mesmerize people. I like R's command line interface. It 
>> completes on symbols and files and I can easily use it 
>> with my favorite editor and run it in the terminal of my choice. I don't 
>> think that more effort should be put into developing bloated GUIs which try 
>> to enforce a standard way of interacting with R.
> 
> I agree, but, in my opinion,  the RGUI icons  shall have a little bit more 
> modern look. Just a bit.
> 
> Thank you,
> Juan

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

Re: [Rd] non-infectious license for R package?

[Marc Schwartz]

> On Mar 25, 2017, at 8:35 AM, Mario Emmenlauer <ma...@emmenlauer.de> wrote:
> 
> 
> On 25.03.2017 14:29, Mario Emmenlauer wrote:
>> 
>> Dear All,
>> 
>> thanks a lot for all the quick and helpful responses! I'm currently
>> interested in the "stance" of this community towards closed source
>> contributions. The way I understand it, currently my options are quite
>> limited: I would most likely need to use a remote procedure call API,
>> and build one side of the API as GPL. But this would make the coupling
>> much slower and more error-prone.
>> 
>> I was actually hoping to give modellers very efficient access to big
>> image analysis data (single cell results in multi-TB range). Currently
>> R seems not easily combined with the classical closed-source company
>> model. Are there considerations to release just the part that is
>> required to build the interface to R under a more permissive license?
> 
> I.e. I was thinking of something like this FAQ entry of the GPL: How
> can I allow linking of proprietary modules with my GPL-covered library
> under a controlled interface only? From
> https://www.gnu.org/licenses/gpl-faq.en.html#LinkingOverControlledInterface
> 
> 
> 
> 
>> All the best,
>> 
>>   Mario
>> 
>> 



Hi,

As per the language included in the section of the FAQ that you reference 
above, if you want to go down that path, you would have to engage in formally 
communicating with the R Foundation, as the copyright holders of R, to solicit 
their formal position, which would be final. Note that depending upon the 
specifics, there may be other parties that would also have to render a 
decision, since other individuals also hold copyrights to included code in the 
standard R distribution and may or may not have given approval to the R 
Foundation to act on their behalf:

  https://svn.r-project.org/R/trunk/doc/COPYRIGHTS

If you wanted to pursue that avenue, you should communicate with the current R 
Foundation Co-Presidents:

  Simon Urbanek (simon.urba...@r-project.org)
  Martyn Plummer (plumm...@iarc.fr)

were they can elect to engage the Board of the R Foundation in further 
discussion.

To the broader issue of the "stance" of the community at large vis-a-vis closed 
source software, you will find, as in any community, a spectrum of positions. 

There are, as you may be aware, commercial versions of R, that have been built 
upon the standard open source R distribution, which offer sufficient additional 
value that their customers are willing to pay for them. In some cases, these 
may include closed source components. A parallel of sorts would be a community 
based, open source version of a Linux server distribution (e.g. CentOS) versus 
a commercial offering (e.g. RHEL), where the latter has paid support options 
and other value added components and services that are revenue generating. In 
these commercial cases, as I referenced in my prior reply, legal counsel with 
expertise in open source licensing and intellectual property rights, will have 
rendered formal legal opinions to provide guidance and comfort that these 
for-profit businesses remain in conformance with license requirements to stay 
clear of any liabilities. No ethical business, in their right mind, would move 
forward without that.

However, at the end of the day, the only position that is relevant to your 
issue is the formal position of the R Foundation itself, since it holds the 
copyright to R as officially distributed and would, if needed, take action in 
the case of license non-conformance.

Others in the community, myself included, can offer opinions, but they hold no 
relevance to your situation, since they are not legally binding. In other 
words, we are not in a position to say that you can or cannot proceed with your 
plan. You can gain some insights, as others have referenced, by using examples 
of what appear to be acceptable implementations. But each situation can have 
sufficient differences as to perhaps not be exactly applicable to yours. Thus, 
part of the potential challenge for you would be to provide sufficient detail 
on your exact implementation plans to allow an opinion to be rendered that 
narrowly covers those details, as opposed to a more generic model.

Regards,

Marc Schwartz

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

Re: [Rd] non-infectious license for R package?

[Marc Schwartz]

See inline...

> On Mar 24, 2017, at 8:52 AM, Mario Emmenlauer <ma...@emmenlauer.de> wrote:
> 
> 
> Dear All,
> 
> I've been following this mailing list for over three years now, but
> its just now that I have realized that R is licensed under GPL! :-)
> 
> I'm not a lawyer and I don't want lawyer advice, but I'd like to get
> your feedback on a license question.


Hi, 

With the usual IANAL caveat and that I am not speaking on behalf of any other 
parties:

The questions you are posing will require legal advice, so your desire above to 
not get legal advice is in direct conflict with what you actually need here.

To your comments below, you cannot change existing licenses on software, R or 
otherwise. That is only something that the copyright holder(s) can do and you 
are not one of them.

The GPL has a FAQ here:

  https://www.gnu.org/licenses/gpl-faq.en.html 
<https://www.gnu.org/licenses/gpl-faq.en.html>

that you may find enlightening.

A very general statement, which is that if your compiled code (in whatever 
language) does not "link" against R's libraries and does not directly contain 
GPL licensed code (e.g. copying and pasting R Foundation copyrighted source 
code into yours), that is one way to steer clear of the viral part of the GPL 
license vis-a-vis R, if you want to, but not the only way and not a guarantee 
either. There can be nuances, some of which are covered in the FAQ above.

On the other hand, if your compiled code is linking to R's libraries, which you 
seem to suggest may be the case below, then your code, at least the relevant 
parts of it, will need to be licensed under a GPL compatible license.

This again is part of the nuance, in terms of the scope of the impact on your 
code (all or parts) and where legal advice is needed, to steer clear of 
downstream potential issues that could result in legal and financial 
liabilities for you.

The issue of linking to third party proprietary libraries is something that you 
will have to evaluate with respect to their licenses and any limitations that 
they may impose on your code and it's licensing.

Since you seem to also be suggesting that you may use closed source components 
in your package, you should be aware, that vis-a-vis CRAN, you would not be 
able to submit your package for distribution via that channel, since CRAN 
submissions may not contain pre-compiled binaries or similar and the entire 
package must conform to a compatible open source license. Thus, if you go down 
that path, you would have to find other distribution channels for your package, 
such as a company web site, etc.

None of the above should be construed as legal advice and if you plan to go 
down the path of offering a commercial service that you would charge clients 
for, a lawyer is mandatory to provide legal guidance and to assess your 
business risks. Even if your actual R related package is offered free of 
charge, while generating revenue through other means, if you should run afoul 
of software licensing requirements, that can still leave you open to financial 
liabilities and put your business and even personal assets at risk.

Regards,

Marc Schwartz


> My goal is to develop commercial
> software for image analysis of biomedical samples that may be used
> i.e. in academic institutions. Since I've been an academic software
> developer for long, a priority for me is to make the data and tools
> easily accessibly for other developers. I have toyed with the idea to
> make a (free) R package that can very efficiently fetch data from the
> database and push back results for visualization. To clarify: I am
> not using R in my software. I'd rather like the institutions of my
> customers to have open (internal) access to their data.
> 
> Now for the question: To efficiently get the data into R, I assume a
> package (possibly in C or C++) is the most reasonable way? If yes,
> would such a package automatically be infected by the GPL? If the
> package links to (proprietary closed source) libraries to efficiently
> access the data, would the libraries in turn be infected?
> 
> I'm asking this very naiively because I understand statement [1] in
> such a way that it is generally encouraged to make data available in
> R. Obviously open source is the preferred way, but my understanding
> is that also closed source extensions can add value and may be
> welcome.
> 
> I was therefore hoping that somebody has prior experience in this
> regard, or can shed further light on statement [1]. Is the R-C-
> interface infectious per se, even when data flows only into R, not
> vice versa? If its infectious, could just the very core of R be
> licensed additionally under a non-infectious license?
> 
> Furthermore, can I avoid infecting my full software stack, for example
> by making only the package open source under a permissive license

Re: [Rd] Suggestion: barplot function

[Marc Schwartz]

> On Feb 3, 2017, at 8:23 AM, Robert Baer  wrote:
> 
> 
> On 1/27/2017 8:30 AM, danielren...@lycos.com wrote:
>> Hello developers folks!
>> 
>> First, congratulations for the wonderful work with R.
>> 
>> For science, barplots with error bars are very important. We were wondering 
>> that is so easy to use the boxplot function:
>> 
>> boxplot(Spores~treatment, col=treatment_colors)
>> 
>> But there is no such function for barplots with standard deviation or 
>> standard error. It becomes a "journey" to plot a simple graph (e.g. 
>> https://www.r-bloggers.com/building-barplots-with-error-bars/).
>> 
>> The same way that is easy to use the boxplot function, do you think it is 
>> possible to upgrade the barplot function: i.e.: barplot(Spores~treatment, 
>> error.bar=standard_error, col=treatment_colors)
> Marc may not speak for R Core, but he certainly has summarized what has been 
> an apparent consensus attitude to barplot() and confidence bars in this 
> community over the last decade.  Further, he is probably right about no 
> changes after this many years.
> 
> I might mention that if you want a close cousin to barplot() that does what 
> you want with base graphics (from the drawing mechanics point of view) see 
> the barplot2() function in the gplots package. You provide your own bar 
> lengths.  Regardless of their merits, barplots are a common graphing 
> mechanism used by my scientific colleagues to convey their data, and I don't 
> see that changing any time soon.  The one thing that is even less forgivable 
> than dynamite plots is bars with no dispersion indication at all. Too bad 
> barplot2() isn't the default.


Hi,

Since Robert has kindly raised the barplot2() function, in the interest of full 
disclosure, as the original author of that function, my prior comments may seem 
contradictory.

I originally wrote the barplot2() function back in 2002 
(https://stat.ethz.ch/pipermail/r-devel/2002-September/025092.html 
), based 
upon my usage patterns at the time. It included the ability to use log scaled 
axes (later added to base R's barplot()), binomial confidence intervals and 
some other features, building directly on the default barplot() function code 
in base R for compatibility.

It was an early attempt back then, to give back to the community based upon 
some requests at the time. Greg Warnes was subsequently kind enough to offer to 
include it in the gplots package on CRAN.

That being said, because of the issues that I raised in my prior reply, which 
also reflect my own evolution in thinking in the many years since, I have not 
used the barplot2() function nor modified/updated the code in any way in well 
over 10 years. In fact, in general, I find that my clients in the clinical 
domains that I work in, have also come to see less value in their use, in 
deference to other presentation formats and I rarely use them in my analyses. 
As I noted in my prior reply, where I see them still commonly used tends to be 
for tabulations/counts for things like monthly/quarterly clinical trial 
enrollment trends, etc.

In either case, Robert rightly raises the point that, despite the criticisms, 
they are still widely used as change can be slow to manifest. Thus, there are 
options to create such plots where desired, using barplot2(), the ggplot2 
package and other functions in various CRAN packages. Or as I noted, if you 
don't want to install a package just for the sake of this one feature, it is 
easy to create them with a few function calls like segments() or arrows() over 
the default barplot.

Regards,

Marc


>> 
>> Thank you so much!
>> Daniel, FU-Berlin
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> -- 
> 
> 
> --
> Robert W. Baer, Ph.D.
> Professor of Physiology
> Kirksville College of Osteopathic Medicine
> A T Still University of Health Sciences
> 800 W. Jefferson St
> Kirksville, MO 63501
> 660-626-2321 Department
> 660-626-2965 FAX
> 
> __
> 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] cross-platform portable code in CRAN Repository Policy

[Marc Schwartz]

> On Jan 27, 2017, at 3:28 PM, Da Zheng <zhengda1...@gmail.com> wrote:
> 
> Hello,
> 
> I'm trying to submit my package to CRAN. When I read the policy, it says:
> Package authors should make all reasonable efforts to provide
> cross-platform portable code. Packages will not normally be accepted
> that do not run on at least two of the major R platforms.
> 
> What major R platforms does this policy refer to?
> Currently, my package runs in Ubuntu. If it works on both Ubuntu and
> Redhat, does it count as two platforms?
> 
> Thanks,
> Da


Hi,

A couple of comments:

1. For future reference, this query would have been better sent to 
R-Package-Devel, which is focused on this topic:

  https://stat.ethz.ch/mailman/listinfo/r-package-devel


2. "Major platforms" would typically refer to Linux, Windows and macOS. So 
Ubuntu and RH would be within Linux as a single platform.


Regards,

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

Re: [Rd] Suggestion: barplot function

[Marc Schwartz]

> On Jan 27, 2017, at 8:30 AM, danielren...@lycos.com wrote:
> 
> Hello developers folks!
> 
> First, congratulations for the wonderful work with R.
> 
> For science, barplots with error bars are very important. We were wondering 
> that is so easy to use the boxplot function:
> 
> boxplot(Spores~treatment, col=treatment_colors)
> 
> But there is no such function for barplots with standard deviation or 
> standard error. It becomes a "journey" to plot a simple graph (e.g. 
> https://www.r-bloggers.com/building-barplots-with-error-bars/).
> 
> The same way that is easy to use the boxplot function, do you think it is 
> possible to upgrade the barplot function: i.e.: barplot(Spores~treatment, 
> error.bar=standard_error, col=treatment_colors)
> 
> Thank you so much!
> Daniel, FU-Berlin


Hi,

With the caveat that I do not speak on behalf of R Core:

Boxplots are specifically designed to include "whiskers" (NOT error bars) that 
aid to visually describe the distribution of continuous data. The whiskers do 
not represent standard deviations (SDs). Thus, that the boxplot() function 
contains the code to draw the whiskers automatically is not relevant to 
barplot().

Barplots are best used to visually present tabulations of categorical data 
(e.g. counts or percentages), in which case, the "error" bars would typically 
represent binomial or similar confidence intervals. Even there, many will 
advocate that dotplots be used instead as a better presentation format, as 
barplots, much like pie charts, have a high "ink to data" ratio.

Barplots should not really be used to present continuous data (e.g. means and 
SDs).

You will find a great deal of disagreement with your premise that barplots with 
error bars are very important to science. If you do a Google search for 
"Dynamite Plot", especially where only the upper error bar is included, you 
will find a variety of critical discussions on that point, such as:

  http://biostat.mc.vanderbilt.edu/wiki/pub/Main/TatsukiRcode/Poster3.pdf 
<http://biostat.mc.vanderbilt.edu/wiki/pub/Main/TatsukiRcode/Poster3.pdf>

You pointed to one example of how easy it is to actually add error bars to a 
barplot in R, and that approach, of incrementally building plots using multiple 
functions, is an integral part of R's philosophy. There is also an example in 
?barplot.

Generally, R's default approaches to most analyses are extremely well reasoned. 
Thus, if you don't see something in a function by default, there is generally 
strong logic behind what is being done, or as in this case, not being done.

If you wanted to, it would be a reasonable exercise for you to create your own 
plotting function that wraps barplot() and either segments() or arrows() in a 
single function call, where you can pass arguments that contain the values for 
the various components and draw the plot as you desire. That is how a lot of R 
code is created.

There are other graphic functions in R packages, such as ggplot2 
(https://www.r-bloggers.com/using-r-barplot-with-ggplot2/ 
<https://www.r-bloggers.com/using-r-barplot-with-ggplot2/>) and others on CRAN 
that offer methods to add error bars to barplots that others have created if 
you wanted to research those.

As a result of all of the above, I am not sure that, after all these years, 
error bars would be added to barplot() as a standard feature.

Regards,

Marc Schwartz


[[alternative HTML version deleted]]

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

Re: [Rd] Spam messages

[Marc Schwartz]

Hi,

FWIW, I checked the R-Devel subscriber list of e-mail addresses (as Co-Admin 
with Martin I have access). There are presently 1,296 subscribers to individual 
posts and 746 to post digests on R-Devel.

Neither of the two e-mail addresses referenced below as being the sources of 
spam are listed as subscribers.

A Google search of those two e-mail addresses also came up empty. The 
"octbm.com <http://octbm.com/>" domain is legitimate, though the web site is 
"under construction" and the whois information shows that it was registered 
earlier this year by a person in Bangladesh who seems to own a large number of 
domains:

  http://www.domainiq.com/email?mesba.ci...@gmail.com

There are a lot of technical ways of falsely generating those two e-mail 
addresses of course and an inspection of the full e-mail headers might be 
fruitful, although there are ways of manipulating those as well.

Regards,

Marc


> On Dec 6, 2016, at 10:20 AM, frede...@ofb.net wrote:
> 
> I agree that no action should be taken.
> 
> It's somewhat mystifying that the robot known as "Amy Kristen"
> responds so quickly after my post, and with such regularity (so far
> twice per hour), using perhaps several email addresses - and using the
> correct "Reply-To" headers. But more mystifying is that she keeps the
> same name the whole time. And lucky, I guess, because otherwise I
> wouldn't know how to filter her out...
> 
> On Tue, Dec 06, 2016 at 10:02:11AM -0600, Marc Schwartz wrote:
>> Hi,
>> 
>> This topic has come up previously, across the R e-mail lists and the 
>> spammers need not be subscribers (but could be), but simply reasonably 
>> competent HTML scrapers.
>> 
>> If you look at the online archives of the R lists, for example R-Devel for 
>> this month:
>> 
>>https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html 
>> <https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html>
>> 
>> and look at the individual posts, there is only minimal munging of e-mail 
>> addresses, which is easily overcome with basic scripting.
>> 
>> This is further compounded by there being a multitude of other places on the 
>> web, where actively updated archives of the R lists exist, providing 
>> additional sources of e-mail addresses for spammers.
>> 
>> Some of the prior discussions had considered that we might preserve only the 
>> list address in the posts sent out (as some groups do) and fully scrape the 
>> sender's e-mail address from the post when distributed and archived. 
>> However, that approach is not without it's own limitations (e.g. would make 
>> cc's and reply-all largely useless, except for off-list discussion) and so 
>> no action has been taken since this seems to be a transient issue.
>> 
>> Regards,
>> 
>> Marc Schwartz
>> 
>> 
>>> On Dec 6, 2016, at 7:52 AM, Mario Emmenlauer <ma...@emmenlauer.de> wrote:
>>> 
>>> 
>>> The problem is not specific to this list. Any kind of public
>>> list may mean that other subscribers (or even the whole world)
>>> can see your email address. So whenever you mail to a (public)
>>> list there is a good chance that afterwards, you will get more
>>> spam. Not really much can be done about it, at least not on
>>> the side of the list, since any of the subscribers may be a
>>> spammer, who can know...
>>> 
>>> All the best,
>>> 
>>>   Mario
>>> 
>>> 
>>> 
>>> On 06.12.2016 14:13, frede...@ofb.net wrote:
>>>> Yes, I just heard from Amy Kristen who is "looking to meet new
>>>> guys"...
>>>> 
>>>> On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
>>>>> Have others received spam messages after posting to this list?
>>>>> 
>>>>> The two problem emails are hodgesdonna...@yahoo.com and
>>>>> amykristen4...@octbm.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
>>>> 
>>> 
>>> 
>>> 
>>> Viele Gruesse,
>>> 
>>>   Mario Emmenlauer
>>> 
>>> 
>>> --
>>> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
>>> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
>>> D-81669 München  http://www.biodataanalysis.de/
>>> 
>>> __
>>> 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] Spam messages

[Marc Schwartz]

Hi,

This topic has come up previously, across the R e-mail lists and the spammers 
need not be subscribers (but could be), but simply reasonably competent HTML 
scrapers.

If you look at the online archives of the R lists, for example R-Devel for this 
month:

https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html 
<https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html>

and look at the individual posts, there is only minimal munging of e-mail 
addresses, which is easily overcome with basic scripting.

This is further compounded by there being a multitude of other places on the 
web, where actively updated archives of the R lists exist, providing additional 
sources of e-mail addresses for spammers.

Some of the prior discussions had considered that we might preserve only the 
list address in the posts sent out (as some groups do) and fully scrape the 
sender's e-mail address from the post when distributed and archived. However, 
that approach is not without it's own limitations (e.g. would make cc's and 
reply-all largely useless, except for off-list discussion) and so no action has 
been taken since this seems to be a transient issue.

Regards,

Marc Schwartz


> On Dec 6, 2016, at 7:52 AM, Mario Emmenlauer <ma...@emmenlauer.de> wrote:
> 
> 
> The problem is not specific to this list. Any kind of public
> list may mean that other subscribers (or even the whole world)
> can see your email address. So whenever you mail to a (public)
> list there is a good chance that afterwards, you will get more
> spam. Not really much can be done about it, at least not on
> the side of the list, since any of the subscribers may be a
> spammer, who can know...
> 
> All the best,
> 
>Mario
> 
> 
> 
> On 06.12.2016 14:13, frede...@ofb.net wrote:
>> Yes, I just heard from Amy Kristen who is "looking to meet new
>> guys"...
>> 
>> On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
>>> Have others received spam messages after posting to this list?
>>> 
>>> The two problem emails are hodgesdonna...@yahoo.com and
>>> amykristen4...@octbm.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
>> 
> 
> 
> 
> Viele Gruesse,
> 
>Mario Emmenlauer
> 
> 
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> 
> __
> 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] seq.int does not return a sequence of integers sometimes

[Marc Schwartz]

> On Aug 3, 2016, at 3:12 PM, Paul Johnson <pauljoh...@gmail.com> wrote:
> 
> I have a script that goes wrong because I assumed that seq.int would
> return integers.
> 
> Below please see it does not unless user is super cautious about
> inserting "L" with inputs. I think seq.int should do coercion for me
> before returning the sequence.
> 
>> xx <- seq.int(1,10)
>> class(xx)
> [1] "integer"
>> is.integer(xx)
> [1] TRUE
>> xx <- seq.int(1,10, 2)
>> class(xx)
> [1] "numeric"
>> is.integer(xx)
> [1] FALSE
>> xx <- seq.int(1,10, 2L)
>> class(xx)
> [1] "numeric"
>> is.integer(xx)
> [1] FALSE
>> xx <- seq.int(1L, 10L, 2L)
>> class(xx)
> [1] "integer"
>> is.integer(xx)
> [1] TRUE
> 
> 
> I think all of those should have same return value, if the function is
> correctly named seq.int.


Paul,

?seq.int has the following:

under Details:

"seq.int is an internal generic which dispatches on methods for "seq" based on 
the class of the first supplied argument (before argument matching)."

and under Value:

"seq.int and the default method of seq for numeric arguments return a vector of 
type "integer" or "double": programmers should not rely on which."


So:

> is.integer(1)
[1] FALSE

> is.integer(1L)
[1] TRUE

which would seem to explain the behavior that you are observing.

Regards,

Marc Schwartz

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

Re: [Rd] RODBC on Mac & _R_CHECK_FORCE_SUGGESTS_

[Marc Schwartz]

> On Jun 20, 2016, at 9:19 AM, Spencer Graves <spencer.gra...@prodsyse.com> 
> wrote:
> 
>   "R CMD check sos" with R 3.3.0 under Mac OS X 10.11.5 ends as follows:
> 
> 
> >* checking package dependencies ... ERROR
> >Package suggested but not available: ‘RODBC’
> >
> >The suggested packages are required for a complete check.
> >Checking can be attempted without them by setting the environment
> >variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
> 
> 
>   Unfortunately, "install.packages('RODBC')" says it's only available in 
> source form.  When I  attempt to install from sources, it fails as follows:
> 
> 
> >checking for sqlext.h... no
> >configure: error: "ODBC headers sql.h and sqlext.h not found"
> >ERROR: configuration failed for package ‘RODBC’
> >* removing 
> >‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/RODBC’
> >Warning in install.packages :
> >  installation of package ‘RODBC’ had non-zero exit status
> 
> 
>   The CRAN checks for RODBC also failed for the same reason 
> (https://cloud.r-project.org/web/checks/check_results_RODBC.html).
> 
> 
> 
>   I'm not sure how to set "the environment variable 
> _R_CHECK_FORCE_SUGGESTS_ to a false value" on my Mac, and I'd rather not do 
> it permanently.  I tried various versions of "R CMD check 
> _R_CHECK_FORCE_SUGGESTS_=FALSE sos_1.3-9.tar.gz" and "R CMD check 
> _R_CHECK_FORCE_SUGGESTS_=0 sos_1.3-9.tar.gz", none of which worked. Somewhere 
> I found a suggestion to try, "R CMD check --as-cran sos_1.3-9.tar.gz".  That 
> also failed for me.
> 
> 
>   Suggestions?
>   Thanks,
>   Spencer Graves


Spencer,

The RODBC related error is a common issue and is covered in the vignette for 
the RODBC package in Appendix A "Installation":

  https://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf

You are missing the two iODBC header files that are required to compile the 
RODBC package from source code.

When I install RODBC on my Mac running 10.11.5 (El Capitan), I use:

install.packages("RODBC", type = "source", 
 configure.args = 
"--with-odbc-include=/Users/marcschwartz/R.Files/SourceAndBinaries/OSX-Tools/iODBC/libiodbc-3.52.10/include/")

where I have placed the extracted iODBC source tarball in:

  /Users/marcschwartz/R.Files/SourceAndBinaries/OSX-Tools/iODBC

The:

  configure.args = "--with-odbc-include=..." 

part of the function call points to where the header files are located after 
extraction from the tarball as per the vignette.

The iODBC source tarball can be downloaded from:

  http://www.iodbc.org/dataspace/iodbc/wiki/iODBC/Downloads


If you want to temporarily set the OS X environment variable, you can open an 
OS X Terminal and in the console, use:

  export _R_CHECK_FORCE_SUGGESTS_=FALSE 

You can then check to see if it is set by using:

  env 

in the Terminal and/or with the following in an R console run from within that 
same Terminal session:

> Sys.getenv("_R_CHECK_FORCE_SUGGESTS_")
[1] "FALSE"


Once you close that Terminal session, that modified environment is lost.

Also, at least the RODBC part of the issue should have been posted to R-SIG-DB 
(https://stat.ethz.ch/mailman/listinfo/r-sig-db), since it is DB interface 
specific. Most queries about RODBC are there in the archives, including those 
covering the missing headers.

The part that covers issues vis-a-vis checking your own package should go to 
R-Package-Devel:

  https://stat.ethz.ch/mailman/listinfo/r-package-devel

rather than R-Devel.

Regards,

Marc Schwartz

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

[Rd] Trivial patch for merge.Rd

[Marc Schwartz]

Hi all,

After replying to r-help earlier today on the merge() related thread, I noted a 
trivial grammatical error in the description for the 'suffixes' argument in 
it's help file.

A patch against the current SVN trunk version of merge.Rd in ..library/base/man 
is attached and pasted here:

--- merge1.Rd   2016-06-08 13:34:35.0 -0500
+++ merge2.Rd   2016-06-08 14:03:34.0 -0500
@@ -42,7 +42,7 @@
columns?}
  \item{suffixes}{a character vector of length 2 specifying the suffixes
to be used for making unique the names of columns in the result
-which not used for merging (appearing in \code{by} etc).}
+which are not used for merging (appearing in \code{by} etc).}
  \item{incomparables}{values which cannot be matched.  See
\code{\link{match}}.  This is intended to be used for merging on one
column, so these are incomparable values of that column.}


Thanks,

Marc Schwartz


--- merge1.Rd   2016-06-08 13:34:35.0 -0500
+++ merge2.Rd   2016-06-08 14:03:34.0 -0500
@@ -42,7 +42,7 @@
 columns?}
   \item{suffixes}{a character vector of length 2 specifying the suffixes
 to be used for making unique the names of columns in the result
-which not used for merging (appearing in \code{by} etc).}
+which are not used for merging (appearing in \code{by} etc).}
   \item{incomparables}{values which cannot be matched.  See
 \code{\link{match}}.  This is intended to be used for merging on one
 column, so these are incomparable values of that column.}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] data frame method for as.table()

[Marc Schwartz]

> On May 23, 2016, at 11:46 AM, Ernest Adrogué <e...@openmailbox.org> wrote:
> 
> Hello,
> 
> Currently it's possible to convert an object of class table to a data frame
> with as.data.frame.table(), but there's no ready-made function, AFAIK, to do
> the reverse operation, i.e. conversion of a data frame to a table.
> 
> Do you think it would be a good idea to add a data.frame method to
> as.table(), to allow such conversions?
> 
> The idea is that if `x' is a table and `y <- as.data.frame(x)', then the
> object returned by `as.table(y)' should be equal to `x'.
> 
> Below is a proof of concept
> 
> as.table.data.frame <- function(x, ..., response) {
>if (missing(response))
>resp <- ncol(x)
>else {
>resp <- match(response[1L], names(x))
>if (is.na(resp))
>stop('not found: ', response[1L])
>}
>x[-resp] <- lapply(x[-resp], as.factor)
>if (any(do.call(table, x[-resp]) > 1L))
>stop('repeated frequency value')
>dn <- lapply(x[-resp], function(y) {
>if (any(is.na(y))) c(levels(y), NA) else levels(y)
>})
>ind <- mapply(function(val, lev) match(val, lev), x[-resp], dn)
>out <- array(dim=unlist(lapply(dn, length)), dimnames=dn)
>out[ind] <- x[[resp]]
>as.table(out)
> }
> 
> and a simple usage example:
> 
>> (y <- table(foo=c('a','a',NA,'b','b'), useNA='always'))
> foo
>   ab  
>   221 
>> (yy <- as.data.frame(y))
>   foo Freq
> 1a2
> 2b2
> 3 1
>> as.table(yy)
> foo
>   ab  
>   221 
>> 
> 
> Any thoughts?

Hi,

I have not tried an exhaustive set of examples, but I believe that ?xtabs will 
get you most of the way there, with the exception of NA handling, which would 
require either nuanced use of ?addNA or preprocessing factors in the input data 
frame to possibly add NA as a factor level where needed.

BTW, from ?as.data.frame.table, see the reference there to xtabs() at the end:

"The as.data.frame method for objects inheriting from class "table" can be used 
to convert the array-based representation of a contingency table to a data 
frame containing the classifying factors and the corresponding entries (the 
latter as component named by responseName). This is the inverse of xtabs."


For example, from ?xtabs, using the ?UCBAdmissions dataset, which is a 3 
dimension table:

> str(UCBAdmissions)
 table [1:2, 1:2, 1:6] 512 313 89 19 353 207 17 8 120 205 ...
 - attr(*, "dimnames")=List of 3
  ..$ Admit : chr [1:2] "Admitted" "Rejected"
  ..$ Gender: chr [1:2] "Male" "Female"
  ..$ Dept  : chr [1:6] "A" "B" "C" "D" ...

DF <- as.data.frame(UCBAdmissions)

> str(DF)
'data.frame':   24 obs. of  4 variables:
 $ Admit : Factor w/ 2 levels "Admitted","Rejected": 1 2 1 2 1 2 1 2 1 2 ...
 $ Gender: Factor w/ 2 levels "Male","Female": 1 1 2 2 1 1 2 2 1 1 ...
 $ Dept  : Factor w/ 6 levels "A","B","C","D",..: 1 1 1 1 2 2 2 2 3 3 ...
 $ Freq  : num  512 313 89 19 353 207 17 8 120 205 ...


# Using your function
DF.Table <- as.table.data.frame(DF)

> str(DF.Table)
 table [1:2, 1:2, 1:6] 512 313 89 19 353 207 17 8 120 205 ...
 - attr(*, "dimnames")=List of 3
  ..$ Admit : chr [1:2] "Admitted" "Rejected"
  ..$ Gender: chr [1:2] "Male" "Female"
  ..$ Dept  : chr [1:6] "A" "B" "C" "D" ...


# Using xtabs()
DF.xtabs <- xtabs(Freq ~ ., data = DF)

> str(DF.xtabs)
 xtabs [1:2, 1:2, 1:6] 512 313 89 19 353 207 17 8 120 205 ...
 - attr(*, "dimnames")=List of 3
  ..$ Admit : chr [1:2] "Admitted" "Rejected"
  ..$ Gender: chr [1:2] "Male" "Female"
  ..$ Dept  : chr [1:6] "A" "B" "C" "D" ...
 - attr(*, "class")= chr [1:2] "xtabs" "table"
 - attr(*, "call")= language xtabs(formula = Freq ~ ., data = DF)


Note that DF.xtabs has additional attributes set as a result of the use of 
xtabs().

In the example that you provided above, you would need to use something along 
the lines of:

> xtabs(Freq ~ addNA(foo), data = yy)
addNA(foo)
   ab  
   221 

so that xtabs() includes the NA level, or for a larger data frame with a lot of 
columns, pre-process the columns so that NA is included in the factor levels 
where you desire.

That latter issue with NA's and xtabs() BTW, has bitten a lot of people over 
the years, where the recommendation to use:

> xtabs(Freq ~ foo, data = yy, exclude = NULL, na.action = na.pass)
foo
a b 
2 2 

does not actually work as believed.

Regards,

Marc Schwartz

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

[Rd] Apparent bug in summary.data.frame() with columns of Date class and NA's present

[Marc Schwartz]

Hi all,

Based upon an exchange with Göran Broström on R-Help today:

  https://stat.ethz.ch/pipermail/r-help/2016-February/435992.html

there appears to be a bug in summary.data.frame() in the case where a data 
frame contains Date class columns that contain NA's and other columns, if 
present, do not.

Example, modified from R-Help:

x <- c(1800, 18810924, 19091227, 19027233, 19310526, 19691228, NA)
x.Date <- as.Date(as.character(x), format = "%Y%m%d")

DF.Dates <- data.frame(Col1 = x.Date)

> summary(x.Date)
Min.  1st Qu.   Median Mean  3rd Qu. 
"1881-09-24" "1902-12-04" "1920-09-10" "1923-04-12" "1941-01-17" 
Max. NA's 
"1969-12-28"  "3" 


# NA's missing from output
> summary(DF.Dates)
  Col1   
 Min.   :1881-09-24  
 1st Qu.:1902-12-04  
 Median :1920-09-10  
 Mean   :1923-04-12  
 3rd Qu.:1941-01-17  
 Max.   :1969-12-28  


DF.Dates$x1 <- 1:7

> DF.Dates
Col1 x1
1 1
2 1881-09-24  2
3 1909-12-27  3
4 4
5 1931-05-26  5
6 1969-12-28  6
7 7

# NA's still missing
> summary(DF.Dates)
  Col1  x1 
 Min.   :1881-09-24   Min.   :1.0  
 1st Qu.:1902-12-04   1st Qu.:2.5  
 Median :1920-09-10   Median :4.0  
 Mean   :1923-04-12   Mean   :4.0  
 3rd Qu.:1941-01-17   3rd Qu.:5.5  
 Max.   :1969-12-28   Max.   :7.0  


DF.Dates$x2 <- c(1:6, NA)

# NA's show if another column has any
> summary(DF.Dates)
  Col1  x1x2  
 Min.   :1881-09-24   Min.   :1.0   Min.   :1.00  
 1st Qu.:1902-12-04   1st Qu.:2.5   1st Qu.:2.25  
 Median :1920-09-10   Median :4.0   Median :3.50  
 Mean   :1923-04-12   Mean   :4.0   Mean   :3.50  
 3rd Qu.:1941-01-17   3rd Qu.:5.5   3rd Qu.:4.75  
 Max.   :1969-12-28   Max.   :7.0   Max.   :6.00  
 NA's   :3  NA's   :1 


The behavior appears to occur because summary.Date() assigns an "NAs" attribute 
internally that contains the count of NA's in the source Date vector:

 x <- summary.default(unclass(object), digits = digits, ...)
 if (m <- match("NA's", names(x), 0)) {
   NAs <- as.integer(x[m])
   x <- x[-m]
   attr(x, "NAs") <- NAs
   }

rather than the count being retained as an actual element in the result vector, 
as in summary.default():

   nas <- is.na(object)
   object <- object[!nas]
   qq <- stats::quantile(object)
   qq <- signif(c(qq[1L:3L], mean(object), qq[4L:5L]), digits)
   names(qq) <- c("Min.", "1st Qu.", "Median", "Mean", "3rd Qu.", 
   "Max.")
   if (any(nas)) 
   c(qq, `NA's` = sum(nas))
   else qq


This results in an apparent (but not real) error in the value of the variable 
'nr' within summary.date.frame(), which is used to set the length of the result 
created within that function:

   nr <- if (nv) 
   max(unlist(lapply(z, NROW)))
   else 0

'nr' is used later in the function to set the length of the initial result 
vector 'sms', which in turn is assigned back to the result list 'z'.

In the case of my example above, where the NA's are not printed, 'nr' is 6, 
rather than 7. 6 is correct, since that is the actual length of the result 
vector from summary.Date(), even though the printed output of the result, would 
appear to contain 7 elements, including the NA count, because of the behavior 
of print.summaryDefault().

This results in an apparent truncation of the result, with a loss of the "NAs" 
attribute from summary.Date(), when the result is returned by 
summary.data.frame().

If the source vector is numeric, as per my example above, then 'nr' is set to 7 
when NA's are present and the result is correctly printed along with the other 
columns.

The history of the difference in the manner in which the NA counts are stored 
in the different summary() methods is not clear and so I am not clear on how to 
consider a resolution.

At least three options seem possible and I have not fully thought through the 
implications of each yet:

1. Modify the code that creates and uses 'nr' in summary.data.frame(), to 
account for the NAs attribute from summary.Date().
2. Restore the NAs attribute later in the code, if present in the vector that 
results from summary.Date().
3. Modify the code in summary.Date() so that it mimics the approach in 
summary.default() relative to storing the NA count.

It is important to note that summary.POSIXct() has code similar to 
summary.Date() relative to the handling of NA's.

In addition, print.summaryDefault() contains checks for both Date and POSIXct 
classes and outputs accordingly. So the inter-dependencies of the handling of 
NA's across the methods are notable.

Thus, since there are likely to be other implications for the choice of 
resolution that I 

Re: [Rd] Test Post

[Marc Schwartz]

Marc Schwartz  me.com> writes:

> 
> Hi,
> 
> Sorry for the noise, this a only a test post. 
> 
> if it works, there should be a reply from me as well.
> 
> Thanks,
> 
> Marc Schwartz
> 
> 


Hi,

This is the reply.

There should be no further activity.

Thanks,

Marc

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

[Rd] Test Post

[Marc Schwartz]

Hi,

Sorry for the noise, this a only a test post. 

if it works, there should be a reply from me as well.

Thanks,

Marc Schwartz

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

Re: [Rd] dead links to manuals

[Marc Schwartz]

 On Jul 7, 2015, at 5:58 AM, Gábor Csárdi csardi.ga...@gmail.com wrote:
 
 E.g. here http://cran.r-project.org/manuals.html the link to
 http://cran.r-project.org/doc/manuals/r-release/R-intro.html gives a
 404.
 
 FYI,
 Gabor


Gabor, this was reported yesterday on R-Help:

  https://stat.ethz.ch/pipermail/r-help/2015-July/430130.html

Regards,

Marc Schwartz

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

Re: [Rd] That 'make check-all' problem with the survival package

[Marc Schwartz]

 On May 16, 2015, at 6:11 AM, Hin-Tak Leung ht...@users.sourceforge.net 
 wrote:
 
 
 
 --
 On Sat, May 16, 2015 8:04 AM BST Uwe Ligges wrote:
 
 Not sure why this goes to R-devel. You just could have asked the 
 maintainer. Terry Therneau is aware of it and promised he will fix it.
 
 
 The quickest fix is to add cmprsk to the recommended list , and that's is an 
 R-devel issue.


Actually, the easiest solution would be for Terry to either modify relevant 
code according to:

  http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Suggested-packages

or perhaps better, as noted, to remove the need for cmprsk at all.

The latter raises the philosophical issue as to whether or not a Recommended 
package should or really needs to have any connections at all to third party 
CRAN packages. It seems to me that the default R distribution of “Base” and 
“Recommended” packages should be able to fully run in a stand alone manner 
without any declared external connections to other non-default packages.

The only other Recommended package that I found that has such a connection is 
nlme, which has a Suggests for Frank’s Hmisc. However, based upon a grep review 
of the package contents, there are only two code based references to Hmisc that 
I located:

./R/newFunc.R:264:  ## e.g. Hmisc's labelled
./tests/augPred_lab.R:2:if(require(Hmisc)) {

Neither of which is really needed (the first being a comment only, so benign) 
and of course the latter goes against the current guidance in R-exts. The 
second, within the if() code, uses the Hmisc label() function, which it seems 
to me is not really needed here.

Regards,

Marc Schwartz


 
 On 16.05.2015 07:22, Hin-Tak Leung wrote:
 'make check-all' for current R has been showing this error in the middle
 for a few months now - any thought on fixing this? I think cmprsk
 should be either included in the recommended bundle, or
 the survival vignette to not depend on it. Having 'make check-all' showing
 glaring ERROR's for a few months seems to defeat the purpose of
 doing any checking at all via 'make check-all'.
 
 FWIW, I did look at when/how the issue was introduced, but it appeared
 that svn://svn.r-forge.r-project.org/svnroot/survival is no longer being
 updated, and git://github.com/cran/survival.git only shows release jumps.
 Anyway, if first appears with survival 2.38-1 in February, and as the 
 previous
 2.37-7 was 13 months older, this info is of no use to anybody.
 I didn't write earlier as I thought the issue would go away at some point;
 but obviously this isn't the case after 3 months.
 
 ---
  ERROR
 Errors in running code in vignettes:
 when running code in ‘compete.Rnw’
   ...
 temp$fstat - as.numeric(event)
 
 temp$msex - with(temp, 1 * (sex == M))
 
 fgfit1 - with(temp, crr(etime, fstat, cov1 = cbind(age,
 + msex, mspike), failcode = 2, cencode = 1, variance = TRUE))
 
   When sourcing ‘compete.R’:
 Error: could not find function crr
 Execution halted
 
 * checking re-building of vignette outputs ... NOTE
 Error in re-building vignettes:
   ...
 Warning in coxph(Surv(futime, death) ~ group:age2 + sex + strata(group),  :
   X matrix deemed to be singular; variable 23 24 25
 Loading required package: cmprsk
 Warning in library(package, lib.loc = lib.loc, character.only = TRUE, 
 logical.return = TRUE,  :
   there is no package called ‘cmprsk’
 
 Error: processing vignette 'compete.Rnw' failed with diagnostics:
  chunk 15 (label = finegray)
 Error in eval(expr, envir, enclos) : could not find function crr
 Execution halted
 
 __
 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

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

Re: [Rd] Color Coding in R-devel/NEWS

[Marc Schwartz]

 On Feb 18, 2015, at 1:44 PM, Bryan Hanson han...@depauw.edu wrote:
 
 On this feed, which I think is the place we should monitor upcoming changes:
 
 http://developer.r-project.org/blosxom.cgi/R-devel/NEWS
 
 What is the significance of the green and pink highlighting?
 
 Thanks, Bryan


I stand to be corrected, but daily diffs are being generated, such that the 
green highlighted text is new since the prior version and the 
pink/strikethrough text is a deletion since the prior version.

Regards,

Marc Schwartz

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

Re: [Rd] R on the Cydia Store

[Marc Schwartz]

 On Dec 9, 2014, at 10:44 AM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
 
 On Dec 9, 2014 6:38 AM, Apps Embedded apps.embed...@gmail.com wrote:
 
 Hi,
 
 We have published an Android app called R Console on the Play Store since
 Décember 2013.
 https://play.google.com/store/apps/details?id=com.appsopensource.R
 https://play.google.com/store/apps/details?id=com.appsopensource.Rpremium
 
 In the mean time, we have developped its equivalent app for the App Store.
 We released it on march 2014. We have been approved from this date by Apple
 to publish it world wide.
 Recently, we learnt that GPL app are not compatible with the App Store
 distribution licence.
 
 What I would like to write here, would fall under this is certainly
 not a topic for R devel, so I refrain.
 
 However, I can say that it's likely your problems wouldn't have stopped there;
 
 [R] R on the iPhone/iPad? Not so mucha GPL violation
 https://stat.ethz.ch/pipermail/r-help/2010-June/240901.html
 
 /Henrik

Hi,

I might add that, given the intentions expressed below, in terms of doing this 
on a jailbroken iOS device via Cydia, the concerns raised in the Apple iOS SDK, 
that I referenced in the above linked post from 2010, essentially go away. 

They would still be germane, as may now be expressed in the current SDK, 
including the use of the new Swift language, if the OP's intent was to pursue 
this via official AppStore channels and am surprised that it was approved by 
Apple previously given the indicated content and functionality of the app.

The primary intention of jailbreaking an iOS device is, of course, to 
circumvent Apple's restrictions on the software that can be installed by using 
third party distribution channels and in the tools that can be used to develop 
apps.

That being said, the licensing issues, as Duncan raised in his reply, are still 
germane and permission from the R Foundation should be sought for any uses 
involving R Foundation copyrighted content. That would be relevant for both the 
iOS implementation and the Android implementation.

Regards,

Marc Schwartz

P.S. I echo's Duncan's comment, in that I am also a member of the R Foundation, 
but am not speaking here on it's behalf.


 
 
 Thus we decided to remove the iOS app from the App Store several days ago.
 
 We are thinking of publishing the same app published under Cydia with a
 freemium model.
 Its licence would be GPL v3.
 
 What we would like to do under Cydia with R Console is to have the
 following behavior :
 - free version will be able to run recommended packages and graphics are
 not enabled. A small ad banner is present on top of the app.
 - premium version will be the same as the free version except the ad banner
 will not be present anymore and 3 compilers will be integrated into the app
 in order to be able to compile and run most of the Cran packages from
 source.
 - graphics may be added in a second step.
 
 The app will be considered as a bundle of open-source tools. This bundle
 will be under the Gnu General Public Licence version 3. Each open-source
 tool which contributes to the overall bundle will stay in its original
 licence (R is GPL v2 for instance) but the bundle will be GPL v3.
 
 
 From your point of view, do you see any legal issue with this project under
 Cydia for jailbroken iOS devices?
 From a trademark point of view, is the name of the apps R Console Free
 and R Console Premium ok ?
 
 Thanks for your help.
 
 Apps Embedded Team.

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

Re: [Rd] R on the Cydia Store

[Marc Schwartz]

 On Dec 9, 2014, at 3:34 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
 
 On 09/12/2014, 4:26 PM, Marc Schwartz wrote:
 
 On Dec 9, 2014, at 10:44 AM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
 
 On Dec 9, 2014 6:38 AM, Apps Embedded apps.embed...@gmail.com wrote:
 
 Hi,
 
 We have published an Android app called R Console on the Play Store since
 Décember 2013.
 https://play.google.com/store/apps/details?id=com.appsopensource.R
 https://play.google.com/store/apps/details?id=com.appsopensource.Rpremium
 
 In the mean time, we have developped its equivalent app for the App Store.
 We released it on march 2014. We have been approved from this date by Apple
 to publish it world wide.
 Recently, we learnt that GPL app are not compatible with the App Store
 distribution licence.
 
 What I would like to write here, would fall under this is certainly
 not a topic for R devel, so I refrain.
 
 However, I can say that it's likely your problems wouldn't have stopped 
 there;
 
 [R] R on the iPhone/iPad? Not so mucha GPL violation
 https://stat.ethz.ch/pipermail/r-help/2010-June/240901.html
 
 /Henrik
 
 Hi,
 
 I might add that, given the intentions expressed below, in terms of doing 
 this on a jailbroken iOS device via Cydia, the concerns raised in the Apple 
 iOS SDK, that I referenced in the above linked post from 2010, essentially 
 go away. 
 
 They would still be germane, as may now be expressed in the current SDK, 
 including the use of the new Swift language, if the OP's intent was to 
 pursue this via official AppStore channels and am surprised that it was 
 approved by Apple previously given the indicated content and functionality 
 of the app.
 
 The primary intention of jailbreaking an iOS device is, of course, to 
 circumvent Apple's restrictions on the software that can be installed by 
 using third party distribution channels and in the tools that can be used to 
 develop apps.
 
 That being said, the licensing issues, as Duncan raised in his reply, are 
 still germane and permission from the R Foundation should be sought for any 
 uses involving R Foundation copyrighted content. That would be relevant for 
 both the iOS implementation and the Android implementation.
 
 Just to be clear:  everybody already has permission from the R copyright
 holders to use R within the existing licenses.  There's no need to seek
 extra permission for that.
 
 Trademarks are different...
 
 Duncan Murdoch


Thanks for the clarification Duncan, I was imprecise in my language.

Regards,

Marc


 
 Regards,
 
 Marc Schwartz
 
 P.S. I echo's Duncan's comment, in that I am also a member of the R 
 Foundation, but am not speaking here on it's behalf.
 
 
 
 
 Thus we decided to remove the iOS app from the App Store several days ago.
 
 We are thinking of publishing the same app published under Cydia with a
 freemium model.
 Its licence would be GPL v3.
 
 What we would like to do under Cydia with R Console is to have the
 following behavior :
 - free version will be able to run recommended packages and graphics are
 not enabled. A small ad banner is present on top of the app.
 - premium version will be the same as the free version except the ad banner
 will not be present anymore and 3 compilers will be integrated into the app
 in order to be able to compile and run most of the Cran packages from
 source.
 - graphics may be added in a second step.
 
 The app will be considered as a bundle of open-source tools. This bundle
 will be under the Gnu General Public Licence version 3. Each open-source
 tool which contributes to the overall bundle will stay in its original
 licence (R is GPL v2 for instance) but the bundle will be GPL v3.
 
 
 From your point of view, do you see any legal issue with this project 
 under
 Cydia for jailbroken iOS devices?
 From a trademark point of view, is the name of the apps R Console Free
 and R Console Premium ok ?
 
 Thanks for your help.
 
 Apps Embedded Team.
 
 

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

Re: [Rd] R on the Cydia Store

[Marc Schwartz]

Hi,

I would send an introductory e-mail to:

  r-foundat...@r-project.org mailto:r-foundat...@r-project.org

That will facilitate further discussion on the matter and additional details 
can be requested offline as may be needed.

Be aware that none of the R Foundation members are lawyers. So while we can 
perhaps offer informal and non-binding opinions, you should seek formal legal 
guidance from counsel specifically familiar with open source licensing 
regarding your obligations in that domain.

Finally, it would be helpful and courteous to know at least a primary contact 
full name for your group, as opposed to the Team moniker.

Regards,

Marc


 On Dec 9, 2014, at 5:39 PM, Apps Embedded apps.embed...@gmail.com wrote:
 
 Hi,
 
 Thanks for your first answers.
 
 So, should we contact the R foundation team members to inform them of our 
 project on the Android platform and on the Cydia Store ?
 If yes, could you give us their email please ? Or should we write to the 
 president of the R foundation for instance ? 
 
 Best regards.
 
 Apps Embedded Team.
 
 
 2014-12-09 23:49 GMT+01:00 Marc Schwartz marc_schwa...@me.com 
 mailto:marc_schwa...@me.com:
 
  On Dec 9, 2014, at 3:34 PM, Duncan Murdoch murdoch.dun...@gmail.com 
  mailto:murdoch.dun...@gmail.com wrote:
 
  On 09/12/2014, 4:26 PM, Marc Schwartz wrote:
 
  On Dec 9, 2014, at 10:44 AM, Henrik Bengtsson h...@biostat.ucsf.edu 
  mailto:h...@biostat.ucsf.edu wrote:
 
  On Dec 9, 2014 6:38 AM, Apps Embedded apps.embed...@gmail.com 
  mailto:apps.embed...@gmail.com wrote:
 
  Hi,
 
  We have published an Android app called R Console on the Play Store since
  Décember 2013.
  https://play.google.com/store/apps/details?id=com.appsopensource.R 
  https://play.google.com/store/apps/details?id=com.appsopensource.R
  https://play.google.com/store/apps/details?id=com.appsopensource.Rpremium
   
  https://play.google.com/store/apps/details?id=com.appsopensource.Rpremium
 
  In the mean time, we have developped its equivalent app for the App 
  Store.
  We released it on march 2014. We have been approved from this date by 
  Apple
  to publish it world wide.
  Recently, we learnt that GPL app are not compatible with the App Store
  distribution licence.
 
  What I would like to write here, would fall under this is certainly
  not a topic for R devel, so I refrain.
 
  However, I can say that it's likely your problems wouldn't have stopped 
  there;
 
  [R] R on the iPhone/iPad? Not so mucha GPL violation
  https://stat.ethz.ch/pipermail/r-help/2010-June/240901.html 
  https://stat.ethz.ch/pipermail/r-help/2010-June/240901.html
 
  /Henrik
 
  Hi,
 
  I might add that, given the intentions expressed below, in terms of doing 
  this on a jailbroken iOS device via Cydia, the concerns raised in the 
  Apple iOS SDK, that I referenced in the above linked post from 2010, 
  essentially go away.
 
  They would still be germane, as may now be expressed in the current SDK, 
  including the use of the new Swift language, if the OP's intent was to 
  pursue this via official AppStore channels and am surprised that it was 
  approved by Apple previously given the indicated content and functionality 
  of the app.
 
  The primary intention of jailbreaking an iOS device is, of course, to 
  circumvent Apple's restrictions on the software that can be installed by 
  using third party distribution channels and in the tools that can be used 
  to develop apps.
 
  That being said, the licensing issues, as Duncan raised in his reply, are 
  still germane and permission from the R Foundation should be sought for 
  any uses involving R Foundation copyrighted content. That would be 
  relevant for both the iOS implementation and the Android implementation.
 
  Just to be clear:  everybody already has permission from the R copyright
  holders to use R within the existing licenses.  There's no need to seek
  extra permission for that.
 
  Trademarks are different...
 
  Duncan Murdoch
 
 
 Thanks for the clarification Duncan, I was imprecise in my language.
 
 Regards,
 
 Marc
 
 
 
  Regards,
 
  Marc Schwartz
 
  P.S. I echo's Duncan's comment, in that I am also a member of the R 
  Foundation, but am not speaking here on it's behalf.
 
 
 
 
  Thus we decided to remove the iOS app from the App Store several days 
  ago.
 
  We are thinking of publishing the same app published under Cydia with a
  freemium model.
  Its licence would be GPL v3.
 
  What we would like to do under Cydia with R Console is to have the
  following behavior :
  - free version will be able to run recommended packages and graphics are
  not enabled. A small ad banner is present on top of the app.
  - premium version will be the same as the free version except the ad 
  banner
  will not be present anymore and 3 compilers will be integrated into the 
  app
  in order to be able to compile and run most of the Cran packages from
  source.
  - graphics may be added in a second step.
 
  The app

Re: [Rd] Why R-project source code is not on Github

[Marc Schwartz]

On Aug 21, 2014, at 3:11 AM, Gaurav Sehrawat igauravsehra...@gmail.com wrote:

 R-Project is missing something important in regards to its development ,
 one simply can't ignore Github ,where collaboration is at it's best .
 
 OR If i am wrong is this the correct R-source :
 https://github.com/wch/r-source
 
 Is anyone thinking to bring R-project org on Github ? Maybe there might be
 some difficulty while porting its version system to Github .
 
 Just a suggestion .
 
 Thanks
 Gaurav Sehrawat
 http://igauravsehrawat.com


The link you have above is to a read-only mirror (perhaps not the only one) of 
the R source code that is kept in the official Subversion repo:

  https://svn.r-project.org/R/

There are also some documents that describe R's development cycle and related 
processes:

  http://www.r-project.org/certification.html

Your suggestion to move to Github is perhaps based upon a false premise, that 
the R community at large has the ability to directly post code/patches to the 
official distribution. We can contribute code and patches, primarily here on 
R-Devel, to the code base. However, only the members of R Core team 
(http://www.r-project.org/contributors.html) have write access to the SVN repo 
above and have to approve any such contributions.

Since the current SVN based system works well for them and provides restricted 
write access that they can control, there is no motivation to move to an 
alternative version control system unless they would find it to be superior for 
their own development processes.

That being said, there are a number of contributing projects that have packages 
on CRAN, that do use Github, myself included. There is also R-Forge 
(https://r-forge.r-project.org), which provides another SVN based platform for 
community package development.

Regards,

Marc Schwartz

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

Re: [Rd] Subscripting Matrices

[Marc Schwartz]

On Aug 6, 2014, at 10:07 AM, Terrence Ireland ky...@his.com wrote:

 There seems to be a result type difference when subscripting a 6 x 1 matrix 
 as compared to a 3 x 2 matrix that is caused by the ncol = 1 compared to ncol 
  1.
 
  ThinMatrix - matrix(1:6,ncol=1)
  ThinMatrix
 [,1]
 [1,]1
 [2,]2
 [3,]3
 [4,]4
 [5,]5
 [6,]6
  FatMatrix - matrix(1:6,ncol=2)
  FatMatrix
 [,1] [,2]
 [1,]14
 [2,]25
 [3,]36
  dim(ThinMatrix[TRUE,])
 NULL  #Though this value should be 6 1
  dim(FatMatrix[TRUE,])
 [1] 3 2
 
 Thanks for your help.
 
 Terry Ireland


Hi,

This question really should have gone to R-Help, not R-Devel and it is a FAQ:

  
http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-do-my-matrices-lose-dimensions_003f

 str(ThinMatrix[TRUE,])
 int [1:6] 1 2 3 4 5 6


Regards,

Marc Schwartz

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

Re: [Rd] single quotes in strings, example block

[Marc Schwartz]

On Jul 31, 2014, at 4:55 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:

 On 31/07/2014, 4:27 AM, Adrian Dușa wrote:
 Dear R-devel,
 
 In the example block of the documentation for a package, I need to use
 a single quote in a string:
 
foo - Don't know
 
 After building the package, it gets printed as:
 
foo - Dont know
 
 I don't see this.  Can you give more details, i.e. R version, how you
 printed it, etc.?
 
 It may be that you're not using an ascii single quote character, your
 editor has slipped in something else.
 
 Duncan Murdoch
 
 
 
 I read the Writing R Extensions and Parsing Rd files from top to
 bottom, but didn't find any solution.
 
 Using \verb{} doesn't help, as:
 Tag \verb is invalid in a \examples block
 
 Neither \sQuote doesn't help, as:
 '\s' is an unrecognized escape in character string starting Don\s
 
 I found the only macros which are interpreted within text are \var and
 \link ... therefore I am stuck.
 
 Any hint to other documentation I might read?
 Thank you,
 Adrian
 


I may not have had enough coffee yet this morning, but might this be related to 
the use of Fancy/Smart quotes?

If so and you are using a text editor that supports them, you may have to 
disable them when working with this kind of output.

Alternatively, or perhaps in addition, take a look at ?options and adjust 
'useFancyQuotes' as may be required. I frequently have to set it to FALSE when 
using Sweave.

Regards,

Marc Schwartz

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

Re: [Rd] Question on Code snippet semantics

[Marc Schwartz]

On Jul 21, 2014, at 10:07 AM, Mick Jordan mick.jor...@oracle.com wrote:

 I came across this code in library.R
 
 package - as.character(substitute(package))
 
 where package is the first argument to the library function.
 
 I've been racking my brains to understand why this is not just an elaborate 
 (and ineffcient) way to write:
 
 package - package
 
 E.g.
 
  package - as.character(substitute(package))
  package
 [1] package
 
 
 Thanks
 Mick Jordan


Frequently used in a function body, where the function author wants the 
argument to be passed as an object name, rather than a character vector, or 
perhaps both, as is the case with library() and require().

For example:

test - function(x) {as.character(substitute(x))}

# Quoted, passing MyPackage as a character vector
 test(MyPackage)
[1] MyPackage


# Not quoted, passing the object MyPackage
 test(MyPackage)
[1] MyPackage


In both cases, the argument passed as 'x' can then be used within the function 
as a character vector, rather than as the object itself.

Regards,

Marc Schwartz

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

Re: [Rd] cummax / cummin for complex numbers

[Marc Schwartz]

On Jul 14, 2014, at 9:53 AM, Michael Haupt michael.ha...@oracle.com wrote:

 Dear all,
 
 in R 3.1.0, this is happening:
 
 cummin(c(1+1i,2-3i,4+5i))
 Error in cummin(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 
  'cummax' not defined for complex numbers
 cummax(c(1+1i,2-3i,4+5i))
 Error in cummax(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 
  'cummin' not defined for complex numbers
 
 It may be fixed in R-devel, but I thought I'd mention it to make sure ...
 
 Best,
 
 Michael


The help file for cummax/cummin in 3.1.1 specifically states:

x  a numeric or complex (not cummin or cummax) object, or an object 
that can be coerced to one of these.


So why would you expect it to work for cummin or cummax when you pass a complex 
'x'?

Regards,

Marc Schwartz

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

Re: [Rd] creating a package from a development source tree

[Marc Schwartz]

On Jul 1, 2014, at 10:26 AM, Greg Minshall minsh...@acm.org wrote:

 hi.  this is sort of a software methodology question.
 
 i'm working on developing a package (with C source code).  developing
 it, i use autotools, git, make, and such like.  as a result, there are
 random files in my source code directory that R CMD check would rather
 not see.  some of these files (such as .git and friends) i could arrange
 to move to just above my development subtree; others of these (such as
 configure.ac and the random crud autoreconf(1) and friends leave laying
 around) can't be moved (afaik).
 
 i'm curious how people move from their personal development tree to a
 tree from which the package can be passed to R CMD *.  do you have a
 makefile in their tree that creates this?  during development, is this
 the path you use for building and testing?
 
 cheers, Greg Minshall


Hi,

Run 'R CMD check' on the file built from 'R CMD build', rather than on the 
actual package source file tree, as per:

  http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Checking-packages

from the Writing R Extensions manual.

You can also use the file .Rbuildignore to define files that should be 
excluded. See the fifth paragraph in:

  
http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Building-package-tarballs


Regards,

Marc Schwartz

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

Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit

[Marc Schwartz]

On Apr 19, 2014, at 8:05 AM, Martin Maechler maech...@stat.math.ethz.ch wrote:

 
 Martin Maechler maech...@stat.math.ethz.ch
on Thu, 17 Apr 2014 11:22:04 +0200 writes:
 
 []
 
 PS: I'm currently testing a patch where 'R CMD Sweave' will
 revert to not deleting anything after running the R code by default.
 
 Martin Maechler
 
 Some may have noted that R-devel, since svn revsion 65401 (= 2014-04-17 
 12:19:44 +0200)
 now is patched, with log message
 
 R CMD Sweave must not delete files by default; buildVignette(*, keep);
 update (and fix/clarify) documentation; 
 cosmetic ( speedup in buildVignettes())
 
 The daily (source!) snapshots of R devel now also contain it.
 
 We plan to port the patch to 'R 3.1.0 patched' (to become 3.1.1
 in the future) after the Easter holidays...
 and would be glad if some volunteers could support development
 of R by testing this (or newer) version of R-devel.
 
 Martin Maechler, ETH Zurich


Hi Martin,

Thanks for this.

I removed 3.1.0 release on my Mac and cleanly installed:

  R Under development (unstable) (2014-04-17 r65403) -- Unsuffered 
Consequences

from Simon's binary site. This is using the Mavericks binary, albeit on Simon's 
site, it indicates r65407.

I ran the prior .Rnw file that started this thread and it now works fine, as 
the created 'non-tex' files are retained upon completion of the R CMD Sweave 
run.

Thanks for the efforts in fixing this issue.

Regards,

Marc Schwartz

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

Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit

[Marc Schwartz]

Hi Martin,

Thanks for your confirmation on this.

I normally do not use R CMD Sweave, as I too run under ESS in normal day to day 
operations. This finding was a quirk of having a particular Rnw document that I 
occasionally run using R CMD Sweave and I had done so over the weekend, 
realizing this behavior.

Thanks again.

Regards,

Marc


On Apr 14, 2014, at 7:28 AM, Martin Maechler maech...@stat.math.ethz.ch wrote:

 Marc Schwartz marc_schwa...@me.com
on Sun, 13 Apr 2014 10:22:55 -0500 writes:
 
 [on the R-SIG-Mac  mailing list] :  
 
 Hi all,
 With R version 3.1.0 on OSX, using either the Snow Leopard or the Mavericks 
 binary installation on a Mac with fully updated Mavericks, there has been a 
 change in behavior since 3.0.3.
 
 I've just written to R-core about this:
 
R CMD Sweave
 
 has *serious* problems also in the very simple case when it
 should produce figures: They are not available after the
 completion of R CMD Sweave,
 confirming your  'deletes non tex files created upon batch mode exit'
 
 So this is not related to OSX only, but also a big problem 
 at least on other *nix descendent platforms, such as Linux.
 
 In short, failure (no graphic produce in the example below) by
 
   R CMD Sweave foo.Rnw
 
 but all is fine with using Sweave(), as you Marc, noted, and hence with  
 
   Rscript -e 'Sweave(foo.Rnw)'
 
 ... and to answer your question:  
 No this was not intended and is probably one of the bigger / 
 most embarrassing bugs in a newly released version of R
 in my view: 
 
 Basically  'R CMD Sweave' is partly broken in R 3.1.0.
 Yes, this should never have happened.
 
 I had to partially revert the R 3.1.0 installation here (our
 statistics dept), by making R 3.0.3 the default 'R'
 for now, as we are relying on 'R CMD Sweave ..' in many places.
 
 Personally I've never noticed the problem, as I seem to always
 Sweave from ESS (Emacs speaks statistics) which calls  Sweave()
 in R, and that works fine, also in  R 3.1.0, as you've already
 noted 
 
 Martin Maechler, ETH Zurich
 
 %
 \documentclass[12pt]{article}
 \usepackage{Sweave}
 \begin{document}  Just a simple graphic 
 
 qqnorm, fig=TRUE= 
 qqnorm(rnorm(20))
 @ 
 
 and that's all, folks!
 \end{document}
 %
 
 I have a master .Rnw file which runs a series of outputs from multiple R 
 code files, each called in BATCH mode using system() from within the master 
 .Rnw file. The output of the R code files go to separate text files in order 
 to catch some of the function call output that would not otherwise be 
 included in the resultant .tex file due to output redirection.
 
 Those text files are then included in the resultant .tex file using, for 
 example:
 
 \lstinputlisting[caption={}]{test.out}
 
 directives which are included in the .Rnw source file.
 
 A simple example to replicate the observed behaviors.
 
 The test.Rnw file content:
 
 %% R CMD Sweave test.Rnw
 results=tex,echo=false=
 system(R CMD BATCH test.R test.out)
 @ 
 
 
 The test.R file content:
 
 options(echo = FALSE)
 options(useFancyQuotes = FALSE)
 installed.packages()
 
 
 On version 3.0.3, the file test.out is created, along with test.tex. 
 test.out contains the output of installed.packages(). I did not include the 
 aforementioned listing directive in test.Rnw here for simplicity.
 
 On version 3.1.0, the file test.out is created, but when the R CMD Sweave 
 command exits and returns to the CLI in the console, test.out is deleted, 
 presumably as part of a post R batch session clean up process. The file 
 test.tex is retained.
 
 I uninstalled 3.1.0 and reinstalled 3.0.3 and observed the prior behavior. I 
 then tried clean installs of both the Snow Leopard and Mavericks 3.1.0 
 binaries, with the new behavior observed in both cases.
 
 In reading the NEWS file for 3.1.0, there are multiple references to Sweave, 
 but there is nothing explicit about this new behavior. 
 
 I should note that when the .Rnw file is run from within an R 3.1.0 
 interactive session using:
 
 Sweave(test.Rnw)
 
 the test.out file is created and not deleted upon the function exit, or when 
 exiting the R session back to the console. 
 
 Thus, this new behavior seems to be limited to running Sweave from the CLI 
 using R CMD. It is not clear to me if this new behavior is by design or 
 perhaps an unintended consequence of changes elsewhere in Sweave processing 
 or in the handling of R in BATCH mode.
 
 When watching the folder where the file output activity takes place, I note 
 that a file .build.timestamp is created and then deleted, which leads me to 
 believe that the new functions fileSnapshot() and changedFiles() are being 
 used in the course of processing R in BATCH mode. If that is correct and 
 there is a clean up step that is occurring upon BATCH mode exit, which 
 deletes all files and folders other than .tex files, is it possible

Re: [Rd] The case for freezing CRAN

[Marc Schwartz]

On Mar 20, 2014, at 12:23 PM, Greg Snow 538...@gmail.com wrote:

 On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel e...@debian.org wrote:
 [snip]
 
 (and some readers
   may recall the infamous Pentium bug of two decades ago).
 
 It was a Flaw not a Bug.  At least I remember the Intel people
 making a big deal about that distinction.
 
 But I do remember the time well, I was a biostatistics Ph.D. student
 at the time and bought one of the flawed pentiums.  My attempts at
 getting the chip replaced resulted in a major run around and each
 person that I talked to would first try to explain that I really did
 not need the fix because the only people likely to be affected were
 large corporations and research scientists.  I will admit that I was
 not a large corporation, but if a Ph.D. student in biostatistics is
 not a research scientist, then I did not know what they defined one
 as.  When I pointed this out they would usually then say that it still
 would not matter, unless I did a few thousand floating point
 operations I was unlikely to encounter one of the problematic
 divisions.  I would then point out that some days I did over 10,000
 floating point operations before breakfast (I had checked after the
 1st person told me this and 10,000 was a low estimate of a lower bound
 of one set of simulations) at which point they would admit that I had
 a case and then send me to talk to someone else who would start the
 process over.


Further segue:

That (1994) was a watershed moment for Intel as a company. A time during which 
Intel's future was quite literally at stake. Intel's internal response to that 
debacle, which fundamentally altered their own perception of just who their 
customer was (the OEM's like IBM, COMPAQ and Dell versus the end users like 
us), took time to be realized, as the impact of increasingly negative PR took 
hold. It was also a good example of the impact of public perception (a flawed 
product) versus the realities of how infrequently the flaw would be observed in 
typical computing. Perception is reality, as some would observe.

Intel ultimately spent somewhere in the neighborhood of $500 million (in 1994 
U.S. dollars), as I recall, to implement a large scale Pentium chip replacement 
infrastructure targeted to end users. The Intel Inside marketing campaign was 
also an outgrowth of that time period.

Regards,

Marc Schwartz


 [snip]
 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 
 
 
 -- 
 Gregory (Greg) L. Snow Ph.D.
 538...@gmail.com
 
 __
 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] The case for freezing CRAN

[Marc Schwartz]

On Mar 20, 2014, at 1:02 PM, Marc Schwartz marc_schwa...@me.com wrote:

 
 On Mar 20, 2014, at 12:23 PM, Greg Snow 538...@gmail.com wrote:
 
 On Thu, Mar 20, 2014 at 7:32 AM, Dirk Eddelbuettel e...@debian.org wrote:
 [snip]
 
(and some readers
  may recall the infamous Pentium bug of two decades ago).
 
 It was a Flaw not a Bug.  At least I remember the Intel people
 making a big deal about that distinction.
 
 But I do remember the time well, I was a biostatistics Ph.D. student
 at the time and bought one of the flawed pentiums.  My attempts at
 getting the chip replaced resulted in a major run around and each
 person that I talked to would first try to explain that I really did
 not need the fix because the only people likely to be affected were
 large corporations and research scientists.  I will admit that I was
 not a large corporation, but if a Ph.D. student in biostatistics is
 not a research scientist, then I did not know what they defined one
 as.  When I pointed this out they would usually then say that it still
 would not matter, unless I did a few thousand floating point
 operations I was unlikely to encounter one of the problematic
 divisions.  I would then point out that some days I did over 10,000
 floating point operations before breakfast (I had checked after the
 1st person told me this and 10,000 was a low estimate of a lower bound
 of one set of simulations) at which point they would admit that I had
 a case and then send me to talk to someone else who would start the
 process over.
 
 
 Further segue:
 
 That (1994) was a watershed moment for Intel as a company. A time during 
 which Intel's future was quite literally at stake. Intel's internal response 
 to that debacle, which fundamentally altered their own perception of just who 
 their customer was (the OEM's like IBM, COMPAQ and Dell versus the end users 
 like us), took time to be realized, as the impact of increasingly negative PR 
 took hold. It was also a good example of the impact of public perception (a 
 flawed product) versus the realities of how infrequently the flaw would be 
 observed in typical computing. Perception is reality, as some would 
 observe.
 
 Intel ultimately spent somewhere in the neighborhood of $500 million (in 1994 
 U.S. dollars), as I recall, to implement a large scale Pentium chip 
 replacement infrastructure targeted to end users. The Intel Inside 
 marketing campaign was also an outgrowth of that time period.
 


Quick correction, thanks to Peter, on my assertion that the Intel Inside 
campaign arose from the 1994 Pentium issue. It actually started in 1991.

I had a faulty recollection from my long ago reading of Andy Grove's 1996 book, 
Only The Paranoid Survive, that the slogan arose from Intel's reaction to the 
Pentium fiasco. It actually pre-dated that time frame by a few years.

Thanks Peter!

Regards,

Marc

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

[Rd] path.package() versus system.file() for locating installed package folders

[Marc Schwartz]

Hi all,

For several years, I have used path.package() to get the path to Perl scripts 
contained within WriteXLS.

I have a request to change this to using system.file(), which would provide the 
ability to utilize WriteXLS functionality, without having to load the package, 
which path.package() requires.

Based upon my review of the code, I don't see any obvious down sides to making 
the change, but wanted to solicit comments from anyone that might challenge the 
change in the code.

Thanks in advance.

Regards,

Marc Schwartz

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

Re: [Rd] path.package() versus system.file() for locating installed package folders

[Marc Schwartz]

On Feb 12, 2014, at 11:05 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:

 On 12/02/2014 16:28, Marc Schwartz wrote:
 Hi all,
 
 For several years, I have used path.package() to get the path to Perl 
 scripts contained within WriteXLS.
 
 I have a request to change this to using system.file(), which would provide 
 the ability to utilize WriteXLS functionality, without having to load the 
 package, which path.package() requires.
 
 Based upon my review of the code, I don't see any obvious down sides to 
 making the change, but wanted to solicit comments from anyone that might 
 challenge the change in the code.
 
 Thanks in advance.
 
 Regards,
 
 Marc Schwartz
 
 I don't think path.package() ever was the right tool: find.package() looks a 
 closer match, and system.file() is a wrapper for it (which was all that was 
 made available for many years: up to R 2.13.0 AFAIR).


Thanks.

I don't, at this point, recall the history as to why I elected to use 
path.package(), but my guess is that I looked at some subset of other CRAN 
packages at the time that also included script files and used them as a model. 
In hindsight, not the best approach.

Regards,

Marc


 
 -- 
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595
 
 __
 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] Where to drop a python script?

[Marc Schwartz]

On Oct 30, 2013, at 1:54 PM, Jonathan Greenberg j...@illinois.edu wrote:

 R-developers:
 
 I have a small python script that I'd like to include in an R package I'm
 developing, but I'm a bit unclear about which subfolder it should go in.  R
 will be calling the script via a system() call.  Thanks!
 
 --j


See Writing R Extensions Manual, section 1.1.7:

  
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dR-scripts-in-packages

If you want to see a package example, my WriteXLS package uses Perl, but the 
concepts will be the same:

  https://github.com/marcschwartz/WriteXLS

If you look at WriteXLS.R around line 130, you can see an example of getting 
the $PATH to the included Perl scripts that I use, which are in the 'inst/Perl' 
folder. Further down around line 230, is where the script is called via 
system(). Note the use of shQuote() for some arguments.

Regards,

Marc Schwartz

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

Re: [Rd] http://r.research.att.com/ (daily R binaries for OSX) seems to be down

[Marc Schwartz]

On Oct 8, 2013, at 2:45 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:

 It appears that http://r.research.att.com/, which provides daily
 builds of the R GUI, R-patched and R-devel for OSX, is down (at least
 since yesterday).  I didn't find any contact information in online web
 caches, so I'm posting here in case the maintainer is listening.
 
 /Henrik


There was a post on this to R-SIG-MAC earlier today, with a reply by Peter:

  https://stat.ethz.ch/pipermail/r-sig-mac/2013-October/010364.html

Regards,

Marc Schwartz

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

Re: [Rd] Vignette problem and CRAN policies

[Marc Schwartz]

Spencer,

FYI. I just noted in your post below the error message from WriteXLS regarding 
TEXT::CSV_XS missing.

Please note that in version =3.0 of WriteXLS (current is 3.2.1), that is no 
longer required and has been replaced by Text::CSV_PP, which is a Pure Perl 
module and is included in the WriteXLS CRAN package to reduce the dependencies 
on nonstandard external Perl modules.

Regards,

Marc Schwartz


On Sep 23, 2013, at 4:28 PM, Spencer Graves spencer.gra...@prodsyse.com wrote:

 Hello, All:
 
 
  Professor Ripley is correct as usual:  I misunderstood his original 
 statement of the problem.
 
 
  He gave two possible solutions.  I could not make the first solution 
 work, and I didn't try the second until someone else on this list explained 
 it in slightly more detail.
 
 
  The correction passed R CMD check on my local computer.  It has been 
 building on R-Forge since 2013-09-20 19:19:14+02.  I hope this completes 
 soon enough for me to meet Ripley's Sept. 25 deadline for this correction to 
 sos.
 
 
  Thanks again to Prof. Ripley and everyone else who took the time to read 
 my post.
 
 
  Spencer
 
 
 On 9/19/2013 12:00 AM, Prof Brian Ripley wrote:
 This is nothing to do with CRAN policies (nor R).
 
 The issue is that the current upquote.sty does not play with 'ae' fonts as 
 used by default by Sweave.  The change is in TeX.
 
 And that was what Spencer Graves was informed.
 
 
 On 19/09/2013 04:35, Spencer Graves wrote:
 Hello, All:
 
 
   The vignette with the sos package used upquote.sty, required
 for R Journal when it was published in 2009.  Current CRAN policy
 disallows upquote.sty, and I've so far not found a way to pass R CMD
 check with sos without upquote.sty.
 
 
   I changed sos.Rnw per an email exchange with Prof. Ripley without
 solving the problem; see below.  The key error messages (see the results
 of R CMD build below) appear to be sos.tex:16: LaTeX Error:
 Environment article undefined and  sos.tex:558: LaTeX Error:
 \begin{document} ended by \end{article}.  When the article worked, it
 had bot \begin{document} and \begin{article}, with matching \end
 statements for both.  I've tried commenting out either without success.
 
 
   The current nonworking code is available on R-Forge via anonymous
 SVN checkout using svn checkout
 svn://svn.r-forge.r-project.org/svnroot/rsitesearch/. Any suggestions
 on how to fix this would be greatly appreciated.
 
 
Thanks,
Spencer
 
 
 ## COMPLETE RESULTS FROM R CMD check 
 
 
 Microsoft Windows [Version 6.1.7600]
 Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
 C:\Users\sgravescd 2013
 C:\Users\sgraves\2013cd R_pkgs
 C:\Users\sgraves\2013\R_pkgscd sos
 C:\Users\sgraves\2013\R_pkgs\soscd pkg
 C:\Users\sgraves\2013\R_pkgs\sos\pkgR CMD build sos
 * checking for file 'sos/DESCRIPTION' ... OK
 * preparing 'sos':
 * checking DESCRIPTION meta-information ... OK
 * installing the package to re-build vignettes
 * creating vignettes ... ERROR
 Loading required package: brew
 
 Attaching package: 'sos'
 
 The following object is masked from 'package:utils':
 
  ?
 
 Loading required package: WriteXLS
 Perl found.
 
 The following Perl modules were not found on this system:
 
 Text::CSV_XS
 
 If you have more than one Perl installation, be sure the correct one was
 used he
 re.
 
 Otherwise, please install the missing modules. See the package INSTALL
 file for
 more information.
 
 Loading required package: RODBC
 Warning in odbcUpdate(channel, query, mydata, coldata[m, ], test = test,  :
character data 'Adrian Baddeley adrian.badde...@uwa.edu.au and
 Rolf Turner
 r.tur...@auckland.ac.nz with substantial contributions of code by
 Kasper Klitgaard Berthelsen;Abdollah Jalilian; Marie-Colette van Liesho
 ut; Ege Rubak;  Dominic Schuhmacher;and Rasmus
 Waagepetersen.
 Additional contributionsby Q.W. Ang;S. Azaele; C. Beale;
 R. Bernhardt;   T. Bendtsen;A. Bevan;   B. Biggerstaff; R. Bivan
 d;  F. Bonneu;  J. Burgos;  S. Byers;   Y.M. Chang; J.B.
 Che
 n;  I. Chernayavsky;Y.C. Chin;  B. Christensen; J.-F. Co
 eurjolly;   R. Corria Ainslie;  M. de la Cruz;  P. Dalgaard;
 P.J. Dig
 gle;P. Donnelly;I. Dryden;  S. Eglen; O. Flores; N.
 Funwi-Gabga;
  A. Gault;   M. Genton;  J. Gilbey;  J. Goldstick;
   P. Graba
 rnik;   C. Graf;J. Franklin;U. Hahn;A. Hardegen; M.
 Herin
 g;  M.B. Hansen;M. Hazelton;J. Heikkinen;   K. Hornik; R. Ihaka
 ;   A. Jammalamadaka;   R. John-Chandran;   D. Johnson; M.
 Kuhn;
  J. Laake;   F. Lavancier;   T. Lawrence;R.A. Lamb;
 J. Lee;
  G.P. Leser; [... truncated]
 Warning in odbcUpdate(channel, query, mydata, coldata[m, ], test = test,  :
character data 'John Fox [aut, cre], Sanford Weisberg [aut], Douglas
 Bates [ct
 b], Steve Ellison [ctb], David Firth [ctb

Re: [Rd] ASCII art in function documentation - difference html and text output?

[Marc Schwartz]

Rainer,

Have you tried:

\preformatted{...}

which is documented in R-exts to preserve line breaks:

Indicate text that is a literal example of a piece of a program. Text is 
displayed using typewriter font if possible. Formatting, e.g. line breaks, is 
preserved. (Note that this includes a line break after the initial {, so 
typically text should start on the same line as the command.)
Due to limitations in LaTeX as of this writing, this macro may not be nested 
within other markup macros other than \dQuote and \sQuote, as errors or bad 
formatting may result. 


I have not used it myself, but might be worth a try, plus or minus the \cr use.

Regards,

Marc Schwartz

On Sep 5, 2013, at 10:23 AM, Rainer M Krug rai...@krugs.de wrote:

 Found a solution.
 
 putting \cr at the end of each line inserts a carriage return, but no
 additional empty line. So
 
 ,
 | \code{+--+--+--+} \cr
 | \code{| 1/16 | 1/16 | 1/16 |} \cr
 | \code{+--+--+--+} \cr
 | \code{| 1/16 | 8/16 | 1/16 |} \cr
 | \code{+--+--+--+} \cr
 | \code{| 1/16 | 1/16 | 1/16 |} \cr
 | \code{+--+--+--+} \cr
 `
 
 produces the desired output.
 
 
 But interestingly,
 
 ,
 | \code{
 | +--+--+--+ \cr
 | | 1/16 | 1/16 | 1/16 | \cr
 | +--+--+--+ \cr
 | | 1/16 | 8/16 | 1/16 | \cr
 | +--+--+--+ \cr
 | | 1/16 | 1/16 | 1/16 | \cr
 | +--+--+--+ \cr
 | }
 `
 
 produces the correct output in html, 
 
 ,
 | /p
 | pcode +--+--+--+ br | 1/16 | 1/16 | 1/16 |
 |   br +--+--+--+ br | 1/16 | 8/16 | 1/16 | br
 |   +--+--+--+ br | 1/16 | 1/16 | 1/16 | br
 |   +--+--+--+ br /code
 | /p
 `
 
 but
 
 ,
 |  ' +--+--+--+
 |  | 1/16 | 1/16 | 1/16 |
 | 
 |  +--+--+--+
 |  | 1/16 | 8/16 | 1/16 |
 |  +--+--+--+
 |  | 1/16 | 1/16 | 1/16 |
 |  +--+--+--+
 `
 
 in the text version - is there a bug somewhere?
 
 Thanks,
 
 Rainer
 
 
 
 Rainer M Krug rai...@krugs.de writes:
 
 Sarah Goslee sarah.gos...@gmail.com writes:
 
 Untested, but did you try wrapping the whole thing in a single code block:
 
 Nope - also in one line.
 
 Rainer
 
 
 \code{
 all
 the
 things
 }
 
 Sarah
 
 On Thu, Sep 5, 2013 at 10:10 AM, Rainer M Krug rai...@krugs.de wrote:
 Hi
 
 I want to include ascii art in a function documentation which should
 look as follow:
 
 ,
 | +--+--+--+
 | | 1/16 | 1/16 | 1/16 |
 | +--+--+--+
 | | 1/16 | 8/16 | 1/16 |
 | +--+--+--+
 | | 1/16 | 1/16 | 1/16 |
 | +--+--+--+
 `
 
 
 to keep the monospaced font even in html, I decided to use \code{}:
 
 ,
 | \code{+--+--+--+}
 |
 | \code{| 1/16 | 1/16 | 1/16 |}
 |
 | \code{+--+--+--+}
 |
 | \code{| 1/16 | 8/16 | 1/16 |}
 |
 | \code{+--+--+--+}
 |
 | \code{| 1/16 | 1/16 | 1/16 |}
 |
 | \code{+--+--+--+}
 `
 
 But the result was an empty line between each text:
 
 ,
 |  '+--+--+--+'
 |
 |  '| 1/16 | 1/16 | 1/16 |'
 |
 |  '+--+--+--+'
 |
 |  '| 1/16 | 8/16 | 1/16 |'
 |
 |  '+--+--+--+'
 |
 |  '| 1/16 | 1/16 | 1/16 |'
 |
 |  '+--+--+--+'
 `
 
 and when no empty lines were included obviously put everything behind
 each other.
 
 My question:
 
 Is there a way that I can achieve the ASCII art as shown above? Is there
 a way of having a \linebreak which does not insert a new line?
 
 Thanks,
 
 Rainer
 
 
 --
 #secure method=pgpmime mode=sign
 
 #secure method=pgpmime mode=sign
 
 -- 
 Rainer M. Krug
 
 email: RMKrugatgmaildotcom
 
 __
 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] Problem with texi2pdf(..,clean=TRUE)

[Marc Schwartz]

On Aug 30, 2013, at 2:00 PM, cstrato cstr...@aon.at wrote:

 Dear all,
 
 To create a *.pdf file from a *.Rnw file I do:
 
  olddir - getwd();
  setwd(outdir);
 
  tryCatch({Sweave(QAReport.Rnw);
tools::texi2pdf(QAReport.tex, clean=TRUE)
   },
   finally = setwd(olddir)
  );
 
 This works fine, however 'clean=TRUE' does only work when:
 outdir - Test/inst/doc/
 but does not remove the files *.aux, *.log, *.toc when:
 outdir - Test/
 
 Why does function texi2pdf() require the directory structure for vignettes 
 for the deletion of interim files?
 
 (The help file?texi2pdf does not mention that this structure is necessary.)
 
 Best regards
 Christian


In the Details section of ?texi2pdf, there is:

Despite the name, this is used in R to compile LaTeX files, specifically those 
generated from vignettes.


Since it is intended specifically for package vignettes, the path requirement 
should not be a surprise. :-)

Regards,

Marc Schwartz

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

Re: [Rd] Problem with texi2pdf(..,clean=TRUE)

[Marc Schwartz]

On Aug 30, 2013, at 2:20 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:

 On Fri, Aug 30, 2013 at 12:14 PM, Duncan Murdoch
 murdoch.dun...@gmail.com wrote:
 On 30/08/2013 3:09 PM, Marc Schwartz wrote:
 
 On Aug 30, 2013, at 2:00 PM, cstrato cstr...@aon.at wrote:
 
 Dear all,
 
 To create a *.pdf file from a *.Rnw file I do:
 
 olddir - getwd();
 setwd(outdir);
 
 tryCatch({Sweave(QAReport.Rnw);
   tools::texi2pdf(QAReport.tex, clean=TRUE)
  },
  finally = setwd(olddir)
 );
 
 This works fine, however 'clean=TRUE' does only work when:
outdir - Test/inst/doc/
 but does not remove the files *.aux, *.log, *.toc when:
outdir - Test/
 
 Why does function texi2pdf() require the directory structure for
 vignettes for the deletion of interim files?
 
 (The help file?texi2pdf does not mention that this structure is
 necessary.)
 
 Best regards
 Christian
 
 
 In the Details section of ?texi2pdf, there is:
 
 Despite the name, this is used in R to compile LaTeX files, specifically
 those generated from vignettes.
 
 
 Since it is intended specifically for package vignettes, the path
 requirement should not be a surprise. :-)
 
 
 There is no path requirement.  Christian was incorrect in his diagnosis.
 
 texi2pdf won't delete files that existed before it was run, whether or not
 they were changed during the run.  That's likely what Christian was seeing.
 
 Or, that the cleanup fails if the compilation is too quick, cf.
 PR#15394 'texi2dvi(..., clean=TRUE) sometimes too quick for clean
 (with PATCH)' submitted on July 17, 2013:
 
  https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15394
 
 /Henrik


Interesting.

It is late on a Friday, so perhaps I am short on functioning neurons.

If the intent of 'clean = TRUE' is to remove the byproducts of compiling the 
.PDF file from the source .TEX file, why not just delete the resultant 
aux|log|tex|dvi files that match the basename of the source .TEX file rather 
than being dependent upon the time stamp? 

Is there a reason that I am failing to consider for a need to retain these 
files if older than the current time stamp? Perhaps if the compilation requires 
multiple cycles of latex processing (eg. the use of longtables, etc.), in which 
case, one could run texi2pdf(..., clean = FALSE) some number of times, then a 
final texi2pdf(..., clean = TRUE) when done. I actually have my own shell 
script that does this when creating Sweave files.

Of course, the help file does have the following for the 'clean' argument: 
...May not work on some platforms.

Thanks,

Marc

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

Re: [Rd] ‘:::’ call

[Marc Schwartz]

On Aug 28, 2013, at 11:15 AM, Paul Gilbert pgilbert...@gmail.com wrote:

 I have a package (TSdbi) which provides end user functions that I export, and 
 several utilities for plugin packages (e.g. TSMySQL) that I do not export 
 because I do not intend them to be exposed to end users. I call these from 
 the plugin packages using TSdbi:::  but that now produces a note in the 
 checks:
 
 * checking dependencies in R code ... NOTE
 Namespace imported from by a ‘:::’ call: ‘TSdbi’
  See the note in ?`:::` about the use of this operator. :: should be
  used rather than ::: if the function is exported, and a package
  almost never needs to use ::: for its own functions.
 
 Is there a preferred method to accomplish this in a way that does not produce 
 a note?
 
 Thanks,
 Paul



Paul,

See this rather lengthy discussion that occurred within the past week:

  https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html

Regards,

Marc Schwartz

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

Re: [Rd] pretty eerie feeling: Google down, Twitter down, R sites up

[Marc Schwartz]

On Jun 27, 2013, at 10:32 AM, Martin Maechler maech...@stat.math.ethz.ch 
wrote:

 Maybe this is just from inside ETH Zurich, 
 but I haven't seen this before in many years:
 for  15 minutes now, for me and at least someone else here,
 
 - Google (incl. Gmail, calendar..) is entirely unreachable
 - Twitter is connecting and is not reached (in the browser),
 
 - three major Swiss news(paper) websites (20min, TA, NZZ) are out
  of reach,
 
 but  of course the ETH web sites are fine for me (but I'm inside ETH) 
 and notably,
 
  www.r-project.org ,
  bugs.r-project.org,
  cran.r-project.org
  developer.r-project.org
  svn.r-project.org
 
 are all fine and up... an eerie feeling indeed.
 
 Martin


Martin,

No problems for me accessing either Google or Twitter. The Twitter Status page:

  http://twitterstatus.tumblr.com/

is not showing anything nor is the Twitter Support account:

  https://twitter.com/Support


That being said, I just got your post, almost an hour after you sent 
it...according to the e-mail headers, the bulk of the delay was within the ETHZ 
domain, between phil2.ethz.ch and hypatia.math.ethz.ch.

Regards,

Marc

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

Re: [Rd] Missing Dependency: tex(latex) is needed by package R-devel - Help Required

[Marc Schwartz]

On May 15, 2013, at 1:05 AM, santoshdvn santosh...@gmail.com wrote:

 Hi ALl,
 
 
 I am trying to install R on RHEL 5.4 
 
 while install R i am getting the dependency errors ..
 
 can you please help on this . 
 
 [root@Rgraph ~]# yum install R
 Loaded plugins: rhnplugin, security
 This system is not registered with RHN.
 RHN support will be disabled.
 Setting up Install Process
 Parsing package install arguments
 Resolving Dependencies
 -- Running transaction check
 --- Package R.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: libRmath-devel = 2.15.2-1.el5 for package: R
 -- Processing Dependency: R-devel = 2.15.2-1.el5 for package: R
 -- Running transaction check
 --- Package libRmath-devel.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: libRmath = 2.15.2-1.el5 for package:
 libRmath-devel
 --- Package R-devel.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: R-core = 2.15.2-1.el5 for package: R-devel
 -- Processing Dependency: tk-devel for package: R-devel
 -- Processing Dependency: texinfo-tex for package: R-devel
 -- Processing Dependency: tex(latex) for package: R-devel
 -- Processing Dependency: tcl-devel for package: R-devel
 -- Processing Dependency: pcre-devel for package: R-devel
 -- Running transaction check
 --- Package R-devel.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: tex(latex) for package: R-devel
 --- Package pcre-devel.x86_64 0:6.6-2.el5_1.7 set to be updated
 --- Package tcl-devel.x86_64 0:8.4.13-3.fc6 set to be updated
 --- Package tk-devel.x86_64 0:8.4.13-5.el5_1.1 set to be updated
 --- Package R-core.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: xdg-utils for package: R-core
 -- Processing Dependency: tex(latex) for package: R-core
 --- Package libRmath.x86_64 0:2.15.2-1.el5 set to be updated
 --- Package texinfo-tex.x86_64 0:4.8-14.el5 set to be updated
 -- Processing Dependency: tetex for package: texinfo-tex
 -- Running transaction check
 --- Package R-devel.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: tex(latex) for package: R-devel
 --- Package xdg-utils.noarch 0:1.0.2-4.el5 set to be updated
 --- Package R-core.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: tex(latex) for package: R-core
 --- Package tetex.x86_64 0:3.0-33.2.el5_1.2 set to be updated
 -- Processing Dependency: tetex-fonts = 3.0 for package: tetex
 -- Processing Dependency: dialog for package: tetex
 -- Running transaction check
 --- Package R-devel.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: tex(latex) for package: R-devel
 --- Package tetex-fonts.x86_64 0:3.0-33.2.el5_1.2 set to be updated
 --- Package dialog.x86_64 0:1.0.20051107-1.2.2 set to be updated
 --- Package R-core.x86_64 0:2.15.2-1.el5 set to be updated
 -- Processing Dependency: tex(latex) for package: R-core
 -- Finished Dependency Resolution
 R-core-2.15.2-1.el5.x86_64 from epel has depsolving problems
  -- Missing Dependency: tex(latex) is needed by package
 R-core-2.15.2-1.el5.x86_64 (epel)
 R-devel-2.15.2-1.el5.x86_64 from epel has depsolving problems
  -- Missing Dependency: tex(latex) is needed by package
 R-devel-2.15.2-1.el5.x86_64 (epel)
 Error: Missing Dependency: tex(latex) is needed by package
 R-devel-2.15.2-1.el5.x86_64 (epel)
 Error: Missing Dependency: tex(latex) is needed by package
 R-core-2.15.2-1.el5.x86_64 (epel)
 [root@Rgraph ~]#
 
 
 Regards,
 santosh



First, this question should have been posted to R-SIG-Fedora:

  https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

which covers RH based (RHEL/CentOS/Fedora) Linux distributions.

That being said, RHEL requires a paid subscription to utilize the Red Hat 
Network (RHN). It would appear that either you are not logged into RHN and/or 
you have not paid for support. You need to resolve that problem.

If you do not want to pay for support and stay with an RHEL compatible 
distribution, consider CentOS:

  http://www.centos.org/

Regards,

Marc Schwartz

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

Re: [Rd] foreign: write.xport

[Marc Schwartz]

On May 1, 2013, at 1:12 PM, Tim Bergsma t...@metrumrg.com wrote:

 I see in the archives significant discussion about SAS, CDISC formats etc.
 for FDA, but no direct suggestion of adding a write.xport method to the
 foreign package.  Are there significant barriers to doing so?



Hi,

The primary barrier would be that a member of the R Core team would likely need 
to have the interest and time to do this and then maintain the code in the 
future, if it were to become a part of the foreign package, since it is part of 
the Recommended packages that ship with R. 

The better alternative would be to see if you can use the SASxport package on 
CRAN:

  http://cran.r-project.org/web/packages/SASxport/

which looks like it was just recently updated, after Greg, the maintainer, had 
gone missing for a few years. So perhaps Greg has resurfaced to resolve some of 
the issues that resulted in the package failing CRAN checks recently.

Regards,

Marc Schwartz

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

Re: [Rd] Rebuild package on R 3.0.0 without source code?

[Marc Schwartz]

On Apr 18, 2013, at 10:07 AM, McGehee, Robert 
robert.mcge...@geodecapital.com wrote:

 R-developers,
 I have a binary R package built using R 2.14.1 that I would like to run on R 
 3.0.0. Unfortunately, the original source code is unavailable, so I cannot 
 rebuild the package as R 3.0.0 requires.
 
 Is there a straight forward way of converting the package (.rdb, .rdx and 
 .rds files) in the binary package from a 2.14.1 version to a 3.0.0 version 
 without the source code (perhaps uncompressing/recompressing somehow)?
 
 Naturally, since the R code is visible, I know I can output all of the parsed 
 objects in the package to a text file to make a skeleton package that can 
 then be built/installed. Something like this:
 
   objs - ls(envir=loadNamespace(binaryPkg), all.names=TRUE)
   dump(objs, file=code.R, envir=loadNamespace(binaryPkg))
 
 However, I'd still lose all the man pages, and since I get a couple of 
 deparse may be incomplete warnings, I worry that this may be introducing 
 additional bugs.
 
 Is there a magic solution here, or is this a fool's errand?
 
 Thanks, Robert

Robert,

Which package? You might find some older version of the package source code 
here:

  http://cran.us.r-project.org/src/contrib/Archive/

or have you already looked there?

Regards,

Marc Schwartz

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

Re: [Rd] Passing R code from webpage

[Marc Schwartz]

On Feb 16, 2013, at 5:48 PM, Matevz Pavlic matevzpav...@gmail.com wrote:

 Hi all, 
 
 Is there a way to pass R code from web page (html file) to do some
 statistics and than plot the output in web browser. 
 
 I am looking forever at this, and cant find a way.
 
 Regards,m



You might have wanted to start by looking at the R FAQ, which contains the 
following:

  http://cran.r-project.org/doc/FAQ/R-FAQ.html#R-Web-Interfaces

More recently, there is Shiny, which I did not see listed in the above:

  http://www.rstudio.com/shiny/

Regards,

Marc Schwartz

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

Re: [Rd] Regression stars

[Marc Schwartz]

FWIW, that has been my default setting for years in my .Rprofile.

If there is some agreement on this from R Core, it would seem that version 
3.0.0 would be a reasonable breakpoint for this change in default behavior.

Regards,

Marc Schwartz

On Feb 7, 2013, at 8:27 AM, John Fox j...@mcmaster.ca wrote:

 Dear Frank,
 
 I'd like to second your implicit motion to make 
 options(show.signif.stars=FALSE) the default.
 
 Thanks for raising this point.
 
 John
 
 On Thu, 7 Feb 2013 05:32:04 -0800 (PST)
 Frank Harrell f.harr...@vanderbilt.edu wrote:
 Today's GNU R tutorial in
 http://how-to.linuxcareer.com/a-quick-gnu-r-tutorial-to-statistical-models-and-graphics
 points out how bad statistical practice is being further perpetuated, by
 virtue of significance stars still being the default in printed output
 from lm models.

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

Re: [Rd] Implications of a Dependency on a GPLed Package

[Marc Schwartz]

 dialects, then the only way to make it
 work would be to use R.  So if you want to distribute it, you would need
 to GPL it.  So lots of the R packages on CRAN that do not have GPL
 compatible licenses would be in violation of the GPL, and since CRAN is
 distributing them, CRAN is in violation of the GPL.  That's nonsense.
 
 (from https://stat.ethz.ch/pipermail/r-help/2008-November/179908.html)
 
 and an email by Prof. Leisch
 
 https://stat.ethz.ch/pipermail/r-devel/2009-April/053141.html
 
 where he mentions ongoing discussions in R Core and the R Foundation. 
 However, these discussions might have only considered Revolution Analytic's 
 ParallelR (the main topic of that thread), and I could not find a follow-up 
 email where the result of that discussion was published.
 
 Did the CRAN maintainers and the R Foundation publish an agreed upon 
 position on the FSF interpretation of the GPL quoted above, and I simply 
 missed it? If yes, could it be added to the R FAQ and/or the CRAN repository 
 policy, such that it is easier to find? If not, may I kindly ask them to 
 explain their position?
 
 No, CRAN and the R Foundation have not published that.  I don't think either 
 group will publish a position.  You can guess the current beliefs of the 
 folks at CRAN by seeing what they do (under the reasonable assumption that 
 they do not think they are doing anything illegal), but those beliefs might 
 change.  The R Foundation does almost nothing, so it's a little more 
 inscrutable.
 
 Note that I am not asking for legal advice,
 
 You should be.  If you really want to know whether they are using your code 
 illegally, or about whether your proposed use of other peoples code is legal, 
 you really should get legal advice.
 
  nor am I advocating for a specific change of the current practices of the R 
  project.
 
 Duncan Murdoch


With the caveat that I am not a lawyer, you have not really provided enough 
information here to formulate even an informal (definitely non-binding) 
response specifically as it pertains to your package, much less the broad issue 
of packages on CRAN in general.

There are some questions that need to be answered, since these types of 
questions have to be answered within specific contexts. For example:

1. Is your package pure R code and contains only code that you have written?

2. Does your package contain code requiring compilation (eg. C, C++, FORTRAN) 
that links against other GPL libraries, R or otherwise?

3. Are you including any other source code, not written by you, that is GPL?


If your package is pure R (no compiled code and no R code from someone else 
that is GPL) and contains no linking (in the compiler sense of the term) to R's 
libraries or the libraries of other GPL licensed code, you are free to 
distribute your package under any license you wish and even restrict use. Note 
that I am focusing on the GPL here and not other looser open source licenses. 

The same applies if you include a DEPENDS line in your DESCRIPTION file, where 
other GPL packages are listed. That has no implication for the licensing of 
your package unless you are linking against libraries in the other GPL 
packages. 

The so-called viral part of the GPL largely comes into play when you link 
against other GPL code or possibly embed other GPL code within yours and 
distribute that product. In that case, your code, at least the part that 
specifically links against other GPL libraries, would have to be licensed under 
the GPL or a GPL compatible license as well. Albeit, even there, we are talking 
about distribution, not use. You could develop a package for internal use 
only, in which case, the license used is irrelevant. 

The GPL really only comes into play when distributing/copying software beyond 
yourself or perhaps your organization and even in that case, there are 
scenarios that would allow for multiple licenses to be used and there is a fair 
amount of commercial software that is distributed in that fashion. The GPL 
components are distributed intact and source is made available, while it is 
possible that proprietary components are also packaged together as part of 
the whole.

There are non-GPL and non-GPL compatible packages on CRAN and this topic has 
come up for [heated] discussion in the past. The CRAN maintainers have not 
placed GPL or GPL compatible only restrictions on the packages on CRAN. That 
there are such packages on CRAN is not a legal issue vis-a-vis the GPL, but a 
philosophical one, which is where the heated discussions tend to arise from.

I would also point out that there are R packages not on CRAN that have been 
made available and the same licensing parameters apply.

Regards,

Marc Schwartz

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

Re: [Rd] Implications of a Dependency on a GPLed Package

[Marc Schwartz]

On Jan 25, 2013, at 12:16 PM, Christian Sigg christ...@sigg-iten.ch wrote:

 Dear Duncan
 
 I don't think my point contradicts the FSF interpretation.  I think they 
 were talking about using GPL modules in a program you distribute, with the 
 implication that you are distributing the modules along with your program.  
 However, I could be wrong.  If I am wrong and the FSF agrees with your 
 strong interpretation, then I do think they are wrong.
 
 Let me again quote parts of the GPL FAQ:
 
 Another similar and very common case is to provide libraries with the 
 interpreter which are themselves interpreted. For instance, Perl comes with 
 many Perl modules, and a Java implementation comes with many Java classes. 
 These libraries and the programs that call them are always dynamically 
 linked together.
 
 A consequence is that if you choose to use GPL'd Perl modules or Java 
 classes in your program, you must release the program in a GPL-compatible 
 way, regardless of the license used in the Perl or Java interpreter that the 
 combined Perl or Java program will run on. 
 
 The second paragraph (applied to R) says that if I use a GPL'd R package, I 
 must release the program in a GPL-compatible way. It makes no mention of 
 distributing the GPLed modules along with the program. 
 
 I think that this FAQ entry precisely exists because in an interpreted 
 environment, it is possible to make use of the functionality of a GPLed 
 package without copying code (in source or binary form) from that package 
 into my program (beyond the API calls), as it would happen in static linking. 
 The last sentence of the first paragraph unambiguously asserts that calling 
 functionality from an R package is equivalent to dynamic linking of my 
 program with the package. 
 
 The preceding entry of the GPL FAQ has this to say:
 
 If a library is released under the GPL (not the LGPL), does that mean that 
 any software which uses it has to be under the GPL or a GPL-compatible 
 license? (#IfLibraryIsGPL)
 
Yes, because the software as it is actually run includes the library.
 
 There exist several licenses which modify the GPL explicitly to allow for 
 dynamic linking to a GPLed library without having to release the program 
 under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. 
 The following section again states that dynamic linking implies that a 
 program and the package become effectively a single program, which needs to 
 be released under the GPL:
 
 Can I release a non-free program that's designed to load a GPL-covered 
 plug-in? (#NFUseGPLPlugins)
 
   (...)
 
If the program dynamically links plug-ins, and they make function calls 
 to each other and share data structures, we believe they form a single 
 program, which must be treated as an extension of both the main program and 
 the plug-ins. In order to use the GPL-covered plug-ins, the main program 
 must be released under the GPL or a GPL-compatible free software license, 
 and that the terms of the GPL must be followed when the main program is 
 distributed for use with these plug-ins.
 
 
 I see nothing in the FAQ which would indicate that these points were only 
 valid if the GPLed R package is distributed along with my program.
 
 
 If you write something that incorporates nothing of mine, I can't see how my 
 copyright could influence you at all.  If a user needs my code to make yours 
 useful, I don't see how any of that changes.  The GPL is quite clear that it 
 doesn't restrict people in how they use the code, it just gives them rights 
 to copy it (possibly in a modified form, if they follow the rules).
 
 I think I understand your position, and personally applied the same reasoning 
 when reading the GPL. But the above quoted sections unambiguously concern 
 usage and dynamic linking, and make no mention of copying code. 
 
 No, CRAN and the R Foundation have not published that.  I don't think either 
 group will publish a position.  You can guess the current beliefs of the 
 folks at CRAN by seeing what they do (under the reasonable assumption that 
 they do not think they are doing anything illegal), but those beliefs might 
 change.  The R Foundation does almost nothing, so it's a little more 
 inscrutable.
 
 I already mentioned in my first email what I assume is the position of the 
 CRAN maintainers and the R Foundation, i.e. that they believe that 
 distributing non GPL-compatible packages which depend on GPL packages is not 
 a violation of the GPL. But if my reading of the GPL FAQ has any merit, then 
 the FSF has a different position. And because the R project is an official 
 GNU project, the FSF interpretation of the GPL is important for the R 
 project. A clarification of the position of the CRAN maintainers and the R 
 Foundation would therefore be helpful.
 
 Prof. Leisch explicitly mentions that discussions concerning such issues 
 (e.g. combining R with non-free functionality) are taking place, and that 

Re: [Rd] Implications of a Dependency on a GPLed Package

[Marc Schwartz]

On Jan 25, 2013, at 2:45 PM, Simon Urbanek simon.urba...@r-project.org wrote:

 
 On Jan 25, 2013, at 3:32 PM, Marc Schwartz wrote:
 
 
 On Jan 25, 2013, at 12:16 PM, Christian Sigg christ...@sigg-iten.ch wrote:
 
 Dear Duncan
 
 I don't think my point contradicts the FSF interpretation.  I think they 
 were talking about using GPL modules in a program you distribute, with the 
 implication that you are distributing the modules along with your program. 
  However, I could be wrong.  If I am wrong and the FSF agrees with your 
 strong interpretation, then I do think they are wrong.
 
 Let me again quote parts of the GPL FAQ:
 
 Another similar and very common case is to provide libraries with the 
 interpreter which are themselves interpreted. For instance, Perl comes 
 with many Perl modules, and a Java implementation comes with many Java 
 classes. These libraries and the programs that call them are always 
 dynamically linked together.
 
 A consequence is that if you choose to use GPL'd Perl modules or Java 
 classes in your program, you must release the program in a GPL-compatible 
 way, regardless of the license used in the Perl or Java interpreter that 
 the combined Perl or Java program will run on. 
 
 The second paragraph (applied to R) says that if I use a GPL'd R package, I 
 must release the program in a GPL-compatible way. It makes no mention of 
 distributing the GPLed modules along with the program. 
 
 I think that this FAQ entry precisely exists because in an interpreted 
 environment, it is possible to make use of the functionality of a GPLed 
 package without copying code (in source or binary form) from that package 
 into my program (beyond the API calls), as it would happen in static 
 linking. The last sentence of the first paragraph unambiguously asserts 
 that calling functionality from an R package is equivalent to dynamic 
 linking of my program with the package. 
 
 The preceding entry of the GPL FAQ has this to say:
 
 If a library is released under the GPL (not the LGPL), does that mean that 
 any software which uses it has to be under the GPL or a GPL-compatible 
 license? (#IfLibraryIsGPL)
 
  Yes, because the software as it is actually run includes the library.
 
 There exist several licenses which modify the GPL explicitly to allow for 
 dynamic linking to a GPLed library without having to release the program 
 under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. 
 The following section again states that dynamic linking implies that a 
 program and the package become effectively a single program, which needs to 
 be released under the GPL:
 
 Can I release a non-free program that's designed to load a GPL-covered 
 plug-in? (#NFUseGPLPlugins)
 
 (...)
 
  If the program dynamically links plug-ins, and they make function calls 
 to each other and share data structures, we believe they form a single 
 program, which must be treated as an extension of both the main program 
 and the plug-ins. In order to use the GPL-covered plug-ins, the main 
 program must be released under the GPL or a GPL-compatible free software 
 license, and that the terms of the GPL must be followed when the main 
 program is distributed for use with these plug-ins.
 
 
 I see nothing in the FAQ which would indicate that these points were only 
 valid if the GPLed R package is distributed along with my program.
 
 
 If you write something that incorporates nothing of mine, I can't see how 
 my copyright could influence you at all.  If a user needs my code to make 
 yours useful, I don't see how any of that changes.  The GPL is quite clear 
 that it doesn't restrict people in how they use the code, it just gives 
 them rights to copy it (possibly in a modified form, if they follow the 
 rules).
 
 I think I understand your position, and personally applied the same 
 reasoning when reading the GPL. But the above quoted sections unambiguously 
 concern usage and dynamic linking, and make no mention of copying code. 
 
 No, CRAN and the R Foundation have not published that.  I don't think 
 either group will publish a position.  You can guess the current beliefs 
 of the folks at CRAN by seeing what they do (under the reasonable 
 assumption that they do not think they are doing anything illegal), but 
 those beliefs might change.  The R Foundation does almost nothing, so it's 
 a little more inscrutable.
 
 I already mentioned in my first email what I assume is the position of the 
 CRAN maintainers and the R Foundation, i.e. that they believe that 
 distributing non GPL-compatible packages which depend on GPL packages is 
 not a violation of the GPL. But if my reading of the GPL FAQ has any merit, 
 then the FSF has a different position. And because the R project is an 
 official GNU project, the FSF interpretation of the GPL is important for 
 the R project. A clarification of the position of the CRAN maintainers and 
 the R Foundation would therefore be helpful.
 
 Prof. Leisch

Re: [Rd] Download R

[Marc Schwartz]

On Dec 16, 2012, at 8:05 PM, Charlotte Maia mai...@gmail.com wrote:

 I use Fedora 10.
 I need to update my computer's R version.
 I apologise if this has come up before.
 
 The Debian and Ubuntu download links appear reasonably up to date.
 The Suse download links appear almost up to date.
 Unfortunately, the Fedora download links are from 2008/2009.
 
 http://cran.r-project.org/bin/linux/
 
 Should the Fedora links be removed or updated?



Fedora has, for several years now, offered R via the normal Fedora yum repos. 
Thus, the RPMs are no longer on CRAN. The same for RHEL via the EPEL.

That being said, I presume that you are aware that Fedora 10 was EOL'd back in 
late 2009. Thus, you have not had any bug fixes, patches, security updates, 
etc. for 3 years, which tends to obviate the reason for using Fedora, which is 
a bleeding edge Linux distribution.

Fedora only supports a given release for around 18 months and the current 
stable release is Fedora 17. I would advise you to upgrade your Fedora version. 
Once you have, you can use:

  yum install R

from the CLI as root to install R.

Also, there is a dedicated e-mail list for R on Fedora:

  https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Any subsequent questions you have about using R on Fedora should be posted 
there. General R questions should go to R-Help. More info in the Posting Guide:

  http://www.r-project.org/posting-guide.html

Regards,

Marc Schwartz

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

Re: [Rd] small issue with over-zealous clean.

[Marc Schwartz]

On Dec 14, 2012, at 1:48 PM, Hin-Tak Leung ht...@users.sourceforge.net wrote:

 --- On Fri, 14/12/12, Uwe Ligges lig...@statistik.tu-dortmund.de wrote:
 
 On 14.12.2012 04:15, Hin-Tak Leung wrote:
 --- On Sun, 9/12/12, Dirk Eddelbuettel e...@debian.org
 wrote:
 
 snipped
 Do you REALLY think svn would not know about
 missing
 files?  There does not
 seem to be a limit on the disdain for svn among git
 users.
 Fascinating.
 
 FWIW, as one of the linux kernel maintainers, I don't
 apologize for being familiar with git. I did not decide git
 as the official tool for maintaining the linux kernel. Linus
 did.
 
 There does not seem to be a limit on the disdain for
 the linux kernel among debian users.
 Fascinating.
 
 
 There *is* no limit on the disdain for people discussing
 off-topic 
 svn/git/linux disdains on the *R*-devel list among R
 developers.
 
 That needs a Fascinating exclamation at the end to be genuine and authentic 
 for the typical R developers/debian users.



That's enough of this off-topic subject matter. Take it off list if you wish to 
continue this dialog.

Any further posts to R-Devel in this vain will not be tolerated.

Marc Schwartz
R-Devel Co-Admin

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

Re: [Rd] Depends/Imports/Suggest/Enhence

[Marc Schwartz]

On Nov 6, 2012, at 10:36 AM, Simon Urbanek simon.urba...@r-project.org wrote:

 
 On Nov 6, 2012, at 11:19 AM, Christophe Genolini wrote:
 
 Hi the list
 
 In the DESCRIPTION file of my package foo0, I have:
 
 Depends: foo1
 Imports: foo2
 Suggest: foo3
 Enhence: foo4
 
 
 (it is really Suggests and Enhances - the above are typos I presume and 
 thus won't be recognized)
 
 
 If I understand correctly, to install foo0 on my computer, I need to already 
 have foo1, foo2, foo3. 
 foo4 is not necessary.
 
 
 No, you only need foo1 and foo2. The other two are optional.


Just to add another option here, you need not have foo1 and foo2 already 
installed to install foo0. You can use:

  install.packages(foo0, dependencies = TRUE)

and that will install foo1 and foo2 at the same time. 'dependencies' defaults 
to FALSE. See ?install.packages for more info.

Regards,

Marc Schwartz


 
 I my R sesssion, when I will write: library(foo0), then the package foo1 
 will be attach. foo2, foo3 
 and foo4 will not. Is that correct?
 
 
 Yes
 
 
 But what is the difference between Import and Suggest?
 
 
 Imports means that symbols are imported form the namespace, so they are 
 mandatory for the package to operate. Suggests means that symbols from the 
 package are not required, but they are used in examples or vignettes, so the 
 listed package(s) will be needed for a full check. They are not needed for 
 the operation of the package, though.
 
 Cheers,
 Simon
 
 
 Christophe

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

Re: [Rd] Depends/Imports/Suggest/Enhence

[Marc Schwartz]

On Nov 6, 2012, at 11:00 AM, Marc Schwartz marc_schwa...@me.com wrote:

 
 On Nov 6, 2012, at 10:36 AM, Simon Urbanek simon.urba...@r-project.org 
 wrote:
 
 
 On Nov 6, 2012, at 11:19 AM, Christophe Genolini wrote:
 
 Hi the list
 
 In the DESCRIPTION file of my package foo0, I have:
 
 Depends: foo1
 Imports: foo2
 Suggest: foo3
 Enhence: foo4
 
 
 (it is really Suggests and Enhances - the above are typos I presume and 
 thus won't be recognized)
 
 
 If I understand correctly, to install foo0 on my computer, I need to 
 already have foo1, foo2, foo3. 
 foo4 is not necessary.
 
 
 No, you only need foo1 and foo2. The other two are optional.
 
 
 Just to add another option here, you need not have foo1 and foo2 already 
 installed to install foo0. You can use:
 
  install.packages(foo0, dependencies = TRUE)
 
 and that will install foo1 and foo2 at the same time. 'dependencies' defaults 
 to FALSE. See ?install.packages for more info.


Actually, a correction here. 'dependencies' defaults to NA, which will handle 
Depends, Imports and LinkingTo for the packages explicitly listed in the 'pkgs' 
argument.

TRUE adds handling for Suggests in the packages listed in the 'pkgs' argument 
and then additional Depends, Imports and LinkingTo in other packages brought in 
as further dependencies. So if you get into nested package dependencies, you 
would want to use this.

Marc


 
 Regards,
 
 Marc Schwartz
 
 
 
 I my R sesssion, when I will write: library(foo0), then the package foo1 
 will be attach. foo2, foo3 
 and foo4 will not. Is that correct?
 
 
 Yes
 
 
 But what is the difference between Import and Suggest?
 
 
 Imports means that symbols are imported form the namespace, so they are 
 mandatory for the package to operate. Suggests means that symbols from the 
 package are not required, but they are used in examples or vignettes, so the 
 listed package(s) will be needed for a full check. They are not needed for 
 the operation of the package, though.
 
 Cheers,
 Simon
 
 
 Christophe
 
 __
 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] Problem in vignette packaging of Sweave in utils package

[Marc Schwartz]

The HTML help related pages are dynamically generated upon request, so there 
are no static pages that would exist otherwise. I can get to the index pages 
for each of the packages mentioned in Yihui's post.

That being said, I can replicate the vignette issue on:

R version 2.15.1 (2012-06-22) -- Roasted Marshmallows

which was a clean install on OSX Lion using the OSX binary on CRAN.


 browseVignettes(utils)
No vignettes found by browseVignettes(utils)

 browseVignettes(grid)
No vignettes found by browseVignettes(grid)

 browseVignettes(parallel)
No vignettes found by browseVignettes(parallel)

 vignette(Sweave)
Warning message:
vignette ‘Sweave’ not found 


However, Matrix and survival did work.

Curiously, testInstalledPackages() did work for the vignettes without returning 
an error:

 Result - testInstalledPackages(types = vignettes)
Running vignettes for package ‘utils’
Running vignettes for package ‘grid’
Running vignettes for package ‘parallel’
Running vignettes for package ‘Matrix’
Running vignettes for package ‘survival’
 Result
[1] 0


I then installed:

R version 2.15.1 Patched (2012-07-02 r59715) -- Roasted Marshmallows

from Simon's site and:

 browseVignettes(utils)
 browseVignettes(grid)
 browseVignettes(parallel)
 vignette(Sweave)

all worked. 

So it would appear that there was something amiss with the 2.15.1 release 
packaging or something involving the vignettes at least for those packages. A 
review of the NEWS file did not reveal anything obvious to me that would be 
relevant.

Regards,

Marc Schwartz


On Jul 3, 2012, at 12:54 PM, Yihui Xie wrote:

 Strange enough; I just noticed the HTML index pages of several base
 packages were gone (e.g. base, stats, tools, utils) under Ubuntu. Not
 sure if this is a problem of Debian packages or R itself.
 
 sessionInfo()
 R version 2.15.1 (2012-06-22)
 Platform: i686-pc-linux-gnu (32-bit)
 
 locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=C LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
 [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
 
 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base
 
 Regards,
 Yihui
 --
 Yihui Xie xieyi...@gmail.com
 Phone: 515-294-2465 Web: http://yihui.name
 Department of Statistics, Iowa State University
 2215 Snedecor Hall, Ames, IA
 
 
 On Tue, Jul 3, 2012 at 1:34 PM, Duncan Murdoch murdoch.dun...@gmail.com 
 wrote:
 On 03/07/2012 1:21 PM, Paul Johnson wrote:
 
 In ?Sweave, it refers to Sweave User Manual. In the doc folder of
 utils package, I see Sweave.pdf.
 
 However, I can't find it from within R
 
 
 vignette(Sweave User Manual)
 Warning message:
 vignette ‘Sweave User Manual’ not found
 
 
 browseVignettes(utils)
 No vignettes found by browseVignettes(utils)
 
 
 library(help=utils)
 
 does not refer to any vignettes.
 
 The vignette does not appear in the main page for utils in help.start().
 
 I checked the source code for the Sweave vignette, but I don't see
 anything wrong. It has all of the required elements:
 
 %\VignetteIndexEntry{Sweave User Manual}
 %\VignettePackage{utils}
 %\VignetteDepends{tools}
 %\VignetteDepends{datasets}
 %\VignetteDepends{stats}
 
 Am I accessing it incorrectly, or is there something wrong in my
 install of R-2.15.1?
 
 
 The vignette name is Sweave, so you should see it when you say
 
 vignette(Sweave)
 
 but you should also have seen it in
 
 browseVignettes(utils)
 
 and
 
 library(help=utils)
 
 and the page for utils in the HTML help.  So it looks as though something is
 wrong in your install.  I do see it in 2.15.1 patched on Windows.
 
 Duncan Murdoch

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

Re: [Rd] seq.Date bug?

[Marc Schwartz]

On Jan 31, 2012, at 2:07 PM, Sarah Goslee wrote:

 I was prompted to try it myself:
 
 On Tue, Jan 31, 2012 at 2:56 PM, Dirk Eddelbuettel e...@debian.org wrote:
 
 R seq(as.Date(Sys.Date()), by=-1 months, length=6)
 [1] 2012-01-31 2011-12-31 2011-12-01 2011-10-31 2011-10-01 
 2011-08-31
 R
 
 Notice how October appears twice.
 
 As does December.
 
 Now, date arithmetic is gruesome but the documentation for seq.Date et al
 does not hint it wouldn't honour the by= argument.  So a bug, or merely a
 somewhat less than desirable features.
 
 The by argument chokes on month if the current day is greater than the
 shortest month in the sequence (presumably due to the irregular nature
 of month lengths):
 
 For leap year 2012:
 seq(as.Date(2012/1/29), by=month, length.out=12) # works
 [1] 2012-01-29 2012-02-29 2012-03-29 2012-04-29 2012-05-29
 [6] 2012-06-29 2012-07-29 2012-08-29 2012-09-29 2012-10-29
 [11] 2012-11-29 2012-12-29
 seq(as.Date(2012/1/30), by=month, length.out=12) # fails
 [1] 2012-01-30 2012-03-01 2012-03-30 2012-04-30 2012-05-30
 [6] 2012-06-30 2012-07-30 2012-08-30 2012-09-30 2012-10-30
 [11] 2012-11-30 2012-12-30
 
 While for non-leap year 2011:
 seq(as.Date(2011/1/28), by=month, length.out=12) # works
 [1] 2011-01-28 2011-02-28 2011-03-28 2011-04-28 2011-05-28
 [6] 2011-06-28 2011-07-28 2011-08-28 2011-09-28 2011-10-28
 [11] 2011-11-28 2011-12-28
 seq(as.Date(2011/1/29), by=month, length.out=12) #fails
 [1] 2011-01-29 2011-03-01 2011-03-29 2011-04-29 2011-05-29
 [6] 2011-06-29 2011-07-29 2011-08-29 2011-09-29 2011-10-29
 [11] 2011-11-29 2011-12-29


The issue is the if the next month in sequence does not contain the date, then 
the date is advanced until the next valid date. For example:

 seq.Date(as.Date(2012/01/30), by = month, length.out = 3)
[1] 2012-01-30 2012-03-01 2012-03-30

February 30th does not exist, thus that date is advanced to March 1st, then the 
next date in the sequence is March 30th. Thus, two days in March.


 seq.Date(as.Date(2012/10/31), by = month, length.out = 3)
[1] 2012-10-31 2012-12-01 2012-12-31

Here, November 31st does not exist, so the date is advanced to the next valid 
date, December 1 and then the next date is December 31. Thus, two days in 
December.


So it appears to be working correctly.

HTH,

Marc Schwartz

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

Re: [Rd] Small nit in Sweave

[Marc Schwartz]

On Nov 15, 2011, at 1:10 PM, Terry Therneau wrote:

 Two small Sweave issues.
 
 1. I had the following line in my code
   echo=FALSE, results=hide
 
 resulting in the message
 Error in match.arg(options$results, c(verbatim, tex, hide)) : 
  'arg' should be one of “verbatim”, “tex”, “hide”
 
  I puzzled on this a bit since my argument exactly matched the message,
 until I thought of trying it without the quotes.
 
 2. Where should I have reported this?  Sweave is not on CRAN so I
 couldn't find the maintainer email there.  Perhaps I'm missing something
 obvious though
 
 Terry T.


Interesting. I never thought of using the 'results' options as quoted character 
vectors, even though in ?RweaveLatex, the description for the 'results' options 
indicates:

character string (verbatim). If verbatim, the output of R commands is 
included in the verbatim-like Soutput environment. If tex, the output is 
taken to be already proper LaTeX markup and included as is. If hide then all 
output is completely suppressed (but the code executed during the weave).


I can see how that could be confusing. All examples of the chunk headers I have 
seen do not use quoted values. Perhaps the above should state Non-quoted 
character values or similar verbiage.

In terms of reporting Terry, Sweave is in the 'utils' package, which is part of 
Base R, therefore under the copyright of The R Foundation. So here is fine.

Regards,

Marc Schwartz

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

Re: [Rd] Referencing 'inst' directory in installed package

[Marc Schwartz]

On Aug 16, 2011, at 10:17 PM, Jonathan Malmaud wrote:

 Hi,
 My R package has files in the 'inst' directory that it needs to reference. 
 How can the R scripts in my package find out the full path to the 'inst' 
 directory after the package is installed, given that different users may have 
 installed the package to different libraries? 
 
 Thanks,
 Jon Malmaud


See ?path.package and ?file.path

Example:

 require(WriteXLS)
Loading required package: WriteXLS

# I am on OSX
 path.package(WriteXLS)
[1] /Library/Frameworks/R.framework/Versions/2.13/Resources/library/WriteXLS

I have Perl scripts in my package, which are in the /inst/Perl folder in the 
package source, so:

 file.path(path.package(WriteXLS), Perl/WriteXLS.pl)
[1] 
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/WriteXLS/Perl/WriteXLS.pl


HTH,

Marc Schwartz

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

Re: [Rd] Welcome Uwe Ligges to R-core

[Marc Schwartz]

On Jul 19, 2011, at 7:29 AM, Prof Brian Ripley wrote:

 Uwe is now a member of R-core.

Congratulations Uwe!

Regards,

Marc Schwartz

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

Re: [Rd] [R] NaN, Inf to NA

[Marc Schwartz]

On May 27, 2011, at 10:33 AM, Duncan Murdoch wrote:

 On 27/05/2011 11:11 AM, Martin Maechler wrote:
   Duncan Murdochmurdoch.dun...@gmail.com
   on Fri, 27 May 2011 08:23:14 -0400 writes:
 
   On 11-05-27 4:27 AM, Albert-Jan Roskam wrote:
   Aha! Thank you very much for that clarification! It would
   be much more user friendly if R generated a
   NotImplementedError or something similar. The 'garbage
   results' are pretty misleading, esp. to a novice.
 
   I think that's a good idea.  The default methods are
   documented to work on atomic vectors; dataframes are not
   atomic vectors, so it would be reasonable to generate an
   error.  (See ?is.atomic for a definition of atomic
   vectors.)
 
   I'll see if this causes a lot of trouble...
 
   Duncan Murdoch
 
 Duncan,
 do you remember the issue of mean(), var(), median(),... etc
 that was the topic a few weeks ago ?
 
 I strongly advocated that  mean.data.frame() should become
 *deprecated*, and I would propose the same for the functions
 mentioned here.
 
 I think you may have misunderstood my proposal.  Currently is.nan, is.finite 
 and is.infinite have no data.frame methods, so the default method is used.  
 The problem is that the default method is too permissive:  it operates on the 
 data.frame by treating it as a list; then it returns FALSE for each list 
 element.  (If there is only one row, it applies the test to the singleton in 
 the column.)   This is pretty strange default behaviour.
 
 What I'm proposing is that the default method should trigger an error if you 
 try to send it anything that's not atomic.  This gives sensible behaviour in 
 most cases; the only one where it doesn't work is a list of singletons, which 
 used to be handled sensibly, but will now fail.
 
 (There's still a question about what the answer should be for these functions 
 when applied to character or raw vectors, which are both atomic.  I'm leaning 
 towards returning FALSE for every element, which matches the current 
 behaviour, but perhaps those should also generate an error.)
 
 I think this partially addresses Bill's objection, but not completely.  
 Someone could still put a class on an atomic vector, and that might not be 
 handled properly by the default method.
 
 People should  *apply (or *ply) on data frames, and not expect
 that all kind of functions have data.frame methods
 which are simply equivalent to basically  sapply(df,function)
 
 {and yes -- all this belongs to R-devel rather than R-help}
 
 Where I've moved it now.
 
 Duncan Murdoch
 Martin


I snipped some of the older content and added Bill.

It seems to me that unless the 'x' argument is both atomic and numeric, these 
functions really don't have much utility, if you are going to implement 
standard default behavior and more rigorous error checking. 

So I would support adding an error message if both conditions are not passed, 
rather than an unpredictable result, which an unsuspecting useR might not catch.

I agree that the non-default methods should be deprecated.

Regards,

Marc

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

[Rd] Patch for hist.Date() function in datetime.R

[Marc Schwartz]

Hi all,

In follow up to my reply to Terry Therneau on r-help regarding the lack of a 
check in hist.Date() for a missing 'breaks' argument, attached is a proposed 
patch which includes such a check, patterned after the same check for 
hist.POSIXt().

The patch is against the current svn 'trunk' version of datetime.R in package 
'graphics'.

Regards,

Marc Schwartz



--- datetime.R  2011-04-22 13:04:29.0 -0500
+++ datetime.R.new  2011-04-22 13:18:10.0 -0500
@@ -237,6 +237,8 @@
 force(xlab)
 incr - 1
 ## handle breaks ourselves
+if(missing(breaks))
+   stop(Must specify 'breaks' in hist(Date))
 if (inherits(breaks, Date)) {
 breaks - as.Date(breaks)
 d - min(abs(diff(unclass(breaks



--- datetime.R  2011-04-22 13:04:29.0 -0500
+++ datetime.R.new  2011-04-22 13:18:10.0 -0500
@@ -237,6 +237,8 @@
 force(xlab)
 incr - 1
 ## handle breaks ourselves
+if(missing(breaks))
+   stop(Must specify 'breaks' in hist(Date))
 if (inherits(breaks, Date)) {
 breaks - as.Date(breaks)
 d - min(abs(diff(unclass(breaks


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