similar to: Shouldn't "Loading" be "Attaching" when referring to library() calls?

>>>>> Michael Chirico via R-devel >>>>> on Mon, 9 Jan 2023 12:25:46 -0800 writes: > require() and library() both emit this message immediately before > running library(): > "Loading required package: %s" > https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c2b908f48c369f40a/src/library/base/R/library.R#L967-L968

We have code that processes a buffer in the forward or backwards direction. It looks similar to the following (https://github.com/weidai11/cryptopp/blob/master/adv-simd.h#L1138): uint8_t * ptr = ... size_t len = ... size_t inc = 16; if (flags & REVERSE_DIRECTION) { ptr += len - inc; inc = 0-inc; } while (len > 16) { // process blocks ptr += inc; len -= 16; } Clang

I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand why yet, but the LegacyPassManager detects that the structural hash of the function has changed, and complains that the pass didn’t correctly report that it changed the function [4] (even though materially, it didn’t). This raises a

We ran into a bug in our package that seems to boil down to isNamespaceLoaded() returning TRUE for namespaces that R is currently loading. We had something like this in an .onLoad function: if (isNamespaceLoaded("upstream")) { upstream::upstream_function() } Which seems OK, unless upstream (recursively) imports the package having this code. Should that happen, the loading of

Hi, I am getting the following error from LLVM 2.9/Final for the sparc code and I wonder whether I am misusing the command line options, which are shown below; clang -ccc-host-triple sparc-unknown-linux -ccc-clang-archs sparc -S -emit-llvm sample1.c -o sample1.ll --> clang: warning: unknow platform, assuming -mfloat-abi=soft --> error: error reading 'soft'

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > A isNamespaceLoaded() function would be a useful thing to > have in general if we are interested in readable code. An > efficient implementation would be just a bonus. Good point (readability), and thank you for the support! Note

Hi, I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux distribution [1], but the build fails during the "make check" phase because of the following 2 issues: 1) The "tools" test in "tests/Examples" requires network access, which it doesn't have in our build environment. Therefore, it fails as follows according to

>>>>> Benjamin Tyner >>>>> on Sat, 21 Jul 2018 13:42:43 -0400 writes: > Not sure whether it is the same issue as was raised here: > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html > but in any case perhaps the problem could partially be remedied on line > 245 of src/library/base/R/library.R by passing the lib.loc to

On 24.07.2018 23:37, Benjamin Tyner wrote: > > > On 07/24/2018 07:50 AM, Martin Maechler wrote: >>>>>>> Benjamin Tyner >>>>>>> ???? on Sat, 21 Jul 2018 13:42:43 -0400 writes: >> ???? > Not sure whether it is the same issue as was raised here: >> ???? > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html >>

>>>>> Benjamin Tyner >>>>> on Fri, 20 Jul 2018 19:42:09 -0400 writes: > Here's a trick/workaround; if lib.loc is the path to your > library, then prior to calling library(), >> environment(.libPaths)$.lib.loc <- lib.loc Well, that is quite a "trick" -- and potentially a pretty dangerous one, not intended when making

>>>>> Peter Simons <simons at nospf.cryp.to> >>>>> on Mon, 27 Feb 2017 10:30:39 +0100 writes: > Hi, I tried compiling the latest pre-release for R 3.3.3 > for the NixOS Linux distribution [1], but the build fails > during the "make check" phase because of the following 2 > issues: > 1) The "tools" test

On 27/02/2017 09:30, Peter Simons wrote: > Hi, > > I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux > distribution [1], but the build fails during the "make check" phase > because of the following 2 issues: Hmm, R-devel (your subject line) is not a pre-release of R 3.3.3: it is 'R Under development' for what is planned as R 3.4.0.

isLoadedNamespace() sounds fine to me.. Thanks for addressing this, Michael On Mon, Jan 26, 2015 at 5:51 AM, Martin Maechler < maechler at lynne.stat.math.ethz.ch> wrote: > >>>>> Michael Lawrence <lawrence.michael at gene.com> > >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > > > A isNamespaceLoaded() function would be a useful

On 07/24/2018 07:50 AM, Martin Maechler wrote: >>>>>> Benjamin Tyner >>>>>> on Sat, 21 Jul 2018 13:42:43 -0400 writes: > > Not sure whether it is the same issue as was raised here: > > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html > > > but in any case perhaps the problem could partially be remedied on

Not sure whether it is the same issue as was raised here: https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html but in any case perhaps the problem could partially be remedied on line 245 of src/library/base/R/library.R by passing the lib.loc to .getRequiredPackages2() ...here is a patch (untested) Index: src/library/base/R/library.R

>>>>> Winston Chang <winstonchang1 at gmail.com> >>>>> on Fri, 23 Jan 2015 10:15:53 -0600 writes: > I think you can simplify a little by replacing this: > pkg %in% loadedNamespaces() > with this: > .getNamespace(pkg) almost: It would be !is.null(.getNamespace(pkg)) > Whereas getNamespace(pkg) will load the

I've just updated to the latest R (2.14.2) on my Ubuntu Lucid box, and now the ggplot2 installed as a .deb package fails to work. $ R -e 'library(ggplot2)' Error in library(pkg, character.only = TRUE, logical.return = TRUE, lib.loc = lib.loc) : package ?proto? does not have a NAMESPACE and should be re-installed Calls: library -> .getRequiredPackages2 -> library Execution

Hi, is there a reason why when calling the argument 'lib.loc' of library() is not used when trying to load the required packages? 0. Package A depends on package B 1. Install packages A and B in a subdirectory 'lib' of the current directory 2. Call: library(A, lib.loc='./lib') This will give something like the following: Loading required package: B Error: package

Calling library(..., quietly=TRUE) may still output: Loading required package: <other pkg> in some cases, e.g. > library("R.utils", quietly=TRUE) Loading required package: R.methodsS3 [...] I traced this to base:::.getRequiredPackages2(), which forgets to pass 'quietly' to an internal library() call: if (!attached) { if (!quietly)

Hi Geoff, Importing symbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add'