similar to: [External] Re: Building Packages. (fwd)

If you are wondering why RStudio did this, you can see their substitute function using (parent.env(environment(install.packages)))$hook They appear to do these things: - Allow package installation to be disabled. - Check if a package to be installed is already loaded, so that RStudio can restart R for the install. - Add Rtools to the PATH if necessary. - Trigger an event to say

Um, what's with the triple colon? At least on my install, double seems to suffice: > identical(utils:::install.packages, utils::install.packages) [1] TRUE > install.packages function (...) .rs.callAs(name, hook, original, ...) <environment: 0x7f79e0019860> -pd > On 21 Mar 2024, at 09:58 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > The good news for

Yes, you're right. The version found in the search list entry for "package:utils" is the RStudio one; the ones found with two or three colons are the original. Duncan Murdoch On 21/03/2024 5:48 a.m., peter dalgaard wrote: > Um, what's with the triple colon? At least on my install, double seems to suffice: > >> identical(utils:::install.packages,

With all this discussion, I shudder to ask this. I may have missed the answers but the discussion seems to have been about identifying and solving the problem rapidly rather than what maybe is best going forward if all parties agree. What was the motivation for what RSTUDIO did for their version and the decision to replace what came with utils unless someone very explicitly over-rode them by

The good news for Jorgen (who may not be reading this thread any more) is that one can still be sure of getting the original install.packages() by using utils:::install.packages( ... ) with *three* colons, to get the internal (namespace) version of the function. Duncan Murdoch On 21/03/2024 4:31 a.m., Martin Maechler wrote: >>>>>> "Duncan Murdoch on Wed, 20 Mar

I posted a description of their changes this morning. Duncan Murdoch On 21/03/2024 11:37 a.m., avi.e.gross at gmail.com wrote: > With all this discussion, I shudder to ask this. I may have missed the > answers but the discussion seems to have been about identifying and solving > the problem rapidly rather than what maybe is best going forward if all > parties agree. > > What

>>>>> "Duncan Murdoch on Wed, 20 Mar 2024 13:20:12 -0400 writes: > On 20/03/2024 1:07 p.m., Duncan Murdoch wrote: >> On 20/03/2024 12:37 p.m., Ben Bolker wrote: >>> Ivan, can you give more detail on this? I've heard this >>> issue mentioned, but when I open RStudio and run >>> find("install.packages") it

On 20/03/2024 1:07 p.m., Duncan Murdoch wrote: > On 20/03/2024 12:37 p.m., Ben Bolker wrote: >> Ivan, can you give more detail on this? I've heard this issue >> mentioned, but when I open RStudio and run find("install.packages") it >> returns "utils::install.packages", and running dump() from within >> RStudio console and from an external

>>>>> Ben Bolker >>>>> on Wed, 20 Mar 2024 13:25:33 -0400 writes: > Hmm, looks platform-specific. Under Linux both RStudio > and external R console return > a0b52513622c41c11e3ef57c7a485767 > for digest::digest(install.packages) Well, platform-specific maybe, notably probably the *RStudio*-version matters (for once). One one

Hmm, looks platform-specific. Under Linux both RStudio and external R console return a0b52513622c41c11e3ef57c7a485767 for digest::digest(install.packages) On 2024-03-20 1:20 p.m., Duncan Murdoch wrote: > On 20/03/2024 1:07 p.m., Duncan Murdoch wrote: >> On 20/03/2024 12:37 p.m., Ben Bolker wrote: >>> ???? Ivan, can you give more detail on this? I've heard this issue

Hey everyone, Thanks for all the input. It's happening again. This time for the packages "DBI", "parallelly", "segmented", "survival", "V8". So, RStudio shows updates for those and updating them via RStudio leads to this output: ``` > install.packages(c("DBI", "parallelly", "segmented", "survival",

On 1/22/19 6:17 PM, Kevin Ushey wrote: > I think that object.size() is most commonly used to answer the question, > "what R objects are consuming the most memory currently in my R session?" > and for that reason I think returning the size of the internal > representations of objects (for e.g. ALTREP objects; unevaluated promises) > is the right default behavior. I

Pasting the entire example into RStudio and hitting return to evaluate does not show this. Evaluating the finall line to print counttt separately does. Looks like RStudio is calling `[[` on your object when examining the environment for the Environment panel. If this concerns you then you should contact RStudio. Best, luke On Mon, 15 Jul 2019, Rui Barradas wrote: > Hello, > > Clean R

On Thu, 18 Jan 2024, Ivan Krylov via R-devel wrote: > ? Tue, 16 Jan 2024 14:16:19 -0500 > Dipterix Wang <dipterix.wang at gmail.com> ?????: > >> Could you recommend any packages/functions that compute hash such >> that the source references and sexpinfo_struct are ignored? Basically >> a version of `serialize` that convert R objects to raw without >> storing

On Mon, 21 Jan 2019, Martin Maechler wrote: >>>>>> Travers Ching >>>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > > > I have a toy alt-rep string package that generates > > randomly seeded strings. example: library(altstringisode) > > x <- altrandomStrings(1e8) head(x) [1] > >

On Mon, 31 Oct 2016, Henrik Bengtsson wrote: > Thank you for looking into this Luke. > > On Thu, Oct 27, 2016 at 9:26 AM, <luke-tierney at uiowa.edu> wrote: >> On unix, unless event polling is enabled Sys.sleep just waits in a >> select() call (with a SIGINT handler in place) so the elapsed time >> isn't checked until after the select call is complete.

Hi all, Assuming this is an R core issue: tryCatch(install.packages("clipr", repos = "bullshit"), warning = function (w) cat("got a warning")) Warning in install.packages : unable to access index for repository bullshit/src/contrib: cannot open URL 'bullshit/src/contrib/PACKAGES' Warning in install.packages : package ?clipr? is not available (for R

On Fri, 1 Sep 2017, Ralf Goertz wrote: > Am Mon, 28 Aug 2017 09:33:31 +0200 > schrieb Ralf Goertz <r_goertz at web.de>: > > > Hello, me again > >> Hi, >> >> I guess there have been discussions about this in the past and from >> what I understood hooking an R-function to facilitate automatic >> adjustment is problematic. So why not doing it

> I would assume that > library(Matrix, include.only="isDiagonal") > implies that only `isDiagonal` ends up on the search path This could also be a reasonable behavior, but neither does that happen today. > I think a far better approach to solve Michael's problem is simply to use > fac2sparse <- Matrix::fac2sparse This does not fully simulate attachment, e.g.

I think that object.size() is most commonly used to answer the question, "what R objects are consuming the most memory currently in my R session?" and for that reason I think returning the size of the internal representations of objects (for e.g. ALTREP objects; unevaluated promises) is the right default behavior. I also agree it would be worth considering adding arguments that control