[Bioc-devel] Delayed Assignment to S4 Slots

[Dario Strbenac via Bioc-devel]

Good day,

I have an S4 class with some slots in my Bioconductor package. One of the slots 
stores the range of top variables to try during feature selection (the 
variables might be ranked by some score, like a t-test). The empty constructor 
looks like

setMethod("ResubstituteParams", "missing", function()
{
  new("ResubstituteParams", nFeatures = seq(10, 100, 10), performanceType = 
"balanced error")
})

But, someone might have a small omics data set with only 40 features (e.g. 
CyTOF). Therefore, trying the top 10, 20, ..., 100 is not a good default. A 
good default would wait until the S4 class is accessed within cross-validation 
and then, based on the dimensions of the matrix or DataFrame, pick a suitable 
range. I looked at delayedAssign, but x is described as "a variable name (given 
as a quoted string in the function call)". It doesn't seem to apply to S4 slots 
based on my understanding of it.

> r <- ResubstituteParams()
> delayedAssign("r@nFeatures", nrow(measurements))
> measurements <- matrix(1:100, ncol = 10)
> r@nFeatures # Still the value from empty constructor.
 [1]  10  20  30  40  50  60  70  80  90 100

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Strange "internal logical NA value has been modified" error

[Pariksheet Nanda]

Hi Hervé,

On 10/13/21 12:43 PM, Hervé Pagès wrote:


On 12/10/2021 15:43, Pariksheet Nanda wrote:


The function in question is:

replace_unstranded <- function (gr) {
 idx <- strand(gr) == "*"
 if (length(idx) == 0L)


    ^
Not related to the "internal logical NA value has been modified" error
but shouldn't you be doing '!any(idx)' instead of 'length(idx) == 0L' here?


Indeed.  Although in a roundabout way the result somehow satisfied the 
unit tests, idx is a poor choice of name because it's really a mask, and 
your suggestion of OR-ing the mask FALSE values with any() is more 
intuitive.  The name is_unstranded might be less cryptic than mask.


Applying your suggestion of the correct condition uncovered a bug where 
return(gr) was returning the unsorted value, which is inconsistent with 
the behavior of the final statement returns a sorted value.  So changed 
to return(sort(gr)) for a consistent contract.


Fixed in f6892ea



Best,
H.


 return(gr)
 sort(c(
 gr[! idx],
 `strand<-`(gr[idx], value = "+"),
 `strand<-`(gr[idx], value = "-")))
}



Pariksheet

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] [External] Re: Strange "internal logical NA value has been modified" error

[Pariksheet Nanda]

Cheers, Luke!

Indeed, the bug could not be caught both using the address sanitizer 
approach pointed out by Henrik nor valgrind in this particular case.


But adding the watchpoint to R_LogicalNAValue worked!

I now have the call stack of the offending functions sample() and 
simulate().  For anyone else who finds the need to do this, do *not* 
specify the SEXP datatype when setting your watchpoint as suggested here 
on StackOverflow (https://stackoverflow.com/a/31202563).  My guess is 
specifying the datatype perhaps causes swapping between the addresses 
spanned by the large SEXP object to the very limited (typically ~8 
registers) for trapping the memory write.  I mention this "wrong way" in 
my steps  below.  To Martin's point, a bit of work was needed to reduce 
to a reliable minimum test case which was turned out to be:


  devtools::install()
  ### In the package "./tests/" directory containing "testthat.R"
  ### run a new R session e.g. `R -f minimum_script.R` with the lines:
  library(tsshmm)
  testthat::test_dir("testthat", package = "tsshmm",
 filter = "train|tss")

Thank you all for your invaluable help,
Pariksheet


Steps to get the call stack:

1) Compile R from source and invoke the debugger:

   R --version | head -1
   # R version 4.1.1 (2021-08-10) -- "Kick Things"
   cd /tmp
   wget https://cloud.r-project.org/src/base/R-4/R-4.1.1.tar.gz
   tar -xf R-4.1.1.tar.gz
   mkdir build-R
   cd build-R/
   ../R-4.1.1/configure  --silent --without-x CFLAGS="-g -O2 -pipe"
   make -j  # -j with C++ will murder your RAM, but C is frugal.
   ./bin/R --debugger=gdb


2) Now that you're in gdb, here's how you set the watchpoint and get the 
back trace:


   (gdb) break memory.c:Rf_InitMemory

   # Breakpoint 1 at 0x177710: file ../../../R-4.1.1/src/main/memory.c, 
line 2136.


   (gdb) run

   # ...
   # Breakpoint 1, Rf_InitMemory () at 
../../../R-4.1.1/src/main/memory.c:2136

   # 2136   init_gctorture();

   (gdb) clear memory.c:Rf_InitMemory

   # Deleted breakpoint 1

   (gdb) print R_LogicalNAValue

   # $1 = (SEXP) 0x0

   (gdb) watch R_LogicalNAValue

   # Hardware watchpoint 2: R_LogicalNAValue

   (gdb) continue

   # Hardware watchpoint 2: R_LogicalNAValue
   #
   # Old value = (SEXP) 0x0
   # New value = (SEXP) 0x55a18140
   # Rf_InitMemory () at ../../../R-4.1.1/src/main/memory.c:2227
   # 2227   LOGICAL(R_LogicalNAValue)[0] = NA_LOGICAL;

   (gdb) info watchpoints

   # Num Type   Disp Enb AddressWhat
   # 2   hw watchpoint  keep y  R_LogicalNAValue
   # breakpoint already hit 1 time

   (gdb) delete 2

   (gdb) info watchpoints

   # No watchpoints.

   (gdb) print R_LogicalNAValue

   # $2 = (SEXP) 0x55a18140

   (gdb) watch *(SEXP) 0x55a18140 # <- *** THIS IS VERY SLOW ***

   Watchpoint 3: *(SEXP) 0x55a18140

   (gdb) delete 3

   (gdb) watch * 0x55a18140 # <- *** Better ***

   # Watchpoint 4: * 0x55a18140

   (gdb) disable

   (gdb) continue
   ...
   > setwd("~/src/tsshmm/tests/")
   > library(tsshmm)
   ...
   > ^C

   # Program received signal SIGINT, Interrupt.
   # 0x77038ff7 in __GI___select (nfds=nfds@entry=1, 
readfds=readfds@entry=0x559f7780 , 
writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0,
   # timeout=timeout@entry=0x0) at 
../sysdeps/unix/sysv/linux/select.c:41

   # 41 ../sysdeps/unix/sysv/linux/select.c: No such file or directory.

   (gdb) enable

   (gdb) continue

   > testthat::test_dir("testthat", package = "tsshmm", filter = 
"train|tss")


   # ...
   # ✔ | F W S  OK | Context
   # ⠏ | 0 | train
   # Thread 1 "R" hit Hardware watchpoint 4: * 0x55a18140

   # Old value = 822083626
   # New value = 805306410
   # RunGenCollect (size_needed=) at 
../../../R-4.1.1/src/main/memory.c:1687

   # 1687   s = next;

   (gdb) backtrace

   #0  RunGenCollect (size_needed=) at 
../../../R-4.1.1/src/main/memory.c:1687
   #1  R_gc_internal (size_needed=) at 
../../../R-4.1.1/src/main/memory.c:3129
   #2  0x556cab98 in Rf_allocVector3 (type=, 
type@entry=13, length=length@entry=626, allocator=allocator@entry=0x0) 
at ../../../R-4.1.1/src/main/memory.c:2775
   #3  0x555c14e0 in Rf_allocVector (length=626, type=13) at 
../../../R-4.1.1/src/include/Rinlinedfuns.h:595

   #4  PutRNGstate () at ../../../R-4.1.1/src/main/RNG.c:444
   #5  0x744cac5e in sample (model=model@entry=0x57da5fa0, 
n=3, from=from@entry=0, f=f@entry=0x744cabf0 ) at 
simulate.c:23
   #6  0x744cad8b in simulate (model=0x57da5fa0, 
obs=, ncol=ncol@entry=100, nrow=nrow@entry=1) at 
simulate.c:101
   #7  0x744ca651 in C_simulate (obs=0x7fffed59c010, 
dim=, trans=, emis=, 
emis_tied=, start=)

   at R_wrap_tsshmm.c:98
   ...


On 10/13/21 8:27 AM, luke-tier...@uiowa.edu wrote:

*Message sent from a system outside of UConn.*


The most likely culprit is C code that is modifying a 

Re: [Bioc-devel] Dev check runtime on all machines

[Hervé Pagès]

Hi Alan,

On 13/10/2021 11:22, alan murphy wrote:

Hi all,

I'm the developer of the MungeSumstats package which is currently timing out on 
the nightly builds for windows (riesling1) but doesn't have any errors: 
https://bioconductor.org/checkResults/3.14/bioc-LATEST/MungeSumstats/riesling1-checksrc.html.

My question is whether there is a reason the builds took a particularly long 
time yesterday?


Running the tests in MungeSumstats takes 228.551 sec. on nebbiolo1 
(Linux release builder) and 659.874 sec. on nebbiolo2 (Linux devel 
builder) so it looks like you added a lot of unit tests to the devel 
version of your package. BTW those times are displayed here



https://bioconductor.org/checkResults/3.13/bioc-LATEST/MungeSumstats/nebbiolo1-checksrc.html

and here


https://bioconductor.org/checkResults/3.14/bioc-LATEST/MungeSumstats/nebbiolo2-checksrc.html

It's a very good thing that you add so many tests to your package. 
Remember however that on Windows we run 'R CMD check' with the 
--force-multiarch option to force all the examples and tests to run 
twice: once in 32-bit mode and once in 64-bit mode. This probably 
explains why you see the TIMEOUT on Windows and not on the other builders.




For example, the MAC (merida1) check ran in 21 minutes but running 
devtools::check() locally after removing all cached items runs in 12.5 minutes. 
Secondly, is there a way to check how long the unit tests took to run on each 
machine? It doesn't seem to be available in the raw or summarised build reports.

I ask because if the checks should generally run quicker I won't make any 
changes to my package to speed up the check. Otherwise, I will likely remove 
some unit tests which I believe account for a decent part of the runtime.


One way to deal with this is to disable the tests on 32-bit Windows. 
This platform will go away soon anyways so there's not much value in 
running the tests for it anymore.


Another option for you, especially if you want to be able to keep adding 
tests to your package, is to add "long tests" to your package and to 
subscribe to our Long Tests builds. See here 
https://bioconductor.org/checkResults/3.14/bioc-longtests-LATEST/ for 
more info.


Hope this helps.

Cheers,
H.



Thanks,
Alan.


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] End-of-life for predictionet

[Kern, Lori]

Thank you for letting us know.  We will begin the deprecation process.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Eeles, 
Christopher 
Sent: Wednesday, October 13, 2021 4:09 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] End-of-life for predictionet

Hello BioC core team,

The predictionet Bioconductor package is out of date and we no longer wish to 
maintain it. Would it be possible to begin the deprecation process?

Thanks for your assistance.

Best,
---
Christopher Eeles
Software Developer
BHK 
Laboratory
Princess Margaret Cancer 
Centre
University Health 
Network



This e-mail may contain confidential and/or privileged information for the sole 
use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was 
originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete 
all copies.
Opinions, conclusions or other information contained in this e-mail may not be 
that of the organization.

If you feel you have received an email from UHN of a commercial nature and 
would like to be removed from the sender's mailing list please do one of the 
following:
(1) Follow any unsubscribe process the sender has included in their email
(2) Where no unsubscribe process has been included, reply to the sender and 
type "unsubscribe" in the subject line. If you require additional information 
please go to our UHN Newsletters and Mailing Lists page.
Please note that we are unable to automatically unsubscribe individuals from 
all UHN mailing lists.


Patient Consent for Email:

UHN patients may provide their consent to communicate with UHN about their care 
using email. All electronic communication carries some risk. Please visit our 
website 
here
 to learn about the risks of electronic communication and how to protect your 
privacy. You may withdraw your consent to receive emails from UHN at any time. 
Please contact your care provider, if you do not wish to receive emails from 
UHN.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1-s4wjcE4Nw0s7erXjRW5U4ktopYgz7cDPOcLCW5jTnm_Jd2spss3TctzgafECcsKxxOAOA8hUEZOFRisx2wdYEDO_jDYnsLxtA60WcyEFdN3LGNcBIZmKciGJFvyu6t7Ts1lAF65uwG7KPdoaWvOh4bWTm1Shinlzet-oNqRsf7Qsu8qeKKv2pjaBkmqEDr3uNysjD-uYSPVcPmZ-UTEhOOzDraincuCWxozD-kKIiwYgXm5CZ1xYw3ftsp-Oanfb6H7CxyM4XqYktWfYtjw8BRzU-ffeBgvpB1snkiaRqOdNJY96DgtqxyWGWpXXLVnLmdWrBwH-77UemUaVMtssA/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] End-of-life for predictionet

[Eeles, Christopher]

Hello BioC core team,

The predictionet Bioconductor package is out of date and we no longer wish to 
maintain it. Would it be possible to begin the deprecation process?

Thanks for your assistance.

Best,
---
Christopher Eeles
Software Developer
BHK 
Laboratory
Princess Margaret Cancer 
Centre
University Health 
Network



This e-mail may contain confidential and/or privileged information for the sole 
use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was 
originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete 
all copies.
Opinions, conclusions or other information contained in this e-mail may not be 
that of the organization.

If you feel you have received an email from UHN of a commercial nature and 
would like to be removed from the sender's mailing list please do one of the 
following:
(1) Follow any unsubscribe process the sender has included in their email
(2) Where no unsubscribe process has been included, reply to the sender and 
type "unsubscribe" in the subject line. If you require additional information 
please go to our UHN Newsletters and Mailing Lists page.
Please note that we are unable to automatically unsubscribe individuals from 
all UHN mailing lists.


Patient Consent for Email:

UHN patients may provide their consent to communicate with UHN about their care 
using email. All electronic communication carries some risk. Please visit our 
website 
here
 to learn about the risks of electronic communication and how to protect your 
privacy. You may withdraw your consent to receive emails from UHN at any time. 
Please contact your care provider, if you do not wish to receive emails from 
UHN.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Release 3.13 is frozen

[Nitesh Turaga]

Hello,

The release 3.13 branch of Bioconductor is now frozen. You will not be able to 
push to this RELEASE_3_13 branch of your package again.

Please review the release schedule 
http://bioconductor.org/developers/release-schedule/ for more information.

Best regards,


Nitesh Turaga
Scientist II, Department of Data Science,
Bioconductor Core Team Member
Dana Farber Cancer Institute

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Dev check runtime on all machines

[alan murphy]

Hi all,

I'm the developer of the MungeSumstats package which is currently timing out on 
the nightly builds for windows (riesling1) but doesn't have any errors: 
https://bioconductor.org/checkResults/3.14/bioc-LATEST/MungeSumstats/riesling1-checksrc.html.

My question is whether there is a reason the builds took a particularly long 
time yesterday? For example, the MAC (merida1) check ran in 21 minutes but 
running devtools::check() locally after removing all cached items runs in 12.5 
minutes. Secondly, is there a way to check how long the unit tests took to run 
on each machine? It doesn't seem to be available in the raw or summarised build 
reports.

I ask because if the checks should generally run quicker I won't make any 
changes to my package to speed up the check. Otherwise, I will likely remove 
some unit tests which I believe account for a decent part of the runtime.

Thanks,
Alan.


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Bioconductor Release 3.13 Code Freeze

[Nitesh Turaga]

Hi

The release 3.13 branch will be frozen after the next 2 hours. After today, you 
will not be able push to this branch.

Please refer to http://bioconductor.org/developers/release-schedule/. 

Best regards,


Nitesh Turaga
Scientist II, Department of Data Science,
Bioconductor Core Team Member
Dana Farber Cancer Institute

> On Oct 7, 2021, at 2:03 AM, Kern, Lori  wrote:
> 
> The release 3.13 branch will be frozen next Tuesday October 12th. After this 
> date there will be no updates to Bioconductor 3.13 packages in Bioconductor 
> EVER. Note this is one day later than previously announced due to the US 
> Holiday on October 11th.
> 
> Cheers,
> 
> 
> Lori Shepherd
> 
> Bioconductor Core Team
> 
> Roswell Park Comprehensive Cancer Center
> 
> Department of Biostatistics & Bioinformatics
> 
> Elm & Carlton Streets
> 
> Buffalo, New York 14263
> 
> 
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Failed to locate any version of JAGS version 4

[Hervé Pagès]

Update: I defined the JAGS_HOME environment variable on riesling1 as 
suggested off-list by Martin (thanks Martin), so now rjags can be loaded 
again. This should solve the problem for CNVrd2, HiLDA, infercnv, and 
MADSEQ.


I did the same on tokay2 (Windows server for the 3.13 builds) where the 
recent update to rjags also broke the 4 Bioconductor packages above. 
While I was on it, I updated JAGS from JAGS-4.2.0 to the latest version 
(JAGS-4.3.0) on tokay2. So now we have the same version on riesling1 and 
tokay2.


Cheers,
H.


On 12/10/2021 13:29, Zhi Yang wrote:
Thank you so much, Herve! It makes sense to me now. I imported R2jags in 
my package, which depends on rjags.


Regards,
Zhi Yang




On Tue, Oct 12, 2021 at 1:14 PM Hervé Pagès > wrote:


Hmm.. so a new version of rjags (4-11) got published on CRAN on Sept 24:

https://cran.r-project.org/package=rjags


and for some reason they modified the code they use in their onLoad()
hook to find JAGS on Windows. They were using in rjags 4-10:

      readRegistry("SOFTWARE\\JAGS", hive="HLM", maxdepth=2,
view="32-bit")


which was working fine on our Windows server riesling1 (and AFAIK also
on the CRAN Windows build machine), but in rjags 4-11 they use:

      readRegistry("SOFTWARE\\JAGS", hive="HLM", maxdepth=2,
view="64-bit")



which fails on riesling1 with:

      Error in readRegistry("SOFTWARE\\JAGS", hive = "HLM", maxdepth
= 2,
view = "64-bit") :

        Registry key 'SOFTWARE\JAGS' not found


I've reinstalled JAGS-4.3.0 on riesling1 but that doesn't change
anything.

Unfortunately this breaks all packages that depend on rjags:

    - https://bioconductor.org/checkResults/3.14/bioc-LATEST/CNVrd2/

    - https://bioconductor.org/checkResults/3.14/bioc-LATEST/HiLDA/

    -
https://bioconductor.org/checkResults/3.14/bioc-LATEST/infercnv/

    - https://bioconductor.org/checkResults/3.14/bioc-LATEST/MADSEQ/


Help appreciated.

BTW your package HiLDA is one of them so I wonder why rjags is not
listed in the Imports field.

Best,
H.


On 11/10/2021 21:24, Zhi Yang wrote:
 > Hello everyone,
 >
 > I encountered a problem with two of my Bioconductor packages
built on the
 > windows server for the next release. Specifically, it couldn't
locate any
 > version of JAGS version 4. Has anyone experienced the same issue with
 > importing or depending on rjags? Thank you!
 >
 > ** using staged installation
 > ** libs
 > "C:/rtools40/mingw32/bin/"g++ -std=gnu++11
 > -I"D:/biocbuild/bbs-3.14-bioc/R/include" -DNDEBUG
 > -I'D:/biocbuild/bbs-3.14-bioc/R/library/Rcpp/include'
 > -I"C:/extsoft/include"     -O2 -Wall  -mfpmath=sse -msse2
 > -mstackrealign  -c EMalgorithm.cpp -o EMalgorithm.o
 > "C:/rtools40/mingw32/bin/"g++ -std=gnu++11
 > -I"D:/biocbuild/bbs-3.14-bioc/R/include" -DNDEBUG
 > -I'D:/biocbuild/bbs-3.14-bioc/R/library/Rcpp/include'
 > -I"C:/extsoft/include"     -O2 -Wall  -mfpmath=sse -msse2
 > -mstackrealign  -c RcppExports.cpp -o RcppExports.o
 > "C:/rtools40/mingw32/bin/"g++ -std=gnu++11
 > -I"D:/biocbuild/bbs-3.14-bioc/R/include" -DNDEBUG
 > -I'D:/biocbuild/bbs-3.14-bioc/R/library/Rcpp/include'
 > -I"C:/extsoft/include"     -O2 -Wall  -mfpmath=sse -msse2
 > -mstackrealign  -c checkBoundary.cpp -o checkBoundary.o
 > "C:/rtools40/mingw32/bin/"g++ -std=gnu++11
 > -I"D:/biocbuild/bbs-3.14-bioc/R/include" -DNDEBUG
 > -I'D:/biocbuild/bbs-3.14-bioc/R/library/Rcpp/include'
 > -I"C:/extsoft/include"     -O2 -Wall  -mfpmath=sse -msse2
 > -mstackrealign  -c convertFromToVector.cpp -o convertFromToVector.o
 > C:/rtools40/mingw32/bin/g++ -std=gnu++11 -shared -s -static-libgcc -o
 > HiLDA.dll tmp.def EMalgorithm.o RcppExports.o checkBoundary.o
 > convertFromToVector.o -LC:/extsoft/lib/i386 -LC:/extsoft/lib
 > -LD:/biocbuild/bbs-3.14-bioc/R/bin/i386 -lR
 > installing to

D:/biocbuild/bbs-3.14-bioc/meat/HiLDA.buildbin-libdir/00LOCK-HiLDA/00new/HiLDA/libs/i386
 > ** R
 > ** inst
 > ** byte-compile and prepare package for lazy loading
 > Error: .onLoad failed in loadNamespace() for 'rjags', details:
 >    call: fun(libname, pkgname)
 >    error: Failed to locate any version of JAGS version 4
 >
 > The rjags package is just an interface to the JAGS library
 > Make sure you have installed JAGS-4.x.y.exe (for any x >=0, y>=0)
 > fromhttp://www.sourceforge.net/projects/mcmc-jags/files

Re: [Bioc-devel] Strange "internal logical NA value has been modified" error

[Hervé Pagès]

Hi Pariksheet,

On 12/10/2021 15:43, Pariksheet Nanda wrote:



The function in question is:


replace_unstranded <- function (gr) {
     idx <- strand(gr) == "*"
     if (length(idx) == 0L)


   ^
Not related to the "internal logical NA value has been modified" error 
but shouldn't you be doing '!any(idx)' instead of 'length(idx) == 0L' here?


Best,
H.


     return(gr)
     sort(c(
     gr[! idx],
     `strand<-`(gr[idx], value = "+"),
     `strand<-`(gr[idx], value = "-")))
}





--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Request GWAS.BAYES to be un-deprecated

[Kern, Lori]

Since the package is building cleanly in devel,  we will undeprecate the 
package.  Thank you for your contiued contributions to Bioconductor.

Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Jake Williams 

Sent: Wednesday, October 13, 2021 11:29 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Request GWAS.BAYES to be un-deprecated


___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1mg1yPS2EPI9Ls19fpZl3xxfmOPJeUzjeXv4ifiqMrt8JQxt5u8AkU2dRoY1v59J579K2LIe6VCOshKlshQoUlRc9S4_ky2VoKxLam6qmeQXleor5tKmS0icNgpqcw8BzqtLZ9CuHW2VHOSITX8vNc5WsnVZclgn_nRb5SPL0GicoJ6oDVfnoEFXtACf4aInr68uYam0pw_c4bjSPuiQ9argxfRz0GEm1mBU88zTAhDVoR9H4RSEu3wvF8UMT8XsPAlr22Iz795uqqbZodLi0tsn86hQ8wueM7daMLAkXlGrwEpO4PpnpiGqiJh1A7h_1/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Request GWAS.BAYES to be un-deprecated

[Jake Williams]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Final List of Deprecated Packages for Bioc3.14

[Kern, Lori]

The Bioconductor Team is continuing to identify packages that will be 
deprecated in the next release to allow for the Bioconductor community to 
respond accordingly. The list will be updated monthly. This is the current list 
of deprecated packages for Bioc 3.14 :




Maintainer requested deprecation:

  *   Software:

  *
  *

 *   MSstatsTMTPTM
 *   MSGFplus
 *   MSGFgui
 *   alsace
 *   dualKS
 *   slinky
 *   FindMyFriends
 *   PanVizGenerator
 *   RGalaxy
  *
  *

Unresponsive maintainers:

  *

Software:

  *
  *

 *   affyPara
 *   ALPS
 *   BrainStars
 *   destiny
 *   ENCODEExplorer
 *   ENVISIONQuery
 *   GeneAnswers
 *   gramm4R
 *   GWAS.BAYES
 *   KEGGprofile
 *   MouseFM
 *   SRGnet
 *   SwimR
  *
  *
  *

  *   Experiment Data:

  *
 *   ABAData
 *   brainImageRdata
 *   PCHiCdata
 *   RITANdata
 *   tcgaWGBSData.hg19
  *
  *
  *
  *
  *

  *   It should be noted, we did try to reach out to these package maintainers 
multiple times and they were either unresponsive or had emails bounce. We 
encourage anyone that is familiar with a package maintainer on this list to 
reach out to them and notify them directly. Packages can be un-deprecated if a 
maintainer fixes the package to build/check cleanly before the next release and 
requests un-deprecation on the bioc-devel@r-project.org mailing list.




Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] [External] Re: Strange "internal logical NA value has been modified" error

[luke-tierney]

The most likely culprit is C code that is modifying a logical vector
without checking whether this is legitimate for R semantics
(i.e. making sure MAYBE_REFERENCED or at least MAYBE_SHARED is FALSE).
If that is the case, then this is legitimate for C code to do in
principle, so UBSAN and valgrind won't help. You need to set a gdb
watchpoint on the location, catch where it is modified, and look up
the call stack from there.

The error signaled in the GC is a sanity check for catching that this
sort of misbehavior has happened in C code. But it is a check after
the fact; it can't tell you more that that the problem happened
sometime before it was detected.

Best,

luke

On Wed, 13 Oct 2021, Martin Morgan wrote:


The problem with using gdb is you'd find yourself in the garbage collector, but 
perhaps quite removed from where the corruption occurred, e.g., gc() might / 
will likely be triggered after you've returned to the top-level evaluation 
loop, and the part of your code that did the corruption might be off the stack.

The problem with devtools::check() (and R CMD check) is that running the unit 
tests occurs in a separate process, so things like setting a global option (and 
even system variable from within R) may not be visible in the process doing the 
check. Conversely, for the same reasons, it seems like the problem can be 
tickled by running the tests alone. So

 R -f /tests/testthat.R

would seem to be a good enough starting point.

Actually, I liked Henrik's UBSAN suggestion, which requires the least amount of 
work. I think I'd then try

 R -d valgrind -f /tests/testthat.R

and then further into the weeds... actually from the section of R-exts you 
mention

 R_C_BOUNDS_CHECK=yes R -f /tests/testthat.R

might also be promising.

Martin

On 10/12/21, 10:30 PM, "Bioc-devel on behalf of Pariksheet Nanda" 
 wrote:

   Hi all,

   On 10/12/21 6:43 PM, Pariksheet Nanda wrote:
   >
   > Error in `...`: internal logical NA value has been modified

   In the R source code, this error is in src/main/memory.c so I was
   thinking one way of investigating might be to run `R --debugger gdb`,
   then running R to load the symbols and either:

   1) set a breakpoint for when it reaches that particular line in
   memory.c:R_gc_internal and then walk up the stack,

   2) or set a watch point on memory.c:R_gc_internal:R_LogicalNAValue
   (somehow; having trouble getting gdb to reach that context).

   3) Then I thought, maybe this is getting far into the weeds and instead
   I could check the most common C related error by enabling bounds
   checking of my C arrays per section 4.4 of the R-exts manual:

   $ R -q
> options(CBoundsCheck = TRUE)
> Sys.setenv(R_C_BOUNDS_CHECK = "yes") # Try both ways *shrug*
> devtools::test()
   ... # All tests still pass.
> devtools::check()
   ... # No change :(

   Maybe I'm not sure I'm using that option correctly?  Or the option is
   ignored in devtools::check().  Or indeed, the error is not from over
   running C array boundaries.

   It turns out that using the precompiled debug symbols[1] isn't all that
   useful here because I don't get line numbers in gdb without the source
   files and many symbols are optimized out, so it looks like I would need
   to compile R from source with -ggdb first instead of using the Debian
   packages.

   Hopefully this is still the right approach?

   Pariksheet


   [1] After install r-base-core-dbg on Debian for the debug symbols.

   ___
   Bioc-devel@r-project.org mailing list
   https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Strange "internal logical NA value has been modified" error

[Martin Morgan]

The problem with using gdb is you'd find yourself in the garbage collector, but 
perhaps quite removed from where the corruption occurred, e.g., gc() might / 
will likely be triggered after you've returned to the top-level evaluation 
loop, and the part of your code that did the corruption might be off the stack.

The problem with devtools::check() (and R CMD check) is that running the unit 
tests occurs in a separate process, so things like setting a global option (and 
even system variable from within R) may not be visible in the process doing the 
check. Conversely, for the same reasons, it seems like the problem can be 
tickled by running the tests alone. So

  R -f /tests/testthat.R

would seem to be a good enough starting point.

Actually, I liked Henrik's UBSAN suggestion, which requires the least amount of 
work. I think I'd then try 

  R -d valgrind -f /tests/testthat.R

and then further into the weeds... actually from the section of R-exts you 
mention

  R_C_BOUNDS_CHECK=yes R -f /tests/testthat.R

might also be promising.

Martin

On 10/12/21, 10:30 PM, "Bioc-devel on behalf of Pariksheet Nanda" 
 
wrote:

Hi all,

On 10/12/21 6:43 PM, Pariksheet Nanda wrote:
>
> Error in `...`: internal logical NA value has been modified

In the R source code, this error is in src/main/memory.c so I was 
thinking one way of investigating might be to run `R --debugger gdb`, 
then running R to load the symbols and either:

1) set a breakpoint for when it reaches that particular line in 
memory.c:R_gc_internal and then walk up the stack,

2) or set a watch point on memory.c:R_gc_internal:R_LogicalNAValue 
(somehow; having trouble getting gdb to reach that context).

3) Then I thought, maybe this is getting far into the weeds and instead 
I could check the most common C related error by enabling bounds 
checking of my C arrays per section 4.4 of the R-exts manual:

$ R -q
 > options(CBoundsCheck = TRUE)
 > Sys.setenv(R_C_BOUNDS_CHECK = "yes") # Try both ways *shrug*
 > devtools::test()
... # All tests still pass.
 > devtools::check()
... # No change :(

Maybe I'm not sure I'm using that option correctly?  Or the option is 
ignored in devtools::check().  Or indeed, the error is not from over 
running C array boundaries.

It turns out that using the precompiled debug symbols[1] isn't all that 
useful here because I don't get line numbers in gdb without the source 
files and many symbols are optimized out, so it looks like I would need 
to compile R from source with -ggdb first instead of using the Debian 
packages.

Hopefully this is still the right approach?

Pariksheet


[1] After install r-base-core-dbg on Debian for the debug symbols.

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel