Re: [Rd] encoding argument of source() in 3.5.0
> peter dalgaard
> on Sun, 3 Jun 2018 23:51:24 +0200 writes:
> Looks like this actually comes from readLines(), nothing
> to do with source() as such: In current R-devel (still):
>> f <- file("http://home.versanet.de/~s-berman/source2.R";,
encoding="UTF-8")
>> readLines(f)
> character(0)
>> close(f)
>> f <- file("http://home.versanet.de/~s-berman/source2.R";)
>> readLines(f)
> [1] "source.test2 <- function() {" "print(\"Non-ascii: äöüß\")"
> [3] "}"
> -pd
and that's not even readLines(), but rather how exactly the
connection is defined [even in your example above]
> urlR <- "http://home.versanet.de/~s-berman/source2.R";
> readLines(urlR, encoding="UTF-8")
[1] "source.test2 <- function() {" "print(\"Non-ascii: äöüß\")"
[3] "}"
> f <- file(urlR, encoding = "UTF-8")
> readLines(f)
character(0)
and the same behavior with scan() instead of readLines() :
> scan(urlR,"") # works
Read 7 items
[1] "source.test2" "<-" "function()" "{"
[5] "print(\"Non-ascii:" "äöüß\")""}"
> scan(f,"") # fails
Read 0 items
character(0)
>
So it seems as if the bug is in the file() [or url()] C code ..
But then we also have to consider Windows .. where I think most changes have
happened during the R-3.4.4 --> R-3.5.0 transition.
>> On 2 Jun 2018, at 15:37 , Stephen Berman wrote:
>>
>> In R 3.5.0 using the `encoding' argument of source() prevents loading
>> files from the internet; without the `encoding' argument files can be
>> loaded from the internet, but if they contain non-ascii characters,
>> these are not correctly displayed under MS-Windows (but they are
>> correctly displayed under GNU/Linux). With R 3.4.{2,3,4} there is no
>> such problem: using `encoding' the files are loaded and non-ascii
>> characters are correctly displayed under MS-Windows (but not without
>> `encoding'). Here is a transcript from R 3.5.0 under GNU/Linux (the
>> URLs are real, in case anyone wants to try and reproduce the problem):
>>
>>> ls()
>> character(0)
>>> source("http://home.versanet.de/~s-berman/source1.R";, encoding="UTF-8")
>>> ls()
>> character(0)
>>> source("http://home.versanet.de/~s-berman/source2.R";, encoding="UTF-8")
>>> ls()
>> character(0)
>>> source("http://home.versanet.de/~s-berman/source1.R";)
>>> ls()
>> [1] "source.test1"
>>> source("http://home.versanet.de/~s-berman/source2.R";)
>>> ls()
>> [1] "source.test1" "source.test2"
>>> source.test1()
>> [1] "This is a test."
>>> source.test2()
>> [1] "Non-ascii: äöüß"
>>
>> (The four non-ascii characters are Unicode 0xE4, 0xF6, 0xFC, 0xDF.)
>> With 3.5.0 under MS-Windows, the transcript is the same except for the
>> display of the last output, which is this:
>>
>> [1] "Non-ascii: äöüß"
>>
>> (Here there are eight non-ascii characters, which display the Unicode
>> decompositions of the four non-ascii characters above.)
>>
>> Here is a transcript from R 3.4.3 under MS-Windows (under GNU/Linux it's
>> the same except that the non-ascii characters are also correctly
>> displayed even without the `encoding' argument):
>>
>>> ls()
>> character(0)
>>> source("http://home.versanet.de/~s-berman/source1.R";)
>>> ls()
>> [1] "source.test1"
>>> source("http://home.versanet.de/~s-berman/source2.R";)
>>> ls()
>> [1] "source.test1" "source.test2"
>>> source.test1()
>> [1] "This is a test."
>>> source.test2()
>> [1] "Non-ascii: äöüß"
>>> rm(source.test2)
>>> ls()
>> [1] "source.test1"
>>> source("http://home.versanet.de/~s-berman/source2.R";, encoding="UTF-8")
>>> ls()
>> [1] "source.test1" "source.test2"
>>> source.test2()
>> [1] "Non-ascii: äöüß"
>>
>> I did a web search but didn't find any reports of this issue, nor did I
>> see any relevant entry in the 3.5.0 NEWS, so this looks like a bug, but
>> maybe I've overlooked something. I'd be grateful for any enlightenment.
>>
>> Steve Berman
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-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-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] encoding argument of source() in 3.5.0
It's not Windows-specific, though. My example was on a Mac...
I hope we can sort this out before 3.5.1.
-pd
> On 4 Jun 2018, at 10:44 , Martin Maechler wrote:
>
> So it seems as if the bug is in the file() [or url()] C code ..
> But then we also have to consider Windows .. where I think most changes have
> happened during the R-3.4.4 --> R-3.5.0 transition.
>
>
>>> On 2 Jun 2018, at 15:37 , Stephen Berman wrote:
>>>
>>> In R 3.5.0 using the `encoding' argument of source() prevents loading
>>> files from the internet; without the `encoding' argument files can be
>>> loaded from the internet, but if they contain non-ascii characters,
>>> these are not correctly displayed under MS-Windows (but they are
>>> correctly displayed under GNU/Linux). With R 3.4.{2,3,4} there is no
>>> such problem: using `encoding' the files are loaded and non-ascii
>>> characters are correctly displayed under MS-Windows (but not without
>>> `encoding'). Here is a transcript from R 3.5.0 under GNU/Linux (the
>>> URLs are real, in case anyone wants to try and reproduce the problem):
>>>
ls()
>>> character(0)
source("http://home.versanet.de/~s-berman/source1.R";, encoding="UTF-8")
ls()
>>> character(0)
source("http://home.versanet.de/~s-berman/source2.R";, encoding="UTF-8")
ls()
>>> character(0)
source("http://home.versanet.de/~s-berman/source1.R";)
ls()
>>> [1] "source.test1"
source("http://home.versanet.de/~s-berman/source2.R";)
ls()
>>> [1] "source.test1" "source.test2"
source.test1()
>>> [1] "This is a test."
source.test2()
>>> [1] "Non-ascii: äöüß"
>>>
>>> (The four non-ascii characters are Unicode 0xE4, 0xF6, 0xFC, 0xDF.)
>>> With 3.5.0 under MS-Windows, the transcript is the same except for the
>>> display of the last output, which is this:
>>>
>>> [1] "Non-ascii: äöüß"
>>>
>>> (Here there are eight non-ascii characters, which display the Unicode
>>> decompositions of the four non-ascii characters above.)
>>>
>>> Here is a transcript from R 3.4.3 under MS-Windows (under GNU/Linux it's
>>> the same except that the non-ascii characters are also correctly
>>> displayed even without the `encoding' argument):
>>>
ls()
>>> character(0)
source("http://home.versanet.de/~s-berman/source1.R";)
ls()
>>> [1] "source.test1"
source("http://home.versanet.de/~s-berman/source2.R";)
ls()
>>> [1] "source.test1" "source.test2"
source.test1()
>>> [1] "This is a test."
source.test2()
>>> [1] "Non-ascii: äöüß"
rm(source.test2)
ls()
>>> [1] "source.test1"
source("http://home.versanet.de/~s-berman/source2.R";, encoding="UTF-8")
ls()
>>> [1] "source.test1" "source.test2"
source.test2()
>>> [1] "Non-ascii: äöüß"
>>>
>>> I did a web search but didn't find any reports of this issue, nor did I
>>> see any relevant entry in the 3.5.0 NEWS, so this looks like a bug, but
>>> maybe I've overlooked something. I'd be grateful for any enlightenment.
>>>
>>> Steve Berman
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] encoding argument of source() in 3.5.0
On Mon, 4 Jun 2018 10:44:11 +0200 Martin Maechler
wrote:
>> peter dalgaard
>> on Sun, 3 Jun 2018 23:51:24 +0200 writes:
>
> > Looks like this actually comes from readLines(), nothing
> > to do with source() as such: In current R-devel (still):
>
> >> f <- file("http://home.versanet.de/~s-berman/source2.R";,
> encoding="UTF-8")
> >> readLines(f)
> > character(0)
> >> close(f)
> >> f <- file("http://home.versanet.de/~s-berman/source2.R";)
> >> readLines(f)
> > [1] "source.test2 <- function() {" "print(\"Non-ascii: äöüß\")"
> > [3] "}"
>
> > -pd
>
> and that's not even readLines(), but rather how exactly the
> connection is defined [even in your example above]
>
> > urlR <- "http://home.versanet.de/~s-berman/source2.R";
> > readLines(urlR, encoding="UTF-8")
> [1] "source.test2 <- function() {" "print(\"Non-ascii: äöüß\")"
> [3] "}"
> > f <- file(urlR, encoding = "UTF-8")
> > readLines(f)
> character(0)
>
> and the same behavior with scan() instead of readLines() :
>
>> scan(urlR,"") # works
> Read 7 items
> [1] "source.test2" "<-" "function()" "{"
> [5] "print(\"Non-ascii:" "äöüß\")""}"
>> scan(f,"") # fails
> Read 0 items
> character(0)
>>
>
> So it seems as if the bug is in the file() [or url()] C code ..
Yes, the problem seems to be restricted to loading files from a
(non-local) URL; i.e. this works fine on my computer:
> source("file:///home/steve/prog/R/source2.R", encoding="UTF-8")
Also, I noticed this works too:
> read.table("http://home.versanet.de/~s-berman/table2";, encoding="UTF-8",
skip=1)
where (if I read the source correctly) using `skip=1' makes read.table()
call readLines(). (The read.table() invocation also works without
`skip'.)
> But then we also have to consider Windows .. where I think most changes have
> happened during the R-3.4.4 --> R-3.5.0 transition.
Yes, please. I need (or at least it would be convenient) to be able to
load R code containing non-ascii characters from the web under
MS-Windows.
Steve Berman
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] encoding argument of source() in 3.5.0
On R 3.5.0 (Mac)
The issue appears when using the default (libcurl) method and specifying the
encoding
Note that using method='internal' causes a segfault if used in conjunction with
encoding. (and works when encoding is not set)
urlR <- "http://home.versanet.de/~s-berman/source2.R";
# works
url_default <- url(urlR)
scan(url_default, "")
# Read 7 items
# [1] "source.test2" "<-" "function()" "{"
"print(\"Non-ascii:" "äöüß\")"
# [7] "}"
url_default_en <- url(urlR, encoding = "UTF-8")
scan(url_default_en, "")
# Read 0 items
# character(0)
url_internal <- url(urlR, method = 'internal')
scan(url_internal, "")
# Read 7 items
# [1] "source.test2" "<-" "function()" "{"
"print(\"Non-ascii:" "äöüß\")"
# [7] "}"
url_internal_en <- url(urlR, encoding = "UTF-8", method = 'internal')
#scan(url_internal_en, "")
#*** caught segfault ***
# address 0x0, cause 'memory not mapped'
url_libcurl <- url(urlR, method = 'libcurl')
scan(url_libcurl, "")
# Read 7 items
# [1] "source.test2" "<-" "function()" "{"
"print(\"Non-ascii:" "äöüß\")"
# [7] "}"
url_libcurl_en <- url(urlR, encoding = "UTF-8", method = 'libcurl')
scan(url_libcurl_en, "")
# Read 0 items
# character(0)
Michael
From: R-devel [r-devel-boun...@r-project.org] on behalf of Stephen Berman
[stephen.ber...@gmx.net]
Sent: Monday, 4 June 2018 7:26 PM
To: Martin Maechler
Cc: R-devel
Subject: Re: [Rd] encoding argument of source() in 3.5.0
On Mon, 4 Jun 2018 10:44:11 +0200 Martin Maechler
wrote:
>> peter dalgaard
>> on Sun, 3 Jun 2018 23:51:24 +0200 writes:
>
> > Looks like this actually comes from readLines(), nothing
> > to do with source() as such: In current R-devel (still):
>
> >> f <- file("http://home.versanet.de/~s-berman/source2.R";,
> encoding="UTF-8")
> >> readLines(f)
> > character(0)
> >> close(f)
> >> f <- file("http://home.versanet.de/~s-berman/source2.R";)
> >> readLines(f)
> > [1] "source.test2 <- function() {" "print(\"Non-ascii: äöüß\")"
> > [3] "}"
>
> > -pd
>
> and that's not even readLines(), but rather how exactly the
> connection is defined [even in your example above]
>
> > urlR <- "http://home.versanet.de/~s-berman/source2.R";
> > readLines(urlR, encoding="UTF-8")
> [1] "source.test2 <- function() {" "print(\"Non-ascii: äöüß\")"
> [3] "}"
> > f <- file(urlR, encoding = "UTF-8")
> > readLines(f)
> character(0)
>
> and the same behavior with scan() instead of readLines() :
>
>> scan(urlR,"") # works
> Read 7 items
> [1] "source.test2" "<-" "function()" "{"
> [5] "print(\"Non-ascii:" "äöüß\")""}"
>> scan(f,"") # fails
> Read 0 items
> character(0)
>>
>
> So it seems as if the bug is in the file() [or url()] C code ..
Yes, the problem seems to be restricted to loading files from a
(non-local) URL; i.e. this works fine on my computer:
> source("file:///home/steve/prog/R/source2.R", encoding="UTF-8")
Also, I noticed this works too:
> read.table("http://home.versanet.de/~s-berman/table2";, encoding="UTF-8",
skip=1)
where (if I read the source correctly) using `skip=1' makes read.table()
call readLines(). (The read.table() invocation also works without
`skip'.)
> But then we also have to consider Windows .. where I think most changes have
> happened during the R-3.4.4 --> R-3.5.0 transition.
Yes, please. I need (or at least it would be convenient) to be able to
load R code containing non-ascii characters from the web under
MS-Windows.
Steve Berman
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
This email has been scanned for the NSW Ministry of Health by the Websense
Hosted Email Security System.
Emails and attachments are monitored to ensure compliance with the NSW Ministry
of health's Electronic Messaging Policy.
__
___
Disclaimer: This message is intended for the addressee named and may contain
confidential information.
If you are not the intended recipient, please delete it and notify the sender.
Views expressed in this message are those of the individual sender, and are not
necessarily the views of the NSW Ministry of Health.
___
This email has been scanned for the NSW Ministry of Health by the Websense
Hosted Email Security System.
Emails and attachmen
Re: [Rd] aic() component in GLM-family objects
> Ben Bolker
> on Sun, 3 Jun 2018 17:33:18 -0400 writes:
> Is it generally known/has it been previously discussed here that the
> $aic() component in GLM-family objects (e.g. results of binomial(),
> poisson(), etc.) does not as implemented actually return the AIC, but
> rather -2*log-likelihood + 2*(model_has_scale_parameter) ?
This rings a faint bell from the last millennium with me,
and the following "fortune" may contain the answer implicitly :
> if(!require("fortunes")) install.packages("fortunes")
> fortune("bug compatib")
For quite a while, bug-for-bug compatibility with S-PLUS v 3.x was considered
important to allow people to port their packages between systems.
-- Peter Dalgaard
R-help (February 2009)
>
Ideally, readers who still have access to a version of S-PLUS / S+
or who have read and internalized or (even co-written !)
"The white book", notably Ch.6, may be able to shed a historic
light on this.
I note that the white book's Appendix B with function help
pages, has a page ?family.object, accessible here
https://sites.oxy.edu/lengyel/M150/Sueselbeck/helpfiles/family.object.html
which does *not* mention a $dev.resid() component, but instead
allows to use $residuals(*, residuals=TRUE)
get the
"
vector of deviance residual, whose weighted sum of
squares is the deviance
"
Given the above, and also the ?glm entry
|| Author(s):
||
|| The original R implementation of ‘glm’ was written by Simon Davies
|| working for Ross Ihaka at the University of Auckland, but has
|| since been extensively re-written by members of the R Core team.
||
|| The design was inspired by the S function of the same name
|| described in Hastie & Pregibon (1992).
actually suggest that it may be hard nowadays to find the
original "design specs" that Simon and Ross had used at the
time, and also that they only were _inspired_ by the white book
chapter 6 (= Hastie & Pregibon (1992)).
> Can anyone in this forum gauge how a documentation patch
> would be received?
It depends on further answers to your questions (i.e, this
thread), but I'd currently say "gratefully".
I'd expect it would be a patch mainly to
src/library/stats/man/family.Rd
Note that help(AIC) has a non-small 'Details' section, but
indeed it does not mention the family(*)$aic function.
> This behaviour does not seem to be documented in ?family (or anywhere
> else I can find), which says:
> aic: function giving the AIC value if appropriate (but ‘NA’ for
> the quasi- families). See ‘logLik’ for the assumptions made
> about the dispersion parameter.
> For a demonstration that e.g. binomial()$aic() is really -2*log L and
> not the AIC, see:
>
https://github.com/wch/r-source/blob/trunk/src/library/stats/R/family.R#L317
> This document
>
> explicates the details a bit more ('L' denotes log-likelihood):
> * family()$aic computes $-2L$, which glm.fit translates to an AIC by
> adding $2k$ and storing it in model$aic
> * logLik.default retrieves model$aic and converts it back to a
> log-likelihood
> * stats:::AIC.default retrieves the log-likelihood and converts it
> back to an AIC (!)
> * family()$dev.resid() computes the squared deviance residuals
> * stats:::residuals.glm retrieves these values and takes the signed
> square root
> cheers
> Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Byte-compilation failure on different architectures / low-memory systems
As you may know, I look after the R package for Debian. My fellow Debianers make me follow a specific protocol -- a so-called "transition" in which all dependent packages on an identified potential breakge are rebuilt under the new (potentially breaking) change. We started adding an r-api-3.4 tag last (major) release. Now it is r-api-3.5 and the transition got started with the green light from the release team last Friday. Now one build failure occurred for one of the (old, effectively litte maintained) RMetrics packages: fBasics. It blows up at the byte-compilation step on at least four (older, smaller) architectures: mips, mipsel, arm64 (ubuntu), ppc64el. More at https://bugs.debian.org/900756 where we also worked out the "solution" of suppressing byte-compilation at installation. Luke, Tomas, ...: Would it help you to get access to such hardware? We may get you some sort of "guest pass" access to porter machines. Else I could try but I have my hands plenty full with the transition (having built [and finally transferred to our Debian Gitlab instance] 20+ package during day two of R/Finance...). Cheers, Dirk PS I CC'ed the bug report, if any follow-up keep the CC it gets logged there. PPS Happy to discuss / help off-list too, of course. -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Byte-compilation failure on different architectures / low-memory systems
I believe a reproducible example is to simply have a very large object defined literally (i.e. through structure() etc) in ./R/ . For example, fBasics has a couple of files test-jbLM.R and test-jbTable.R which are about 500 KB. For a given amount of RAM, I believe any sufficiently large file will also break a package if byte compilation is not turned off, regardless of architecture. A similar issue occurred with package ddalpha, though the maintainer has since fixed that I believe. On 5 June 2018 at 01:14, Dirk Eddelbuettel wrote: > > As you may know, I look after the R package for Debian. My fellow Debianers > make me follow a specific protocol -- a so-called "transition" in which all > dependent packages on an identified potential breakge are rebuilt under the > new (potentially breaking) change. We started adding an r-api-3.4 tag last > (major) release. Now it is r-api-3.5 and the transition got started with the > green light from the release team last Friday. > > Now one build failure occurred for one of the (old, effectively litte > maintained) RMetrics packages: fBasics. It blows up at the byte-compilation > step on at least four (older, smaller) architectures: mips, mipsel, arm64 > (ubuntu), ppc64el. More at https://bugs.debian.org/900756 where we also > worked out the "solution" of suppressing byte-compilation at installation. > > Luke, Tomas, ...: Would it help you to get access to such hardware? > > We may get you some sort of "guest pass" access to porter machines. Else I > could try but I have my hands plenty full with the transition (having built > [and finally transferred to our Debian Gitlab instance] 20+ package during > day two of R/Finance...). > > Cheers, Dirk > > PS I CC'ed the bug report, if any follow-up keep the CC it gets logged there. > > PPS Happy to discuss / help off-list too, of course. > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Byte-compilation failure on different architectures / low-memory systems
Hi Dirk, thanks for the report. Access to the test system is not necessary, the memory requirements of the byte-code compiler are usually platform-independent and specifically with this package I can reproduce they are very high. We'll have a look what we can do, certainly there should at least be a way to recover and use the uncompiled version when memory allocation fails, this is already done by the JIT but not when compiling during installation. Before R or the package is patched, the only workaround for memory constrained systems is probably to disable byte-compilation of this package, as I read you are doing already. Best Tomas On 06/04/2018 05:14 PM, Dirk Eddelbuettel wrote: As you may know, I look after the R package for Debian. My fellow Debianers make me follow a specific protocol -- a so-called "transition" in which all dependent packages on an identified potential breakge are rebuilt under the new (potentially breaking) change. We started adding an r-api-3.4 tag last (major) release. Now it is r-api-3.5 and the transition got started with the green light from the release team last Friday. Now one build failure occurred for one of the (old, effectively litte maintained) RMetrics packages: fBasics. It blows up at the byte-compilation step on at least four (older, smaller) architectures: mips, mipsel, arm64 (ubuntu), ppc64el. More at https://bugs.debian.org/900756 where we also worked out the "solution" of suppressing byte-compilation at installation. Luke, Tomas, ...: Would it help you to get access to such hardware? We may get you some sort of "guest pass" access to porter machines. Else I could try but I have my hands plenty full with the transition (having built [and finally transferred to our Debian Gitlab instance] 20+ package during day two of R/Finance...). Cheers, Dirk PS I CC'ed the bug report, if any follow-up keep the CC it gets logged there. PPS Happy to discuss / help off-list too, of course. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] user macros with multi-line arguments in Rd (was Re: Rd parser throws error for user macros invoked with empty argument)
Now in R-devel,
Best,
Tomas
On 06/01/2018 11:33 AM, Tomas Kalibera wrote:
Thanks for the report, I am testing a patch that will allow multi-line
arguments to user macros.
Best
Tomas
On 05/25/2018 04:45 PM, Georgi Boshnakov wrote:
While on the topic of Rd macro arguments, it seems that if a
multiline argument is supplied, the lines after the first are
silently ignored:
f <- tempfile()
mac6 <- "\\newcommand{\\mac6}{mac6: #1}"
cat(mac6, "\\mac6{2*3
2+2
sin(pi)
}\n", file = f)
rd <- tools::parse_Rd(f)
rd
mac6: 2*3
---
Georgi Boshnakov
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: 25 May 2018 10:05
To: Georgi Boshnakov; r-devel@r-project.org
Subject: Re: [Rd] Rd parser throws error for user macros invoked with
empty argument
Thanks for the report and the examples - and they do not have to be that
verbose, it is enough to just define and use a command, e.g.
cat("\\newcommand{\\mac1}{MAC1:#1}\\mac1{}", file=f)
rd <- tools::parse_Rd(f)
Whenever you get an error message like "Value of SET_STRING_ELT() must
be a 'CHARSXP' not a 'NULL'", there is a bug (at least the error message
should be relevant/informative).
I am testing a patch that will allow empty arguments to macros (they
will expand to an empty string, like in LaTeX).
Best
Tomas
On 05/14/2018 11:23 PM, Georgi Boshnakov wrote:
Bug or feature?
I get the following error from parse_Rd() when a user Rd macro
(including system ones) is invoked with empty argument {},
eg \mymacro{}:
Error in tools::parse_Rd(fn) :
Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
A full example is further below with the system macro \CRANpkg{}. In
this example it doesn't make sense to use empty argument but the
error is not specific to this particular macro.
--
Georgi Boshnakov
Create an Rd file containing system macro \CRANpkg{bibtex},
parse_Rd() is ok:
=
fn <- tempfile()
writeLines("\\name{dummyfun}
\\alias{dummyfun}
\\title{Dummy title}
\\description{Dummy description}
\\usage{
dummyfun(x, ...)
}
\\arguments{
\\item{x}{a value.}
\\item{\\dots}{further arguments.}
}
\\details{
\\CRANpkg{bibtex}
}
", fn)
tools::parse_Rd(fn)
...
\details{
\href{{https://CRAN.R-project.org/package=bibtex}{\pkg{bibtex}}}
}
With empty argument - \CRANpkg{} - Rd parser throws error. Of course
it is silly in this example but I have used it with other user
defined macros where it may make sense to have empty argument.
writeLines("\\name{dummyfun}
\\alias{dummyfun}
\\title{Dummy title}
\\description{Dummy description}
\\usage{
dummyfun(x, ...)
}
\\arguments{
\\item{x}{a value.}
\\item{\\dots}{further arguments.}
}
\\details{
\\CRANpkg{}
}
", fn)
tools::parse_Rd(fn)
Error in tools::parse_Rd(fn) :
Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Understanding the sequence of events when calling the R dpois function
Hi Jason,
Duncan Temple Lang answered a similar question for me last year and wrote
up the method here: http://dsi.ucdavis.edu/Notes/R/FindingNativeCodeInR.html
Basically the C level debugger can be very helpful for figuring out what's
happening.
Best,
Clark
On Fri, Jun 1, 2018 at 4:47 AM, Jason Serviss wrote:
> Chuck and Greg,
>
> Thanks a lot for your help! I have a much better understanding now of what
> is happening “under the hood”.
>
> Kind Regards,
> Jason
>
>
> > On 31 May 2018, at 20:08, Greg Minshall wrote:
> >
> > Jason,
> >
> > as Chuck Berry (to whom, *thanks* for 'do {...} while(0)'!) suggested,
> > using grep, or even grep executed from find, such as
> >
> > find . -type f -exec grep -H "dpois" \{\} \; | less
> >
> > (executed from the root of an R source tree), is your friend.
> >
> > cheers, Greg
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
