Re: [Rd] Issue with memory deallocation/fragmentation on systems which use glibc
I would like to submit issue to wishlist at the bug reporting system (
https://www.r-project.org/bugs.html) based on my emails. Unfortunately I
don't have bugzilla account. Can someone from R-core help to obtain it? (I
see that I should *"ask an R Core member to add you manually to R’s
Bugzilla members"*)
- https://stat.ethz.ch/pipermail/r-devel/2017-June/074487.html
- https://stat.ethz.ch/pipermail/r-devel/2017-June/074500.html
- https://stat.ethz.ch/pipermail/r-devel/2017-July/074614.html
2017-07-09 13:12 GMT+03:00 Dmitriy Selivanov :
> Dear R-devel mailing list and especially R-core, is there any chance to
> receive feedback on issue I described in previous emails? I would consider
> such behaviour as a bug.
>
> As a work-around I've created small "clean-up" function:
>
> malloc_trim_finalizer = function(e) {
> res = NULL
> if(R.version$os == "linux-gnu") {
> flog.debug("Calling malloc_trim(0L) to trigger glibc to release
> memory\n")
> res = malloc_trim(0L)
> }
> res
> }
>
> And at the end of each function which produce a lot of intermediate small
> objects I provide it to reg.finalizer():
> some_function = function(...) {
> # do some useful work
> result = TRUE
> # register finalizer
> e = environment()
> reg.finalizer(e, malloc_trim_finalizer)
> return(result)
> }
>
> 2017-06-22 11:12 GMT+04:00 Dmitriy Selivanov
> :
>
>> A few additional details. According to Linux Programmer's Manual
>>
>>1. http://man7.org/linux/man-pages/man3/mallopt.3.html
>>2. http://man7.org/linux/man-pages/man3/malloc_trim.3.html
>>
>> And if I understood everything correctly `free` could trigger
>> `malloc_trim` based on value of several environment variables -
>> MALLOC_TOP_PAD_ and MALLOC_TRIM_THRESHOLD_. However setting them as low as
>> 1 or 0 doesn't have any effect (but as I wrote in previous email manual
>> call of `malloc_trim` helps to release memory).
>>
>
>
>
> --
> Regards
> Dmitriy Selivanov
>
--
Regards
Dmitriy Selivanov
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with S4 methods dispatching on `...` (aka dotsMethods)
I pushed the patch to the 3.4 branch. Feel free to test.
Michael
On Wed, Jul 26, 2017 at 4:02 AM, Andrzej Oleś wrote:
> Hi Michael,
>
> it seems that your patch to S4 generics dispatching on `...` is still
> available only in R-devel, and was not included in the minor R-3.4.1
> release. I was wondering what is the policy of incorporating bug fixes from
> the devel branch into release, and whether there is any chance that the
> broken `...` dispatch is fixed before R-3.5.0?
>
> Cheers,
> Andrzej
>
>
> On Tue, Apr 25, 2017 at 4:15 PM, Andrzej Oleś
> wrote:
>>
>> You're right, I must have mixed up my R versions when running the example,
>> as the problem seems to be resolved in R-devel.
>>
>> Sorry for the noise and thanks again for fixing this.
>>
>> Andrzej
>>
>> On Tue, Apr 25, 2017 at 3:55 PM, Michael Lawrence
>> wrote:
>>>
>>> I attempted to fix it, and that example seems to work for me. It's
>>> also a (passing) regression test in R. Are you sure you're using a new
>>> enough R-devel?
>>>
>>>
>>> On Tue, Apr 25, 2017 at 2:34 AM, Andrzej Oleś
>>> wrote:
>>> > Hi Michael,
>>> >
>>> > thanks again for your patch! I've tested it and I'm happy to confirm
>>> > that
>>> > `callNextMethod()` works with methods dispatching on `...`.
>>> >
>>> > However, the second issue I reported still seems to be unresolved.
>>> > Consider
>>> > the following toy example, where the `f()` calls differ in result
>>> > depending
>>> > on whether the dispatch happens on a formal argument or the `...`
>>> > argument.
>>> >
>>> >
>>> > f = function(x, ..., a = b) {
>>> > b = "missing 'a'"
>>> > print(a)
>>> > }
>>> >
>>> > f()
>>> > ## [1] missing 'a'
>>> >
>>> > f(a = 1)
>>> > ## [1] 1
>>> >
>>> > setGeneric("f", signature = "x")
>>> >
>>> > # works as the non-generic version
>>> > f()
>>> > ## [1] missing 'a'
>>> >
>>> > setGeneric("f", signature = "...")
>>> >
>>> > # unexpectedly fails to find 'b'
>>> > f()
>>> > ## Error in print(a) : object 'b' not found
>>> >
>>> >
>>> > Any chances of fixing this?
>>> >
>>> > Cheers,
>>> > Andrzej
>>> >
>>> >
>>> >
>>> > On Fri, Apr 21, 2017 at 11:40 AM, Andrzej Oleś
>>> > wrote:
>>> >>
>>> >> Great, thanks Michael for you quick response!
>>> >>
>>> >> I started off with a question on SO because I was not sure whether
>>> >> this
>>> >> was an actual bug or I was just missing something obvious. I'm looking
>>> >> forward to the patch.
>>> >>
>>> >> Cheers,
>>> >> Andrzej
>>> >>
>>> >>
>>> >> On Thu, Apr 20, 2017 at 10:28 PM, Michael Lawrence
>>> >> wrote:
>>> >>>
>>> >>> Thanks for pointing out these issues. I have a fix that I will commit
>>> >>> soon.
>>> >>>
>>> >>> Btw, I would never have seen the post on Stack Overflow. It's best to
>>> >>> report bugs on the bugzilla.
>>> >>>
>>> >>> Michael
>>> >>>
>>> >>> On Thu, Apr 20, 2017 at 8:30 AM, Andrzej Oleś
>>> >>>
>>> >>> wrote:
>>> >>> > Hi all,
>>> >>> >
>>> >>> > I recently encountered some unexpected behavior with S4 generics
>>> >>> > dispatching on `...`, which I described in
>>> >>> >
>>> >>> >
>>> >>> > http://stackoverflow.com/questions/43499203/use-callnextmethod-with-dotsmethods
>>> >>> >
>>> >>> > TL;DR: `callNextMethod()` doesn't work in methods dispatching on
>>> >>> > `...`,
>>> >>> > and
>>> >>> > arguments of such methods are resolved differently than the
>>> >>> > arguments
>>> >>> > of
>>> >>> > methods dispatching on formal arguments.
>>> >>> >
>>> >>> > Could this indicate a potential problem with the implementation of
>>> >>> > the
>>> >>> > `...` dispatch?
>>> >>> >
>>> >>> > Cheers,
>>> >>> > Andrzej
>>> >>> >
>>> >>> > [[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
[Rd] I have corrected a dead link in the treering documentation
The attached patch corrects a dead link in the treering documentation.
The URL in the manual [1] refers to a personal home page belonging to
Christine Hallman (user "hallman") on the website of the University of
Arizona Laboratory of Tree-Ring Research (LTRR). It seems that the LTRR
personal homepages have been moved to a new root directory [2] and that
Hallman's webpage is no longer there.
I have contacted Dr. Hallman. She confirmed that the LTRR hosting has
changed and that she has not set up her website on a new host. Also,
I have not managed to find any other photographs of the Methuselah Walk.
So the page on the Wayback Machine [3] is the best option I see for now.
Dr. Hallman also told me that she has more photographs of the tree, and
she has offered to publish them in order that we may reference more
photographs eventually.
I have used approximately the following procedure to build and confirm
that the result is formatted properly. (I'm think all of these lines are
necessary, but I am not sure that this is the right order.)
./configure --without-recommended-packages
cd src/library
make all docs Rdfiles
cd -
make
bin/R -e 'help(treering)'
I found other dead links in the base documentation, but I thought most
should be kept for reference, as they were usually links to a
publisher's webpage for a particular journal article or book. The link
of present interest just provides context about the tree whose rings
were measured, so I think it is okay to change the link.
[1] http://www.ltrr.arizona.edu/~hallman/sitephotos/meth.html
[2] http://www.ltrr.arizona.edu/webhome/
[3]
https://web.archive.org/web/20110523225828/http://www.ltrr.arizona.edu/~hallman/sitephotos/meth.html
Index: src/library/datasets/man/treering.Rd
===
--- src/library/datasets/man/treering.Rd(revision 72947)
+++ src/library/datasets/man/treering.Rd(working copy)
@@ -32,6 +32,6 @@
}
\references{
For some photos of Methuselah Walk see
- \url{http://www.ltrr.arizona.edu/~hallman/sitephotos/meth.html}
+
\url{https://web.archive.org/web/20110523225828/http://www.ltrr.arizona.edu/~hallman/sitephotos/meth.html}
}
\keyword{datasets}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] force promises inside lapply
Hi,
I thought I understood the change to lapply semantics resulting from this,
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16093
However, would someone care to explain why this does not work?
> L <- list(a=1, b=2, c=3)
> str(lapply(L, function(x){ y <- substitute(x); force(x); eval(y) }))
Error in eval(y) : object 'X' not found
Basically, my primary goal is to achieve the same result as,
> str(lapply(L, function(x){ eval.parent(substitute(x)) }))
List of 3
$ a: num 1
$ b: num 2
$ c: num 3
but without having to resort to eval.parent as that seems to rely on an
implementation detail of lapply.
My secondary goal is to understand why force(x) does not actually force
the promise here,
> str(lapply(L, function(x){ force(x); pryr::is_promise(x) }))
List of 3
$ a: logi TRUE
$ b: logi TRUE
$ c: logi TRUE
,
Regards
Ben
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] force promises inside lapply
1: substitute(), when given an argument to a function (which will be a
promise) gives you the unevaluated expression given as the argument:
> L <- list(a=1, b=2, c=3)
> str(lapply(L, function(x) substitute(x)))
List of 3
$ a: language X[[i]]
$ b: language X[[i]]
$ c: language X[[i]]
The 'X' and 'i' are in a frame constructed by lapply and you are not really
supposed to depend on the precise form of those expressions.
2: An evaluated promise is still a promise: it has the 'evaled' field set
to TRUE and the 'value' field set to the result of evaluating 'code' in
'env'.
> f <- function(x, force) {
if (force) force(x)
if (pryr::is_promise(x)) promise_info(x)
else "not a promise"
}
> str(f(log(-1), force=FALSE))
List of 4
$ code : language log(-1)
$ env :
$ evaled: logi FALSE
$ value : NULL
> str(f(log(-1), force=TRUE))
List of 4
$ code : language log(-1)
$ env : NULL
$ evaled: logi TRUE
$ value : num NaN
Warning message:
In log(-1) : NaNs produced
Can you give a concrete example of what you are try to accomplish?
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Jul 28, 2017 at 3:04 PM, Benjamin Tyner wrote:
> Hi,
>
> I thought I understood the change to lapply semantics resulting from this,
>
>https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16093
>
> However, would someone care to explain why this does not work?
>
>> L <- list(a=1, b=2, c=3)
>> str(lapply(L, function(x){ y <- substitute(x); force(x); eval(y) }))
>Error in eval(y) : object 'X' not found
>
> Basically, my primary goal is to achieve the same result as,
>
>> str(lapply(L, function(x){ eval.parent(substitute(x)) }))
>List of 3
> $ a: num 1
> $ b: num 2
> $ c: num 3
>
> but without having to resort to eval.parent as that seems to rely on an
> implementation detail of lapply.
>
> My secondary goal is to understand why force(x) does not actually force
> the promise here,
>
>> str(lapply(L, function(x){ force(x); pryr::is_promise(x) }))
>List of 3
> $ a: logi TRUE
> $ b: logi TRUE
> $ c: logi TRUE
> ,
> Regards
> Ben
>
> __
> 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
Re: [Rd] force promises inside lapply
Thanks Bill. I think my confusion may have been in part due to my
conflating two distinct meanings of the term "evaluate"; the help for
force says it "forces the evaluation of a function argument" whereas the
help for eval says it "evaluates the ... argument ... and returns the
computed value". I found it helpful to compare:
> lapply(list(a=1,b=2,c=3), function(x){ force(substitute(x)) })
$a
X[[i]]
$b
X[[i]]
$c
X[[i]]
versus
> lapply(list(a=1,b=2,c=3), function(x){ eval(substitute(x)) })
Error in eval(substitute(x)) : object 'X' not found
Now for the context my question arose in: given a function
loader <- function(package, quietly = TRUE) {
wrapper <- if (quietly) suppressPackageStartupMessages else `{`
expr <- substitute(wrapper(library(package = package)))
eval(expr)
}
prior to R version 3.2, one could do things like
lapply(c("MASS", "boot"), loader)
but not anymore (which is fine; I agree that one should not depend on
lapply's implementation details).
Regards,
Ben
On 07/28/2017 06:53 PM, William Dunlap wrote:
1: substitute(), when given an argument to a function (which will be a
promise) gives you the unevaluated expression given as the argument:
> L <- list(a=1, b=2, c=3)
> str(lapply(L, function(x) substitute(x)))
List of 3
$ a: language X[[i]]
$ b: language X[[i]]
$ c: language X[[i]]
The 'X' and 'i' are in a frame constructed by lapply and you are not
really supposed to depend on the precise form of those expressions.
2: An evaluated promise is still a promise: it has the 'evaled' field
set to TRUE and the 'value' field set to the result of evaluating
'code' in 'env'.
> f <- function(x, force) {
if (force) force(x)
if (pryr::is_promise(x)) promise_info(x)
else "not a promise"
}
> str(f(log(-1), force=FALSE))
List of 4
$ code : language log(-1)
$ env :
$ evaled: logi FALSE
$ value : NULL
> str(f(log(-1), force=TRUE))
List of 4
$ code : language log(-1)
$ env : NULL
$ evaled: logi TRUE
$ value : num NaN
Warning message:
In log(-1) : NaNs produced
Can you give a concrete example of what you are try to accomplish?
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Jul 28, 2017 at 3:04 PM, Benjamin Tyner > wrote:
Hi,
I thought I understood the change to lapply semantics resulting
from this,
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16093
However, would someone care to explain why this does not work?
> L <- list(a=1, b=2, c=3)
> str(lapply(L, function(x){ y <- substitute(x); force(x);
eval(y) }))
Error in eval(y) : object 'X' not found
Basically, my primary goal is to achieve the same result as,
> str(lapply(L, function(x){ eval.parent(substitute(x)) }))
List of 3
$ a: num 1
$ b: num 2
$ c: num 3
but without having to resort to eval.parent as that seems to rely
on an implementation detail of lapply.
My secondary goal is to understand why force(x) does not actually
force the promise here,
> str(lapply(L, function(x){ force(x); pryr::is_promise(x) }))
List of 3
$ a: logi TRUE
$ b: logi TRUE
$ c: logi TRUE
,
Regards
Ben
__
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
