Re: [Rd] as.list method for by Objects

[Martin Maechler]

> Henrik Bengtsson 
> on Thu, 1 Feb 2018 10:26:23 -0800 writes:

> On Thu, Feb 1, 2018 at 12:14 AM, Martin Maechler
>  wrote:
>>> Michael Lawrence 
>>> on Tue, 30 Jan 2018 15:57:42 -0800 writes:
>> 
>> > I just meant that the minimal contract for as.list() appears to be 
that it
>> > returns a VECSXP. To the user, we might say that is.list() will always
>> > return TRUE.
>> 
>> Indeed. I also agree with Herv'e that the user level
>> documentation should rather mention  is.list(.) |--> TRUE  than
>> VECSXP, and interestingly for the experts among us,
>> the  is.list() primitive gives not only TRUE for  VECSXP  but
>> also of LISTSXP (the good ole' pairlists).
>> 
>> > I'm not sure we can expect consistency across methods
>> > beyond that, nor is it feasible at this point to match the
>> > semantics of the methods package. It deals in "class
>> > space" while as.list() deals in "typeof() space".
>> 
>> > Michael
>> 
>> Yes, and that *is* the extra complexity we have in R (inherited
>> from S, I'd say)  which ideally wasn't there and of course is
>> not there in much younger languages/systems such as julia.
>> 
>> And --- by the way let me preach, for the "class space" ---
>> do __never__ use
>> 
>> if(class(obj) == "")
>> 
>> in your code (I see this so often, shockingly to me ...) but rather use
>> 
>> if(inherits(obj, ""))
>> 
>> instead.

> Second this one.  But, soon (*) the former will at least give the
> correct answer when length(class(obj)) == 1 
> and produce an error
> otherwise.

Not quite; I think you you did not get the real danger in using
'class(.) == *':
What you say above would only be true if there were only S3 classes!
Try the following small R snippet

myDate <- setClass("myDate", contains = "Date")
## Object of class "myDate"
## [1] "2018-02-02"
(d <- myDate(Sys.Date()))
class(d) == "Date"  # is FALSE (hence of length 1)
inherits(d, "Date") # is TRUE

> So, several of these cases will be caught at run-time in a
> near future.

Maybe.  But all the others are  still wrong, as I show above.
Martin

> (*) When _R_CHECK_LENGTH_1_CONDITION_=true becomes the default
> behavior - hopefully by R 3.5.0.

>> 
>> Martin

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

Re: [Rd] Best practices in developing package: From a single file

[Joris Meys]

On Thu, Feb 1, 2018 at 6:20 PM, Gabriel Becker  wrote:

>
> Or perhaps you could imagine two help systems, akin to --help and man for
> command line tools, one of which is minimalist showing usage, etc,
> generated by roxygen comments, and one of which is much more extensive, and
> not tied to (what could be extremely large) comments in the same .R file as
> the code.
>

That sounds like basic help files and a few vignettes. I would argue we
have the tools to do this if necessary. One can even create topics in the
help file system (by using either Rd manually or through roxygen) that
aren't necessarily tied to a function. And each time I come to the same
conclusion: we have multiple tools to do this. We just need package
developers to care enough to do it.

-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Rd] Best practices in developing package: From a single file

[Duncan Murdoch]

On 01/02/2018 12:20 PM, Gabriel Becker wrote:
[ lots deleted...]


Or perhaps you could imagine two help systems, akin to --help and man for
command line tools, one of which is minimalist showing usage, etc,
generated by roxygen comments, and one of which is much more extensive, and
not tied to (what could be extremely large) comments in the same .R file as
the code.


I think the input method and output form should be orthogonal.  Several 
front ends already implement minimalist help (e.g. RStudio displays the 
usage and description sections from the help page).


I'd rather have the help info coming from a separate file; other people 
apparently prefer to put it in the .R file.  I think both methods should 
be supported.  It makes sense to me to get both types of info from one 
place, but the author should be able to choose where that is.


Duncan Murdoch

P.S.  I've been playing around with Georgi Boshnakov's Rdpack package, 
putting together an RStudio plug-in to make usage updates trivial.  If 
anyone wants to try it out it's on my Github page for now 
(dmurdoch/Rdpack), but once it's usable, Georgi has said he will merge 
it back into his.


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

Re: [Rd] Best practices in developing package: From a single file

[Michael Lawrence]

On Thu, Feb 1, 2018 at 9:20 AM, Gabriel Becker  wrote:

> On Thu, Feb 1, 2018 at 5:24 AM, Lionel Henry  wrote:
>
> > On 31 janv. 2018, at 09:08, Gabriel Becker  wrote:
> >
> > > it *actively discourages* the bits it doesn't directly support.
> >
> > It may be discouraging to include Rd syntax in roxygen docs but only
> > because the LaTeX-like syntax of Rd is burdensome, not because of
> > roxygen. It is still handy to have inlined Rd as a backup and we do
> > use it for the cases where we need finer grained control.
> >
>
> I only somewhat agree with this. Part of it is the Rd specifically, I
> agree, but part of it is just the fact that it is a different syntax at
> all. People who write roxygen documentation tend to think about and write
> it in roxygen, I think. Any switch out to another syntax, thus introducing
> two syntaxes side-by-side, is discouraged by the very fact that they are
> thinking in roxygen comments.
>
> Again, this is a "discouragement", not a disallowing. I know that people
> who care deeply about writing absolutely top notch documentation, and who
> also use roxygen will do the switch when called for, but the path of least
> resistance, i.e. the pattern of behavior that is *encouraged* by roxygen2
> is to not do that, and simply write documentation using only the supported
> roxygen2 tags. I'm not saying this makes the system bad, per se. As I
> pointed out, I use it in many of my packages (and it was my choice to do
> so, not because I inherited code from someone who already did), but
> pretending it doesn't encourage certain types of behavior doesn't seem like
> the right way to go either.
>
>
> >
> > I agree with your sentiment that roxygen encourages writing of
> > documentation for time-constrained users.
> >
>
> I do think it does that, but that was really only half of what I said, I
> said it encourages time constrained users to write middling (i.e. not
> great) documentation. Another person pointed out that structurally it
> really encourages terseness in the explanations of parameters, which I
> think is very true and have heard independently from others when talking
> about it as well. This is again not a requirement, but it is a real thing.
>
>
> >
> > I'll add that the major problem of documentation is not fancy
> > formatting but the content getting out of sync with the codebase.
> > Having documentation sitting next to the code is the preferred
> > antidote to doc rot, e.g. docstrings in lisp languages, Julia and
> > Python, the Linux kernel-doc system, doxygen, javadoc, ...
> >
>
> I mean, it is *an *antidote to doc rot. And sure, one that is used
> elsewhere. You could easily imagine one that didn't require it though.
> Perhaps doc files associated with objects (including closures) could embed
> a hash of the object they document, then you could see which things have
> changed since the documentation was updated and look at which documentation
> is still ok and which needs updating. That's just off the top of my head,
> I'm sure you could make the detection much more sophisticated.
>
> Or perhaps you could imagine two help systems, akin to --help and man for
> command line tools, one of which is minimalist showing usage, etc,
> generated by roxygen comments, and one of which is much more extensive, and
> not tied to (what could be extremely large) comments in the same .R file as
> the code.
>
>
This is basically what I meant by the template-based approach. Have the
details in the template, and the vitals in the doc comment block. Combine
the two and view the docs in different ways, dynamically.


> Best,
> ~G
>
>
> > It is true that R CMD check extensive checks help a lot as well in
> > this regard though only for things that can be checked automatically.
> >
> > Best,
> > Lionel
> >
> >
>
>
> --
> Gabriel Becker, PhD
> Scientist (Bioinformatics)
> Genentech Research
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[Rd] R-gui sessions end when executing C-code

[Jesper Hybel Pedersen]

Hi

I'm trying to develop some C code to find the fixpoint of a contraction 
mapping, the code compiles and gives the right results when executed in R.
However R-gui session is frequently terminated. I'm suspecting some access 
violation error due to the exception code 0xc005
In the error report windows 10 gives me.

It is the first time I'm writing any C-code so I'm guessing I have done 
something really stupid. I have been trying to debug the code for a couple of 
days now,
But I simply can't figure out what generates the problem. Could it be something 
particular to my windows set up and security stuff?


I'm in the process of reading Writing R Extensions and Hadley Wickham's 
Advanced R but might have missed something.

The windows error report:

Faulting application name: Rgui.exe, version: 3.33.6774.0, time stamp: 
0x58bd6d26
Faulting module name: R.dll, version: 3.33.6774.0, time stamp: 0x58bd6d0b
Exception code: 0xc005
Fault offset: 0x0010b273
Faulting process id: 0x1d14
Faulting application start time: 0x01d39aede45c96e9
Faulting application path: C:\Program Files\R\R-3.3.3\bin\x64\Rgui.exe
Faulting module path: C:\Program Files\R\R-3.3.3\bin\x64\R.dll
Report Id: c78d7c52-72c5-40f3-a3cc-927323d2af07
Faulting package full name:
Faulting package-relative application ID:


### How I call the C-function in R

dyn.load("C://users//jeshyb//desktop//myC//lce_fixpoint_cc.dll")


N = 10
H = 3
v <- rnorm(N*H)
mu <- 0.1
psi <- matrix(c(1,0,0.5,0.5,0,1),nrow=2)
K <- dim(psi)[1]
p <- rep(1/H,N*H)
error <- 1e-10


f<-function(p,v,mu,psi,N,H,K)
   {
  
.Call("lce_fixpoint_cc",p, v,  mu,  psi,  as.integer(N), as.integer(H),  
as.integer(K),error)
   }


for (i in 1:100)
   {
  v <- rnorm(N*H)
  p <- rep(1/H,N*H)
  a<-f(p,v,mu,psi,N,H,K)
   }


a<-f(p,v,mu,psi,N,H,K)
plot(a)



 The C- function



#include 
#include 


SEXP lce_fixpoint_cc(SEXP q, SEXP v, SEXP mu, SEXP psi, SEXP N,SEXP H, SEXP K, 
SEXP err)
{

   int n_prot = 0;
   /* Make ready integer and double constants */
   PROTECT(N); n_prot++;
   PROTECT(H); n_prot++;
   PROTECT(K); n_prot++;
   int N_c = asInteger(N);
   int H_c = asInteger(H);
   int K_c = asInteger(K);

   double mu_c = asReal(mu);
   double mu2_c = 1.0 - mu_c;
   double error_c = asReal(err);
   double lowest_double = 1e-15;
   double tmp_c;
   double denom;
   double error_temp;
   double error_i_c;


   /* Make ready vector froms input */
   PROTECT(q); n_prot++;
   PROTECT(v); n_prot++;
   PROTECT(psi); n_prot++;
   double *v_c; v_c = REAL(v);
   double *psi_c; psi_c = REAL(psi);

   /* Initialize new vectors not given as input */
   SEXP q_copy = PROTECT(duplicate(q)); n_prot++;
   double *q_c; q_c = REAL(q_copy);

   SEXP q_new = 
PROTECT(allocVector(REALSXP,length(q))); n_prot++;
   double *q_new_c; q_new_c = REAL(q_new);

   SEXP eta = PROTECT(allocVector(REALSXP,H_c)); 
n_prot++;
   double *eta_c; eta_c = REAL(eta);

   SEXP exp_eta = PROTECT(allocVector(REALSXP,H_c)); 
n_prot++;
   double *exp_eta_c; exp_eta_c = REAL(exp_eta);

   SEXP psi_ln_psiq = 
PROTECT(allocVector(REALSXP,H_c)); n_prot++;
   double *psi_ln_psiq_c; psi_ln_psiq_c = 
REAL(psi_ln_psiq);

   int not_converged;
   int maxIter = 1;
   int iter;
   int start_c;

   /* loop indeces */
   int i;
   int j;
   int k;

   /* loop over observational units to find choice 
probabilities for i=1,...,N */
   for (i=0;ierror_i_c)

{

Re: [Rd] R-gui sessions end when executing C-code

[William Dunlap via R-devel]

   SEXP eta = PROTECT(allocVector(REALSXP,H_c)); n_prot++;
   double *eta_c; eta_c = REAL(eta);
   for (i=0;i wrote:

> Hi
>
> I'm trying to develop some C code to find the fixpoint of a contraction
> mapping, the code compiles and gives the right results when executed in R.
> However R-gui session is frequently terminated. I'm suspecting some access
> violation error due to the exception code 0xc005
> In the error report windows 10 gives me.
>
> It is the first time I'm writing any C-code so I'm guessing I have done
> something really stupid. I have been trying to debug the code for a couple
> of days now,
> But I simply can't figure out what generates the problem. Could it be
> something particular to my windows set up and security stuff?
>
>
> I'm in the process of reading Writing R Extensions and Hadley Wickham's
> Advanced R but might have missed something.
>
> The windows error report:
>
> Faulting application name: Rgui.exe, version: 3.33.6774.0, time stamp:
> 0x58bd6d26
> Faulting module name: R.dll, version: 3.33.6774.0, time stamp: 0x58bd6d0b
> Exception code: 0xc005
> Fault offset: 0x0010b273
> Faulting process id: 0x1d14
> Faulting application start time: 0x01d39aede45c96e9
> Faulting application path: C:\Program Files\R\R-3.3.3\bin\x64\Rgui.exe
> Faulting module path: C:\Program Files\R\R-3.3.3\bin\x64\R.dll
> Report Id: c78d7c52-72c5-40f3-a3cc-927323d2af07
> Faulting package full name:
> Faulting package-relative application ID:
>
>
> ### How I call the C-function in R
>
> dyn.load("C://users//jeshyb//desktop//myC//lce_fixpoint_cc.dll")
>
>
> N = 10
> H = 3
> v <- rnorm(N*H)
> mu <- 0.1
> psi <- matrix(c(1,0,0.5,0.5,0,1),nrow=2)
> K <- dim(psi)[1]
> p <- rep(1/H,N*H)
> error <- 1e-10
>
>
> f<-function(p,v,mu,psi,N,H,K)
>{
>
> .Call("lce_fixpoint_cc",p, v,  mu,  psi,  as.integer(N), as.integer(H),
> as.integer(K),error)
>}
>
>
> for (i in 1:100)
>{
>   v <- rnorm(N*H)
>   p <- rep(1/H,N*H)
>
> a<-f(p,v,mu,psi,N,H,K)
>}
>
>
> a<-f(p,v,mu,psi,N,H,K)
> plot(a)
>
>
>
>  The C- function
>
>
>
> #include 
> #include 
>
>
> SEXP lce_fixpoint_cc(SEXP q, SEXP v, SEXP mu, SEXP psi, SEXP N,SEXP H,
> SEXP K, SEXP err)
> {
>
>int n_prot = 0;
>/* Make ready integer and double constants */
>PROTECT(N); n_prot++;
>PROTECT(H); n_prot++;
>PROTECT(K); n_prot++;
>int N_c = asInteger(N);
>int H_c = asInteger(H);
>int K_c = asInteger(K);
>
>double mu_c = asReal(mu);
>double mu2_c = 1.0 - mu_c;
>double error_c = asReal(err);
>double lowest_double = 1e-15;
>double tmp_c;
>double denom;
>double error_temp;
>double error_i_c;
>
>
>/* Make ready vector froms input */
>PROTECT(q); n_prot++;
>PROTECT(v); n_prot++;
>PROTECT(psi); n_prot++;
>double *v_c; v_c = REAL(v);
>double *psi_c; psi_c = REAL(psi);
>
>/* Initialize new vectors not given as input */
>SEXP q_copy = PROTECT(duplicate(q)); n_prot++;
>double *q_c; q_c = REAL(q_copy);
>
>SEXP q_new = 
> PROTECT(allocVector(REALSXP,length(q)));
> n_prot++;
>double *q_new_c; q_new_c = REAL(q_new);
>
>SEXP eta = PROTECT(allocVector(REALSXP,H_c));
> n_prot++;
>double *eta_c; eta_c = REAL(eta);
>
>SEXP exp_eta = PROTECT(allocVector(REALSXP,H_c));
> n_prot++;
>double *exp_eta_c; exp_eta_c = REAL(exp_eta);
>
>SEXP psi_ln_psiq =
> PROTECT(allocVector(REALSXP,H_c)); n_prot++;
>double *psi_ln_psiq_c; psi_ln_psiq_c =
> REAL(psi_ln_psiq);
>
>int not_converged;
>int maxIter = 1;
>int iter;
>int start_c;
>
>/* loop indeces */
>int i;
>int j;
>int k;
>
>/* loop over observational units to find choice
> probabilities for i=1,...,N */
>for (i=0;i  

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

Yes, indeed Gitlab GUI Core Code is Open Source (Libre / Community
Edition): https://gitlab.com/gitlab-org/gitlab-ce

> But his instructions required command-line git, and my main claim is that 
> Github is not good enough to do the kinds of things I want to do and R Core 
> would need to do.
>
> My other claim is that git is too hard to use.

I'm sure that Git Command Line Recipe Documentation can solve this
issue, Gitlab, in particular, has a wiki in which this kind of issues
could be documented. Also Git cheat-sheets might prove useful. In
addition, any feature request could be done in Gitlab Issue Section
(See above), or if that does not still does not convince, other
options could be considered, such as Bitbucket
(https://bitbucket.org/), etc.

In addition, the Git Repository:
* Could be self-hosted in the University Servers (Just as SVN actually
is nowadays).
* Be accessed either by the Command Line or the Graphical User
Interface (As users prefer).

The main reason motivating the move to the GIT Repository, as said
before, is that it would to allow individual users or companies from
the R Consortium to do pull requests based on issues for improving
base R code.

Indeed, in some years from now I would like to help to improve base R
myself, maybe re-writing some parts of the code in C++, fixing bugs,
or who knows :)

Kind regards,
Juan Telleria

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

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

> So I created a branch within my fork, and committed the change there. But 
> Github provides no way to create a pull request that only includes the new 
> stuff!
> Every attempt I made would have included everything from both bug fixes.

I have been doing some tests, and I think that this issue can be
easily addressed with Bitbucket GUI (https://bitbucket.org/product),
which is free for Open Source Projects
(https://www.atlassian.com/software/views/open-source-license-request)
and seems easy to use (So it follows the K.I.S.S. principle).

Just another alternative instead of Gitlab for self-hosting... no worries.

Best,
Juan

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