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

[peter dalgaard]

> 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 (åöä), 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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] [R] a question of etiquette

[peter dalgaard]

t;>>> Subject: [R] a question of etiquette
>>>> Date: June 1, 2020 at 11:34:00 AM CDT
>>>> To: r-h...@r-project.org
>>>> 
>>>> The new version of a package which I maintain will include a new function 
>>>> which I have ported to R from Matlab.
>>>> The documentation of this R function indicates the authors of the original 
>>>> Matlab code, reference to their paper, URL of the source code.
>>>> 
>>>> Question: is this adequate, or should I include them as co-authors of the 
>>>> package, or as contributors, or what else?
>>>> Is there a general policy about this matter?
>>>> 
>>>> Adelchi Azzalini
>>>> http://azzalini.stat.unipd.it/
>>>> 
>>>> __
>>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>> PLEASE do read the posting guide 
>>>> http://www.R-project.org/posting-guide.html
>>>> and provide commented, minimal, self-contained, reproducible code.
>>> [[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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] note about mispelled words

[Peter Dalgaard]

However, notice that if it is the guy from the Kruskal-Wallis test (William K., 
1919--2005), the "Kruskall" is in fact misspelt. It might be someone else, of 
course...

-pd

> On 17 Mar 2020, at 18:24 , Duncan Murdoch  wrote:
> 
> I believe it is also acceptable to explain in your submission message that 
> the misspelled words are all proper names.  As far as I know, misspellings 
> are not enough of a problem to cause an automatic rejection, so a human being 
> will be making a judgment about the note.
> 
> Duncan Murdoch
> 
> On 17/03/2020 11:41 a.m., Henrik Bengtsson wrote:
>> You can single quote them to avoid them being spell checked, e.g. ...
>> using methods of 'Kruskall' and 'Brainerd'.  This is a common and
>> accepted practice.
>> This is hinted at in "Writing R Extensions" (e.g. help.start());
>> The mandatory ‘Description’ field should give a comprehensive
>> description of what the package does. One can use several (complete)
>> sentences, but only one paragraph. It should be intelligible to all
>> the intended readership (e.g. for a CRAN package to all CRAN users).
>> It is good practice not to start with the package name, ‘This package’
>> or similar. As with the ‘Title’ field, double quotes should be used
>> for quotations (including titles of books and articles), and single
>> quotes for non-English usage, including names of other packages and
>> external software. This field should also be used for explaining the
>> package name if necessary. URLs should be enclosed in angle brackets,
>> e.g. ‘<https://www.r-project.org>’: see also Specifying URLs.
>> /Henrik
>> On Tue, Mar 17, 2020 at 8:30 AM Gianmarco Alberti
>>  wrote:
>>> 
>>> Hello,
>>> I am checking a package of mine, and I got only 1 note regarding possibly 
>>> misspelled words in the DESCRIPTION.
>>> 
>>> The issue I am facing is that those 6 words are not actually misspelled, 
>>> being either first or last names of individuals (actually, statistician; 
>>> e.g., Kruskall, Brainerd).
>>> 
>>> Shall I have to do something (removing those; which does not make sense), 
>>> or upon submitting my new version of the package there is a way to make 
>>> clear that that note can be ignored?
>>> 
>>> By the way, those names were already there in earlier versions of the 
>>> package and no note cropped out in those occasions.
>>> 
>>> Thank you
>>> Best
>>> GmA
>>> 
>>> 
>>> Dr Gianmarco Alberti (PhD Udine)
>>> Lecturer in Spatial Forensics
>>> Coordinator of the BA course in Criminology
>>> Department of Criminology
>>> Faculty for Social Wellbeing
>>> Room 332, Humanities B (FEMA)
>>> University of Malta, Msida, Malta (Europe) - MSD 2080
>>> tel +356 2340 3718
>>> 
>>> Academic profiles
>>> https://www.researchgate.net/profile/Gianmarco_Alberti4
>>> https://malta.academia.edu/GianmarcoAlberti
>>> 
>>> Google Scholar profile
>>> https://scholar.google.com/citations?user=tFrJKQ0J=en
>>> 
>>> Correspondence Analysis website
>>> http://cainarchaeology.weebly.com/
>>> 
>>> R packages on CRAN:
>>> CAinterprTools
>>> https://cran.r-project.org/web/packages/CAinterprTools/index.html
>>> 
>>> GmAMisc
>>> https://cran.r-project.org/package=GmAMisc
>>> 
>>> movecost
>>> https://cran.r-project.org/web/packages/movecost/index.html
>>> 
>>> 
>>> [[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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Need help to resolve NOTEs in auto check

[peter dalgaard]

(a) Spelling issues: False positive are checked manually by CRAN, so just tell 
them on submission. For software items, Uwe at some point recommended "Single 
quotes around software names such as 'pkg', functions should be written with 
parentheses as in foo()."

(b) The procedure for submitting is to run 'R CMD build' on the (unpackaged) 
source directory, then submit the resulting .tar.gz file. If you don't do that, 
the build time stamp will be absent. Similarly 'R CMD check' should be run on 
the output from 'R CMD build'. Like this (oups, that dir is out of sync on this 
computer):

Peters-iMac:ISWR-2nd-ed pd$ R CMD build ISwR
* checking for file ‘ISwR/DESCRIPTION’ ... OK
* preparing ‘ISwR’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* looking to see if a ‘data/datalist’ file should be added
* re-saving .R files as .rda
  NB: *.R converted to .rda: other files may need to be removed
* re-saving tabular files
* creating default NAMESPACE file
* building ‘ISwR_2.0-5.tar.gz’

Peters-iMac:ISWR-2nd-ed pd$ R CMD check --as-cran ISwR_2.0-5.tar.gz 
* using log directory ‘/Users/pd/BIOSTAT/books/ISWR-2nd-ed/ISwR.Rcheck’
* using R version 3.6.0 (2019-04-26)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* using option ‘--as-cran’
* checking for file ‘ISwR/DESCRIPTION’ ... OK
* this is package ‘ISwR’ version ‘2.0-5’
* checking CRAN incoming feasibility ... WARNING
Maintainer: ‘Peter Dalgaard ’

Insufficient package version (submitted: 2.0.5, existing: 2.0.8)

Days since last update: 2

The Date field is over a month old.
* checking package namespace information ... OK
*..


(c) Examples _will_ be run as part of the check procedure. If that produces 
stray files in the check directory, you will tget the message that you see. In 
interactive usage, example(...) will similarly create files in the current 
directory, which is verboten, so write to a temporary directory instead. (See 
help(tempfile) for specifics).

> On 22 Jan 2020, at 11:29 , Ian Walker  wrote:
> 
> Hello,
> 
> I'm trying to repackage an R function so I can update the licence. I'm stuck 
> with the automatic checks. The problem appears to be the following three 
> NOTEs in the checking output:
> 
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: ‘Ian Walker <
> i.wal...@bath.ac.uk
>> ’
> 
> Possibly mis-spelled words in DESCRIPTION:
>  DEMs (7:503)
>  STL (7:47)
>  stereolithography (7:52)
>  stl (7:24)
> 
> The build time stamp is missing.
> 
> It's not clear what is wrong here - is it the spellings (which are fine) or 
> the time stamp? If the latter, how do I resolve this?
> 
> * checking DESCRIPTION meta-information ... NOTE
> Checking should be performed on sources prepared by ‘R CMD build’.
> 
> I can't make any sense of this issue!
> 
> * checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>  ‘lovelyfunction.stl’ ‘volcano.stl’
> 
> These two .stl files are simply mentioned in the documentation's example code 
> - they're files that would be created if somebody ran the example code; 
> they're not in the R package I've created.
> 
> Thanks for any help,
> 
> Ian
> --
> Dr Ian Walker FHEA | Department of Psychology, University of Bath
> i.wal...@bath.ac.uk (academic) | m...@drianwalker.com (other matters)
> 
> Website: drianwalker.com | Twitter: twitter.com/ianwalker
> 
> My books:
> Research Methods and Statistics - a new, clear introduction 
> http://tinyurl.com/res-stats
> Research with People - the essential research textbook: http://amzn.to/sRbYxy
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] CRAN submission with "possibly unsafe calls" or alternative approach?

[peter dalgaard]

I think you may want to rethink the mechanism. 

Locked bindings are generally there to allow the compiler to make assumptions 
about the type, etc., of objects (or rather: not make assumptions because it 
will know what the type is). Unlocking invalidates this and may trigger 
recompilation or introduce errors. (There are people who know the details much 
better than I do).

I seem to recall that people have come up with ways to set up an environment 
which can contain mutable objects of this sort.

-pd

> On 6 Dec 2019, at 10:05 , Rainer M Krug  wrote:
> 
> Hi
> 
> In my package `dmdScheme` I define three variables. Depending on a state in 
> the package (a selected metadata schemes) these are set as followed from 
> within the package:
> 
> ```
>  unlockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
>  assign("dmdScheme_example", scheme_example, "package:dmdScheme")
>  lockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
> 
> 
>  scheme_raw <- as_dmdScheme_raw(scheme_example)
>  unlockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
>  assign("dmdScheme_raw", scheme_raw, "package:dmdScheme")
>  lockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
> 
> 
>  scheme <- as_dmdScheme(scheme_raw, keepData = FALSE, checkVersion = FALSE)
>  unlockBinding("dmdScheme", as.environment("package:dmdScheme"))
>  assign("dmdScheme", scheme, "package:dmdScheme")
>  lockBinding("dmdScheme", as.environment("package:dmdScheme”))
> ```
> 
> ( See 
> https://github.com/Exp-Micro-Ecol-Hub/dmdScheme/blob/b97e7b5ef116476e065aeec1da1050eecbd6adf7/R/scheme_use.R#L37-L49
>  )
> 
> My reasoning is that I want to lock these variables, as they are essential to 
> the functioning of the package.
> 
> But I get, probably not surprising, the following NOTE:
> 
> 
> ```
> * checking R code for possible problems ... NOTE
> Found the following possibly unsafe calls:
> File ‘dmdScheme/R/scheme_use.R’:
>  unlockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
>  unlockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
>  unlockBinding("dmdScheme", as.environment("package:dmdScheme"))
> ```
> 
> For the submission to CRAN, Can I disregard this note and explain it during 
> the submission?
> 
> My second question concerns the values itself. I set the variables to NULL in 
> the /data folder in the package, but even after they are set as above, the 
> valuee in `dmdScheme::dmdScheme` is still NULL:
> 
> ```
>> names(dmdScheme)
> [1] "Experiment"   "Genus""Treatments"   "Measurement"
> [5] "DataExtraction"   "DataFileMetaData"
>> names(dmdScheme::dmdScheme)
> NULL
>> 
> ```
> 
> Is there a way, that I can change the value of dmdScheme::… variables during 
> runtime?
> 
> Thanks,
> 
> Rainer
> 
> 
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys. (Germany)
> 
> Orcid ID: 0000-0002-7490-0066
> 
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
> 
> Office:   +41 (0)44 635 47 64
> Cell: +41 (0)78 630 66 57
> email:  rainer.k...@uzh.ch
>   rai...@krugs.de
> Skype: RMkrug
> 
> PGP: 0x0F52F982
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Fix non-ASCII characters in R packages

[peter dalgaard]

Dunno if it helps, but the NOTE is about "checking data", which, as far as I 
can decipher the code, means that it is looking at datasets in the data/ 
directory. So I suspect that looking at *.R files is not going to be the right 
thing to do.

-pd

> On 2 Dec 2019, at 14:57 , Rafael Pereira  wrote:
> 
> Hi all,
> 
> I am trying to update my R package on CRAN but I am being requested to fix
> this NOTE:
> 
> checking data for non-ASCII characters ... NOTE Note: found 58 marked
> Latin-1 strings
> 
> I have used to code below to identify my scripts that have strings using
> non-ASCII characters. The problem is that in most cases these non-ASCII
> characters are used in the documentation of functions, so I cannot simply
> convert their encoding using iconv() for example
> 
> # Find scripts using non-ASCII characters
>  f <- list.files(pattern = "*.R", recursive = T)
>  r <- lapply(f, tools::showNonASCIIfile)
> 
> I've tried (1) reopening and (2) resaving those scripts with UTF-8
> encoding, (3) setting UTF-8 as the default encoding of the project, but
> nothing seems to fix this issue. Any suggestions?
> 
> obs. I've posted this question on SO
> https://stackoverflow.com/questions/59139923/fix-non-ascii-characters-in-r-packages
> 
> best,
> 
> Rafael Pereira
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Building fails with 'mypackage/DESCRIPTION' does not exist

[peter dalgaard]

Is it really called "mypackage"? Otherwise I'd first check that it is spelled 
the same way in all cases... 

Another possibility is that the embedded spaces in the pathname is doing you in.

-pd

> On 30 Sep 2019, at 16:31 , Steve Gutreuter  wrote:
> 
> I have a package which will no longer build after minor changes.  The
> problem occurs under both Windows 10 and Linux Mint.  For example, from a
> Windows terminal I do:
> 
> C:\Users\xyz\OneDrive - ORG\Computing\Devel> R CMD build screenr
> 
> and I get:
> 
> * checking for file 'mypackage/DESCRIPTION' ... OK
> * preparing 'mypackage':
> * checking DESCRIPTION meta-information ... OK
> * installing the package to process help pages
> * saving partial Rd database
> Error in .read_description(ldpath) :
>   file 'mypackage/DESCRIPTION' does not exist
> Execution halted
> 
> So the first and third lines of output contradict the error message, and of
> course mypackage/DESCRIPTION does exist.  I suspect the problem has nothing
> to do with the DESCRIPTION file, but have not found way to identify the
> actual problem in searches on StackOverflow and elsewhere. My .R files in
> mypackage/R contain Roxygen comments, and curiously devtools::document()
> adds nothing to mypackage/man.
> 
> Any suggestions about how to debug or solve this problem?
> 
> Thanks!
> Steve
> 
>   [[alternative HTML version deleted]]
> 
> ______
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] script translation - good practice?

[peter dalgaard]

Yes. Check out

https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

and also note that CC-BY is not recommended as a software license (by CC 
themselves). As there is one-way compatibility, it should be possible to 
clarify the situation by putting your derivative work under the GPL.

Although not legally required, it would probably be good manners to inform the 
original authors.

-pd

> On 18 Sep 2019, at 14:20 , Raphael Bonnet  
> wrote:
> 
> Thank you Peter for your response,
> 
> It looks ok for the license. The journal's content appears to be under this 
> license:
> https://creativecommons.org/licenses/by/3.0/
> 
> Raphael
> 
> Le 18/09/2019 à 14:11, peter dalgaard a écrit :
>> Not a lawyer, but...
>> 
>> I would expect that it depends on what license it was published under 
>> originally. If it doesn't explicitly allow the creation of derivative works, 
>> then I would be wary.
>> 
>> -pd
>> 
>>> On 18 Sep 2019, at 13:59 , Raphael Bonnet 
>>>  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I just rewrote a bit of Matlab code into R and that I would like to make it 
>>> available for the community.
>>> Unfortunately this bit of code has been published by authors that I've 
>>> never contacted.
>>> 
>>> I was wondering if I could submit a package to CRAN by keeping the same 
>>> license as the journal in which the code was published and citing the paper 
>>> and the authors.
>>> Can I associate myself as [cre, trl] in the description file?
>>> 
>>> Thanks,
>>> Raphael
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] script translation - good practice?

[peter dalgaard]

Not a lawyer, but...

I would expect that it depends on what license it was published under 
originally. If it doesn't explicitly allow the creation of derivative works, 
then I would be wary.

-pd

> On 18 Sep 2019, at 13:59 , Raphael Bonnet  
> wrote:
> 
> Hi everyone,
> 
> I just rewrote a bit of Matlab code into R and that I would like to make it 
> available for the community.
> Unfortunately this bit of code has been published by authors that I've never 
> contacted.
> 
> I was wondering if I could submit a package to CRAN by keeping the same 
> license as the journal in which the code was published and citing the paper 
> and the authors.
> Can I associate myself as [cre, trl] in the description file?
> 
> Thanks,
> Raphael
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Misspelled words in DESCRIPTION

[peter dalgaard]

I'd write "PK/PD" though. Or did the world change while I was looking the other 
way?

-pd

> On 20 Aug 2019, at 00:42 , John Harrold  wrote:
> 
> Yeah that's it. Thanks Uwe and Ben.
> 
> On Mon, Aug 19, 2019 at 3:21 PM Ben Bolker  wrote:
> 
>> 
>>  I suspect the NOTE said something about "*possibly* misspelled words"
>> (emphasis added). This should be OK; just put the explanation below in
>> your notes to CRAN about the submission, clarifying that this is indeed
>> a false positive.
>> 
>>  cheers
>>Ben Bolker
>> 
>> On 2019-08-19 6:13 p.m., John Harrold wrote:
>>> Hello,
>>> 
>>> I am attempting to submit my first package to CRAN. I believe I've
>>> successfully gotten rid of all the notes, but there is one that I'm
>> unable
>>> to eliminate. In the DESCRIPTION file in both the Title and Description
>>> fields I use the term PKPD. This stands for Pharmacokinetics and
>>> Pharmacodynamics. It seems that none of these are recognized as words
>> that
>>> are spelled correctly. They are kind of important in the context of the
>>> package and there are no other better or more accurate descriptors that I
>>> can use.
>>> 
>>> Is there a way to get around this?
>>> 
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> 
> -- 
> John
> :wq
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Whack-a-mole base::assign(".ptime", proc.time(), pos = "CheckExEnv")

[peter dalgaard]

That line is a generic part of the timing (it records current time so that at 
the end you can do what amounts to "Time used:" proc.time() - .ptime). 

It is not likely to contain the actual error -- notice that the message just 
gives you a best guess of the error location and that may fail. You probably 
need to have a look at the actual radsafer-Ex.R file and its output to find the 
true culprit.

If you have catastrophic failures, yes, you see them only one at a time.

-pd

> On 30 Apr 2019, at 03:16 , Mark Hogue  wrote:
> 
> (The subject title is in reference to the arcade game where fake mole heads
> pop up and the contestant is challenged to smash them down as more and more
> keep popping up.)
> 
> I made some changes to a package and when I run the R CMD check, I get one
> error with this lead-in notification:
> 
> Running examples in 'radsafer-Ex.R' failed
>  The error most likely occurred in:
> *base::assign(".ptime", proc.time(), pos = "CheckExEnv")*
> 
> When I do something with the affected function, I get a similar error on
> another function.
> 
> Could it have something to do with my having added argument checks on these
> functions? Could someone advise where to go to understand this error
> better? And is it normal to get only one error at a time like this?
> 
> Thanks,
> 
> Mark
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] dtrti2 error on CRAN checks

[peter dalgaard]

Kurt Hornik submitted a bug report to the gfortran maintainers yesterday, and 
yes, it seems to have a lot to do with this.

He and Brian Ripley have been able to pinpoint it to certain gfortran revisions 
(specifically gfortran-9 at least r268992, or gfortran-8 at least r269349), but 
we're lacking a simple test case.

-pd

> On 18 Apr 2019, at 07:53 , Benjamin Christoffersen  wrote:
> 
> Thanks for the quick reply. First a correction. I meant Ubuntu 18.04.2
> of course, sorry.
> 
>> In short, you need to look more closely.
> Is there a way to tell which BLAS and LAPACK is used on the Debian
> machines on CRAN? I checked the "CRAN Package Check Flavors" page but
> there is no information there regarding BLAS or LAPACK.
> 
> I have tried to test the package with Atlas, OpenBlas, and the
> reference implementation with gcc 7.3.0 and 8.2.0. It all worked
> without any errors.
> 
> It seems that gcc has changed since January from version 8.2.0 and
> 7.3.0 to 8.3.0 on the tests on CRAN. Further, it is now Debian version
> 8.3.0-2 instead of Debian 8.2.0-7 and Debian 7.3.0-29. I do not know
> whether this can matter.
> 
> Sincerely yours,
> Benjamin Christoffersen
> 
> 
> 
> 
> 
> 
> 
> Den ons. 17. apr. 2019 kl. 11.38 skrev Dirk Eddelbuettel :
>> 
>> 
>> On 17 April 2019 at 11:06, Benjamin Christoffersen wrote:
>> | Since the start of April, I have gotten some errors on the Debian
>> | machines on the check on CRAN for my package dynamichazard. The places
>> | where I get the errors seems to come down to LAPACK's dtrtri routine.
>> | I have tried to reproduce the error on Debian 18.04.2 with clang 8.0.0
>> | but I cannot reproduce them.
>> |
>> | The errors came suddenly and the tests passed before. I see similar
>> | issues (I think) in the following package:
>> |  - RcppHMM
>> |  - BNPmix
>> |  - themetagenomics
>> |  - tidytext
>> |  - stm
>> |
>> | Any ideas what the error may be? Here is the relevant code parts for
>> | one of the failed tests:
>> | 
>> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/for_tests.cpp#L216
>> | 
>> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/arma_BLAS_LAPACK.cpp#L26
>> | 
>> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L67
>> 
>> There are four or more different sources of LAPACK and BLAS on Debian as we
>> (since the late 1990s !!)  utilize the nature of the _interface_ allowing
>> different packages to fill in.
>> 
>> So there could be
>>  i)   the R internal source with a partial library -- Fedora/CentOS use this
>>   but the Debian distro builds do not
>>  ii)  "reference BLAS", external, unoptimized
>>  iii) OpenBLAS, the successor to Goto, parallel via multithreading
>>  iv)  Atlas, "tuned" but not mulitthreading
>> and more as eg Intel MKL via a quick script (see my blog).
>> 
>> As a historical aside, and way-back-when, ii) earned us year's long growling
>> from the direction of Oxfordshire because some early/old versions of LAPACK
>> had bugs.  But it cuts both ways: the external versions tend to be complete
>> whereas what R ships with internally contains a subset -- and at least one
>> (early) user of RcppArmadillo was bitten when R built from sources using
>> defaults would not have the complex operations he needed. To R Core's credit
>> these missing functions got filled in over the years.
>> 
>> In short, you need to look more closely. On the Ubuntu 18.10 machine that I
>> type this on, sessionInfo()'s second paragraph has
>> 
>>  Matrix products: default
>>  BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
>>  LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.3.so
>> 
>> which IIRC is also the default (via some Debian/Ubuntu internal 'ordering' of
>> the available alternatives).
>> 
>> Hth, Dirk
>> 
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] attempt to re-insert old removed package

[peter dalgaard]

For most packages[*], I assume that you can just take on the role as 
maintainer, bump the version number and resubmit. If you don't actually 
maintain it, then of course it might fall of CRAN again after a while.

-pd

[*] Actually, I expect that CRAN policy implies "all" here; I just can't be 
bothered to check...


> On 5 Apr 2019, at 10:24 , Ramón Fallon  wrote:
> 
> Hi,
> 
> I've been searching for some procedures to try an get an old package back
> into CRAN.
> 
> It's package that has the re exclamation mark on cran github and is not
> available via install.packages() for modern version of R.
> 
> However some small changes to the source were enough to get it installed
> via R CMD INSTALL, so I thought I might how difficult it would be to get it
> back into the CRAN repo, but I have been able to find procedures for that
> process.
> 
> Any body who has managed this already? Helpful links appreciated, many
> thanks.
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] obscure syntax error

[peter dalgaard]

It could use a little whitespace, but I (and the Rstudio script editor) can't 
spot anything wrong, like mismatching braces or parens, and all 
else-at-beginning-of-line is inside the function. 

Could it be an incomplete last line?

-pd

> On 22 Mar 2019, at 11:18 , Jim Lemon  wrote:
> 
> Hi,
> I have been attempting to check a new version of the prettyR package,
> and have struck a difficult problem. The check fails at the
> installation, and when I track the error, it is "Unexpected end of
> input" in the xtab function. I have tried a number of things as I
> thought that it was a non-printing character (I have had that happen
> before). I can paste the entire function into an R session and there
> is no error. Has anyone struck an error like this before?
> 
> xtab<-function(formula,data,varnames=NULL,or=TRUE,chisq=FALSE,phi=FALSE,
> html=FALSE,bgcol="lightgray") {
> 
> if(missing(formula))
>  stop("Usage: 
> xtab(formula,data,varnames=NULL,or=TRUE,chisq=FALSE,phi=FALSE\n")
> ft<-as.character(attr(terms(formula),"variables")[-1])
> nft<-length(ft)
> if(nft>2) {
>  xt<-list()
>  by.factor<-as.factor(data[[ft[nft]]])
>  factor.levels<-levels(by.factor)
>  factor.labels<-attr(data[,ft[nft]],"value.labels")
>  if(!is.null(names(factor.labels))) factor.labels<-names(factor.levels)
>  if(is.null(factor.labels)) factor.labels<-factor.levels
>  nlevels<-length(factor.levels)
>  for(i in 1:nlevels) {
>   currentdata<-subset(data,by.factor==factor.levels[i])
>   for(j in 1:dim(currentdata)[2])
>attr(currentdata[,j],"value.labels")<-attr(data[,j],"value.labels")
>   currentcount<-length(currentdata[[nft]])
>   totalcount<-length(data[[nft]])
>   cat("\nCount for",ft[nft],"=",factor.labels[i],"is",currentcount,
>"(",round(100*currentcount/totalcount,1),"%)\n\n")
>   rightside<-ifelse(nft>3,paste(ft[2:(nft-1)],sep="",collapse="+"),ft[2])
>   next.formula<-as.formula(paste(ft[1],rightside,sep="-",collapse=""))
>   xt[[i]]<-xtab(next.formula,data=currentdata,varnames=varnames,chisq=chisq,
>phi=phi,html=html,bgcol=bgcol)
>  }
> }
> else {
>  if(missing(data)) xt<-calculate.xtab(get(ft[1]),get(ft[2]),varnames=varnames)
>  else xt<-calculate.xtab(data[,ft[1]],data[,ft[2]],varnames=varnames)
> }
> attr(xt,"class")<-"xtab"
> return(xt)
> }
> Thanks for any pointers.
> 
> Jim
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[peter dalgaard]

It's not "stealth fixed"! It was never there... (on the release branch)

The timestamp checking code is still present in R-devel. I presume something 
needs to be done about the breakage.

- pd

> On 7 Mar 2019, at 14:38 , Bob Rudis  wrote:
> 
> It's fixed in the RC that's GA on the 11th.
> 
> I think perhaps "stealth fixed" may be more appropro since it's not in SVN 
> logs, Bugzilla nor noted prominently in any of the various NEWS* files.
> 
> Then there's the "why was the core R installation using a third party, 
> non-HTTPS site for this to begin with".
> 
> And, in other news, there are tests in the R source that rely on a check of 
> `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is 
> registered. Thankfully there's no current IP address associated with it. 
> Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might be 
> a better choice as well since that won't break the reason for the 
> connectivity checks and won't arbitrarily send telemetry pings to third 
> parties in the even anyone outside of R Core decides to run the tests (say, 
> when patching something in R).
> 
> -boB
> 
>> On Mar 7, 2019, at 07:54, Rainer M Krug  wrote:
>> 
>> I can confirm the same when checking on travis with r-devel.
>> 
>> And thanks for the tip with
>> 
>> env:
>> - _R_CHECK_SYSTEM_CLOCK_=0
>> 
>> In .travis.yml
>> 
>> Seems to be working now
>> 
>> Rainer
>> 
>> 
>> 
>>> On 7 Mar 2019, at 12:48, Ralf Herold  wrote:
>>> 
>>> Dear All,
>>> 
>>> Checking a new package under development produces a warning in a local 
>>> R-devel MS Windows environment (output below).
>>> 
>>> Building it with R-devel on Travis fails (because warnings are changed to 
>>> errors), but is successful when setting environment variable 
>>> _R_CHECK_SYSTEM_CLOCK_ to zero.
>>> 
>>> No issue occurs when checking and building with R-stable and R-oldrel on 
>>> Travis, or with any R version on win-builder.r-project.org.
>>> 
>>> The warning concerns using http://worldclockapi.com/, which however seems 
>>> out of service ("The web app you have attempted to reach is currently 
>>> stopped and does not accept any requests."). This is referenced in the main 
>>> function for R CMD check 
>>> (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may 
>>> concern more R-devel than R-package-devel. I am posting here to check if 
>>> the issue was noticed by other package developers and to check the impact.
>>> 
>>> Thanks for any suggestions.
>>> Best regards,
>>> Ralf
>>> 
>>> 
>>> PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe' CMD check 
>>> E:\mypackage_0.1.2.3.tar.gz --as-cran
>>> * using log directory 'C:/Users/username/ctrdata.Rcheck'
>>> * using R Under development (unstable) (2019-03-05 r76200)
>>> * using platform: x86_64-w64-mingw32 (64-bit)
>>> * using session charset: ISO8859-1
>>> * using option '--as-cran'
>>> [...]
>>> * checking package directory ... OK
>>> * checking for future file timestamps ...Warning in file(con, "r") :
>>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
>>> was '403 Site Disabled'
>>> WARNING
>>> unable to verify current time
>>> * checking 'build' directory … OK
>>> [...]
>>> 
>>> 
>>> 
>>> ## Ralf Herold
>>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>>> ## https://paediatricdata.eu/
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> 
>> 
>> 
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982
>> 
>> 
>>  [[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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R

[peter dalgaard]

The difference is obviously in the "con" men. The definition of role="con" in 
the MARC code list is

Conservator [con]
A person or organization responsible for documenting, preserving, or treating 
printed or manuscript material, works of art, artifacts, or other media
UF Preservationist

Is this as intended?

-pd

> On 6 Feb 2019, at 13:26 , Ivan Krylov  wrote:
> 
> Hi!
> 
> I'm relying on Authors@R to generate the Author: and Maintainer:
> headers. When checking my package at win-builder using R-unstable, I
> got a NOTE that Author field differs from that derived from Authors@R:
> 
>>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'
> 
>>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>>> [cre, cph]'
> 
> Link to full check output:
> https://win-builder.r-project.org/EWz9zWS0niO3/
> 
> The actual field from DESCRIPTION now looks like this:
> 
>>> Authors@R: c(person('Miquel', 'Garriga', email =
>>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>>> c('con', 'cph')), person('Alexander', 'Semke', email =
>>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))
> 
> The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
> stable, which might explain the differences in utils:::format.person.
> 
> What should I do to avoid the NOTE?
> 
> -- 
> Best regards,
> Ivan
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] RData files with identical objects in package

[peter dalgaard]

There is (of course) a difference between what is the default for a (missing) 
field in DESCRIPTION and what shells like RStudio put into the field by 
default... 

I don't think there is a discrepancy between what is in the official 
documentation and what R and R CMD * actually does.

-pd

> On 14 Jan 2019, at 07:10 , Troels Ring  wrote:
> 
> Thank you so much! Perhaps it could be mentioned in the official
> documentation on writing R extensions - even if - if I can read English -
> the 
> default is to avoid "lazyData" loading - and "laxyData" loading is in some
> opposition to loading using data() - whereas - if we use RStudio, and make
> an R documentation file for data, we have it ending with:
> \examples{
> data(ddd)
> ## maybe str(ddd) ; plot(ddd) ...
> }
> \keyword{datasets}
> 
> At the same time as "lazyData" is used default in DESCRIPTION ?
> 
> 1.1.6 Data in packages
> The data subdirectory is for data files, either to be made available via
> lazy-loading or for loading using data(). (The choice is made by the
> 'LazyData' field in the DESCRIPTION file: the default is not to do so.) It
> should not be used for other data files needed by the package, and the
> convention has grown up to use directory inst/extdata for such files.
> 
> All best wishes
> Troels
> 
> 
> -Oprindelig meddelelse-
> Fra: peter dalgaard  
> Sendt: 13. januar 2019 22:00
> Til: Troels Ring 
> Cc: Michael Dewey ; package-develop
> 
> Emne: Re: [R-pkg-devel] RData files with identical objects in package
> 
> I think it is illegal if you use the lazyload database, because that is
> indexed by name and contains every object that would be created by data().
> This creates an obvious issue if two objects share a name. 
> 
> Once you use the lazyload database, loading the package creates an
> environment which is initially full of promises, one for each object.
> Evaluating one of these makes the actual object appear in the environment. 
> 
> Using data() causes the corresponding promise(s) to be created in the global
> environment. IIRC, there is a registry that says which objects are created
> by which arguments to data(), but as they are still taken from the lazydata
> database, the last one created with a given name still wins.
> 
> -ps 
> 
>> On 13 Jan 2019, at 14:13 , Troels Ring  wrote:
>> 
>> Thanks a lot - I'm sure you are right that I could just use different 
>> names but I cannot understand why it could cause problem to have two 
>> different well formated .RData files in the /data directory both with 
>> an "x" - is that really illegal? I cannot see it stated in the 
>> official munual - but it is long (wrting r extensions) -BW Troels
>> 
>> -Oprindelig meddelelse-
>> Fra: Michael Dewey 
>> Sendt: 13. januar 2019 12:56
>> Til: Troels Ring ; package-develop 
>> 
>> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>> 
>> Dear Troels
>> 
>> Perhaps I misunderstand what you are trying to do but would it be 
>> possible to put each x and y into a list or a dataframe with different 
>> names and then modify your usgae to pull them from there? Then there 
>> would be no danger of users getting the wrong x and y
>> 
>> Michael
>> 
>> On 13/01/2019 08:38, Troels Ring wrote:
>>> Dear friends - I have a package under creation making heavy 
>>> calculations on chemical/clinical data and I plan to include as 
>>> "examples" the use of some literature data used in my papers. To 
>>> illustrate what then occurs, I made two RData files consisting only 
>>> of x and y with different values for x and y like
>>> 
>>> X <- 100
>>> 
>>> Y <- 1000
>>> 
>>> save(x,y,file="first.RData")
>>> 
>>> and then a new x and y in "second" with x <- 45 and y <- 32
>>> 
>>> When I put these in a "data" directory of a new package without 
>>> further ado in RStudio
>>> 
>>> Ctrl-shift-L
>>> 
>>> Ctrl-shift-B
>>> 
>>> 
>>> 
>>> .there is a warning
>>> 
>>> * installing *source* package 'try' ...
>>> 
>>> ** R
>>> 
>>> ** data
>>> 
>>> *** moving datasets to lazyload DB
>>> 
>>> warning: objects 'x', 'y' are created by more than one data call
>>> 
>>> ** byte-compile and prepare package for lazy loading
>>> 
>>> ** help
>>> 
>>>  converting help for package 'try'
>

Re: [R-pkg-devel] Package update submission to CRAN fails on pretest

[peter dalgaard]

Hmm, no ERRORs in the CRAN checks at this moment? 

Re. utf-8, on Mac OS, the CRAN checks have a note about 90 strings marked as 
utf8.

I see 57 of them in


> life$Country[Encoding(life$Country)!="unknown"]
 [1] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep."
 [3] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep."
 [5] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep."
...

and 32 more in "mortality". You go find the remaining 1...

This seems to be an issue with the quote symbol:


> u <- life$Country[Encoding(life$Country)!="unknown"][1]
> Encoding(u)
[1] "UTF-8"
> Encoding(u) <- "bytes"
> u
[1] "Korea, Dem. People\\xe2\\x80\\x99s Rep."


I have no clue why this is not an issue on only some platforms.

-pd


> On 7 Dec 2018, at 08:54 , Wolfgang Lenhard 
>  wrote:
> 
> Dear list,
> I am getting problems when trying to submit an update of the package 
> cNORM to CRAN. I am developing the package with RStudio and devtools and 
> I am using Travis for automatic testing. The package is tested locally 
> on Win10 and Mac OS X and on Travis with Ubuntu and Mac both for 
> development and release versions of R. All local tests and tests on 
> Travis work flawlessly - no errors, warning or notes. When submitting to 
> CRAN, a note and an error show up on some of the Linux OS (Fedora & 
> Solaris) and Mac OS X, while others display an 'OK' (Win, Debian). The 
> results: https://cran.r-project.org/web/checks/check_results_cNORM.html
> 
> - error: This seems to be related to the vignette with the following 
> message:
>> * checking examples ... ERROR
>> Running examples in ‘cNORM-Ex.R’ failed
> I can however not identify the location of the error
> 
> - Note: Check: data for non-ASCII characters
> 
> The strange thing is: I checked all data files multiple times. They 
> mainly consist of data.frames with numerics and all colnames  are ASCII. 
> I am not able to replicate the issue. The same is true for the error, 
> which does not show up on Travis and as well locally. And finally, the 
> results state, that the version of the package is 1.0.1, which had been 
> the first submission to CRAN a month ago. The current version of the 
> package is 1.1.1. Could this be the reason for the problem?
> 
> Do you have an idea how to progress with the testing or how to locate 
> the errors? Any help is welcome.
> 
> Best regards,
> Wolfgang Lenhard
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Effieciency drop in do.call?

[peter dalgaard]

A classical way of encountering this is

x <- rnorm(1000)
do.call("plot", list(x))

A way out is

do.call("plot", list(quote(x)))

-pd


> On 19 Nov 2018, at 22:32 , peter dalgaard  wrote:
> 
> If it was just about args evaluation, then the slowness would be in the 
> list() call, no?
> An accidental deparse of a large structure could well be the culprit.
> 
> -pd
> 
> 
>> On 19 Nov 2018, at 18:53 , Gabor Grothendieck  
>> wrote:
>> 
>> The do.call version evaluates all arguments while the normal version
>> may not depending on the function.  There could also be a difference
>> if the function uses non-standard evaluation since in that case the
>> two could be passing different different argument values.
>> 
>> For an example of the second case,
>> 
>> f <- function(x) deparse(substitute(x))
>> 
>> f(pi)
>> ## [1] "pi"
>> 
>> do.call("f", list(pi))
>> ## [1] "3.14159265358979"
>> 
>> On Mon, Nov 19, 2018 at 11:50 AM Paul Buerkner  
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> today, I stumbled upon a puzzling (to me) problem apparently related to
>>> do.call() that resulted
>>> in an efficiency drop of multiple orders of magnitudes compared to just
>>> calling the function directly (multiple minutes as compared to one second).
>>> 
>>> That is
>>> 
>>> fun(a = a, b = b, c = c, ...)
>>> 
>>> took one second, while
>>> 
>>> args <- list(a = a, b = b, c = c, ...)
>>> do.call(fun, args)
>>> 
>>> took multiple minutes.
>>> 
>>> In my package (brms), I use do.call in various places but only in one it
>>> resulted in this
>>> efficiency drop.
>>> 
>>> Before I try to make a reproducible example, I wanted to ask if there are
>>> any known issues
>>> with do.call that may explain this?
>>> 
>>> Paul
>>> 
>>>   [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> 
>> 
>> -- 
>> Statistics & Software Consulting
>> GKX Group, GKX Associates Inc.
>> tel: 1-877-GKX-GROUP
>> email: ggrothendieck at gmail.com
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Effieciency drop in do.call?

[peter dalgaard]

If it was just about args evaluation, then the slowness would be in the list() 
call, no?
An accidental deparse of a large structure could well be the culprit.

-pd


> On 19 Nov 2018, at 18:53 , Gabor Grothendieck  wrote:
> 
> The do.call version evaluates all arguments while the normal version
> may not depending on the function.  There could also be a difference
> if the function uses non-standard evaluation since in that case the
> two could be passing different different argument values.
> 
> For an example of the second case,
> 
>  f <- function(x) deparse(substitute(x))
> 
>  f(pi)
>  ## [1] "pi"
> 
>  do.call("f", list(pi))
>  ## [1] "3.14159265358979"
> 
> On Mon, Nov 19, 2018 at 11:50 AM Paul Buerkner  
> wrote:
>> 
>> Hi all,
>> 
>> today, I stumbled upon a puzzling (to me) problem apparently related to
>> do.call() that resulted
>> in an efficiency drop of multiple orders of magnitudes compared to just
>> calling the function directly (multiple minutes as compared to one second).
>> 
>> That is
>> 
>> fun(a = a, b = b, c = c, ...)
>> 
>> took one second, while
>> 
>> args <- list(a = a, b = b, c = c, ...)
>> do.call(fun, args)
>> 
>> took multiple minutes.
>> 
>> In my package (brms), I use do.call in various places but only in one it
>> resulted in this
>> efficiency drop.
>> 
>> Before I try to make a reproducible example, I wanted to ask if there are
>> any known issues
>> with do.call that may explain this?
>> 
>> Paul
>> 
>>[[alternative HTML version deleted]]
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
> 
> -- 
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Unexpected symbol when checking package examples

[Peter Dalgaard]

Not just a capitalization issue (mertools vs. merTools)?

Barring that, maybe locale trouble? Can you also do things like

LC_ALL=C R < merTools-Ex.R

?

Also, check for lines starting with "else" (I think you shouldn't be able to 
run it line-by-line if that was the issue, though).

-pd

> On 11 Nov 2018, at 21:39 , Jared Knowles  wrote:
> 
> Hi!
> 
> I have a bit of a weird issue when I'm trying to check my package merTools
> (source repo available here: https://github.com/jknowles/merTools
> 
> On Windows and Linux builds for R-release and R-devel, when R CMD CHECK
> checks examples, it returns the following error below:
> 
> Warning: parse error in file 'merTools-Ex.R':
> 1: unexpected symbol
> 117: cleanEx()
> 118: nameEx
> 
> 
> Upon inspecting the example file generated by R CMD CHECK (mertools-Ex.R) -
> it contains only valid R code. I can run it line by line or source the
> whole file in R without any errors. But, during the check process, this
> error occurs.
> 
> The functions cleanEx() and nameEx() appear to be created as part of the
> checking process.
> 
> I have not changed the examples in the code since the last time I ran R CMD
> CHECK so I am quite confident that the example code for all functions is
> valid R code.
> 
> Any ideas on what might be the source of this problem?
> 
>   Thanks!
> Jared
> 
> 
> 
> Jared Knowles
> President, Civilytics Consulting LLC
> www.jaredknowles.com
> 
>   [[alternative HTML version deleted]]
> 
> ______
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] R graphics 'text' package 'adj' parameter order wrong incorrect reversed?

[peter dalgaard]

Exactly. And left alignment means that the left end of the text is aligned with 
the anchor point, etc. So documentation is correct.

-pd

> On 19 Sep 2018, at 01:33 , Jim Lemon  wrote:
> 
> Hi Simon,
> I think the conventions of typesetting are to blame. Think of an
> invisible box around the text being displayed.
> __
> |Left justification  |
> |-|
> meaning that the text _starts_ at the left of the field and is to the
> right of the text position specified
> __
> |Right justification|
> |-|
> 
> meaning that the text _ends_ at the right of the field and is to the
> left of the text position. Can't do the top and bottom justification
> this way, but I think you get the idea.
> 
> Jim
> 
> On Wed, Sep 19, 2018 at 9:13 AM Simon Dedman  wrote:
>> 
>> Original stack overflow post here:
>> https://stackoverflow.com/questions/52194719/r-graphic-text-package-adj-parameter-order-wrong-incorrect-reversed
>> 
>> Hopefully this is now the appropriate place to post this as the above post
>> got a single comment of agreement.
>> 
>> Content:
>> 
>> I believe R core package graphics text function's adj parameter is
>> incorrectly described in the manual
>> <https://stat.ethz.ch/R-manual/R-devel/library/graphics/html/text.html> and
>> would be grateful if someone could confirm this before I submit a bug report
>> <https://www.r-project.org/bugs.html>.
>> 
>> adj text:
>> 
>> adj allows adjustment of the text with respect to (x, y). Values of 0, 0.5,
>> and 1 specify left/bottom, middle and right/top alignment, respectively.
>> 
>> Since text controls these labels and not the points which have already been
>> plotted, I can't see how "with respect to x,y" can mean anything other than
>> "in this direction relative to their points".
>> 
>> However the order is reversed: 0,0 (supposedly left & bottom) is top &
>> right; 1,1 (supposedly right & top) is left and bottom.
>> 
>> Reproducible example:
>> 
>> tens = 1:10
>> plot(tens, tens, xlab = "adj 0,0 left/bottom")
>> text(tens, tens, labels = letters[tens], adj = c(0,0))
>> plot(tens, tens, xlab = "adj 0.5,0.5 middle")
>> text(tens, tens, labels = letters[tens], adj = c(0.5,0.5))
>> plot(tens, tens, xlab = "adj 1,1 right/top")
>> text(tens, tens, labels = letters[tens], adj = c(1,1))
>> 
>> Thanks.
>> 
>>[[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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Replicate solaris errors

[peter dalgaard]

Have you tried asking CRAN for help? I mean, if you don't fix an obvious error, 
with a well-known cause, like the log thing, they'll get fed up and throw you 
off. However, fixing and then discovering an issue elsewhere is different, 
especially if you cannot easily reproduce it at your end. 

-pd

> On 11 Aug 2018, at 20:41 , Thibault Vatter  wrote:
> 
> Yes, the non-portable call to log which causes the current build to fail on
> solaris has been corrected in a development version. However, the segfault
> that we don't understand and were asked to correct was present in the
> previous versions (e.g., 0.2.8.1.0 and 0.2.7.1.0), and we believe that it
> is likely to reappear if we resubmit with only the non-portable log call
> corrected.
> 
> This is why, in order to avoid resubmitting with the segfault still there
> and having the package removed from CRAN, we would like to be able to
> replicate the solaris build.
> 
> On Sat, Aug 11, 2018 at 2:17 PM Iñaki Úcar  wrote:
> 
>> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter
>> () escribió:
>>> 
>>> Dear package developers,
>>> 
>>> We've recently received an email letting us know that our package
>>> rvinecopulib (
>>> https://cran.r-project.org/web/packages/rvinecopulib/index.html) would
>> be
>>> removed from CRAN unless the errors from the solaris build were
>> corrected.
>>> 
>>> Note that the package compile and the unit tests pass on the other test
>>> platforms from CRAN and even a local R devel build with ASAN / UBSAN
>>> sanitizers. On solaris, the package compiles but a segfault is produced
>> by
>>> one unit test for a reason that we still don't understand.
>> 
>> Are you talking about a new development version that is not still on
>> CRAN? Because the current CRAN version fails to install.
>> 
>> Iñaki
>> 
>>> 
>>> To replicate the issue, I tried to mimic CRAN's solaris config (
>>> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a
>>> virtual machine following the steps in the gist below (based on
>> Jeroen's):
>>> 
>>> https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6
>>> 
>>> Note that the "--with-readline=no" configure option at the end was added
>>> because I got "configure: error: --with-readline=yes (default) and
>>> headers/libs are not available" without it.
>>> 
>>> Unfortunately, I then got the "configure: error: a suitable iconv is
>>> essential" and could not proceed to build R.
>>> 
>>> I know that I should get GNU iconv as specified in the installation
>> manual,
>>> hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I
>>> verified that iconv is in /opt/csw/lib as expected and I thought that
>>> adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would
>>> then do the trick, but it does not seem to be the case.
>>> 
>>> Two questions:
>>> 
>>> 1) What did I miss or do wrong?
>>> 
>>> 2) Anyone found a way to replicate solaris CRAN builds to test packages?
>> I
>>> tried to use https://builder.r-hub.io/, but some of my package's
>>> dependencies fail to install because of udunits2 is missing on their
>> system
>>> if I recall correctly.
>>> 
>>> Thibault
>>> 
>>>[[alternative HTML version deleted]]
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Warnings and error message in CRAN Package Check Results

[peter dalgaard]

> On 25 Mar 2018, at 00:42 , Wenchao Ma <wenchao2...@gmail.com> wrote:
> 
>arma::vec Pj = Calc_Pj(par = par, designMj = designMj, linkfunc = 
> linkfunc, boundary = boundary, eps = eps);

I was never any good at C++, but that syntax looks like R code. Does C++ allow 
tag=value argument specification? Aren't all the subexpressions of type "par = 
par" just assignments??

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] win-builder 3.3.3 libcurl error + NOTE

[peter dalgaard]

Sorry, I forgot: We don't switch until _release_ of 3.5.0, four weeks further 
down the line. Still, it doesn't seem worth it making much of a fuss about 
3.3.3.

-pd

> On 24 Mar 2018, at 10:10 , peter dalgaard <pda...@gmail.com> wrote:
> 
> Given that R-oldrelease will become 3.4.4 when we branch for 3.5.0 on Monday, 
> perhaps you could just wait it out?
> 
> -pd
> 
>> On 23 Mar 2018, at 17:59 , Tyler <tyle...@gmail.com> wrote:
>> 
>> I am getting a NOTE only on R-oldrelease when checking my package on
>> win-builder:
>> 
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: 'Tyler Morgan-Wall <tyle...@gmail.com>'
>> 
>> Found the following (possibly) invalid URLs:
>> URL: http://github.com/tylermorganwall/skpr
>>   From: DESCRIPTION
>>   Status: Error
>>   Message: libcurl error code 35
>>  error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
>> protocol version
>> URL: http://github.com/tylermorganwall/skpr/issues
>>   From: DESCRIPTION
>>   Status: Error
>>   Message: libcurl error code 35
>>  error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
>> protocol version
>> 
>> I checked the version of the package currently on the CRAN that passed
>> without any libcurl errors or NOTEs back in January, and it too displayed
>> this NOTE, which again only occurred on R-oldrelease. Is there a way to
>> prevent this or should I just mention this NOTE in my CRAN submission
>> comment?
>> 
>> Tyler
>> 
>>  [[alternative HTML version deleted]]
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] win-builder 3.3.3 libcurl error + NOTE

[peter dalgaard]

Given that R-oldrelease will become 3.4.4 when we branch for 3.5.0 on Monday, 
perhaps you could just wait it out?

-pd

> On 23 Mar 2018, at 17:59 , Tyler <tyle...@gmail.com> wrote:
> 
> I am getting a NOTE only on R-oldrelease when checking my package on
> win-builder:
> 
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: 'Tyler Morgan-Wall <tyle...@gmail.com>'
> 
> Found the following (possibly) invalid URLs:
>  URL: http://github.com/tylermorganwall/skpr
>From: DESCRIPTION
>Status: Error
>Message: libcurl error code 35
>   error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> protocol version
>  URL: http://github.com/tylermorganwall/skpr/issues
>From: DESCRIPTION
>Status: Error
>Message: libcurl error code 35
>   error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> protocol version
> 
> I checked the version of the package currently on the CRAN that passed
> without any libcurl errors or NOTEs back in January, and it too displayed
> this NOTE, which again only occurred on R-oldrelease. Is there a way to
> prevent this or should I just mention this NOTE in my CRAN submission
> comment?
> 
> Tyler
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission Rpolyhedra 0.2.2

[peter dalgaard]

The NOTEs look harmless, the WARNING is this

 (InternalException (HostCannotConnect "badges.ropensci.org" [connect: failed 
(Connection refused (WSAECONNREFUSED))]))

so badges did not want to speak to win-builder. Doesn't look like something you 
can deal with, except by removing the offending badge from README.md. 

The "Current CRAN" business is about the previous version, so likely irrelevant.

It seems reasonable for you to take the "false positive" route.

-pd


> On 15 Mar 2018, at 06:38 , alejandro baranek <alejandrobara...@gmail.com> 
> wrote:
> 
> Hi list:
> 
> Please someone can help me with the stranges errors I recivied after a
> minor bugfix in my package? tests ok, devtools::check() ok, TRAVIS CI ok...
> What is the problem?
> 
> Best, Ale.
> 
> -- Forwarded message --
> From: <uwe.lig...@r-project.org>
> Date: 2018-03-15 1:39 GMT-03:00
> Subject: [CRAN-pretest-archived] CRAN submission Rpolyhedra 0.2.2
> To: abara...@dc.uba.ar
> Cc: cran-submissi...@r-project.org
> 
> 
> Dear maintainer,
> 
> package Rpolyhedra_0.2.2.tar.gz does not pass the incoming checks
> automatically, please see the pre-test at:
> <https://win-builder.r-project.org/incoming_pretest/180315_
> 032641_Rpolyhedra_022/00check.log>
> Status: 1 WARNING, 2 NOTEs
> 
> Current CRAN status: ERROR: 5, NOTE: 3, OK: 4
> See: <https://CRAN.R-project.org/web/checks/check_results_Rpolyhedra.html>
> 
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on
> the R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please
> reply-all to this message and explain.
> 
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/180315_
> 032641_Rpolyhedra_022>
> The files will be removed after roughly 7 days.
> 
> 
> Best regards,
> CRAN teams' auto-check service
> 
> 
> 
> 
> -- 
> alejandro baranek
> @ken4rab <https://twitter.com/ken4rab>
> qbotics <http://qbotics.tumblr.com/> | surferinvaders
> <http://surferinvaders.tumblr.com> | algebraic-soundscapes
> <http://imaginary.org/content/algebraic-soundscapes> | surfer-shuffle
> <http://imaginary.org/program/surfer-shuffle>
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Warning "Dependence on R version '3.3.3' not with patchlevel 0"

[peter dalgaard]

Yep. Bear in mind that many system-wide installation, e.g. in universities, are 
of .0 or .1 releases and upgraded yearly. If we end up with packages depending 
on packages depending on a later version, bad things can happen (and _did_ 
happen in the 3.2.* series). For the same reason, we have become very careful 
not to add features into R-patched,so it should be rather unlikely that 
packages that work with x.y.z do not also work with x.y.0.

-pd

> On 3 Jan 2018, at 14:33 , Uwe Ligges <lig...@statistik.tu-dortmund.de> wrote:
> 
> 
> 
> On 03.01.2018 13:59, Hockemeyer, Cord (cord.hockeme...@uni-graz.at) wrote:
>> Hi everybody,
>> on submitting a new package I got a rejection because of the above warning 
>> in the CRAN-check. I guess it is because of the "Depends" entry "R (>= 
>> 3.3.3)" in the DESCRIPTION file but I have no idea how to do this otherwise. 
>> Any hel�p would be highly appreciated.
> 
> If sufficient, use R (>= 3.3.0), otherwise R (>= 3.4.0): If you rely on a 
> specific patchlevel, binary repositories are inconsistant on CRAN and 
> typically you should be able to rely on a x.y.0 release.
> 
> Best,
> Uwe Ligges
> 
> 
>> Best regards,
>>Cord
>> Cord Hockemeyer
>> Institut f�r Psychologie, Universit�t Graz
>> Tel.: +43 316 380 8531
>> https://psychologie.uni-graz.at/allgemeine/hockemeyer
>>  [[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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] package dependencies not detected?

[peter dalgaard]

> On 16 Aug 2017, at 11:11 , Berry Boessenkool <berryboessenk...@hotmail.com> 
> wrote:
> 
> 
> Hi,
> 
> 
> if a function in a package uses graphics::legend in the code, but does not 
> import it in the namespace, shouldn't there be a warning in the check?
> 

Er, no... Importing into a namespace is used to avoid the graphics:: qualifier. 
This is conceptually different from having a dependency.

-pd


> There is not, also not on CRAN (one of my packages did this with 
> stats::density).
> 
> Should I report this to the CRAN team?
> 
> 
> Regards,
> 
> Berry
> 
> 
> Here's a minimal working example using devtools:
> 
> ### install.packages(c("devtools","roxygen2"))
> 
> # create package structure 
> getwd()
> devtools::create("testPack", description=list(License="GPL (>=2)"))
> setwd("testPack/")
> devtools::check() # everything is fine
> 
> # add function 
> cat("
> #' @title test function
> #' @description test function
> #' @export
> #' @importFrom graphics plot
> #' @examples testFun(1:6, col=2)
> #' @param x Values
> #' @param args List of arguments passed to legend
> #' @param \\dots Further arguments passed to plot
> #'
> testFun <- function(
>  x,
>  args=list(x='topright', legend=c('A','B'), lty=1),
>  ...
>  )
>  {
>  plot(x, ...)
>  do.call(graphics::legend, args)
>  }
> ", file="R/testFun.R")
> 
> devtools::check() # no problems - even though I only import plot, not legend
> # same thing if I use graphics::legend directly (outside of do.call)
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

[R-pkg-devel] R 3.4.1 at end of June

[peter dalgaard]

Just a quick note to say that we intend to have a patch release, probably on 
June 30, mainly to pick up a few balls that were dropped on the 3.4.0 release. 
Full schedule to appear later (just need a little time to actually set it up + 
checking that the date doesn't collide with schedules of other people).

- Peter Dalgaard

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com











-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com











-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Help package checks using valgrind

[peter dalgaard]

mative output?
>(for Fedora or any other platforms using docker)
> 
> 3) Any alternative methods recommended for tracking this down instead of 
> using valgrind?
> 
> 
> 
> Thanks!
> Merlise
> 
>> sessionInfo()
> R version 3.4.0 (2017-04-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Fedora 23 (Twenty Three)
> 
> Matrix products: default
> BLAS: /usr/local/lib64/R/lib/libRblas.so
> LAPACK: /usr/local/lib64/R/lib/libRlapack.so
> 
> 
> source code is at http://github.com/merliseclyde/BAS
> 
> 
> 
> Merlise A Clyde
> Professor & Chair Department of Statistical Science
> Duke University
> http://stat.duke.edu/~clyde
> 
> cl...@duke.edu<mailto:cl...@duke.edu>
> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] R Packages Never Finish Check

[peter dalgaard]

l --as-cran'
>> * checking for file 'linkedata/DESCRIPTION' ... OK
>> * checking extension type ... Package
>> * this is package 'linkedata' version '0.1.0'
>> * checking package namespace information ... OK
>> * checking package dependencies ... NOTE
>> Package suggested but not available for checking: 'pvsolcalcs'
>> * checking if this is a source package ... OK
>> * checking if there is a namespace ... OK
>> * checking for executable files ... OK
>> * checking for hidden files and directories ... OK
>> * checking for portable file names ... OK
>> * checking whether package 'linkedata' can be installed ... OK
>> * checking installed package size ...
>> 
>> 
>> 
>> 
>> 
>> **
>> This e-mail and any attachments thereto may contain confidential information 
>> and/or information protected by intellectual property rights for the 
>> exclusive attention of the intended addressees named above. If you have 
>> received this transmission in error, please immediately notify the sender by 
>> return e-mail and delete this message and its attachments. Unauthorized use, 
>> copying or further full or partial distribution of this e-mail or its 
>> contents is prohibited.
>> **
>> 
>>  [[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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

[peter dalgaard]

I don't have hard info on ABI compatibility between gcc versions, but there 
have been issues in the past, at least with with gfortran.

Now, many people/schools will have R-3.2.x installed, built with gcc 4.6.y. We 
cannot retroactively recompile their installation, nor expect them to install a 
new version built with gcc 4.9.z. This raises a specific question and a generic 
one:

- specific: Will a package binary of gower built with 4.9 work with R built 
with 4.6?
- generic: Is is sufficiently likely that a given package if compiled with a 
different compiler version that CRAN would consider having a mechanism to 
specify a particular compiler version?

I suspect that the answer to the second question is no.

Whether to condition on R >= 3.3 is a good idea largely depends on two things

- the user base (would they upgrade R anyways?)
- are there other packages that depends on gower? (CRAN keeps only the newest 
version of a package so requiring a newer R could affect users with less 
aggressive update policies. This already happened when the pbkrtest package 
update rendered the car package unloadable.)

You do have a 4th option: conditionalize the _code_ on the R version, then 
remove old-style code when 3.2.x becomes history.

-pd

On 25 Aug 2016, at 11:20 , Mark van der Loo <mark.vander...@gmail.com> wrote:

> Dear listers,
> 
> 
> Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
> that this is because it uses gcc 4.6.3 which has limited support for OpenMP
> (the errors are the same as I got on the old travis-ci build environment,
> see my related question[1]).
> 
> Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
> toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
> included." Not sure what that says about CRAN, but I'm hoping/guessing it
> uses Rtools the same way as we do.
> 
> So I guess I have the following options:
> 
> - make my package depend on R>=3.3
> - Alter my code (as kindly suggested by Ott Toomet in [1])
> - Tell CRAN to use the modern compiler.
> 
> Obviously, the latter would be easiest. Is this is even possible? For a
> local installation I could set an environment variable[3], but how about
> doing this at CRAN?
> 
> Thanks,
> Mark
> 
> 
> [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
> [2] https://cran.r-project.org/bin/windows/Rtools/
> [3]
> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> 
>   [[alternative HTML version deleted]]
> 
> ______
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Pkgs with ToS violations

[peter dalgaard]

On 04 Aug 2016, at 05:21 , Dirk Eddelbuettel <e...@debian.org> wrote:

> 
> On 3 August 2016 at 22:26, Bob Rudis wrote:
> | I came across https://cran.rstudio.com/web/packages/boxoffice/index.html
> | in CRAN today and while I don't expect CRAN to be a legal authority,
> | should there not be some kind of policy for excluding R packages that
> | deliberately violate (data) site ToS? (I'm asking this here vs sending
> | a note to CRAN folks since I tend to be a bit sensitive to this
> | particular issue).
> | 
> | Box Office Mojo - which is really just Amazon - clearly states that
> | the activities this package facilitates are in violation of their ToS.
> | Unlike examples on blogs that also violate BOM ToS, this pkg in CRAN
> | is almost legitimizing the violations.
> | 
> | Amazon only goes after a few folks a year and it's unlikely R folks
> | will be their target (for now) but that doesn't make it OK IMO.
> | 
> | Is this worth bringing up to CRAN?
> 
> I think so.
> 


By all means bring it up. But there's the usual tools-vs-action discussion, and 
I do notice that the ToS has

• Licensing IMDb's Content; Consent to Use Robots and Crawlers: If you are 
interested in receiving our express written permission to use our content for 
your non-personal (including commercial) use, please contact our Licensing 
Department. We do allow the limited use of robots and crawlers, such as those 
from certain search engines, with our express written consent. 

I.e., it could be a matter of suitable flagging of the software as requiring 
permission. You likely don't wnat CRAN to run automated tests that run 
scrapers, though.

-pd 


> Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Recommendation on qr method export

[Peter Dalgaard]

Not strictly what you're asking, but at some point it may be important to note 
that the "QR" method used by lm() and friends (notably anova() and aov()) 
actually relies on successive orthogonalization. This does yield a QR 
decomposition but the reverse is not true. A generic X=QR decomposition does 
orthogonalize, but it does not necessarily hold that the first k columns of Q 
spans the same subspace as the first k columns of X. LINPACK's QR happens to be 
implemented as successive orthogonalization, but LAPACK's is not, so only the 
former is usable with lm().

So, I suppose what I am getting at is that not even lm() uses qr(), it calls 
LINPACK directly.

-pd


> On 02 Aug 2016, at 21:17 , Charles Determan  wrote:
> 
> Hello,
> 
> I am currently working on an implementation of QR decomposition (leveraging
> a C++ library via Rcpp).  Naturally I would like to have the R syntax as
> similar as possible to base R 'qr' function.  Given the class structure of
> my package my instinct was to export an S4/S3 method.
> 
> However, the QR decomposition doesn't store the final QR matrix in the same
> format as base R via LINPACK, nor does it return 'qraux', 'rank' or 'pivot'
> objects but instead a 'betas' object.  The final 'R' and 'Q' matrices are
> in fact identical to those ultimately returned by qr.R or qr.Q.
> 
> So my question is, given these differences, should I just create a
> different function name or would creating a qr.myclass dispatch be
> acceptable (whether S3 or S4)?  I would prefer the latter as I would like
> the classes to potentially take advantage of previously written code using
> 'qr'.
> 
> Thanks,
> Charles
> 
>   [[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] Namespace error

[peter dalgaard]

On 17 Feb 2016, at 10:25 , Gábor Csárdi <csardi.ga...@gmail.com> wrote:

> On Wed, Feb 17, 2016 at 1:04 AM, Duncan Murdoch
> <murdoch.dun...@gmail.com> wrote:
>> On 16/02/2016 12:14 PM, Glenn Schultz wrote:
>>> 
>>> All
>>> 
>>> I am not sure why I am getting this error and I cannot find anything on
>>> the net other than try to restart R. I am
>>> using Roxygen2 and it clearly says don't edit by hand at the top of the
>>> namespace so I am stuck as what to do or look for.
>> 
>> 
>> You will need to contact the Roxygen2 maintainers about this.  We don't
>> support it.
> 
> So, this mailing list is about developing packages using base R
> packages only and exclusively?
> 
> I suggest that the owners clarify this on the "about" page, because I
> totally missed it, and almost answered this question. :)


Well, by all means, then

It's like r-help. Sometimes a question seems better directed at RStudio support 
or the platform specific mailing lists, and people get redirected, but hey, 
we're supposed to be friendly in here, so if you happen to know the answer, 
just tell. 

(The list was mainly set up to facilitate issues between CRAN and package 
maintainers, so the expertise that you can assume to be present is that of 
people who know why CRAN is being picky, etc. There's little point in keeping 
the expertise of others out, but there's a blurry line towards doing 3rd party 
maintainers' work for them.)

-pd

> 
> Gabor
> 
>> Duncan Murdoch
> [...]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Namespace: summary of all undefined globals

[peter dalgaard]

The "release branch", currently 3.2.x, by principle contains patch releases of 
3.2.0 (i.e. bug fix releases; we do occasionally let new features slip in, but 
only if they are truly orthogonal to existing code, which is usually not the 
case in the QA/QC areas). If something was in r-devel in July, then it will 
have been slated for 3.3.0. 

The most obvious way to get hold of the feature is to install/build a current 
version of R-devel. Otherwise, you have to port the code to the release branch 
yourself.

-pd

> On 22 Dec 2015, at 11:34 , Patrick Giraudoux 
> <patrick.giraud...@univ-fcomte.fr> wrote:
> 
> Dear listers,
> 
> Kurt (subject "CRAN packages maintained by you" sent on 02/07/2015) was 
> mentionning to package maintainers that "with current versions of r-devel, 
> one can get a convenient summary of all undefined globals" and describing how 
> to get a summary conveniently.
> 
> Now I am using R 3.2.3 but cannot get this by using rcmd check --as-cran 
> mypackage, the "traditionnal" namespace with obviously incomplete declaration 
> going through the check 'checking R code for possible problems' with no note.
> 
> Can you confirm that the implementation of R-devel in July, is still NOT in R 
> 3.2.3 and that one should still use the current version of r-devel to get a 
> summary of undefined globals (through notes after 'checking R code for 
> possible problems) ? Is there a way to get it from R 3.2.3 ?
> 
> Thanks in advance,
> 
> Patrick
> 
> ______
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Using the correct R binary in configure script

[peter dalgaard]

> On 26 Sep 2015, at 17:43 , Dirk Eddelbuettel <e...@debian.org> wrote:
> 
> R_HOME is set to the result of the command R RHOME if and only it is unset.
> 
> And it usually is unset. 

Did you actually mean that, Dirk? I would expect that R_HOME would be set by 
"myR CMD whatever" before it got to the configure script, so that the default R 
would only be used as a last resort. And R rather actively defends itself 
against R_HOME being set in its environment.

E.g.

$ R_HOME=/tmp R CMD env | grep R_HOME
WARNING: ignoring environment value of R_HOME
R_HOME=/Library/Frameworks/R.framework/Resources

(I'm not sure that it is actually supposed to work, but apparently R CMD foo 
executes 'foo' in the same environment as R CMD check et al.)

-pd

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-pkg-devel] Setting up R-devel in Linux Mint 17.1 64-bit

[peter dalgaard]

 On 21 Jul 2015, at 08:12 , Johannes Ranke jra...@uni-bremen.de wrote:
 
 
 Could you guys move to r-devel? This has nothing to do with _package_
 development.
 
 OK, the details of how to configure a build are maybe a bit too far off... 
 But 
 in general, testing with a recent development build is an important part of 
 submitting packages to CRAN, so it seems to me that this list may serve to 
 collect information on how this can be done?

In a word: No.

So is getting R installed in the first place, running it on a Mac, sorting out 
library dependencies, etc. All of these things have their own mailing lists, 
full of people that know about stuff. We do not want to duplicate their content 
here, possibly with lesser competence. Plus, it clogs up the archives of _this_ 
list.

-pd

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

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