date:20170503

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

2017-05-03 Thread Hervé Pagès

On 05/03/2017 12:04 PM, Hervé Pagès wrote:

Not sure why the performance penalty of nonstandard evaluation would
be more of a concern here than for something like switch().

which is actually a primitive. So it seems that there is at least
another way to go than 'dots <- match.call(expand.dots=FALSE)$...'

Thanks,
H.

If that can't/won't be fixed, what about fixing the man page so it's
in sync with the current behavior?

Thanks,
H.

On 05/03/2017 02:26 AM, peter dalgaard wrote:

The first line of stopifnot is

n <- length(ll <- list(...))

which takes ALL arguments and forms a list of them. This implies
evaluation, so explains the effect that you see.

To do it differently, you would have to do something like

   dots <- match.call(expand.dots=FALSE)$...

and then explicitly evaluate each argument in turn in the caller
frame. This amount of nonstandard evaluation sounds like it would
incur a performance penalty, which could be undesirable.

If you want to enforce the order of evaluation, there is always

   stopifnot(A)
   stopifnot(B)

-pd

On 3 May 2017, at 02:50 , Hervé Pagès  wrote:

Hi,

It's surprising that stopifnot() keeps evaluating its arguments after
it reaches the first one that is not TRUE:

 > stopifnot(3 == 5, as.integer(2^32), a <- 12)
 Error: 3 == 5 is not TRUE
 In addition: Warning message:
 In stopifnot(3 == 5, as.integer(2^32), a <- 12) :
   NAs introduced by coercion to integer range
 > a
 [1] 12

The details section in its man page actually suggests that it should
stop at the first non-TRUE argument:

 ‘stopifnot(A, B)’ is conceptually equivalent to

  { if(any(is.na(A)) || !all(A)) stop(...);
if(any(is.na(B)) || !all(B)) stop(...) }

Best,
H.

--
Hervé Pagès

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

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

__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=JwgKhKD2k-9Kedeh6pqu-A8x6UEV0INrcxcSGVGo3Tg=f7IKJIhpRNJMC3rZAkuI6-MTdL3GAKSV2wK0boFN5HY=

--
Hervé Pagès

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

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

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

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

2017-05-03 Thread Hervé Pagès

Not sure why the performance penalty of nonstandard evaluation would
be more of a concern here than for something like switch().

If that can't/won't be fixed, what about fixing the man page so it's
in sync with the current behavior?

Thanks,
H.

On 05/03/2017 02:26 AM, peter dalgaard wrote:

The first line of stopifnot is

n <- length(ll <- list(...))

which takes ALL arguments and forms a list of them. This implies evaluation, so 
explains the effect that you see.

To do it differently, you would have to do something like

   dots <- match.call(expand.dots=FALSE)$...

and then explicitly evaluate each argument in turn in the caller frame. This 
amount of nonstandard evaluation sounds like it would incur a performance 
penalty, which could be undesirable.

If you want to enforce the order of evaluation, there is always

   stopifnot(A)
   stopifnot(B)

-pd

On 3 May 2017, at 02:50 , Hervé Pagès  wrote:

Hi,

It's surprising that stopifnot() keeps evaluating its arguments after
it reaches the first one that is not TRUE:

 > stopifnot(3 == 5, as.integer(2^32), a <- 12)
 Error: 3 == 5 is not TRUE
 In addition: Warning message:
 In stopifnot(3 == 5, as.integer(2^32), a <- 12) :
   NAs introduced by coercion to integer range
 > a
 [1] 12

The details section in its man page actually suggests that it should
stop at the first non-TRUE argument:

 ‘stopifnot(A, B)’ is conceptually equivalent to

  { if(any(is.na(A)) || !all(A)) stop(...);
if(any(is.na(B)) || !all(B)) stop(...) }

Best,
H.

--
Hervé Pagès

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

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

__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=JwgKhKD2k-9Kedeh6pqu-A8x6UEV0INrcxcSGVGo3Tg=f7IKJIhpRNJMC3rZAkuI6-MTdL3GAKSV2wK0boFN5HY=

--
Hervé Pagès

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

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

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

Re: [Bioc-devel] github mirror out of sync for ensembldb

2017-05-03 Thread Leonardo Collado Torres

Hi,

Ahh, ok. What I meant was that the "master" branch in
Bioconductor-mirror is not up to date with bioc-devel. I could see
that aCGH did have a release-3.5 branch, but that the "master" branch
wasn't updated. You can see something similar for
https://github.com/Bioconductor-mirror/derfinder/branches where
https://github.com/Bioconductor-mirror/derfinder/blob/master/DESCRIPTION#L5
shows version 1.9.11 while bioc-devel's
http://bioconductor.org/packages/devel/bioc/html/derfinder.html is at
1.11.0

Basically, the equivalent of older commits like
https://github.com/Bioconductor-mirror/derfinder/commit/4687d52b8c6fda6541d2454bda1517ed2776d351
and 
https://github.com/Bioconductor-mirror/derfinder/commit/a0f94bae0270f390afc00468d953237f44722790
are missing.

Best,
Leo

On Wed, May 3, 2017 at 1:54 PM, Rainer Johannes
 wrote:
>
>
>> On 3 May 2017, at 19:51, Martin Morgan  wrote:
>>
>> On 05/03/2017 01:10 PM, Leonardo Collado Torres wrote:
>>> Hi,
>>>
>>> I don't think that any of the Bioconductor-mirror repos have been
>>> updated to match the current bioc-devel branch. For example, look at
>>> https://github.com/Bioconductor-mirror/aCGH/blob/master/DESCRIPTION#L4
>>> which is one of the first packages by alphabetical order. My guess is
>>> that they are working on the svn to git transition plan described at
>>> https://stat.ethz.ch/pipermail/bioc-devel/2017-March/010691.html.
>>
>> That's not correct, the repositories should be (in general) up to date. I 
>> believe Johannes' package is current (sorry, by the time I got to it it had 
>> healed itself and I didn't respond to the list).
>>
>
> No prob. I've made an update to the package and after committing the change 
> to the Bioc svn ensembldb was synced successfully.
>
>> aCGH actually had a RELEASE_3_5 branch; I'll investigate why aCGH and at 
>> least some other packages have not been fully updated after the branch.
>>
>> Martin
>>
>>
>>>
>>> Best,
>>> Leo
>>>
>>> On Thu, Apr 27, 2017 at 6:52 AM, Rainer Johannes
>>>  wrote:
 Hi,

 the github mirror for ensembldb seems to be out of sync with the BioC svn, 
 i.e. the DESCRIPTION in 
 https://github.com/Bioconductor-mirror/ensembldb/blob/master/DESCRIPTION 
 is still at version 1.99.14 while in the svn it's already 2.1.0.

 First I thought the sync is not yet finished, but the release-3.5 was 
 already created on the github mirror, so I guess sync must have been stuck 
 somewhere.

[[alternative HTML version deleted]]

 ___
 Bioc-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>> This email message may contain legally privileged and/or confidential 
>> information.  If you are not the intended recipient(s), or the employee or 
>> agent responsible for the delivery of this message to the intended 
>> recipient(s), you are hereby notified that any disclosure, copying, 
>> distribution, or use of this email message is prohibited.  If you have 
>> received this message in error, please notify the sender immediately by 
>> e-mail and delete this email message from your computer. Thank you.
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] github mirror out of sync for ensembldb

2017-05-03 Thread Rainer Johannes



> On 3 May 2017, at 19:51, Martin Morgan  wrote:
> 
> On 05/03/2017 01:10 PM, Leonardo Collado Torres wrote:
>> Hi,
>> 
>> I don't think that any of the Bioconductor-mirror repos have been
>> updated to match the current bioc-devel branch. For example, look at
>> https://github.com/Bioconductor-mirror/aCGH/blob/master/DESCRIPTION#L4
>> which is one of the first packages by alphabetical order. My guess is
>> that they are working on the svn to git transition plan described at
>> https://stat.ethz.ch/pipermail/bioc-devel/2017-March/010691.html.
> 
> That's not correct, the repositories should be (in general) up to date. I 
> believe Johannes' package is current (sorry, by the time I got to it it had 
> healed itself and I didn't respond to the list).
> 

No prob. I've made an update to the package and after committing the change to 
the Bioc svn ensembldb was synced successfully.

> aCGH actually had a RELEASE_3_5 branch; I'll investigate why aCGH and at 
> least some other packages have not been fully updated after the branch.
> 
> Martin
> 
> 
>> 
>> Best,
>> Leo
>> 
>> On Thu, Apr 27, 2017 at 6:52 AM, Rainer Johannes
>>  wrote:
>>> Hi,
>>> 
>>> the github mirror for ensembldb seems to be out of sync with the BioC svn, 
>>> i.e. the DESCRIPTION in 
>>> https://github.com/Bioconductor-mirror/ensembldb/blob/master/DESCRIPTION is 
>>> still at version 1.99.14 while in the svn it's already 2.1.0.
>>> 
>>> First I thought the sync is not yet finished, but the release-3.5 was 
>>> already created on the github mirror, so I guess sync must have been stuck 
>>> somewhere.
>>> 
>>> 
>>> 
>>> 
>>>[[alternative HTML version deleted]]
>>> 
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
> 
> 
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] github mirror out of sync for ensembldb

2017-05-03 Thread Martin Morgan


On 05/03/2017 01:10 PM, Leonardo Collado Torres wrote:

Hi,

I don't think that any of the Bioconductor-mirror repos have been
updated to match the current bioc-devel branch. For example, look at
https://github.com/Bioconductor-mirror/aCGH/blob/master/DESCRIPTION#L4
which is one of the first packages by alphabetical order. My guess is
that they are working on the svn to git transition plan described at
https://stat.ethz.ch/pipermail/bioc-devel/2017-March/010691.html.


That's not correct, the repositories should be (in general) up to date. 
I believe Johannes' package is current (sorry, by the time I got to it 
it had healed itself and I didn't respond to the list).


aCGH actually had a RELEASE_3_5 branch; I'll investigate why aCGH and at 
least some other packages have not been fully updated after the branch.


Martin




Best,
Leo

On Thu, Apr 27, 2017 at 6:52 AM, Rainer Johannes
 wrote:

Hi,

the github mirror for ensembldb seems to be out of sync with the BioC svn, i.e. 
the DESCRIPTION in 
https://github.com/Bioconductor-mirror/ensembldb/blob/master/DESCRIPTION is 
still at version 1.99.14 while in the svn it's already 2.1.0.

First I thought the sync is not yet finished, but the release-3.5 was already 
created on the github mirror, so I guess sync must have been stuck somewhere.




[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Any progress on write.csv fileEncoding for UTF-16 and UTF-32 ?

2017-05-03 Thread Duncan Murdoch


Now fixed in R-devel revision 72650.

Duncan Murdoch

On 02/05/2017 4:11 AM, Duncan Murdoch wrote:

On 01/05/2017 8:49 PM, Jack Kelley wrote:

Thanks for looking into this.

A few notes regarding all the UTF encodings on Windows 10 ...


This all stems from the ancient bad decision by Microsoft to translate
LF characters to CR LF when writing text files.  R passes 0A or 0A 00 or
0A 00 00 00 to the output routine (part of the C run-time), and it needs
to figure out how many characters there are in those bytes in order to
add the appropriate CR with the right width.

The default is 8 bit, so you get 0D 0A in current versions of R,
regardless of the encoding.

There are ways to declare UTF-16LE (see
https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx, or Google
"Windows fopen" if that moves), but no other wide encoding.  That's what
I'm putting in place if you ask for UTF-16LE or UCS-2LE.  So far I'm not
planning to handle UTF-16BE or UTF-32, because doing those would mean R
would have to handle the translation of LF itself, and I'm too lazy to
do that.

So far this is working for writes, but not reads.  I still have to track
down what's going wrong there.

Duncan Murdoch



The default eol for write.csv (via write.table) is "\n" and always gives
as.raw (c (0x0d, 0x0a)), that is,   as adjacent
bytes. This is fine for UTF-8 but wrong for UTF-16 and UTF-32.

EXAMPLE: Using UTF-32 for exaggeration (note also that 3 nul bytes are
missing in the final CR+LF):

df <- data.frame (x = 1:2, y = 3:4)

$`UTF-32LE`$default.eol$raw
 [1] 22 00 00 00 78 00 00 00 22 00 00 00 2c 00 00 00 22 00 00 00 79 00 00 00
22
[26] 00 00 00 0d 0a 00 00 00 31 00 00 00 2c 00 00 00 33 00 00 00 0d 0a 00 00
00
[51] 32 00 00 00 2c 00 00 00 34 00 00 00 0d 0a 00 00 00

$`UTF-32BE`$default.eol$raw
 [1] 00 00 00 22 00 00 00 78 00 00 00 22 00 00 00 2c 00 00 00 22 00 00 00 79
00
[26] 00 00 22 00 00 00 0d 0a 00 00 00 31 00 00 00 2c 00 00 00 33 00 00 00 0d
0a
[51] 00 00 00 32 00 00 00 2c 00 00 00 34 00 00 00 0d 0a

(Nevertheless, Microsoft Excel 2013 tolerates these CSVs!)

One trick/solution is to use eol = "\r" (that is,  only).

Regards -- Jack Kelley




remove (list = objects())
print (sessionInfo())
cat ("##\n\n")

ENCODING <- c (
  "UTF-8",
  "UTF-16LE", "UTF-16BE", "UTF-16",
  "UTF-32LE", "UTF-32BE", "UTF-32"
)

df <- data.frame (x = 1:2, y = 3:4)

csv <- structure (lapply (ENCODING, function (encoding) {
  csv <- sprintf ("df_%s.csv", encoding)
  write.csv (df, csv, fileEncoding = encoding, row.names = FALSE)
  list (default.eol = list (
csv = csv, raw = readBin (csv, "raw", 1000))
  )
}), .Names = ENCODING)

EOL <- c (LF = "\n", CR = "\r", "CR+LF" = "\r\n")

CSV <- structure (lapply (ENCODING, function (encoding) {
  structure (
lapply (names (EOL), function (EOL.name) {
  csv <- sprintf ("df_%s_eol=%s.csv", encoding, EOL.name)
  write.csv (
df, csv, fileEncoding = encoding, row.names = FALSE,
eol = EOL [EOL.name]
  )
  list (csv = csv, raw = readBin (csv, "raw", 1000))
  }), .Names = names (EOL))
}), .Names = ENCODING)

print (csv)
print (CSV)




-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Tuesday, 2 May 2017 04:22
To: Jack Kelley ; r-devel@r-project.org
Subject: Re: [Rd] Any progress on write.csv fileEncoding for UTF-16 and
UTF-32 ?

On 30/04/2017 12:23 PM, Duncan Murdoch wrote:

No, I don't think anyone is working on this.

There's a fairly simple workaround for the UTF-16 and UTF-32 iconv
issues:  don't attempt to produce character vectors, produce raw vectors
instead. (The "toRaw" argument to iconv() asks for this.) Raw vectors
can contain embedded nulls.  Character vectors can't, because
internally, R is using 8 bit C strings, and the nulls are string
terminators.

I don't know how difficult it would be to fix the write.table problems.


I've now taken a look, and it appears as if it's not too hard.  I'll see
if I can work out a patch that I trust.

Duncan Murdoch



Duncan Murdoch

On 29/04/2017 7:53 PM, Jack Kelley wrote:

"R version 3.4.0 (2017-04-21)"  on "x86_64-w64-mingw32" platform
... [rest omitted]







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

Re: [Bioc-devel] github mirror out of sync for ensembldb

2017-05-03 Thread Leonardo Collado Torres

Hi,

I don't think that any of the Bioconductor-mirror repos have been
updated to match the current bioc-devel branch. For example, look at
https://github.com/Bioconductor-mirror/aCGH/blob/master/DESCRIPTION#L4
which is one of the first packages by alphabetical order. My guess is
that they are working on the svn to git transition plan described at
https://stat.ethz.ch/pipermail/bioc-devel/2017-March/010691.html.

Best,
Leo

On Thu, Apr 27, 2017 at 6:52 AM, Rainer Johannes
 wrote:
> Hi,
>
> the github mirror for ensembldb seems to be out of sync with the BioC svn, 
> i.e. the DESCRIPTION in 
> https://github.com/Bioconductor-mirror/ensembldb/blob/master/DESCRIPTION is 
> still at version 1.99.14 while in the svn it's already 2.1.0.
>
> First I thought the sync is not yet finished, but the release-3.5 was already 
> created on the github mirror, so I guess sync must have been stuck somewhere.
>
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[R-pkg-devel] Any new developments on "apparent S3 method" issue?

2017-05-03 Thread Lenth, Russell V

Package developers list:

I recently added an 'as.mcmc.list' method for objects in one of my packages. 
Now, in doing an --as-cran check, I get this message:

* checking S3 generic/method consistency ... NOTE
Found the following apparent S3 methods exported but not registered:
  as.mcmc.list
See section 'Registering S3 methods' in the 'Writing R Extensions' manual.

Apparently, the checking routines conclude that I should register an 'as.mcmc' 
method for class "list" -- something that does not exist and is not needed. I 
did some searching, and found an exchange on this issue from January 2015, in 
which a "nonS3Method()" construct was proposed. That sure looks like what is 
needed, but it still doesn't exist. Is there a different way to handle this 
that has been developed?

Further information -- this is related to the *coda* package, and my NAMESPACE 
file contains this code:

if (requireNamespace("coda", quietly = TRUE)) {
importFrom(coda, as.mcmc, as.mcmc.list)
export(as.mcmc, as.mcmc.list)
S3method(as.mcmc, ref.grid)
S3method(as.mcmc.list, ref.grid)
}

This seems clear enough; and what's mysterious is that *coda* passes the CRAN 
checks without this same NOTE.

As a possible workaround, I am considering:
   -- providing and registering my own S3 method 'as.mcmc' for class "list" --- 
in spite of my disinterest in providing this 
  -- not importing coda::as.mcmc.list and instead exporting my own generic that 
handles objects of class "list" separately

Any suggestions?

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science   
The University of Iowa  -  Iowa City, IA 52242  USA   
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

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

Re: [Rd] Generate reproducible output independently of the build path

2017-05-03 Thread Ximin Luo

Ximin Luo:
> [..]
> 
> I've attached a patch (applies to both 3.3.3 and 3.4) that fixes this issue; 
> however I know it's not perfect and would welcome feedback on how to make it 
> acceptable to the R project.
> 

Hi all, attached is an updated version of the patch.

We've tested this on our jenkins infrastructure and it makes 463/478 Debian R 
packages reproducible:

https://tests.reproducible-builds.org/debian/issues/unstable/randomness_in_r_rdb_rds_databases_issue.html

The previous version of the patch was slightly flawed, it made 2 of these 
packages fail-to-build-from-source (r-bioc-biobase, r-cran-shinybs). This is 
fixed in the current patch attached, and these packages reproduce with it.

The remaining FTBFS (r-cran-randomfields) are due to incompatibilities between 
r-base 3.3.3 and 3.4.0, being discussed in Debian bug 861333, and are not 
caused by this patch.

The remaining 14 unreproducible packages are likely unreproducible due to 
issues specifically in those packages. For example 
r-cran-runit-0.4.31/man/checkFuncs.Rd contains an explicit absolute path, and 
making this relative fixes the unreproducibility. I have not yet checked the 
other packages.

> For example, I've tried to limit the effects of the patch only to the RDB 
> loading/saving code, but I'm not familiar with the codebase so it would be 
> good if someone could verify that I did this correctly. Then, ideally we 
> would also add some tests to ensure that unreproduciblity does not crop back 
> in "by accident". R code heavily relies on absolute paths, and I went down 
> several dead-ends chasing and editing variables containing absolute paths, 
> before I finally managed to get this working patch, so I suspect that without 
> specific reproducibility tests, this issue might recur in the future.
> 

I've been talking with Dirk Eddelbuettel off-thread and he suggested that the 
rest of the patch could also be guarded by something like 
getOption("useRelativePath", bool).

It would be good if other members of R Core could comment and give me some more 
guidance along these lines. :)

> I've checked that the existing tests still pass, with this patch applied to 
> the Debian package. I have some errors like:
> [..]
> :* checking whether the package can be loaded ... ERROR
> [..]

We also figured out that this was a previous issue with Debian R 3.3.3, the 
error goes away with 3.4.0 either patched or unpatched.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
--- r-base-3.4.0.orig/src/library/base/R/namespace.R
+++ r-base-3.4.0/src/library/base/R/namespace.R
@@ -192,7 +192,8 @@
 
 loadNamespace <- function (package, lib.loc = NULL,
keep.source = getOption("keep.source.pkgs"),
-   partial = FALSE, versionCheck = NULL)
+   partial = FALSE, versionCheck = NULL,
+   relpath = FALSE)
 {
 libpath <- attr(package, "LibPath")
 package <- as.character(package)[[1L]]
@@ -506,6 +505,12 @@
 # else warning(gettextf("package %s contains no R code",
 #sQuote(package)), call. = FALSE, domain = NA)
 
+# if relpath is asked for, set this here. we do this *after* the
+# sys.source() step just above, because some packages' top-level code
+# like to call things like packageDescription() which requires an
+# actually-existing path info for them to work.
+if (relpath) setNamespaceInfo(ns, "path", file.path(".", package))
+
 ## partial loading stops at this point
 ## -- used in preparing for lazy-loading
 if (partial) return(ns)
--- r-base-3.4.0.orig/src/library/tools/R/admin.R
+++ r-base-3.4.0/src/library/tools/R/admin.R
@@ -788,7 +788,6 @@
 .install_package_Rd_objects <-
 function(dir, outDir, encoding = "unknown")
 {
-dir <- file_path_as_absolute(dir)
 mandir <- file.path(dir, "man")
 manfiles <- if(!dir.exists(mandir)) character()
 else list_files_with_type(mandir, "docs")
--- r-base-3.4.0.orig/src/library/tools/R/makeLazyLoad.R
+++ r-base-3.4.0/src/library/tools/R/makeLazyLoad.R
@@ -28,7 +28,7 @@
 if (packageHasNamespace(package, dirname(pkgpath))) {
 if (! is.null(.getNamespace(as.name(package
 stop("namespace must not be already loaded")
-ns <- suppressPackageStartupMessages(loadNamespace(package, lib.loc, keep.source, partial = TRUE))
+ns <- suppressPackageStartupMessages(loadNamespace(package, lib.loc, keep.source, partial = TRUE, relpath = TRUE))
 makeLazyLoadDB(ns, dbbase, compress = compress)
 }
 else
--- r-base-3.4.0.orig/src/library/tools/R/parseRd.R
+++ r-base-3.4.0/src/library/tools/R/parseRd.R
@@ -63,6 +63,7 @@
 basename <- basename(srcfile$filename)
 srcfile$encoding <- encoding
 srcfile$Enc <- "UTF-8"
+srcfile$wd <- "."
 
 if (encoding == "ASCII") {
 if

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Re: [Bioc-devel] github mirror out of sync for ensembldb

Re: [Bioc-devel] github mirror out of sync for ensembldb

Re: [Bioc-devel] github mirror out of sync for ensembldb

Re: [Rd] Any progress on write.csv fileEncoding for UTF-16 and UTF-32 ?

Re: [Bioc-devel] github mirror out of sync for ensembldb

[R-pkg-devel] Any new developments on "apparent S3 method" issue?

Re: [Rd] Generate reproducible output independently of the build path

9 matches

Site Navigation

Mail list logo

Footer information