similar to: Developing with Namespaces (was: Recent and upcoming changes to R-devel)

Yes, you are absolutely right and I'm pretty sure this will be fixed in one way or another. IMO, the failing test should simply use all.equal.POSIXt's new argument check.tzone=FALSE. Two simple alternatives modifying all.equal.POSIXt behaviour: - make check.tzone=FALSE the default: this is inconsistent with other arguments of all.equal methods, always defaulting to stricter checks -

So let me try to raise this issue once more, and perhaps be more clear about what I think the issue is.. In my opinion there is now a bug in make check in R-development (tested today with r79361). As I see it, I specify a reasonable TZ environment variable and this leads to make check emitting an error. Best, Kasper On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen < kasperdanielhansen

(xposted to bioc-devel and r-devel as I feel it is relevant to both communities) As someone whose body of work is likely to consist mostly of infrastructural packages and research directly in computing I wholeheartedly agree with Kasper's suggestion that we as a community should work to provide and use package citations. I borrow heavily from existing work in terms of both concept and

For people reading this: I was installing bzip2 by hand. Two things to bear in mind (1) it only installs a shared library if you use a special Makefile (this is clearly stated in the installation docs) and (2) I had to symlink libbz2.so.1 to libbz2.so.1.0.6 (the included libbz2.so.1.0 was not being picked up). Best, Kasper On Fri, Mar 27, 2015 at 11:19 AM, Kasper Daniel Hansen <

>>>>> Kasper Daniel Hansen <kasperdanielhansen at gmail.com> >>>>> on Fri, 19 May 2017 20:09:24 -0400 writes: > I rebuilt R with > export LC_CTYPE=en_US.UTF-8 > and the test still fail. Surprisingly, when I run R from the bin directory > and execute the test code, it runs without error: >> oloc <-

Aaaah ... and argh - I should have better not to post R question at midnight, especially when I know it forks the process and it's not using threads. Brain meltdown. (So, we'll proceed trying to use pthreads in matrixStats also for Windows). Sorry for the noise and thanks Kasper. Henrik On Aug 15, 2015 02:52, "Kasper Daniel Hansen" <kasperdanielhansen at gmail.com> wrote:

There was an R-core meeting the week before last, and various planned changes will appear in R-devel over the next few weeks. These are changes planned for R 2.14.0 scheduled for Oct 31. As we are sick of people referring to R-devel as '2.14' or '2.14.0', that version number will not be used until we reach 2.14.0 alpha. You will be able to have a package depend on an svn

I rebuilt R with export LC_CTYPE=en_US.UTF-8 and the test still fail. Surprisingly, when I run R from the bin directory and execute the test code, it runs without error: > oloc <- Sys.getlocale("LC_CTYPE") > mbyte.lc <- { + if(.Platform$OS.type == "windows") + "English_United States.28605" + else if(grepl("[.]UTF-8$", oloc,

As I see it, the display showing the first p << n PCs adding up to 100% of the variance is plainly wrong. I suspect it comes about via a mental short-circuit: If we try to control p using a tolerance, then that amounts to saying that the remaining PCs are effectively zero-variance, but that is (usually) not the intention at all. The common case is that the remainder terms have a roughly

Kasper, I haven?t checked in depth, so just to clarify: you *are* setting CXX11=g++ so it is doing what you asked it to. Since the settings are inherited upwards, this implies that you are setting both CXX14 and CXX17 to g++. So I?m not quite sure I understand your concern. Cheers, Simon > On Sep 3, 2019, at 9:02 PM, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote: >

> On 25 Mar 2016, at 10:08 , Jari Oksanen <jari.oksanen at oulu.fi> wrote: > >> >> On 25 Mar 2016, at 10:41 am, peter dalgaard <pdalgd at gmail.com> wrote: >> >> As I see it, the display showing the first p << n PCs adding up to 100% of the variance is plainly wrong. >> >> I suspect it comes about via a mental short-circuit: If we

Just thought I would mention that the issue below (and in https://stat.ethz.ch/pipermail/r-devel/2013-April/066318.html) is still not resolved. It hasn't been a big problem, but it potentially could be, if a critical package were to have this error on release day, then all its dependencies would fail to build, which would probably require us to postpone our release. See the complete thread

Yes, the potential issue I see is that make check fails when I explicitly set TZ. However, I set it to be the same as what the system reports when I login. Details: The system (RHEL) I am working on has $ strings /etc/localtime | tail -n 1 EST5EDT,M3.2.0,M11.1.0 $ date +%Z EDT $ echo $TZ US/Eastern On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer <seb.meyer at fau.de> wrote: > Thank

Thank you all for your comments and suggestions. @Frederik, my reason for mucking with environments is that I want to minimize the number of names that import adds to my current environment. For instance, if module foo defines a function bar, I want my client code to look like this: import("foo") foo$bar(1,2,3) rather than import("foo") bar(1,2,3) (Just a personal

Thank you for the report. In R-devel, all.equal.POSIXt() by default reports inconsistent time zones. Previously, > x <- Sys.time() > all.equal(x, as.POSIXlt(x, tz = "EST5EDT")) would return TRUE. To ignore the time zone attributes in R-devel, the argument 'check.tzone = FALSE' needs to be used. That said, I can reproduce the 'make check' failure in R-devel on

I agree with Kasper, this is a 'big' issue. Does your method of taking only n PCs reduce the load on memory? The new addition to the summary looks like a good idea, but Proportion of Variance as you describe it may be confusing to new users. Am I correct in saying Proportion of variance describes the amount of variance with respect to the number of components the user chooses to show? So

There is a new version of the 'mvbutils' package (v1.1.1) available on CRAN. For existing users, the main new features are: (i) 'help' now works properly with with R2.0+ (!) (ii) 'mvbutils' is now NAMESPACEd, so you can avoid naming conflicts with other packages. (Many functions are no longer user-visible. (iii) Lazy-loading of individual objects is now available. Among

There is a new version of the 'mvbutils' package (v1.1.1) available on CRAN. For existing users, the main new features are: (i) 'help' now works properly with with R2.0+ (!) (ii) 'mvbutils' is now NAMESPACEd, so you can avoid naming conflicts with other packages. (Many functions are no longer user-visible. (iii) Lazy-loading of individual objects is now available. Among

> On 25 Mar 2016, at 10:41 am, peter dalgaard <pdalgd at gmail.com> wrote: > > As I see it, the display showing the first p << n PCs adding up to 100% of the variance is plainly wrong. > > I suspect it comes about via a mental short-circuit: If we try to control p using a tolerance, then that amounts to saying that the remaining PCs are effectively zero-variance, but

There is no way to control this at runtime. We will probably have to add a configure test. Best, Tomas On 05/04/2017 03:23 PM, Kasper Daniel Hansen wrote: > Thanks. > > I assume there is no way to control this via. environment variables or > configure settings? Obviously that would be great for something like > this which affects tests and seems to be a known problem for older