Re: [R-pkg-devel] flang-new-18 complains: incompatiple object shapes

[Göran Broström]

Thanks for the reply, Ivan. I think that 'problem solved': I just 
received a message from Uwe saying that the rejection was a mistake.


Best, Göran

Den 2024-09-20 kl. 14:07, skrev Ivan Krylov:

В Fri, 20 Sep 2024 13:44:44 +0200
Göran Broström  пишет:


It is of course easy (but tedious) to cut the Gordian knot by
explicitly writing out the loops that defines 'daxpy', but is it
necessary?


Definitely not. I think that flang will be satisfied if you provide an
explicit interface for DAXPY. Do you need help testing your code with
this compiler?



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

[R-pkg-devel] flang-new-18 complains: incompatiple object shapes

[Göran Broström]

More specifically: I submitted a new version of eha to CRAN, but:
"... does not pass the incoming checks automatically,..."

I found warnings in

https://win-builder.r-project.org/incoming_pretest/eha_2.11.5_20240919_123016/Debian/00install.out
-
/getsums.f:65:16: warning: Reference to the procedure 'daxpy' has an 
implicit interface that is distinct from another reference: incompatible 
dummy argument #5: incompatible dummy data object shapes

 call daxpy(j2, tmp2, zma, 1, szz(index), 1)
 ^^^
./getsums.f:51:10: previous reference to 'daxpy'
   call daxpy(k, epy, zma, 1, sz, 1)
   ^

The arguments 'szz(index)' and 'sz' are compared and found to be 
'incompatible'. szz and sz are both double vectors, szz is the upper 
triangle of a symmetric covariance matrix, stored as a vector of length 
n * (n + 1) / 2 (space saving, this is F77 code written some 40 years ago).


This is the point of view of a compiler called 'flang-new-18' (Debian). 
However, gfortran and myself disagree, and I am interested in hearing a 
suggestion of what measures I should take.


It is of course easy (but tedious) to cut the Gordian knot by explicitly 
writing out the loops that defines 'daxpy', but is it necessary?


Thanks, Göran

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

[R-pkg-devel] NOTE or Information?

[Göran Broström]

A thirty-year-old format error in the C code of my package eha was 
finally detected by the latest R-devel, thanks to CRAN for that!


However, I also get a message never seen before, when I check the package:

---
Attaching package: ‘rlang’

The following object is masked from ‘package:base’:

%||%
---

I guess that this is a result of my use of devtools and roxygen for 
writing documentation. Is this a bug in rlang and the mask part of the 
message will go away when it is fixed?


Thanks, Göran

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

Re: [R-pkg-devel] Package broke with R 4.3.0

[Göran Broström]

Den 2023-06-27 kl. 17:17, skrev Göran Broström:

If(zoom %in% c(“alaska”,  “hawaii”)…


Wrong, maybe

if (("alaska" %in% zoom) || ("hawaii" %in% zoom)){}




Göran


27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:

It appears that my R package choroplethr broke due to this change in R
4.3.0:

CHANGES IN R 4.3.0:

SIGNIFICANT USER-VISIBLE CHANGES:

Calling && or || with LHS or (if evaluated) RHS of length greater than one
is now always an error, with a report of the form

'length = 4' in coercion to 'logical(1)'
Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.

The specific line which broke is this:
https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24

The bug can be reproduced like this:

zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
  "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
  "tennessee", "virginia", "california", "delaware", "west virginia",
  "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
  "kansas", "maryland", "colorado", "new jersey", "north carolina",
  "south carolina", "washington", "vermont", "utah", "iowa",
"kentucky",
  "maine", "massachusetts", "connecticut", "michigan", "missouri",
  "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
  "rhode island", "south dakota", "district of columbia", "texas",
  "georgia", "hawaii", "illinois", "indiana")

if (zoom == "alaska" || zoom == "hawaii") {}
Error in zoom == "alaska" || zoom == "hawaii" :
  'length = 51' in coercion to 'logical(1)'

I have two questions:

1. Can someone explain why this change was introduced to the language?
2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
code?

I came up with two solutions that work. The first checks whether zoom is of
length 1:

if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }

The second keeps the vector recycling, but then uses all to coerce the
vector to be a single value. In retrospect, I think I likely assumed that
this is what R < 4.3.0 was doing when the code worked. (But I wrote this
code many years ago, so I can't be sure!):

if (all(zoom == "alaska") || all(zoom == "hawaii")) {}

Thanks in advance.

Ari

[[alternative HTML version deleted]]

__
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] Package broke with R 4.3.0

[Göran Broström]

If(zoom %in% c(“alaska”,  “hawaii”)…

Göran

> 27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:
> 
> It appears that my R package choroplethr broke due to this change in R
> 4.3.0:
> 
> CHANGES IN R 4.3.0:
> 
> SIGNIFICANT USER-VISIBLE CHANGES:
> 
> Calling && or || with LHS or (if evaluated) RHS of length greater than one
> is now always an error, with a report of the form
> 
> 'length = 4' in coercion to 'logical(1)'
> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
> 
> The specific line which broke is this:
> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
> 
> The bug can be reproduced like this:
> 
> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
>  "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
>  "tennessee", "virginia", "california", "delaware", "west virginia",
>  "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
>  "kansas", "maryland", "colorado", "new jersey", "north carolina",
>  "south carolina", "washington", "vermont", "utah", "iowa",
> "kentucky",
>  "maine", "massachusetts", "connecticut", "michigan", "missouri",
>  "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
>  "rhode island", "south dakota", "district of columbia", "texas",
>  "georgia", "hawaii", "illinois", "indiana")
> 
> if (zoom == "alaska" || zoom == "hawaii") {}
> Error in zoom == "alaska" || zoom == "hawaii" :
>  'length = 51' in coercion to 'logical(1)'
> 
> I have two questions:
> 
> 1. Can someone explain why this change was introduced to the language?
> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
> code?
> 
> I came up with two solutions that work. The first checks whether zoom is of
> length 1:
> 
> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }
> 
> The second keeps the vector recycling, but then uses all to coerce the
> vector to be a single value. In retrospect, I think I likely assumed that
> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
> code many years ago, so I can't be sure!):
> 
> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
> 
> Thanks in advance.
> 
> Ari
> 
>[[alternative HTML version deleted]]
> 
> __
> 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] katex

[Göran Broström]

On 2023-04-25 10:02, Ivan Krylov wrote:

On Mon, 24 Apr 2023 18:17:22 +0200
Göran Broström  wrote:


cannot open file '/usr/lib/R/doc/html/katex/katex.js': No such
file or directory



I still get the error with R CMD check --as-cran. What am I
missing? Obviously /usr/lib/R/doc/html/katex/katex.js (no 'doc'), but
...

I am installing R via apt.


Thank you for mentioning this detail!

At least in Debian packages, R's copy of KaTeX lives in /usr/share: per
Debian policy, "share" is for human-readable files like KaTeX, and
"lib" is for shared libraries, compiled code and the like.

For a copy of R built from source, it's not a problem:


Thanks. I have now built R from source and can confirm that everything 
works nicely. Can't remember when and why I stopped building R from 
source, probably not a good idea.


Göran

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

[R-pkg-devel] katex

[Göran Broström]

I upgraded to 4.3.0 and rebuilt and checked a package with --as-cran, 
receiving


* checking PDF version of manual ... OK
* checking HTML version of manual ...Warning in file(con, "r") :
  cannot open file '/usr/lib/R/doc/html/katex/katex.js': No such file 
or directory

Error in file(con, "r") : cannot open the connection
Execution halted

Never heard of 'katex' but googled and found it interesting to try, so I 
installed the R package katex and, on my ubuntu system:


$ sudo apt install katex

but I still get the error with R CMD check --as-cran. What am I missing?
Obviously /usr/lib/R/doc/html/katex/katex.js (no 'doc'), but ...

I am installing R via apt.

Thanks, Göran

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

Re: [R-pkg-devel] Invalid UTF-8

[Göran Broström]

On 2022-10-18 21:53, peter dalgaard wrote:




On 18 Oct 2022, at 16:37 , Dirk Eddelbuettel 
wrote:


On 17 October 2022 at 13:20, Göran Broström wrote:

| G;ran (US keyboard)

:)

A fortunes candidate?



Incidentally, he's Gæran on a DK keyboard but Gøran on an NO one. The
three Scandinavian languages have the same three extra letters (æøå),
but Swedish writes the former two with diaeresis (like German),
reverses their order in the alphabet (åöä), 


Actually, the order is åäö (Swedish). Didn't know about the different
Scandinavian alphabetical orderings, thanks for the info!

g,


and switches ö and ä on
the keyboard (compared to Danish, that is). Norwegian writes and
sorts like Danish, but has the same key reversion as Swedish.
"Brotherly love"...

-pd



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

Re: [R-pkg-devel] Invalid UTF-8

[Göran Broström]

Thanks Ivan,

I found two simple ways to convert this old file to UTF-8:

(i) In emacs, C-x  f  (default is utf-8)

(ii) In RStudio, set Tools-Global Options-Code-Saving-
Default text encoding  to UTF-8

No problem with new files.

G;ran (US keyboard)

Den 2022-10-17 kl. 11:18, skrev Ivan Krylov:

В Mon, 17 Oct 2022 11:07:25 +0200
Göran Broström  пишет:


warning: invalid UTF-8 in comment [-Winvalid-utf8]
(It's my name)

So I wonder: How do I make valid UTF-8 in comment?


The file GB_zeroin.c is saved in Latin-1 encoding. The warning should
go away once you convert it to UTF-8.



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

[R-pkg-devel] Invalid UTF-8

[Göran Broström]

Hello,

I suddenly get Warnings from  CRAN (clang):

warning: invalid UTF-8 in comment [-Winvalid-utf8]
(It's my name)

So I wonder: How do I make valid UTF-8 in comment?
(I already have "Encoding: UTF-8" in the DESCRIPTION file)

Thanks, Göran

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

Re: [R-pkg-devel] Using the amsmath package in a vignette.

[Göran Broström]

Hi Rolf,

On 2021-03-04 03:51, Rolf Turner wrote:


I am trying to create a vignette in a package (basically just using 
LaTeX code; no R calculations or data are involved).


The LaTeX code involves the use of the align* environment from the
amsmath package.  When I try to run Sweave() on the *.Rnw file I get
a corresponding *.tex file, but then when I run pdflatex on that file
I get an error:


! LaTeX Error: Command \iint already defined. Or name \end...
illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation. Type  H
  for immediate help. ...

l.649 ...d{\iint}{\DOTSI\protect\MultiIntegral{2}}


which is completely opaque to me.


Shouldn't be; the amsmath package defines \iint, and the error message 
says that it was already defined, probably in another package you have 
loaded. Easily found by googling. My first hit was


https://tex.stackexchange.com/questions/356599/command-iint-already-defined

If I don't have \usepackage{amsmath} in the *.Rnw file, I get 
(unsurprisingly) an error message to the effect that the align* 
environment is undefined.


Is there any way to make use of amsmath facilities in a vignette?


Absolutely, I am doing it with no problem. I have in one preamble


\documentclass[a4paper,12pt]{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
% \VignetteIndexEntry{Parametric duration models}
\newcommand{\btheta}{{\ensuremath{\boldsymbol{\theta
\newcommand{\bbeta}{{\ensuremath{\boldsymbol{\beta
\newcommand{\bz}{\ensuremath{\mathbf{z}}}
and so forth



Alternatively, is there any way to simply use the pdf output
obtained by processing an ordinary LaTeX file as a vignette?  I have
done a bit of web searching on this, but all of the hits that I get
seem to be substantially out of date.  They refer to putting
vignettes in /inst/doc and I'm pretty sure that this is no longer how
it's done. (But I find all of the vignette business rather
bewildering and confusing.)

Grateful for any advice.


Have you read the "Writing R Extensions"? There 'inst/doc' is mentioned 
under 'Non-Sweave vignettes'.


Best, Göran Broström


cheers,

Rolf Turner



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

Re: [R-pkg-devel] Vignette fonts problem

[Göran Broström]

Update: I tried this on another machine with the same setup (I thought), 
and no problem with the R-devel check!


Must find those fonts ...

On CRAN soon!

Göran

On 2020-12-13 18:33, Göran Broström wrote:

I have built and checked eha_2.8.2 with R-4.0.3 and everything is OK.

However, checking with the current (2020-12-12) R-devel, I get:

--- re-building ‘tpchreg.Rmd’ using rmarkdown
Quitting from lines 103-108 (tpchreg.Rmd)
Error: processing vignette 'tpchreg.Rmd' failed with diagnostics:
X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 1 at size 12 
could not be loaded

--- failed re-building ‘tpchreg.Rmd’

In 'tpchreg.Rmd' I have:

---
title: "Proportional hazards regression with tabular data"
author: "Göran Broström"
package: eha
date: "`r Sys.Date()`"
slug: eha
link-citations: yes
output:
     bookdown::html_document2:
     toc: yes
     toc_depth: 2
pkgdown:
     as_is: true
bibliography: mybib.bib
vignette: >
   %\VignetteIndexEntry{Proportional hazards regression with tabular data}
   %\VignetteEngine{knitr::rmarkdown}
   %\VignetteEncoding{UTF-8}
   \usepackage[utf8]{inputenc}
---

and the lines 103-108 are:

```{r glmbasefig,  fig.cap = "Age-specific mortality, Sweden 1968-2019. 
Poisson regression."}

oldpar <- par(las = 1, lwd = 1.5, mfrow = c(1, 2))
plot(0:(n-1), haz, type = "s", main = "log(hazards)",
  xlab = "Age", ylab = "", log = "y")
plot(0:(n-1), haz, type = "s", main = "hazards",
  xlab = "Age", ylab = "Deaths / Year")
```

So, why do I get the fonts error now (and not earlier) and where can I 
find the fonts? (Ubuntu 20.04). And will it help, so the package is 
accepted by CRAN?


Thanks, Göran

__
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-pkg-devel] Vignette fonts problem

[Göran Broström]

I have built and checked eha_2.8.2 with R-4.0.3 and everything is OK.

However, checking with the current (2020-12-12) R-devel, I get:

--- re-building ‘tpchreg.Rmd’ using rmarkdown
Quitting from lines 103-108 (tpchreg.Rmd)
Error: processing vignette 'tpchreg.Rmd' failed with diagnostics:
X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 1 at size 12 
could not be loaded

--- failed re-building ‘tpchreg.Rmd’

In 'tpchreg.Rmd' I have:

---
title: "Proportional hazards regression with tabular data"
author: "Göran Broström"
package: eha
date: "`r Sys.Date()`"
slug: eha
link-citations: yes
output:
bookdown::html_document2:
toc: yes
toc_depth: 2
pkgdown:
as_is: true
bibliography: mybib.bib
vignette: >
  %\VignetteIndexEntry{Proportional hazards regression with tabular data}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
  \usepackage[utf8]{inputenc}
---

and the lines 103-108 are:

```{r glmbasefig,  fig.cap = "Age-specific mortality, Sweden 1968-2019. 
Poisson regression."}

oldpar <- par(las = 1, lwd = 1.5, mfrow = c(1, 2))
plot(0:(n-1), haz, type = "s", main = "log(hazards)",
 xlab = "Age", ylab = "", log = "y")
plot(0:(n-1), haz, type = "s", main = "hazards",
 xlab = "Age", ylab = "Deaths / Year")
```

So, why do I get the fonts error now (and not earlier) and where can I 
find the fonts? (Ubuntu 20.04). And will it help, so the package is 
accepted by CRAN?


Thanks, Göran

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

Re: [R-pkg-devel] import with except(ion)

[Göran Broström]

Just a final observation: This can happen to anybody

-
> lm(weight ~ feed, data = chickwts)

Call:
lm(formula = weight ~ feed, data = chickwts)

Coefficients:
  (Intercept)  feedhorsebeanfeedlinseed   feedmeatmeal 
feedsoybean  feedsunflower
  323.583   -163.383   -104.833-46.674 
-77.155  5.333


> lm(weight ~ frailty(feed), data = chickwts)
Error in frailty(feed) : could not find function "frailty"

> library(survival)
> lm(weight ~ frailty(feed), data = chickwts)

Call:
lm(formula = weight ~ frailty(feed), data = chickwts)

Coefficients:
  (Intercept)  frailty(feed)
  232.165  8.147
---

G,

On 2020-11-02 11:15, Göran Broström wrote:

Thanks!

Göran

On 2020-11-02 11:09, Sebastian Meyer wrote:

No need to reinvent the wheel. Göran, you already use the "specials"
feature of terms.formula to find strata():


specials: which functions in the formula should be marked as special in
   the 'terms' object?  A character vector or 'NULL'.


I think you can do the same for frailty(), for example:


formula <- Surv(time, status) ~ age + frailty(inst)

Terms <- terms(formula, specials = "frailty")
frailties <- attr(Terms, "specials")$frailty
if (length(frailties)) warning("frailty() is not supported by coxreg")



Best regards,

Sebastian


Am 31.10.20 um 14:30 schrieb Gabor Grothendieck:
coxreg could search for frailty and issue a warning or error if 
found.  This
returns TRUE if frailty is used in the formula argument as a function 
but

not otherwise.  That would allow implementation of a nicer message than
if it were just reported as a missing function.

find_frailty <- function(e) {
 if (is.logical(e)) return(e)
 if (length(e) > 1) {
 if (identical(e[[1]], as.name("frailty"))) return(TRUE)
 for (i in 1:length(e)) if (isTRUE(Recall(e[[i]]))) return(TRUE)
 }
 FALSE
}
find_frailty(frailty ~ frailty)
## [1] FALSE
fo <- Surv(time, status) ~ age + frailty(inst)
find_frailty(fo)
## [1] TRUE

On Fri, Oct 30, 2020 at 2:46 PM Göran Broström 
 wrote:


My CRAN package eha depends on the survival package, and that creates
problems with innocent users: It is about the 'frailty' function
(mainly). While (after 'library(eha)')

f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the 
use of

the coxreg function from eha

f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty
function essentially returns its input and coxreg is happy with that,
treats it as an ordinary numeric (or factor) covariate, and nonsense is
produced, but some users think otherwise. (Maybe it would be better to
introduce frailty in a separate argument?)

I want to prevent this to happen, but I do not understand how to do it
in the best way. I tried to move survival from Depends: to Imports: and
adding import(survival, except = c(frailty, cluster)) to NAMESPACE. 
This

had the side effect that a user must qualify the Surv function by
survival::Surv, not satisfactory (similarly for other popular functions
in survival).

Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these
issues. I have used Depends: survival for a long time and been happy
with that.

Any help on this is highly appreciated.

Göran

__
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


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

Re: [R-pkg-devel] import with except(ion)

[Göran Broström]

Thanks!

Göran

On 2020-11-02 11:09, Sebastian Meyer wrote:

No need to reinvent the wheel. Göran, you already use the "specials"
feature of terms.formula to find strata():


specials: which functions in the formula should be marked as special in
   the 'terms' object?  A character vector or 'NULL'.


I think you can do the same for frailty(), for example:


formula <- Surv(time, status) ~ age + frailty(inst)

Terms <- terms(formula, specials = "frailty")
frailties <- attr(Terms, "specials")$frailty
if (length(frailties)) warning("frailty() is not supported by coxreg")



Best regards,

Sebastian


Am 31.10.20 um 14:30 schrieb Gabor Grothendieck:

coxreg could search for frailty and issue a warning or error if found.  This
returns TRUE if frailty is used in the formula argument as a function but
not otherwise.  That would allow implementation of a nicer message than
if it were just reported as a missing function.

find_frailty <- function(e) {
 if (is.logical(e)) return(e)
 if (length(e) > 1) {
 if (identical(e[[1]], as.name("frailty"))) return(TRUE)
 for (i in 1:length(e)) if (isTRUE(Recall(e[[i]]))) return(TRUE)
 }
 FALSE
}
find_frailty(frailty ~ frailty)
## [1] FALSE
fo <- Surv(time, status) ~ age + frailty(inst)
find_frailty(fo)
## [1] TRUE

On Fri, Oct 30, 2020 at 2:46 PM Göran Broström  wrote:


My CRAN package eha depends on the survival package, and that creates
problems with innocent users: It is about the 'frailty' function
(mainly). While (after 'library(eha)')

f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the use of
the coxreg function from eha

f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty
function essentially returns its input and coxreg is happy with that,
treats it as an ordinary numeric (or factor) covariate, and nonsense is
produced, but some users think otherwise. (Maybe it would be better to
introduce frailty in a separate argument?)

I want to prevent this to happen, but I do not understand how to do it
in the best way. I tried to move survival from Depends: to Imports: and
adding import(survival, except = c(frailty, cluster)) to NAMESPACE. This
had the side effect that a user must qualify the Surv function by
survival::Surv, not satisfactory (similarly for other popular functions
in survival).

Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these
issues. I have used Depends: survival for a long time and been happy
with that.

Any help on this is highly appreciated.

Göran

__
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] import with except(ion)

[Göran Broström]

On 2020-10-31 14:30, Gabor Grothendieck wrote:

coxreg could search for frailty and issue a warning or error if found.  This
returns TRUE if frailty is used in the formula argument as a function but
not otherwise.  That would allow implementation of a nicer message than
if it were just reported as a missing function.

find_frailty <- function(e) {
 if (is.logical(e)) return(e)
 if (length(e) > 1) {
 if (identical(e[[1]], as.name("frailty"))) return(TRUE)
 for (i in 1:length(e)) if (isTRUE(Recall(e[[i]]))) return(TRUE)
 }
 FALSE
}
find_frailty(frailty ~ frailty)
## [1] FALSE
fo <- Surv(time, status) ~ age + frailty(inst)
find_frailty(fo)
## [1] TRUE


Thanks Gabor, I thought of checking for the use of the three coxph 
specials frailty, cluster, and tt in my functions coxreg, phreg, aftreg, 
tpchreg, gompreg, and weibreg. Your function would come in handy for this.


Göran



On Fri, Oct 30, 2020 at 2:46 PM Göran Broström  wrote:


My CRAN package eha depends on the survival package, and that creates
problems with innocent users: It is about the 'frailty' function
(mainly). While (after 'library(eha)')

f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the use of
the coxreg function from eha

f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty
function essentially returns its input and coxreg is happy with that,
treats it as an ordinary numeric (or factor) covariate, and nonsense is
produced, but some users think otherwise. (Maybe it would be better to
introduce frailty in a separate argument?)

I want to prevent this to happen, but I do not understand how to do it
in the best way. I tried to move survival from Depends: to Imports: and
adding import(survival, except = c(frailty, cluster)) to NAMESPACE. This
had the side effect that a user must qualify the Surv function by
survival::Surv, not satisfactory (similarly for other popular functions
in survival).

Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these
issues. I have used Depends: survival for a long time and been happy
with that.

Any help on this is highly appreciated.

Göran

__
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] import with except(ion)

[Göran Broström]

On 2020-10-31 13:49, Duncan Murdoch wrote:

On 30/10/2020 2:45 p.m., Göran Broström wrote:

My CRAN package eha depends on the survival package, and that creates
problems with innocent users: It is about the 'frailty' function
(mainly). While (after 'library(eha)')

f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the use of
the coxreg function from eha

f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty
function essentially returns its input and coxreg is happy with that,
treats it as an ordinary numeric (or factor) covariate, and nonsense is
produced, but some users think otherwise. (Maybe it would be better to
introduce frailty in a separate argument?)

I want to prevent this to happen, but I do not understand how to do it
in the best way. I tried to move survival from Depends: to Imports: and
adding import(survival, except = c(frailty, cluster)) to NAMESPACE. This
had the side effect that a user must qualify the Surv function by
survival::Surv, not satisfactory (similarly for other popular functions
in survival).

Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these
issues. I have used Depends: survival for a long time and been happy
with that.

Any help on this is highly appreciated.


I don't know if you received any private replies, but I don't see any 
public ones.


No replies so far.


It's not clear from your message what you would like to happen with 
expressions like


  f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

For example, would you like to generate an error, because you don't 
support frailty in this context?  Could you clarify that?


Yes, this should generate an error. I think I have solved this problem 
by using importFrom(survival, ...), where I replace ... with all the 
functions I want from survival (not including frailty, cluster, ...)

and then export some of them. For now I have in NAMESPACE

importFrom(survival,Surv)
importFrom(survival,attrassign)
importFrom(survival,coxph)
importFrom(survival,strata)
importFrom(survival,untangle.specials)
...
export(Surv)
export(strata)

I also have to write documentation for Surv and strata.

Is this reasonable?

Göran



Duncan Murdoch


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

Re: [R-pkg-devel] import with except(ion)

[Göran Broström]

On 2020-10-31 12:09, Göran Broström wrote:
I think I finally got it: I must involve the export business after 
importing, thus, in NAMESPACE:


importFrom(survival,Surv)
export(Surv)

That's all,


Not really:

* checking for missing documentation entries ... WARNING
Undocumented code objects:
  ‘Surv’ ‘coxph’ ‘strata’
All user-level objects in a package should have documentation entries.



G,

On 2020-10-30 19:45, Göran Broström wrote:
My CRAN package eha depends on the survival package, and that creates 
problems with innocent users: It is about the 'frailty' function 
(mainly). While (after 'library(eha)')


f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the use 
of the coxreg function from eha


f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty 
function essentially returns its input and coxreg is happy with that, 
treats it as an ordinary numeric (or factor) covariate, and nonsense 
is produced, but some users think otherwise. (Maybe it would be better 
to introduce frailty in a separate argument?)


I want to prevent this to happen, but I do not understand how to do it 
in the best way. I tried to move survival from Depends: to Imports: 
and adding import(survival, except = c(frailty, cluster)) to 
NAMESPACE. This had the side effect that a user must qualify the Surv 
function by survival::Surv, not satisfactory (similarly for other 
popular functions in survival).


Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these 
issues. I have used Depends: survival for a long time and been happy 
with that.


Any help on this is highly appreciated.

Göran

__
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] import with except(ion)

[Göran Broström]

I think I finally got it: I must involve the export business after 
importing, thus, in NAMESPACE:


importFrom(survival,Surv)
export(Surv)

That's all,

G,

On 2020-10-30 19:45, Göran Broström wrote:
My CRAN package eha depends on the survival package, and that creates 
problems with innocent users: It is about the 'frailty' function 
(mainly). While (after 'library(eha)')


f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the use of 
the coxreg function from eha


f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty 
function essentially returns its input and coxreg is happy with that, 
treats it as an ordinary numeric (or factor) covariate, and nonsense is 
produced, but some users think otherwise. (Maybe it would be better to 
introduce frailty in a separate argument?)


I want to prevent this to happen, but I do not understand how to do it 
in the best way. I tried to move survival from Depends: to Imports: and 
adding import(survival, except = c(frailty, cluster)) to NAMESPACE. This 
had the side effect that a user must qualify the Surv function by 
survival::Surv, not satisfactory (similarly for other popular functions 
in survival).


Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these 
issues. I have used Depends: survival for a long time and been happy 
with that.


Any help on this is highly appreciated.

Göran

__
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-pkg-devel] import with except(ion)

[Göran Broström]

My CRAN package eha depends on the survival package, and that creates 
problems with innocent users: It is about the 'frailty' function 
(mainly). While (after 'library(eha)')


f1 <- coxph(Surv(time, status) ~ age + frailty(inst), data = lung)

produces what you would expect (a frailty survival analysis), the use of 
the coxreg function from eha


f2 <- coxreg(Surv(time, status) ~ age + frailty(inst), data = lung)

produces (almost) nonsense. That's because the survival::frailty 
function essentially returns its input and coxreg is happy with that, 
treats it as an ordinary numeric (or factor) covariate, and nonsense is 
produced, but some users think otherwise. (Maybe it would be better to 
introduce frailty in a separate argument?)


I want to prevent this to happen, but I do not understand how to do it 
in the best way. I tried to move survival from Depends: to Imports: and 
adding import(survival, except = c(frailty, cluster)) to NAMESPACE. This 
had the side effect that a user must qualify the Surv function by 
survival::Surv, not satisfactory (similarly for other popular functions 
in survival).


Another option I thought of was to define my own Surv function as
Surv <- survival::Surv in my package, but it doesn't feel right.
It seems to work, though.

As you may understand from this, I am not very familiar with these 
issues. I have used Depends: survival for a long time and been happy 
with that.


Any help on this is highly appreciated.

Göran

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

Re: [R-pkg-devel] data and load version 3

[Göran Broström]

On 2020-06-30 11:58, Ivan Krylov wrote:

On Tue, 30 Jun 2020 11:48:29 +0200
Göran Broström  wrote:


No point at all with version 3 in packages?


Format version 3 [1] introduces support for ALTREP objects [2].
Examples of where ALTREP might be useful include really long integer
vectors, like 1:1e10.



Thanks, no need for that in the actual data files, so I'll convert them 
to version 2.


Göran

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

Re: [R-pkg-devel] data and load version 3

[Göran Broström]

On 2020-06-30 01:07, Jeff Newmiller wrote:

Your choice. Do you want to support people using older versions of R, or not?


Is that all? No point at all with version 3 in packages? Why was it 
introduced? I have seen an argument for version 2: "... needed ... to 
support name spaces", but version 3 ...


Göran



On June 29, 2020 1:55:02 PM PDT, "Göran Broström"  wrote:

I added two data sets (.rda) to my package eha, but when I build the
new
version I get:

WARNING: Added dependency on R >= 3.5.0 because serialized objects in
serialize/load version 3 cannot be read in older versions of R.
File(s)
containing such objects: ‘eha/data/swedeaths.rda’
‘eha/data/swepop.rda’

In DESCRIPTION I have 'Depends: R (>= 3.0.0)'

After googling for a while (found nothing relevant in 'WRE'), I
understand that I have two options: (i) Change 'Depends' in DESCRIPTION

as suggested, and (ii) using save with 'version = 2' for the new files.

And, if I am recommended to choose (i), should I recreate the old data
files with 'version = 3'?

My guess is go for (i) and version = 3 for all data files, but I feel
that I need advise.

Thanks, Göran

__
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-pkg-devel] data and load version 3

[Göran Broström]

I added two data sets (.rda) to my package eha, but when I build the new 
version I get:


 WARNING: Added dependency on R >= 3.5.0 because serialized objects in 
serialize/load version 3 cannot be read in older versions of R.  File(s) 
containing such objects: ‘eha/data/swedeaths.rda’  ‘eha/data/swepop.rda’


In DESCRIPTION I have 'Depends: R (>= 3.0.0)'

After googling for a while (found nothing relevant in 'WRE'), I 
understand that I have two options: (i) Change 'Depends' in DESCRIPTION 
as suggested, and (ii) using save with 'version = 2' for the new files.


And, if I am recommended to choose (i), should I recreate the old data 
files with 'version = 3'?


My guess is go for (i) and version = 3 for all data files, but I feel 
that I need advise.


Thanks, Göran

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

Re: [R-pkg-devel] Forward function call

[Göran Broström]

Thanks for the responses!

I found the suggestion

Call[[1]] <- quote(survival::coxph)

easiest to implement. And it works.

Best, Göran

On 2020-06-08 21:42, Ben Bolker wrote:

  I think quote(survival::coxph) will work in place of as.name() ?

On Mon, Jun 8, 2020 at 3:12 PM Göran Broström  wrote:


Hello,

the function 'coxreg' in my package 'eha' is often just a wrapper for
'coxph' in survival, so I have code like

  if (cox.ph){
  Call <- match.call()
  Call[[1]] <- as.name("coxph")
  fit <- eval.parent(Call)
  return(fit)
  }

which works since eha depends on survival. Now I am thinking of changing
Depends to Imports, and I would like to change the code to

  if (cox.ph){
  Call <- match.call()
  Call[[1]] <- as.name("survival::coxph")
  fit <- eval.parent(Call)
  return(fit)
  }

but this doesn't work, because the function name is turned into
`survival::coxph` (with the backticks) and the evaluation fails.

How can I solve this?

Thanks, G,

__
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-pkg-devel] Forward function call

[Göran Broström]

Hello,

the function 'coxreg' in my package 'eha' is often just a wrapper for 
'coxph' in survival, so I have code like


if (cox.ph){
Call <- match.call()
Call[[1]] <- as.name("coxph")
fit <- eval.parent(Call)
return(fit)
}

which works since eha depends on survival. Now I am thinking of changing 
Depends to Imports, and I would like to change the code to


if (cox.ph){
Call <- match.call()
Call[[1]] <- as.name("survival::coxph")
fit <- eval.parent(Call)
return(fit)
}

but this doesn't work, because the function name is turned into
`survival::coxph` (with the backticks) and the evaluation fails.

How can I solve this?

Thanks, G,

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

Re: [R-pkg-devel] pdflatex is not available

[Göran Broström]

On 2019-12-14 14:02, Sarah Goslee wrote:

It sounds like you're on a Mac? Then you need to install MacTeX,
http://www.tug.org/mactex/ to get pdflatex.


Or maybe tinytex will do? https://yihui.org/tinytex/

Göran



Sarah

On Fri, Dec 13, 2019 at 7:11 PM Cathy Lee Gierke  wrote:


Does anyone know why I might get this error?

Hmm ... looks like a package

Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :

   pdflatex is not available

Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :

*  pdflatex is not available*

*Error in running tools::texi2pdf()*

You may want to clean up by 'rm -Rf

/var/folders/0m/41bxx35j5x9f_tks7zrd7jh0gn/T//Rtmpuv00M5/Rd2pdf8f2a123193cb'

* checking for detritus in the temp directory ... OK

* DONE



There are no clues in the Rdlatex.log
I have attached the ...manual.tex file.  Is there a way to check it for
non-ascii or non-printing characters on a Mac?  I have had that problem
before, but I'm not finding any now.  Maybe I have the wrong command?


find /Users/user/CATkit/CATkit/man | perl -ne 'print if /[^[:ascii:]]/'

find /Users/user/CATkit/CATkit/man/CatCall.rd | perl -ne 'print if
/[^[:ascii:]]/'


Should there be a pdf file somewhere?

Thanks,
Cathy Lee Gierke



__
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] R, BLAS, and FCLEN (solved, really!)

[Göran Broström]

On 2019-09-13 12:34, Göran Broström wrote:

Dear Tomas,

your explanation matches exactly my expectation, but not my experience. 
I uploaded (to CRAN) version 2.7.5 yesterday, and there I use, in  the 
Fortran function gmlfun, directly called by .Fortran:


   call cdgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
  & score, ione)

that is, the C wrapper of dgemv (my home-brew)

No warnings from R-devel CMD check --as-cran, and when installed it runs 
fine.


However, if I change that call to

    call dgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
  & score, ione)

that is, a direct call to the Fortran subroutine dgemv, I get, from 
R-devel CMD check --as-cran,


gmlfun.f:224:1: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

   & score, ione)
  ^
/home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type 
mismatch in parameter 12

  F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
  ^


This error message was triggered by my mistake in the change from cdgemv 
to dgemv: I forgot to change 'trans' back from type INTEGER to 
CHARACTER. Our final conclusion (for now) is then:


Yes, you can call BLAS subroutines directly from Fortran code, even in 
packages! Many thanks to Tomas!


Excuse my confusion,

G,



and when I install and run, I get error:

 > library(eha)
Loading required package: survival
 > fit <- coxreg(Surv(enter, exit, event) ~ ses, data = mort, geometric 
= TRUE)

Error in geome.fit(X, Y, rs, strats, offset, init, max.survs, method,  :
   BLAS/LAPACK routine 'DGEMV ' gave error code -1
 >
 > sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04
...
Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
...
Other attached packages:
[1] eha_2.7.5.1000    survival_2.44-1.1
-

To summarize: The calls from C code are fixed and work fine. Direct call 
from fortran "level 1" gives error, from "level 2" is fine. "level 1" is 
fortran code directly called by .Fortran, "level 2" is fortran code 
called from fortran code called by .Fortran.


This was done with

R Under development (unstable) (2019-08-31 r77115). I could try a more 
recent version of R-devel.


About a 'small reproducible example': It is not that easy to shrink the 
eha package to include only the relevant fortran code, since there are 
subtle interdependencies in the package code. It would take a 
considerable amount of time (for me) to create that package.
I can make eha_2.7.5.tar.gz available, but it was sent in to CRAN 
yesterday.


Göran

On 2019-09-13 11:07, Tomas Kalibera wrote:

Dear Göran,

I can reproduce the problem with eha version 2.6.0. The reason for the 
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv 
from Fortran code, but the calls to dgemv from the C code from the 
other source files in your package. There is no need to go through 
wrappers when calling dgemv from Fortran (as long as both modules are 
compiled with the same compiler, or with compatible compilers).


When you fix all the calls to dgemv in your C source files to use 
"FCONE", as documented in WRE, the warning about the call to dgemv 
from geomsup.f will go away (yes, the warnings from the LTO 
linker/compiler are confusing). There is no need for creating any 
wrappers for BLAS/LAPACK calls.


One can check that the generated calls from the Fortran are correct 
e.g. via compiling with -fdump-tree-all and then dumping

$ egrep -e '(^;;)|(dgemv)' eha.so.ltrans0.232t.optimized | grep dgemv -B1
(the file name above will depend on the exact version of your compiler)

;; Function d2_loglik_ph (d2_loglik_ph, funcdef_no=77, decl_uid=4474, 
cgraph_uid=103, symbol_order=990)
   dgemv_ (&trans, mb_497(D), nn_499(D), &alf, z_502(D), mb_497(D), 
b_503(D), &one, &Rf_beta, ezb_501, &one);

--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87, 
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
   dgemv_ (&trans, mb_253(D), nn_255(D), &alf, z_258(D), mb_253(D), 
b_259(D), &one, &Rf_beta, ezb_257, &one);

--
;; Function gmlfun (gmlfun_, funcdef_no=98, decl_uid=4484, 
cgraph_uid=108, symbol_order=874)
   dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_68(D), antcov_63(D), &C.7966, 
covar_83(D), nn_68(D), beta_84(D), &C.7965, &C.7964, score_81(D), 
&C.7963, 1);

--
;; Function geomsup (geomsup_, funcdef_no=116, decl_uid=4498, 
cgraph_uid=117, symbol_order=823)
   dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_55(D), antcov_51(D), &C.9626, 
covar_89(D), nn_55(D), startbeta_83(D), &C.9625, &C.9624, score_87(D), 
&C.9623, 1);

--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph

Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)

[Göran Broström]

Dear Tomas,

your explanation matches exactly my expectation, but not my experience. 
I uploaded (to CRAN) version 2.7.5 yesterday, and there I use, in  the 
Fortran function gmlfun, directly called by .Fortran:


  call cdgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
 & score, ione)

that is, the C wrapper of dgemv (my home-brew)

No warnings from R-devel CMD check --as-cran, and when installed it runs 
fine.


However, if I change that call to

   call dgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
 & score, ione)

that is, a direct call to the Fortran subroutine dgemv, I get, from 
R-devel CMD check --as-cran,


gmlfun.f:224:1: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

  & score, ione)
 ^
/home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type 
mismatch in parameter 12

 F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 ^

and when I install and run, I get error:

> library(eha)
Loading required package: survival
> fit <- coxreg(Surv(enter, exit, event) ~ ses, data = mort, geometric 
= TRUE)

Error in geome.fit(X, Y, rs, strats, offset, init, max.survs, method,  :
  BLAS/LAPACK routine 'DGEMV ' gave error code -1
>
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04
...
Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
...
Other attached packages:
[1] eha_2.7.5.1000survival_2.44-1.1
-

To summarize: The calls from C code are fixed and work fine. Direct call 
from fortran "level 1" gives error, from "level 2" is fine. "level 1" is 
fortran code directly called by .Fortran, "level 2" is fortran code 
called from fortran code called by .Fortran.


This was done with

R Under development (unstable) (2019-08-31 r77115). I could try a more 
recent version of R-devel.


About a 'small reproducible example': It is not that easy to shrink the 
eha package to include only the relevant fortran code, since there are 
subtle interdependencies in the package code. It would take a 
considerable amount of time (for me) to create that package.

I can make eha_2.7.5.tar.gz available, but it was sent in to CRAN yesterday.

Göran

On 2019-09-13 11:07, Tomas Kalibera wrote:

Dear Göran,

I can reproduce the problem with eha version 2.6.0. The reason for the 
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv 
from Fortran code, but the calls to dgemv from the C code from the other 
source files in your package. There is no need to go through wrappers 
when calling dgemv from Fortran (as long as both modules are compiled 
with the same compiler, or with compatible compilers).


When you fix all the calls to dgemv in your C source files to use 
"FCONE", as documented in WRE, the warning about the call to dgemv from 
geomsup.f will go away (yes, the warnings from the LTO linker/compiler 
are confusing). There is no need for creating any wrappers for 
BLAS/LAPACK calls.


One can check that the generated calls from the Fortran are correct e.g. 
via compiling with -fdump-tree-all and then dumping

$ egrep -e '(^;;)|(dgemv)' eha.so.ltrans0.232t.optimized | grep dgemv -B1
(the file name above will depend on the exact version of your compiler)

;; Function d2_loglik_ph (d2_loglik_ph, funcdef_no=77, decl_uid=4474, 
cgraph_uid=103, symbol_order=990)
   dgemv_ (&trans, mb_497(D), nn_499(D), &alf, z_502(D), mb_497(D), 
b_503(D), &one, &Rf_beta, ezb_501, &one);

--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87, 
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
   dgemv_ (&trans, mb_253(D), nn_255(D), &alf, z_258(D), mb_253(D), 
b_259(D), &one, &Rf_beta, ezb_257, &one);

--
;; Function gmlfun (gmlfun_, funcdef_no=98, decl_uid=4484, 
cgraph_uid=108, symbol_order=874)
   dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_68(D), antcov_63(D), &C.7966, 
covar_83(D), nn_68(D), beta_84(D), &C.7965, &C.7964, score_81(D), 
&C.7963, 1);

--
;; Function geomsup (geomsup_, funcdef_no=116, decl_uid=4498, 
cgraph_uid=117, symbol_order=823)
   dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_55(D), antcov_51(D), &C.9626, 
covar_89(D), nn_55(D), startbeta_83(D), &C.9625, &C.9624, score_87(D), 
&C.9623, 1);

--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7, 
symbol_order=1772)
   dgemv_ (&trans, &nn, &p, &one, covar_281(D), &nn, beta_340(D), &ione, 
&one, score_230, &ione);


You can see that the calls to dgemv from gmlfun and geomsup are fine 
(from Fortran code), the other are bad (from C code).  Indeed, one would 
have found out also by creating a minimal reproducible example - it is 
always useful, even w

Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)

[Göran Broström]

On 2019-09-12 09:13, Martin Maechler wrote:

Göran Broström
 on Wed, 11 Sep 2019 13:36:40 +0200 writes:


 > A followup question: Is it possible to call a BLAS/LAPACK subroutine,
 > where one parameter is character, from FORTRAN (77) code called by
 > .Fortran? (No problem "in the past".)

[as there wasn't a reply till now : ]

Yes, that should continue to be possible.

 > And if yes, how?

I'm sorry I don't know (and currently lack the time to try to find out)...


I solved it by writing a C wrapper (for the BLAS subroutine dgemv) cdgemv:

#define USE_FC_LEN_T
#include 
#include 
#ifndef FCONE
# define FCONE
#endif
#include 
#include "cdgemv.h"

void F77_SUB(cdgemv)(const int *trans, const int *m, const int *n,
 const double *alpha, const double *a,
 const int *lda,
 const double *x, const int *incx,
 const double *beta,
 double *y, const int *incy){
   char trams;

   if (*trans == 1){
  trams = 'N';
  F77_CALL(dgemv)(&trams, m, n, alpha, a, lda, x, incx, beta, y,
  incy FCONE);
   }else
  Rprintf("trans has wrong value\n");
   }
}

which I call from Fortran. Curiously, a Fortran wrapper also seems to work.

G,


Martin

 >   Documentation describes calls from C to Fortran and
 > vice versa, but not this situation (AFAICS).

 > Yes, I know that .Fortran is not well seen these days, but my fortran
 > code is ancient, from the before-R era, and I would like to leave it 
as-is.

 > G,

 > Den 2019-09-01 kl. 21:46, skrev Göran Broström:
 >>
 >>
 >> On 2019-08-31 18:47, Göran Broström wrote:
 >>> I'm having difficulties updating my package eha: When I run standard
 >>> checks 'at home' everything is fine, but 'CRAN-submissions' reports
 >>> (among other things):
 >>>
 >>> geomsup.f:324:9: warning: type of ‘dgemv’ does not match original
 >>> declaration [-Wlto-type-mismatch]
 >>>    324 |  & one, score, ione)
 >>>    | ^
 >>> /home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch
 >>> in parameter 12
 >>>    107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 >>>    | ^
 >>>
 >>> This is odd since the LAPACK subroutine dgemv takes only 11
 >>> parameters. However, in include/R_ext/BLAS.h we have
 >>>
 >>> F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 >>>  const double *alpha, const double *a, const int *lda,
 >>>  const double *x, const int *incx, const double *beta,
 >>>  double *y, const int *incy FCLEN);
 >>>
 >>> with a 12th parameter FCLEN?? How am I supposed to fix this, and what
 >>> the ... is FCLEN? googling leads to nothing useful (for me). It seems
 >>> as if R is redefining some standard LAPACK routines.
 >>>
 >>> Also a note I do not understand (in this context):
 >>>
 >>> note: type ‘void’ should match type ‘long int’
 >>>
 >>> Any help is much appreciated.
 >>>
 >>> Best, Göran
 >>>
 >>> PS. How can I trigger these Warnings 'at home'?
 >>
 >> See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks to Uwe
 >> Ligges).
 >>
 >> Another relevant document seems to be (2019-05-15):
 >>
 >> 
https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html
 >>
 >>
 >> First sentence:
 >> "Recent version of the GNU Fortran compiler (7, 8, 9) include
 >> optimizations that break interoperability between C and Fortran code
 >> with BLAS/LAPACK."
 >>
 >> And later:
 >> "For the time being, everyone should use -fno-optimize-sibling-calls
 >> with GFortran version 7 and newer."
 >>
 >> G,
 >>
 >>> __
 >>> 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



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

Re: [R-pkg-devel] R, BLAS, and FCLEN

[Göran Broström]

A followup question: Is it possible to call a BLAS/LAPACK subroutine, 
where one parameter is character, from FORTRAN (77) code called by 
.Fortran? (No problem "in the past".)


And if yes, how?  Documentation describes calls from C to Fortran and 
vice versa, but not this situation (AFAICS).


Yes, I know that .Fortran is not well seen these days, but my fortran 
code is ancient, from the before-R era, and I would like to leave it as-is.


G,

Den 2019-09-01 kl. 21:46, skrev Göran Broström:



On 2019-08-31 18:47, Göran Broström wrote:
I'm having difficulties updating my package eha: When I run standard 
checks 'at home' everything is fine, but 'CRAN-submissions' reports 
(among other things):


geomsup.f:324:9: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

   324 |  & one, score, ione)
   | ^
/home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch 
in parameter 12

   107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
   | ^

This is odd since the LAPACK subroutine dgemv takes only 11 
parameters. However, in include/R_ext/BLAS.h we have


F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 const double *alpha, const double *a, const int *lda,
 const double *x, const int *incx, const double *beta,
 double *y, const int *incy FCLEN);

with a 12th parameter FCLEN?? How am I supposed to fix this, and what 
the ... is FCLEN? googling leads to nothing useful (for me). It seems 
as if R is redefining some standard LAPACK routines.


Also a note I do not understand (in this context):

note: type ‘void’ should match type ‘long int’

Any help is much appreciated.

Best, Göran

PS. How can I trigger these Warnings 'at home'?


See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks to Uwe 
Ligges).


Another relevant document seems to be (2019-05-15):

https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html 



First sentence:
"Recent version of the GNU Fortran compiler (7, 8, 9) include 
optimizations that break interoperability between C and Fortran code 
with BLAS/LAPACK."


And later:
"For the time being, everyone should use -fno-optimize-sibling-calls 
with GFortran version 7 and newer."


G,


__
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] R, BLAS, and FCLEN

[Göran Broström]

On 2019-08-31 18:47, Göran Broström wrote:
I'm having difficulties updating my package eha: When I run standard 
checks 'at home' everything is fine, but 'CRAN-submissions' reports 
(among other things):


geomsup.f:324:9: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

   324 |  & one, score, ione)
   | ^
/home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch in 
parameter 12

   107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
   | ^

This is odd since the LAPACK subroutine dgemv takes only 11 parameters. 
However, in include/R_ext/BLAS.h we have


F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
     const double *alpha, const double *a, const int *lda,
     const double *x, const int *incx, const double *beta,
     double *y, const int *incy FCLEN);

with a 12th parameter FCLEN?? How am I supposed to fix this, and what 
the ... is FCLEN? googling leads to nothing useful (for me). It seems as 
if R is redefining some standard LAPACK routines.


Also a note I do not understand (in this context):

note: type ‘void’ should match type ‘long int’

Any help is much appreciated.

Best, Göran

PS. How can I trigger these Warnings 'at home'?


See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks to Uwe 
Ligges).


Another relevant document seems to be (2019-05-15):

https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html

First sentence:
"Recent version of the GNU Fortran compiler (7, 8, 9) include 
optimizations that break interoperability between C and Fortran code 
with BLAS/LAPACK."


And later:
"For the time being, everyone should use -fno-optimize-sibling-calls 
with GFortran version 7 and newer."


G,


__
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] R, BLAS, and FCLEN

[Göran Broström]

On 2019-08-31 21:26, Duncan Murdoch wrote:

On 31/08/2019 12:47 p.m., Göran Broström wrote:

I'm having difficulties updating my package eha: When I run standard
checks 'at home' everything is fine, but 'CRAN-submissions' reports
(among other things):

geomsup.f:324:9: warning: type of ‘dgemv’ does not match original
declaration [-Wlto-type-mismatch]
    324 |  & one, score, ione)
    | ^
/home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch in
parameter 12
    107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
    | ^

This is odd since the LAPACK subroutine dgemv takes only 11 parameters.
However, in include/R_ext/BLAS.h we have

F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
    const double *alpha, const double *a, const int *lda,
    const double *x, const int *incx, const double *beta,
    double *y, const int *incy FCLEN);

with a 12th parameter FCLEN?? How am I supposed to fix this, and what
the ... is FCLEN? googling leads to nothing useful (for me). It seems as
if R is redefining some standard LAPACK routines.

Also a note I do not understand (in this context):

note: type ‘void’ should match type ‘long int’

Any help is much appreciated.



Sounds likely to be related to this item from R-devel NEWS:

http://developer.r-project.org/blosxom.cgi/R-devel/2019/08/29#n2019-08-29

"   Header ‘Rconfig.h’ contains the value of ‘FC_LEN_T’ deduced at 
installation which is used by the prototypes in headers ‘R_ext/BLAS.h’ 
and ‘R_ext/Lapack.h’ but to avoid extensive breakage this is only 
exposed when ‘USE_FC_LEN_T’ is defined.


     If a package's C/C++ calls to BLAS/LAPACK allow for the ‘hidden’ 
arguments used by most Fortran compilers to pass the lengths of Fortran 
character arguments, define ‘USE_FC_LEN_T’ and include ‘Rconfig.h’ 
(possibly _via_ ‘R.h’) before including ‘R_ext/BLAS.h’ or 
‘R_ext/Lapack.h’."


Thanks Duncan,

but my call to dgemv is from a FORTRAN subroutine, no C is involved. It 
is called by .Fortran in R code. I am confused (not for the first time).


Göran



Duncan Murdoch


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

[R-pkg-devel] R, BLAS, and FCLEN

[Göran Broström]

I'm having difficulties updating my package eha: When I run standard 
checks 'at home' everything is fine, but 'CRAN-submissions' reports 
(among other things):


geomsup.f:324:9: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

  324 |  & one, score, ione)
  | ^
/home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch in 
parameter 12

  107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
  | ^

This is odd since the LAPACK subroutine dgemv takes only 11 parameters. 
However, in include/R_ext/BLAS.h we have


F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
const double *alpha, const double *a, const int *lda,
const double *x, const int *incx, const double *beta,
double *y, const int *incy FCLEN);

with a 12th parameter FCLEN?? How am I supposed to fix this, and what 
the ... is FCLEN? googling leads to nothing useful (for me). It seems as 
if R is redefining some standard LAPACK routines.


Also a note I do not understand (in this context):

note: type ‘void’ should match type ‘long int’

Any help is much appreciated.

Best, Göran

PS. How can I trigger these Warnings 'at home'?

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

Re: [R-pkg-devel] can't reproduce cran-pretest error

[Göran Broström]

Inline:

On 2018-07-26 21:11, Brad Eck wrote:

Dear list,

I'm having trouble reproducing errors from CRAN's pretests.

I have a package on CRAN called epanet2toolkit that provides R bindings
to a legacy simulation engine written in C.  So far I've released two
versions
to CRAN without trouble.  Now I'm making a third release, principally to
include
a citation for the package, but also to clean up warnings raised by new
compilers.

My latest submission fails the CRAN pretests for Debian with errors in the
examples and tests:
https://win-builder.r-project.org/incoming_pretest/
epanet2toolkit_0.3.0_20180726_102947/Debian/00check.log

For what it's worth, the package checks fine under R-3.4.4, R-3.5.0 and
R-devel
r74997 (2018-07-21) and r74923 (2018-06-20).

However, when I run the debian-r-devel checks locally (albeit in Docker) I
get
a couple of warnings, but no errors. Since I can't reproduce the error, it's
difficult to fix. See below the relevant lines of 00check.log:

* using log directory ‘/pkg/epanet2toolkit.Rcheck’
* using R Under development (unstable) (2018-07-25 r75006)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* using option ‘--as-cran’
* checking for file ‘epanet2toolkit/DESCRIPTION’ ... OK
* checking extension type ... Package
...
* checking whether package ‘epanet2toolkit’ can be installed ... WARNING
Found the following significant warnings:
   text.h:421:9: warning: ‘KwKw  /d’ directive writing
30 bytes into a region of size between 23 and 278 [-Wformat-overflow=]
See ‘/pkg/epanet2toolkit.Rcheck/00install.out’ for details.
...
* checking compilation flags used ... WARNING
Compilation used the following non-portable flag(s):
   ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’


This warning can safely be ignored, I have been told. It may also be 
avoided:


https://stat.ethz.ch/pipermail/r-package-devel/2018q3/002878.html

Göran


* checking compiled code ... OK
* checking examples ... OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ... OK
   Running ‘testthat.r’
* checking PDF version of manual ... OK
* DONE
Status: 2 WARNINGs, 1 NOTE


Thanks in advance for any insights.

[[alternative HTML version deleted]]

__
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] compilation flags WARNING

[Göran Broström]

Thanks Heather and Iñaki: I understand.

I have an old Makevars file in the src directory of the package.  I 
guess I can set the flags there? Now it only contains


# PKG_CFLAGS = -Wall
# PKG_FFLAGS = -Wall -fbounds-check
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

Göran

On 2018-07-05 17:43, Heather Turner wrote:



On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote:

El jue., 5 jul. 2018 a las 16:11, Göran Broström
() escribió:


I am preparing a CRAN release of eha (a trivial change due to a change
in the survival package), but when checking the build I get:

goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
...
* checking compilation flags used ... WARNING
Compilation used the following non-portable flag(s):
‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
...


AFAIK, these are new checks. I get similar warnings on Fedora for
different flags.


I have never seen this before and I haven't (to my knowledge) set any
compilation flags. It is my first build and check on a newly upgraded
ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
or is that observation irrelevant?


Again AFAIK (there are package maintainers for several distros here
that can correct me if I'm wrong), each distro defines some policies
regarding compilation flags that are applied to all packages by
default. So these warnings can be safely ignored locally (or you may
override them), because those flags won't be defined on CRAN.


Yes, by default the compilation flags are those set when R was installed. You 
can see the current flags via

R CMD config CFLAGS

which in your case should include  ‘-Wdate-time’ etc.

As Iñaki says you can safely ignore the warning, but if you prefer to not to 
have any warnings you can solve this by creating a Makevars.site file with 
CFLAGS excluding the non-portable ones, e.g.

CFLAGS=-Wall -g O0 -fPIC

This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc.

See 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
 for more information.

Heather


Iñaki



Göran Broström


__
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

[R-pkg-devel] compilation flags WARNING

[Göran Broström]

I am preparing a CRAN release of eha (a trivial change due to a change 
in the survival package), but when checking the build I get:


goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
...
* checking compilation flags used ... WARNING
Compilation used the following non-portable flag(s):
  ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
...

I have never seen this before and I haven't (to my knowledge) set any 
compilation flags. It is my first build and check on a newly upgraded 
ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian, 
or is that observation irrelevant?


Göran Broström

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

Re: [R-pkg-devel] Producing ß in help files.

[Göran Broström]

Den 2018-01-06 kl. 04:41, skrev Rolf Turner:


P. S.  It also seems to me to be polite --- if that's the way the bloke
writes his name, then  that's the way that I ought to write it when
referring to him.


I couldn't agree more: Thanks Rolf!

Göran

PS. I follow Uwe's recommendation and write \enc{Göran}{George} after
\encoding{UTF-8}. (Goeran?? Too ugly.)

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

Re: [R-pkg-devel] Debian: example file is no longer read correctly

[Göran Broström]

On 2017-12-20 18:54, Dirk Eddelbuettel wrote:


On 20 December 2017 at 15:32, Göran Broström wrote:
| > Or can someone tell me how to install the package using R devel on Linux?
|
| Good question (which I missed). I do it like this:
|
| (i) Download and unpack the tarball R-devel in ~/src/
| (ii) ./configure and make
| (iii) Start R-devel:  $ ~/src/R-devel/bin/R
| (iv) > install.packages(...)
|
| This seems to install packages in R-devel/library/, separate from your
| main R installation. Note that I do not install R-devel.
|
| This is found by trial-and-error. I don't know if it is the recommended way.

It is, but more work. (I still do it as it is set up.)


Thanks Dirk, that's exactly what I wanted to hear!


Another good way is to use the rocker/drd container (where "drd" is short for
"daily R-devel").  Requires a system that can run Docker, which is most these
days, and generally worth it.


I'll spend the holidays to learn.

Göran


Dirk



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

Re: [R-pkg-devel] Debian: example file is no longer read correctly

[Göran Broström]

On 2017-12-20 15:32, Göran Broström wrote:



On 2017-12-20 11:11, Blume Christine wrote:

Dear all,



[...]



Or can someone tell me how to install the package using R devel on Linux?


Good question (which I missed). I do it like this:

(i) Download and unpack the tarball R-devel in ~/src/
(ii) ./configure and make
(iii) Start R-devel:  $ ~/src/R-devel/bin/R
(iv) > install.packages(...)


Or

(iii) $ ~/src/R-devel/bin/R CMD INSTALL tar.gz

Göran



This seems to install packages in R-devel/library/, separate from your 
main R installation. Note that I do not install R-devel.


This is found by trial-and-error. I don't know if it is the recommended 
way.


Göran



Thanks a lot!
Christine


[[alternative HTML version deleted]]

__
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] Debian: example file is no longer read correctly

[Göran Broström]

On 2017-12-20 11:11, Blume Christine wrote:

Dear all,



[...]



Or can someone tell me how to install the package using R devel on Linux?


Good question (which I missed). I do it like this:

(i) Download and unpack the tarball R-devel in ~/src/
(ii) ./configure and make
(iii) Start R-devel:  $ ~/src/R-devel/bin/R
(iv) > install.packages(...)

This seems to install packages in R-devel/library/, separate from your 
main R installation. Note that I do not install R-devel.


This is found by trial-and-error. I don't know if it is the recommended way.

Göran



Thanks a lot!
Christine


[[alternative HTML version deleted]]

__
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] Debian: example file is no longer read correctly

[Göran Broström]

On 2017-12-20 12:14, Göran Broström wrote:

Christine,

the error message from CRAN/r-devel-linux suggests that the error comes 
from your function nparACT_flex_loop . There your code below is embedded

in a loop:

for (zz in 1:nofiles) 

If nofiles == 0 (no found files), this loop is still executed (R is not 
Fortran). Maybe this is the cause of the failure?


No, it is not. But when I ran R CMD check --as-cran ..., a file 
'nparACT-Ex.timings' was created in 
'nparACT.Rcheck/sleepstudy_example/', which your example reads, and 
disaster follows.


R CMD check (without --as-cran) avoids this problem, but CRAN will not 
accept it. Seems to be the writing to and reading from disc that is 
problematic and in need of some structure? Others may help with that.


Göran



You should anyway use seq_len(nofiles) or seq_along(files) instead of 
1:nofiles, or check the  number of files found.


Göran

On 2017-12-20 11:11, Blume Christine wrote:

Dear all,

I guess I need your help again. With debian my package (nparACT) gives 
an error message that seems to be related to loading the data:


  Warning in is.na(data$activity) :
  is.na() applied to non-(list or vector) of type 'NULL'
 Error in 1:a : argument of length 0

Although I have set up a virtual machine to test the package using the 
R devel version with Linux (Debian), it gives me a hard time to find 
out what is wrong since I do not manage to install packages using the 
devel version...


Does anyone know what has changed so this text file is not read in any 
longer? The code for reading in the text file is:


data <- read.table(paste(path,name, sep="/"), header = F)
 if (is.data.frame(data)==F){
   data = as.data.frame(data)
 }
 if(ncol(data) == 2){
   data[,1] <- as.POSIXct(data[,1])
   data[,2] <- as.numeric(as.character(data[,2]))
   names(data)[1] <- "time"
   names(data)[2] <- "activity"
    }
 if(ncol(data) == 3){
   names(data)[1] <- "date"
   names(data)[2] <- "time"
   names(data)[3] <- "activity"
   data$date <- NULL
   data$time <- as.POSIXct(data$time, format="%H:%M:%S")
   data$activity <- as.numeric(as.character(data$activity))
 }

Or can someone tell me how to install the package using R devel on Linux?

Thanks a lot!
Christine


[[alternative HTML version deleted]]

__
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] Debian: example file is no longer read correctly

[Göran Broström]

Christine,

the error message from CRAN/r-devel-linux suggests that the error comes 
from your function nparACT_flex_loop . There your code below is embedded

in a loop:

for (zz in 1:nofiles) 

If nofiles == 0 (no found files), this loop is still executed (R is not 
Fortran). Maybe this is the cause of the failure?


You should anyway use seq_len(nofiles) or seq_along(files) instead of 
1:nofiles, or check the  number of files found.


Göran

On 2017-12-20 11:11, Blume Christine wrote:

Dear all,

I guess I need your help again. With debian my package (nparACT) gives an error 
message that seems to be related to loading the data:

  Warning in is.na(data$activity) :
  is.na() applied to non-(list or vector) of type 'NULL'
 Error in 1:a : argument of length 0

Although I have set up a virtual machine to test the package using the R devel 
version with Linux (Debian), it gives me a hard time to find out what is wrong 
since I do not manage to install packages using the devel version...

Does anyone know what has changed so this text file is not read in any longer? 
The code for reading in the text file is:

data <- read.table(paste(path,name, sep="/"), header = F)
 if (is.data.frame(data)==F){
   data = as.data.frame(data)
 }
 if(ncol(data) == 2){
   data[,1] <- as.POSIXct(data[,1])
   data[,2] <- as.numeric(as.character(data[,2]))
   names(data)[1] <- "time"
   names(data)[2] <- "activity"
}
 if(ncol(data) == 3){
   names(data)[1] <- "date"
   names(data)[2] <- "time"
   names(data)[3] <- "activity"
   data$date <- NULL
   data$time <- as.POSIXct(data$time, format="%H:%M:%S")
   data$activity <- as.numeric(as.character(data$activity))
 }

Or can someone tell me how to install the package using R devel on Linux?

Thanks a lot!
Christine


[[alternative HTML version deleted]]

__
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] Error in re-building vignettes (SOLVED)

[Göran Broström]

Hi again,

today I INSTALLED R-devel (2017-12-05 r73849) and updated all packages

> update.packages(checkBuilt = TRUE)

and rebuilt eha_2.5.1 and now all checks passed! Maybe the update of 
packages was necessary.


On its way to CRAN now.

Göran

On 2017-12-05 21:51, Göran Broström wrote:

Hi,

I am checking my eha package with R-3.4.3:

goran@M6800:~/R$ R CMD check --as-cran eha_2.5.1.tar.gz

which results in

* DONE

Status: OK

Fine, but with R-devel (2017-12-04 r73829)

goran@M6800:~/R$ ~/src/R-devel/bin/R CMD check --as-cran eha_2.5.1.tar.gz

.

* checking re-building of vignette outputs ... WARNING
Error in re-building vignettes:
   ...

  *** caught segfault ***
address 0x1, cause 'memory not mapped'

Traceback:
  1: .Call(C_stri_locate_all_regex, str, pattern, omit_no_match, 
opts_regex)
  2: stri_locate_all_regex(string, pattern, omit_no_match = TRUE, 
opts_regex = opts)

  3: stringr::str_locate_all(input, inline.code)
  4: parse_inline(g, patterns)
  5: FUN(X[[i]], ...)
  6: lapply(groups, function(g) {    block = grepl(chunk.begin, g[1]) if 
(!set.preamble && !parent_mode()) {    return(if (block) "" else 
g)    }    if (block) {    n = length(g)    if (n >= 2 && 
grepl(chunk.end, g[n])) g = g[-n]    g = strip_block(g, 
patterns$chunk.code)    params.src = if (group_pattern(chunk.begin)) 
{    stringr::str_trim(gsub(chunk.begin, "\\1", g[1]))    } 
   else ""    parse_block(g[-1], g[1], params.src)    }    else 
parse_inline(g, patterns)})

  7: split_file(lines = text)
  8: process_file(text, output)
  9: knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet, 
    encoding = encoding)
10: rmarkdown::render(file, encoding = encoding, quiet = quiet, envir = 
globalenv())

11: vweave_rmarkdown(...)
12: engine$weave(file, quiet = quiet, encoding = enc)
13: doTryCatch(return(expr), name, parentenv, handler)
14: tryCatchOne(expr, names, parentenv, handlers[[1L]])
15: tryCatchList(expr, classes, parentenv, handlers)
16: tryCatch({    engine$weave(file, quiet = quiet, encoding = enc) 
setwd(startdir)    find_vignette_product(name, by = "weave", engine = 
engine)}, error = function(e) {    stop(gettextf("processing vignette 
'%s' failed with diagnostics:\n%s", file, conditionMessage(e)), 
domain = NA, call. = FALSE)})

17: buildVignettes(dir = "/home/goran/R/eha.Rcheck/vign_test/eha")
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault (core dumped)

* checking PDF version of manual ... OK
* DONE

Status: 1 WARNING, 2 NOTEs

So, can I send this version of eha to CRAN?

Göran Broström

__
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-pkg-devel] Error in re-building vignettes

[Göran Broström]

Hi,

I am checking my eha package with R-3.4.3:

goran@M6800:~/R$ R CMD check --as-cran eha_2.5.1.tar.gz

which results in

* DONE

Status: OK

Fine, but with R-devel (2017-12-04 r73829)

goran@M6800:~/R$ ~/src/R-devel/bin/R CMD check --as-cran eha_2.5.1.tar.gz

.

* checking re-building of vignette outputs ... WARNING
Error in re-building vignettes:
  ...

 *** caught segfault ***
address 0x1, cause 'memory not mapped'

Traceback:
 1: .Call(C_stri_locate_all_regex, str, pattern, omit_no_match, opts_regex)
 2: stri_locate_all_regex(string, pattern, omit_no_match = TRUE, 
opts_regex = opts)

 3: stringr::str_locate_all(input, inline.code)
 4: parse_inline(g, patterns)
 5: FUN(X[[i]], ...)
 6: lapply(groups, function(g) {block = grepl(chunk.begin, g[1]) 
if (!set.preamble && !parent_mode()) {return(if (block) "" else 
g)}if (block) {n = length(g)if (n >= 2 && 
grepl(chunk.end, g[n])) g = g[-n]g = strip_block(g, 
patterns$chunk.code)params.src = if (group_pattern(chunk.begin)) 
{stringr::str_trim(gsub(chunk.begin, "\\1", g[1]))} 
  else ""parse_block(g[-1], g[1], params.src)}else 
parse_inline(g, patterns)})

 7: split_file(lines = text)
 8: process_file(text, output)
 9: knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet, 
   encoding = encoding)
10: rmarkdown::render(file, encoding = encoding, quiet = quiet, envir = 
globalenv())

11: vweave_rmarkdown(...)
12: engine$weave(file, quiet = quiet, encoding = enc)
13: doTryCatch(return(expr), name, parentenv, handler)
14: tryCatchOne(expr, names, parentenv, handlers[[1L]])
15: tryCatchList(expr, classes, parentenv, handlers)
16: tryCatch({engine$weave(file, quiet = quiet, encoding = enc) 
setwd(startdir)find_vignette_product(name, by = "weave", engine = 
engine)}, error = function(e) {stop(gettextf("processing vignette 
'%s' failed with diagnostics:\n%s", file, conditionMessage(e)), 
domain = NA, call. = FALSE)})

17: buildVignettes(dir = "/home/goran/R/eha.Rcheck/vign_test/eha")
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault (core dumped)

* checking PDF version of manual ... OK
* DONE

Status: 1 WARNING, 2 NOTEs

So, can I send this version of eha to CRAN?

Göran Broström

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

[R-pkg-devel] Summary: tibbles are not data frames

[Göran Broström]

Dear all,

I got an overwhelming amount of response to my question, and making a
complete summary is not possible. However, I learned that I should 
change things like 'dat[5:8, 1]' to 'dat[[1]][5:8]',

respecting the fact that a data frame is a list, in my packages.
Accidentally, this also solves the problem  of using tibbles where data 
frames are expected. The classes "tbl" and "tbl_df" will be preserved on 
output; no need to use 'as.data.frame', the simple check 'is.data.frame' 
is enough.


Thanks for a very interesting and enlightening discussion! A special 
thanks to Hadley for sharing great packages with us; I could only wish 
they were easier to use in my own packages;)


Göran

On 2017-09-26 15:37, Hadley Wickham wrote:

On Tue, Sep 26, 2017 at 2:30 AM, Göran Broström
 wrote:

I am beginning to get complaints from users of my CRAN packages
(especially 'eha') to the effect that they get error messages like
"Error: Unsupported use of matrix or array for column indexing".

It turns out that they are sticking in tibbles into functions that
expect data frames as input. And I am using the kind of subsetting
that Hadley dislikes (eha is an old package, much older than
tibbles). It is of course a simple matter to change the code so it
handles both data frames and tibbles correctly, but this affects
many functions, and it will take some time. And when the next guy
introduces 'troubles' as an improvement of 'tibbles', I will have
to rewrite the code again.


Changing df[, x] to df[[x]] is not very hard and makes your code 
easier to understand because it more clearly conveys the intent that 
you want a single column.



While I like Hadley's way of doing it, I think it is a mistake to
let a tibble also be of class data frame. To me it is a matter of
inheritance and backwards compability: A tibble should add nice
things to a data frame, not change basic behaviour, in order to
call itself a data frame.

Is it correct to let a tibble be of class "data.frame"?


If it not inherit from data frame, it would be not work with the 99% 
of functions that work with data frames and don't deliberately take 
advantage of the dropping behaviour of [. In other words, it would

be pointless.

I decided to make [.tibble type-stable (i.e. always return a data 
frame) because this behaviour causes substantial problems in real

data analysis code. I did it understanding that it would cause some
package developers frustration, but I think it's better for a handful
of package maintainers to be frustrated than hundreds of users
creating dangerous code.

Hadley



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

Re: [R-pkg-devel] tibbles are not data frames

[Göran Broström]

On 2017-09-26 15:37, Hadley Wickham wrote:

On Tue, Sep 26, 2017 at 2:30 AM, Göran Broström  wrote:

I am beginning to get complaints from users of my CRAN packages (especially
'eha') to the effect that they get error messages like "Error: Unsupported
use of matrix or array for column indexing".

It turns out that they are sticking in tibbles into functions that expect
data frames as input. And I am using the kind of subsetting that Hadley
dislikes (eha is an old package, much older than tibbles). It is of course a
simple matter to change the code so it handles both data frames and tibbles
correctly, but this affects many functions, and it will take some time. And
when the next guy introduces 'troubles' as an improvement of 'tibbles', I
will have to rewrite the code again.


Changing df[, x] to df[[x]] is not very hard and makes your code
easier to understand because it more clearly conveys the intent that
you want a single column.


Couldn't agree more: Not because it works with tibbles, but because it 
works with lists. And therefore with data frames. If we trust inheritance.


Göran


While I like Hadley's way of doing it, I think it is a mistake to let a
tibble also be of class data frame. To me it is a matter of inheritance and
backwards compability: A tibble should add nice things to a data frame, not
change basic behaviour, in order to call itself a data frame.

Is it correct to let a tibble be of class "data.frame"?


If it not inherit from data frame, it would be not work with the 99%
of functions that work with data frames and don't deliberately take
advantage of the dropping behaviour of [. In other words, it would be
pointless.

I decided to make [.tibble type-stable (i.e. always return a data
frame) because this behaviour causes substantial problems in real data
analysis code.
I did it understanding that it would cause some package
developers frustration, but I think it's better for a handful of
package maintainers to be frustrated than hundreds of users creating
dangerous code.



Hadley



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

Re: [R-pkg-devel] tibbles are not data frames

[Göran Broström]

Thanks Gábor,

that is OK. However, if I would like an input tibble remain a tibble 
(after massaging) in output, as a courtesy to the user, this will fail. 
I think that it works if I instead treat the input as a list: That's all 
'the tibble way' does (in my case at least).


Göran

On 2017-09-26 14:17, Gábor Csárdi wrote:

Yes, basically tibbles violate the substitution principle. A lot of
other packages do, probably base R as well, although it is sometimes
hard to say, because there is no clear object hierarchy.

Let's take a step back, and see how you can check for a data frame argument.

1. Weak check.

is.data.frame(arg)

This essentially means that you trust subclasses of data.frame to
adhere to the substitution principle. While this is nice in theory, a
lot packages (including both major packages implementing subclasses of
data.frame!) do not always adhere. So this is not really a safe
solution.

Base R does this as well, sometimes, e.g. aggregate.data.frame has:

 if (!is.data.frame(x))
 x <- as.data.frame(x)

which is essentially equivalent to the weak check, since it leaves
data.frame subclasses untouched.

2. Strong "check".

arg <- as.data.frame(arg)

This is safer, because it does not rely on subclass implementors. It
also has the additional benefit that your code is polymorphic: it
works with any input, as long as it can be converted to a data frame.

Base R also uses this often, e.g. in merge.data.frame:

 nx <- nrow(x <- as.data.frame(x))
 ny <- nrow(y <- as.data.frame(y))

Gabor

Disclaimer: I do not represent the tibble authors in any way.

On Tue, Sep 26, 2017 at 11:21 AM, David Hugh-Jones
 wrote:

These replies seem to be missing the point, which is that old code has to be
rewritten because tibbles don't behave like data frames.

It is true that subclasses can override behaviour, but there is an implicit
contract that the same methods should do the same things.

The as.xxx pattern seems weird to me, though I see it a lot. What is the
point of inheritance if you always have to convert an object upwards before
you can treat it as a member of the superclass?

I can see this argument will run...

David

On 26 September 2017 at 11:15, Gábor Csárdi  wrote:


What is the benefit here, compared to just calling as.data.frame() on it?

Gabor

On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke 
wrote:

Since tibbles add their class attributes first, you could use:

tb <- tibble(a = 5)
inherits(tb, "data.frame", which = TRUE) == 1

if "tb" is a data frame (only), TRUE is returned, for tibble FALSE. You
could then coerce to data frame: as.data.frame(tb)

-Ursprüngliche Nachricht-
Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im
Auftrag von Göran Broström
Gesendet: Dienstag, 26. September 2017 12:09
An: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] tibbles are not data frames



On 2017-09-26 11:56, Gábor Csárdi wrote:

On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys 
wrote:

I don't like the dropping of dimensions either. That doesn't change
the fact that a tibble reacts different from a data.frame. So tibbles
do not inherit correctly from the class data.frame, and it can thus
be argued that it's against OOP paradigms to pretend tibbles inherit
from the class data.frame.


I have yet to see an OOP system in which a subclass cannot override
the methods of its superclass. Not only is this in line with OOP
paradigms, it is actually one of the essential OOP features.

To be more constructive, if you have a function that only works with
data frame inputs, then it is good practice to check that the supplied
input is indeed a data frame. This is independent of tibbles.


It is not. I check input for being a data frame, but tibbles pass that
test. That's the essence of the problem.


In practice it seems to me that an easy fix is to just call
as.data.frame on the input. This should either convert it to a data
frame, or throw an error.


Sure, but I still need to rewrite the package.

Görn


For tibbles it
drops the tbl* classes.

Gabor


Defensive coding techniques would check if it's a tibble and return
an error saying a data.frame is expected. Unless tibbles inherit
correctly from data.frame.

I have nothing against tibbles. But calling them "data.frame" raises
expectations that can't be fulfilled.


[...]

__
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

--

_

Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
Rechts; Gerichtsstand: Hamburg | www.uke.de
Vorstandsmi

Re: [R-pkg-devel] tibbles are not data frames

[Göran Broström]

On 2017-09-26 14:01, Daniel Lüdecke wrote:

You wrote:

The correct and logical way (which I use in 'eha') is to check if input is a 
data frame, and if not, throw an error.

If you want to check for a data frame (and a data frame only), because you 
don't want to coerce *any* object to data frames, then this would be one way to 
check for df/tibble, and coerce tibbles only. That's what I had in mind...

But as I mentioned before, since simplifying is the most (or even only?) relevant point 
when dealing with tibbles, I have re-written all parts in my packages that used df[, x] 
indexing, and replaced with df[[x]], resp. used df[, x, drop = FALSE], or - if a vector 
is needed - you can use "dplyr::pull()" to make sure you get a vector.


One important thing for me (my packages) is to stay out of dependence on 
other packages, as far as it is possible. But I am in the process of 
doing what you suggest: Treat a data frame as the _list_ it is. Back to 
basics!


Göran



Best
Daniel

-Ursprüngliche Nachricht-
Von: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
Gesendet: Dienstag, 26. September 2017 12:15
An: Daniel Lüdecke 
Cc: R Package Devel 
Betreff: Re: [R-pkg-devel] tibbles are not data frames

What is the benefit here, compared to just calling as.data.frame() on it?

Gabor

On Tue, Sep 26, 2017 at 11:11 AM, Daniel Lüdecke  wrote:

Since tibbles add their class attributes first, you could use:

tb <- tibble(a = 5)
inherits(tb, "data.frame", which = TRUE) == 1

if "tb" is a data frame (only), TRUE is returned, for tibble FALSE.
You could then coerce to data frame: as.data.frame(tb)

-Ursprüngliche Nachricht-
Von: R-package-devel [mailto:r-package-devel-boun...@r-project.org] Im
Auftrag von Göran Broström
Gesendet: Dienstag, 26. September 2017 12:09
An: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] tibbles are not data frames



On 2017-09-26 11:56, Gábor Csárdi wrote:

On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys  wrote:

I don't like the dropping of dimensions either. That doesn't change
the fact that a tibble reacts different from a data.frame. So
tibbles do not inherit correctly from the class data.frame, and it
can thus be argued that it's against OOP paradigms to pretend
tibbles inherit from the class data.frame.


I have yet to see an OOP system in which a subclass cannot override
the methods of its superclass. Not only is this in line with OOP
paradigms, it is actually one of the essential OOP features.

To be more constructive, if you have a function that only works with
data frame inputs, then it is good practice to check that the
supplied input is indeed a data frame. This is independent of tibbles.


It is not. I check input for being a data frame, but tibbles pass that test. 
That's the essence of the problem.


In practice it seems to me that an easy fix is to just call
as.data.frame on the input. This should either convert it to a data
frame, or throw an error.


Sure, but I still need to rewrite the package.

Görn


For tibbles it
drops the tbl* classes.

Gabor


Defensive coding techniques would check if it's a tibble and return
an error saying a data.frame is expected. Unless tibbles inherit
correctly from data.frame.

I have nothing against tibbles. But calling them "data.frame" raises
expectations that can't be fulfilled.


[...]

__
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

--

_

Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
Rechts; Gerichtsstand: Hamburg | www.uke.de
Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr.
Dr. Uwe Koch-Gromus, Joachim Prölß, Martina Saurin (komm.)
_

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


--

_

Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; 
Gerichtsstand: Hamburg | www.uke.de
Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. Uwe 
Koch-Gromus, Joachim Prölß, Martina Saurin (komm.)
_

SAVE PAPER - THINK BEFORE PRINTING
__
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] tibbles are not data frames

[Göran Broström]

On 2017-09-26 11:56, Gábor Csárdi wrote:

On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys  wrote:

I don't like the dropping of dimensions either. That doesn't change the
fact that a tibble reacts different from a data.frame. So tibbles do not
inherit correctly from the class data.frame, and it can thus be argued that
it's against OOP paradigms to pretend tibbles inherit from the class
data.frame.


I have yet to see an OOP system in which a subclass cannot override the methods
of its superclass. Not only is this in line with OOP paradigms, it is
actually one of
the essential OOP features.

To be more constructive, if you have a function that only works with
data frame inputs, then
it is good practice to check that the supplied input is indeed a data
frame. This is
independent of tibbles.


It is not. I check input for being a data frame, but tibbles pass that 
test. That's the essence of the problem.



In practice it seems to me that an easy fix is to just call
as.data.frame on the input. This should
either convert it to a data frame, or throw an error.


Sure, but I still need to rewrite the package.

Görn


For tibbles it
drops the tbl* classes.

Gabor


Defensive coding techniques would check if it's a tibble and
return an error saying a data.frame is expected. Unless tibbles inherit
correctly from data.frame.

I have nothing against tibbles. But calling them "data.frame" raises
expectations that can't be fulfilled.


[...]

__
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] tibbles are not data frames

[Göran Broström]

On 2017-09-26 11:35, Joris Meys wrote:
I don't like the dropping of dimensions either. That doesn't change the 
fact that a tibble reacts different from a data.frame. So tibbles do not 
inherit correctly from the class data.frame, and it can thus be argued 
that it's against OOP paradigms to pretend tibbles inherit from the 
class data.frame. Defensive coding techniques would check if it's a 
tibble and return an error saying a data.frame is expected. Unless 
tibbles inherit correctly from data.frame.


The correct and logical way (which I use in 'eha') is to check if input 
is a data frame, and if not, throw an error. Checking for other things 
would soon be too overwhelming.




I have nothing against tibbles. But calling them "data.frame" raises 
expectations that can't be fulfilled.


Exactly what I think. I wouldn't object to changing base data frames to 
behave like tibbles (with a few exceptions).


Göran



On Tue, Sep 26, 2017 at 11:23 AM, Stefan McKinnon Høj-Edwards 
mailto:s...@iysik.com>> wrote:


Thanks for the examples. Personally, I have been struck out multiple
times by data frames dropping dimensions, so I have a distaste for
this dropping behaviour.

Personally, I prefer data frame *not* to drop dimensions. They are
not arrays, where slicing drops a dimension makes sense because all
entries are same data type.
You can pull out a column in vector form from both tribbles and data
frame with the $ index; subsetting a row from a data frame and
forcing it into an atomic vector will require cast all columns to
lowest common denominator, often character.

So I would argue that yes, tribbles are data.frame with extra bells
and whistles, even if I do not understand the use of list columns.

I suggest a defensive coding technique; if you need a data frame
subset to really be a vector, cast it as a vector. Users *will*
attempt to throw unexpected structures at your methods. When your
methods fails in mysterious ways because it didn't extract a vector,
users will be stupefied. Fail at `as.vector` will indicate why.

Kindly,
Stefan

Stefan McKinnon Høj-Edwards
ph.d. Genetics
+44 (0)776 231 2464 
+45 2888 6598 
Skype: stefan_edwards

2017-09-26 10:05 GMT+01:00 Joris Meys mailto:joris.m...@ugent.be>>:

Here's one difference:

atib <- tibble(a = 1:5, b = letters[5:1])
atib[3,"a"]
as.data.frame(atib)[3,"a"]

The second line returns a tibble (no dropping dimensions), the
third line does (dropping dimensions). Huge difference if you
use [ , aColumn] to select a vector from a data frame.

Cheers
Joris

On Tue, Sep 26, 2017 at 10:57 AM, Stefan McKinnon Høj-Edwards
mailto:s...@iysik.com>> wrote:

Hi Göran,

Could you please elaborate on which kind of subsetting that
Hadley dislikes?
I am yet to encounter operations on data frames that are not
possible on
tribbles.

Kindly,
Stefan McKinnon Hoj-Edwards

Stefan McKinnon Høj-Edwards
ph.d. Genetics
+44 (0)776 231 2464 
    +45 2888 6598 
Skype: stefan_edwards

2017-09-26 8:30 GMT+01:00 Göran Broström
mailto:goran.brost...@umu.se>>:

 > I am beginning to get complaints from users of my CRAN
packages
 > (especially 'eha') to the effect that they get error
messages like "Error:
 > Unsupported use of matrix or array for column indexing".
 >
 > It turns out that they are sticking in tibbles into
functions that expect
 > data frames as input. And I am using the kind of
subsetting that Hadley
 > dislikes (eha is an old package, much older than
tibbles). It is of course
 > a simple matter to change the code so it handles both
data frames and
 > tibbles correctly, but this affects many functions, and
it will take some
 > time. And when the next guy introduces 'troubles' as an
improvement of
 > 'tibbles', I will have to rewrite the code again.
 >
 > While I like Hadley's way of doing it, I think it is a
mistake to let a
 > tibble also be of class data frame. To me it is a matter
of inheritance and
 > backwards compability: A tibble should add nice things to
a data frame, not
     > change basic behaviour, in order to call itself a data frame.
 >
 > Is it correct to

Re: [R-pkg-devel] tibbles are not data frames

[Göran Broström]

Hej Stefan,

On 2017-09-26 10:57, Stefan McKinnon Høj-Edwards wrote:

Hi Göran,

Could you please elaborate on which kind of subsetting that Hadley dislikes?
I am yet to encounter operations on data frames that are not possible on 
tribbles.


For instance, if 'dat' is a data frame, dat[1:3, 5] returns a vector of 
length 3. If 'dat' is a tibble, you do dat[[5]][1:3] to get the same 
vector. A tibble never 'drops dimensions'. See Hadley's book, on the web.


Göran



Kindly,
Stefan McKinnon Hoj-Edwards

Stefan McKinnon Høj-Edwards
ph.d. Genetics
+44 (0)776 231 2464
+45 2888 6598
Skype: stefan_edwards

2017-09-26 8:30 GMT+01:00 Göran Broström <mailto:goran.brost...@umu.se>>:


I am beginning to get complaints from users of my CRAN packages
(especially 'eha') to the effect that they get error messages like
"Error: Unsupported use of matrix or array for column indexing".

It turns out that they are sticking in tibbles into functions that
expect data frames as input. And I am using the kind of subsetting
that Hadley dislikes (eha is an old package, much older than
tibbles). It is of course a simple matter to change the code so it
handles both data frames and tibbles correctly, but this affects
many functions, and it will take some time. And when the next guy
introduces 'troubles' as an improvement of 'tibbles', I will have to
rewrite the code again.

While I like Hadley's way of doing it, I think it is a mistake to
let a tibble also be of class data frame. To me it is a matter of
inheritance and backwards compability: A tibble should add nice
things to a data frame, not change basic behaviour, in order to call
    itself a data frame.

Is it correct to let a tibble be of class "data.frame"?

Göran Broström

__
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<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-pkg-devel] tibbles are not data frames

[Göran Broström]

I am beginning to get complaints from users of my CRAN packages 
(especially 'eha') to the effect that they get error messages like 
"Error: Unsupported use of matrix or array for column indexing".


It turns out that they are sticking in tibbles into functions that 
expect data frames as input. And I am using the kind of subsetting that 
Hadley dislikes (eha is an old package, much older than tibbles). It is 
of course a simple matter to change the code so it handles both data 
frames and tibbles correctly, but this affects many functions, and it 
will take some time. And when the next guy introduces 'troubles' as an 
improvement of 'tibbles', I will have to rewrite the code again.


While I like Hadley's way of doing it, I think it is a mistake to let a 
tibble also be of class data frame. To me it is a matter of inheritance 
and backwards compability: A tibble should add nice things to a data 
frame, not change basic behaviour, in order to call itself a data frame.


Is it correct to let a tibble be of class "data.frame"?

Göran Broström

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

[R-pkg-devel] Mis-spelled word with winbuilder

[Göran Broström]

I'm checking my package with winbuilder and get one NOTE:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Göran Broström '

Possibly mis-spelled words in DESCRIPTION:
  piecewise (9:43)

How should it be spelled? I have googled 'piecewise' and it seems to be 
widely used with that spelling.


Thanks, Göran

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