Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet

[peter dalgaard]

I don't recall exactly what I did 18 years ago eiher and I likely don't have 
the time to dig into the archives and reconstruct.

I can imagine that the issue had to do with the protocol around creating and 
mapping windows. Presumably the segfault comes from looking for events on a 
window that hasn't been created yet, or has already been destroyed, leading to 
a NULL reference somewhere. I have a vague recollection that the issue was 
window manager dependent (in 2001 probably not twm, more likely xvwm on RedHat 
if it was affecting me). 

A proper fix should go via proper understanding of the X11 protocol - 
uncommenting a line is as bad as commenting it in the 1st place So more 
like "wait for window to exist THEN process events" -- but the 1st part may be 
WM specific, etc. 

I recall docs being quite obtuse, and the X11 "mechanism not policy" credo 
doesn't help as WMs are not obliged to (say) send notifications, so you can end 
up stalling, waiting for events that never happen.

It is entirely possible that there is stuff in here that I didn't understand 
properly at the time, and still don't!

- pd

> On 24 Apr 2019, at 02:30 , Paul Murrell  wrote:
> 
> Hi
> 
> Sorry, I can't offer an explanation for the commented-out line.
> However, regarding your final question of avoiding the R-core bottleneck, you 
> do have the option of creating a third-party graphics device package.  See, 
> for example, the 'tikzDevice' and 'svglite' packages on CRAN.  Does that 
> provide you with a way forward ?
> 
> Paul
> 
> On 20/04/2019 5:27 p.m., frede...@ofb.net wrote:
>> Dear R Devel,
>> 
>> I know that someone put this line in src/modules/X11/devX11.c:2824 for
>> a reason, because commenting it out causes R to miss an important
>> ConfigureNotify event in my window manager. The result is that plots
>> are initially drawn off the window borders, unreadable.
>> 
>>R_ProcessX11Events((void*) NULL);
>> 
>> Unfortunately for me, this line is commented in the standard release
>> of R, it has "#if BUG ... #endif" around it.
>> 
>> I guess it is also unfortunate for anyone who uses the same window
>> manager as I do, namely i3, which I think is pretty popular among Unix
>> power users these days; not to mention other full-screen window
>> managers which probably exhibit the same bug in R.
>> 
>> Maybe everyone on the Core team uses twm as their window manager? Or
>> RStudio on Windows? Which would be sad because then we're not
>> representing an important user demographic, namely those who prefer
>> software which is modern and powerful, yet simple to understand and
>> modify; fully configurable and interoperable and so on.
>> 
>> I first reported this bug 3 years ago. In doing research for my bug
>> report, I found that the line was commented out by Peter Dalgaard in
>> 2001 with the explanation "X11 segfault fix - I hope".
>> 
>> I don't know what the way forward is. Obviously the Core Team has
>> reason to say, "look, this isn't very important, it's been broken
>> since 2001, maybe fixing it will cause the undocumented segfault bug
>> to reappear, clearly no one here uses your window manager". Do I have
>> to submit a correctness proof for the proposed change? What do I do?
>> 
>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702
>> 
>> As mentioned in my bug report, I checked using gdb that
>> ConfigureNotify is indeed being received by the call to
>> R_ProcessX11Events() when it is uncommented. I haven't experienced any
>> segfaults.
>> 
>> It's good that Peter left evidence that "R_ProcessX11Events" was being
>> called 18 years ago from X11DeviceDriver(). If he had deleted the
>> line, rather than commenting it, then discovering the reason for the
>> window rendering bug would have been much harder for me.
>> 
>> However, the downside is that now it is not just a matter of inserting
>> the line where it belongs; I also feel a bit like I have to explain
>> why it was initially removed. But although I've given it some thought,
>> I still have no idea.
>> 
>> Somewhat tangentially, I am wondering if there is some way that we
>> could make the development of R's graphics code proceed at a faster
>> rate, for example by pulling it out into a separate module, so that
>> people could offer alternative implementations via CRAN etc., rather
>> than having R Core be the bottleneck. Would this make sense? Has it
>> already been done?
>> 
>> Thank you,
>> 
>> Frederick
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> -- 
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Co

[Rd] configure script issue with -flto with recent gcc and system ar/ranlib

[Thomas König]

Hi,

there can be an issue with recent gcc where the system-installed "ar"
and "ranlib" commands cannot handle LTO binaries.  On compilation, this
manifests itself with error messages claiming that they need extra
plugins.

This can be fixed by using the command line

$ AR=gcc-ar RANLIB=gcc-ranlib ./configure --enable-lto

so it is not a big issue, but it would still be nicer if the configure
script tested the functionality of ar and ranlib itself and would
select the appropriate one accordingly.

This is with R version 3.5.3.

Regards

Thomas

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

Re: [Rd] Use of C++ in Packages

[John Mount]

I appreciate the writing on this.

However I definitely think there is a huge difference between "use with care" 
and "don't use".  They just are not the same statement. 

> On Mar 29, 2019, at 10:15 AM, Simon Urbanek  
> wrote:
> 
> Jim,
> 
> I think the main point of Tomas' post was to alert R users to the fact that 
> there are very serious issues that you have to understand when interfacing R 
> from C++. Using C++ code from R is fine, in many cases you only want to 
> access R data, use some library or compute in C++ and return results. Such 
> use-cases are completely fine in C++ as they don't need to trigger the issues 
> mentioned and it should be made clear that it was not what Tomas' blog was 
> about.
> 
> I agree with Tomas that it is safer to give an advice to not use C++ to call 
> R API since C++ may give a false impression that you don't need to know what 
> you're doing. Note that it is possible to avoid longjmps by using 
> R_ExecWithCleanup() which can catch any longjmps from the called function. So 
> if you know what you're doing you can make things work. I think the issue 
> here is not necessarily lack of tools, it is lack of knowledge - which is why 
> I think Tomas' post is so important.
> 
> Cheers,
> Simon
> 
> 
>> On Mar 29, 2019, at 11:19 AM, Jim Hester  wrote:
>> 
>> First, thank you to Tomas for writing his recent post[0] on the R
>> developer blog. It raised important issues in interfacing R's C API
>> and C++ code.
>> 
>> However I do _not_ think the conclusion reached in the post is helpful
>>> don’t use C++ to interface with R
>> 
>> There are now more than 1,600 packages on CRAN using C++, the time is
>> long past when that type of warning is going to be useful to the R
>> community.
>> 
>> These same issues will also occur with any newer language (such as
>> Rust or Julia[1]) which uses RAII to manage resources and tries to
>> interface with R. It doesn't seem a productive way forward for R to
>> say it can't interface with these languages without first doing
>> expensive copies into an intermediate heap.
>> 
>> The advice to avoid C++ is also antithetical to John Chambers vision
>> of first S and R as a interface language (from Extending R [2])
>> 
>>> The *interface* principle has always been central to R and to S
>> before. An interface to subroutines was _the_ way to extend the first
>> version of S. Subroutine interfaces have continued to be central to R.
>> 
>> The book also has extensive sections on both C++ (via Rcpp) and Julia,
>> so clearly John thinks these are legitimate ways to extend R.
>> 
>> So if 'don't use C++' is not realistic and the current R API does not
>> allow safe use of C++ exceptions what are the alternatives?
>> 
>> One thing we could do is look how this is handled in other languages
>> written in C which also use longjmp for errors.
>> 
>> Lua is one example, they provide an alternative interface;
>> lua_pcall[3] and lua_cpcall[4] which wrap a normal lua call and return
>> an error code rather long jumping. These interfaces can then be safely
>> wrapped by RAII - exception based languages.
>> 
>> This alternative error code interface is not just useful for C++, but
>> also for resource cleanup in C, it is currently non-trivial to handle
>> cleanup in all the possible cases a longjmp can occur (interrupts,
>> warnings, custom conditions, timeouts any allocation etc.) even with R
>> finalizers.
>> 
>> It is past time for R to consider a non-jumpy C interface, so it can
>> continue to be used as an effective interface to programming routines
>> in the years to come.
>> 
>> [0]: 
>> https://developer.r-project.org/Blog/public/2019/03/28/use-of-c---in-packages/
>> [1]: https://github.com/JuliaLang/julia/issues/28606
>> [2]: https://doi.org/10.1201/9781315381305
>> [3]: http://www.lua.org/manual/5.1/manual.html#lua_pcall
>> [4]: http://www.lua.org/manual/5.1/manual.html#lua_cpcall
>> 
>> __
>> 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

---
John Mount
http://www.win-vector.com/  
Our book: Practical Data Science with R http://www.manning.com/zumel/ 





[[alternative HTML version deleted]]

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

[Rd] improve matrix conformability error message

[Joshua N Pritikin]

Incorrect code,

A <- matrix(1, 2, 2)
B <- matrix(2, 3, 2)
A %*% B

Produces

  Error in A %*% B : non-conformable arguments

It would be helpful to show the matrix dimensions,

  Error in A %*% B : non-conformable arguments of dimensions (2, 2) and (3, 2)

-- 
Joshua N. Pritikin, Ph.D.
Virginia Institute for Psychiatric and Behavioral Genetics
Virginia Commonwealth University
PO Box 980126
800 E Leigh St, Biotech One, Suite 1-133
Richmond, VA 23219
http://exuberant-island.surge.sh

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

Re: [Rd] R prompt updates are not validated

[Tomas Kalibera]

On 4/18/19 11:07 PM, Jack Wasey wrote:

I was trying to get an interactive R prompt with the current working directory. 
I reviewed R source 'main.c' and 'options.c', and saw that a 20 char buffer is 
used when in Browse debugging mode, but that no other validation is done on the 
length of the prompt option.
There is no limit enforced on the length of the prompt option. There is 
nothing wrong about accepting strings of unlimited length, when they are 
handled properly. I don't see any problem in how the prompt string is 
handled in the present code base. The only reason to add such limit may 
be to hide the readline issue you found, but perhaps it would be better 
to solve that on the readline side, unless you have a realistic 
reproducible example to trigger the problem.

This hangs R, or takes extremely long to return:

# R --vanilla
big <- paste(sample(LETTERS, size = 1e7, replace = TRUE), collapse = "")
options(prompt = big)

Running R with gdb and interrupting to get backtraces shows that 'pushReadLine' 
in 'unix/sys-std.c' results in a chain of libreadline calls, including, in my 
case at least, UTF-8 and a lot of __strlen_avx2 activity. 'R_PromptString' in 
'main.c' should check prompt is a reasonable length, as well as a check when 
setting the prompt in 'options.c'. This may be a readline bug, too? I watched 
it do nothing for a while, it didn't seem to accumulate much or any new memory 
while watching 'top', but did max one core of CPU.


I can reproduce this issue with readline on Ubuntu and Fedora, 
rl_callback_handler_install() takes very long, spending a lot on time in 
encoding conversions, and for large inputs corrupts memory. On macOS 
with editline I could get long prompts working fine (fast and without 
crashing). I don't see how this could be a problem in R, it seems to be 
in readline: if you or anyone find it to be a problem worth spending 
time on, I would suggest creating a small standalone C example to 
trigger it and file a bug against readline.



I've searched R-devel and see minimal discussion of security threats in R. Has 
anybody fuzzed R with data or source files? As R grows in popularity, I hope 
there is some pro-active security work going on, which I understand may not 
always best be done on a public mailing list.


Keep in mind that R by design lets you run arbitrary code on the machine 
without any restriction (e.g. via "system", "library", "dyn.load"), and 
there is no API in R to restrict access to those and similar functions. 
So, there is no point in exploiting say a buffer overflow bug. Of 
course, a buffer overflow bug is still a correctness problem and will be 
fixed if found and reported.


Tomas



Jack Wasey

__
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] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet

[peter dalgaard]

OK, so I did the archaeology anyway


This was the story, R-core November 29, 2001. Part of thread "X11 still 
segfaults". 

>>
.
Gah. I've been too tired today. Why did that take me so long?

The culprit seems to be 

R_ProcessEvents((void*) NULL)

in newX11DeviceDriver

This gets called *before* this stuff at the end of Rf_addX11Device

dd = GEcreateDevDesc(dev);
addDevice((DevDesc*) dd);
initDisplayList((DevDesc*) dd);

and it is that "dd" that gets called by Rf_playDisplayList. Removing
the offending line stops the segfaulting, seemingly with no ill
effects. 

I'm not really sure what the use of that line ever was; it might be
necessary to make the call somewhere later, but it appears to have
been possible to race past it before receiving any events all the
time.

I also changed a couple of spots missing dd->newDevStruct=1

Will commit in a moment.
<<

And the following day, in "graphics saga part III", we had

->>
...

I can't make it happen in 1.3.1 but...

It is probably not unrelated to the R_ProcessEvents line that
I took out, but that was definitely wrong. However, one might reenable
it if one could change this bit of code 

if (!(ptr_X11DeviceDriver)((DevDesc*)(dev), display, width, height, ps, 
gamma, 
  colormodel, maxcubesize, canvascolor)) {
free(dev);
errorcall(gcall, "unable to start device %s", devname);
}
gsetVar(install(".Device"), mkString(devname), R_NilValue);
dd = GEcreateDevDesc(dev);
addDevice((DevDesc*) dd);
initDisplayList((DevDesc*) dd);


and put the if-clause last. A cursory clance through the three
functions that are being called didn't reveal anything that would rely
on having opened the device driver first. 

Paul?

(I might try it locally, but I'm not sure I should commit anything.)

<<---

It seems that the suggestion was never followed up on?

-pd


> On 24 Apr 2019, at 11:42 , peter dalgaard  wrote:
> 
> I don't recall exactly what I did 18 years ago eiher and I likely don't have 
> the time to dig into the archives and reconstruct.
> 
> I can imagine that the issue had to do with the protocol around creating and 
> mapping windows. Presumably the segfault comes from looking for events on a 
> window that hasn't been created yet, or has already been destroyed, leading 
> to a NULL reference somewhere. I have a vague recollection that the issue was 
> window manager dependent (in 2001 probably not twm, more likely xvwm on 
> RedHat if it was affecting me). 
> 
> A proper fix should go via proper understanding of the X11 protocol - 
> uncommenting a line is as bad as commenting it in the 1st place So more 
> like "wait for window to exist THEN process events" -- but the 1st part may 
> be WM specific, etc. 
> 
> I recall docs being quite obtuse, and the X11 "mechanism not policy" credo 
> doesn't help as WMs are not obliged to (say) send notifications, so you can 
> end up stalling, waiting for events that never happen.
> 
> It is entirely possible that there is stuff in here that I didn't understand 
> properly at the time, and still don't!
> 
> - pd
> 
>> On 24 Apr 2019, at 02:30 , Paul Murrell  wrote:
>> 
>> Hi
>> 
>> Sorry, I can't offer an explanation for the commented-out line.
>> However, regarding your final question of avoiding the R-core bottleneck, 
>> you do have the option of creating a third-party graphics device package.  
>> See, for example, the 'tikzDevice' and 'svglite' packages on CRAN.  Does 
>> that provide you with a way forward ?
>> 
>> Paul
>> 
>> On 20/04/2019 5:27 p.m., frede...@ofb.net wrote:
>>> Dear R Devel,
>>> 
>>> I know that someone put this line in src/modules/X11/devX11.c:2824 for
>>> a reason, because commenting it out causes R to miss an important
>>> ConfigureNotify event in my window manager. The result is that plots
>>> are initially drawn off the window borders, unreadable.
>>> 
>>>   R_ProcessX11Events((void*) NULL);
>>> 
>>> Unfortunately for me, this line is commented in the standard release
>>> of R, it has "#if BUG ... #endif" around it.
>>> 
>>> I guess it is also unfortunate for anyone who uses the same window
>>> manager as I do, namely i3, which I think is pretty popular among Unix
>>> power users these days; not to mention other full-screen window
>>> managers which probably exhibit the same bug in R.
>>> 
>>> Maybe everyone on the Core team uses twm as their window manager? Or
>>> RStudio on Windows? Which would be sad because then we're not
>>> representing an important user demographic, namely those who prefer
>>> software which is modern and powerful, yet simple to understand and
>>> modify; fully configurable and interoperable and so on.
>>> 
>>> I first reported this bug 3 years ago. In doing research for my bug
>>> report, I found that the line was commented out by Peter Dalgaard in
>>> 2001 with the explanation "X11 segfault fi

[Rd] Bug in "stats4" package - "confint" method

[Stefano de Pretis]

Dear R developers,

I noticed a bug in the stats4 package, specifically in the confint method 
applied to “mle” objects.
In particular, when some “fixed” parameters define the log likelihood, these 
parameters are stored within the mle object but they are not used by the 
“confint" method, which retrieves their value from the global environment 
(whenever they still exist). 

Sample code:

> ## Avoid printing to unwarranted accuracy
> od <- options(digits = 5)
> x <- 0:10
> y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
> 
> ## Easy one-dimensional MLE:
> nLL <- function(lambda, y) -sum(stats::dpois(y, lambda, log = TRUE))
> fit0 <- mle(nLL, start = list(lambda = 5), fixed=list(y=y), nobs = NROW(y))
> confint(fit0)
Profiling...
  2.5 %  97.5 % 
 9.6524 13.6716 
> rm(y)
> confint(fit0)
Profiling...
Error in eval(expr, p) : object 'y' not found

In this sample code, I’m showing that after the removal of y from the global 
environment the method ‘confint’ is not able anymore to act on the object 
‘fit0’.

This retrieval from the global environment is actually dangerous because it’s 
silent and in case the user changes the value of ‘y’ for another purpose the 
method ‘confint’ will return a wrong evaluation of the confidence interval 
without throwing any warning.

I suggest to use the fixed values that are already contained within the mle 
object:

> fit0@fullcoef[grep('y', names(fit0@fullcoef))]
 y1  y2  y3  y4  y5  y6  y7  y8  y9 y10 y11 
 26  17  13  12  20   5   9   8   5   4   8 

Additionally, the method ‘coef’ returns both the coefficient and the fixed 
parameters - while should return only the parameters - , while the ‘fullcoef’ 
method is not implemented - while present in the documentation of 'mle-class’.

Best,
Stefano
 
Center for Genomic Science of IIT@SEMM

Stefano de Pretis, PhD
Postdoctoral fellow
stefano.depre...@iit.it 
Via Adamello 16, 20139 Milan, Italy 

t: +39 02 94375046



[[alternative HTML version deleted]]

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

Re: [Rd] Bug in "stats4" package - "confint" method

[peter dalgaard]

Yep, I know. Well, maybe I didn't, but there are also issues with propagation 
of fixedness in constrained optimization.

Revising mle() had neen on my todo list for way too long. The bbmle package 
handles this better, I believe. 

-pd

> On 24 Apr 2019, at 16:51 , Stefano de Pretis  wrote:
> 
> Dear R developers,
> 
> I noticed a bug in the stats4 package, specifically in the confint method 
> applied to “mle” objects.
> In particular, when some “fixed” parameters define the log likelihood, these 
> parameters are stored within the mle object but they are not used by the 
> “confint" method, which retrieves their value from the global environment 
> (whenever they still exist). 
> 
> Sample code:
> 
>> ## Avoid printing to unwarranted accuracy
>> od <- options(digits = 5)
>> x <- 0:10
>> y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
>> 
>> ## Easy one-dimensional MLE:
>> nLL <- function(lambda, y) -sum(stats::dpois(y, lambda, log = TRUE))
>> fit0 <- mle(nLL, start = list(lambda = 5), fixed=list(y=y), nobs = NROW(y))
>> confint(fit0)
> Profiling...
>  2.5 %  97.5 % 
> 9.6524 13.6716 
>> rm(y)
>> confint(fit0)
> Profiling...
> Error in eval(expr, p) : object 'y' not found
> 
> In this sample code, I’m showing that after the removal of y from the global 
> environment the method ‘confint’ is not able anymore to act on the object 
> ‘fit0’.
> 
> This retrieval from the global environment is actually dangerous because it’s 
> silent and in case the user changes the value of ‘y’ for another purpose the 
> method ‘confint’ will return a wrong evaluation of the confidence interval 
> without throwing any warning.
> 
> I suggest to use the fixed values that are already contained within the mle 
> object:
> 
>> fit0@fullcoef[grep('y', names(fit0@fullcoef))]
> y1  y2  y3  y4  y5  y6  y7  y8  y9 y10 y11 
> 26  17  13  12  20   5   9   8   5   4   8 
> 
> Additionally, the method ‘coef’ returns both the coefficient and the fixed 
> parameters - while should return only the parameters - , while the ‘fullcoef’ 
> method is not implemented - while present in the documentation of 'mle-class’.
> 
> Best,
> Stefano
> 
> Center for Genomic Science of IIT@SEMM
> 
> Stefano de Pretis, PhD
> Postdoctoral fellow
> stefano.depre...@iit.it 
> Via Adamello 16, 20139 Milan, Italy 
> 
> t: +39 02 94375046
> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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

[Rd] Questions/suggestions about new staged installation

[Pages, Herve]

Hi,

I was playing around with inotifywait (great tool!) to see the new 
staged installation of source packages in action. In one terminal I'm 
monitoring the create/delete/move events of the installation library with:

   inotifywait -m --timefmt '%F %T' --format '%T -- %w %e %f' -e create 
-e delete -e move path/to/R/library/

While in another terminal I install CRAN package abc with:

   R CMD INSTALL abc_2.1.tar.gz

All deps are already installed.

## With R 3.5

When installing abc the first time with R 3.5 inotifywait reports the 
following events:

2019-04-24 16:57:42 -- /home/hpages/R/R-3.5.r75051/library/ CREATE,ISDIR 
00LOCK-abc
2019-04-24 16:57:42 -- /home/hpages/R/R-3.5.r75051/library/ CREATE,ISDIR abc
2019-04-24 16:57:45 -- /home/hpages/R/R-3.5.r75051/library/ DELETE,ISDIR 
00LOCK-

Then on subsequent times:

2019-04-24 16:58:14 -- /home/hpages/R/R-3.5.r75051/library/ CREATE,ISDIR 
00LOCK-abc
2019-04-24 16:58:14 -- /home/hpages/R/R-3.5.r75051/library/ 
MOVED_FROM,ISDIR abc
2019-04-24 16:58:14 -- /home/hpages/R/R-3.5.r75051/library/ CREATE,ISDIR abc
2019-04-24 16:58:17 -- /home/hpages/R/R-3.5.r75051/library/ DELETE,ISDIR 
00LOCK-abc

IIUC the additional 'MOVED_FROM,ISDIR abc'  event on subsequent installs 
is triggered by the backing up of the earlier installation in case the 
new installation fails.

## With R 3.6

First installation:

2019-04-24 17:09:04 -- /home/hpages/R/R-3.6.r76385/library/ CREATE,ISDIR 
00LOCK-abc
2019-04-24 17:09:04 -- /home/hpages/R/R-3.6.r76385/library/ CREATE,ISDIR abc
2019-04-24 17:09:08 -- /home/hpages/R/R-3.6.r76385/library/ 
MOVED_TO,ISDIR abc
2019-04-24 17:09:09 -- /home/hpages/R/R-3.6.r76385/library/ DELETE,ISDIR 
00LOCK-abc

Subsequent installations:

2019-04-24 17:09:59 -- /home/hpages/R/R-3.6.r76385/library/ CREATE,ISDIR 
00LOCK-abc
2019-04-24 17:09:59 -- /home/hpages/R/R-3.6.r76385/library/ 
MOVED_FROM,ISDIR abc
2019-04-24 17:09:59 -- /home/hpages/R/R-3.6.r76385/library/ CREATE,ISDIR abc
2019-04-24 17:10:02 -- /home/hpages/R/R-3.6.r76385/library/ 
MOVED_TO,ISDIR abc
2019-04-24 17:10:03 -- /home/hpages/R/R-3.6.r76385/library/ DELETE,ISDIR 
00LOCK-abc

IIUC the new 'MOVED_TO,ISDIR abc' event is triggered by the package 
installation folder being moved from the temporary location to the final 
location.

However I wonder about the CREATE,ISDIR abc event. It looks like even 
for a staged installation tools:::.install_packages() still creates the 
empty abc dir. This should no longer be necessary because this empty 
folder is replaced later by the 'MOVED_TO,ISDIR abc' event. Am I missing 
something?

Another thing: the times indicate that the 'MOVED_TO,ISDIR abc' event 
(move from temp to final location) happens about 3-4 seconds after the 
'MOVED_FROM,ISDIR abc' event (backing up). In this interval of time, the 
abc package is missing. Wouldn't it be safer to leave the earlier 
installation where it is and to replace it when the new installation 
folder is moved from the temporary location to the final location? Said 
otherwise, the backing up step no longer seems necessary with staged 
installs. So inotifywait would report something like this:

2019-04-24 17:09:59 -- /home/hpages/R/R-3.6.r76385/library/ CREATE,ISDIR 
00LOCK-abc
2019-04-24 17:10:02 -- /home/hpages/R/R-3.6.r76385/library/ 
MOVED_TO,ISDIR abc
2019-04-24 17:10:03 -- /home/hpages/R/R-3.6.r76385/library/ DELETE,ISDIR 
00LOCK-abc

That is, only 3 events. On first and subsequent installation.

Cheers,

H.


 > sessionInfo()
R version 3.6.0 beta (2019-04-12 r76385)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.5 LTS

Matrix products: default
BLAS:   /home/hpages/R/R-3.6.r76385/lib/libRblas.so
LAPACK: /home/hpages/R/R-3.6.r76385/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8    LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] compiler_3.6.0


-- 
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