I'm wondering if there is a way to suppress console output from a single library in processing? Specifically, I am using SimpleOpenNI and it constantly outputs stuff like the below many times a second:
[Info] [VTRgbPacketProcessor] avg. time: 22.8676ms -> ~43.73Hz [Info]
[DepthPacketStreamParser] 1 packets were lost [Info]
[OpenGLDepthPacketProcessor] avg. time: 5.9517ms -> ~168.019Hz
The library is working fine but the output is a bit annoying as I'm trying to use the console to test stuff.
Anyone know a way to suppress output from a specific library? I've looked through the SimpleOpenNI docs and cant find anything that helps.
Cheers
You generally have three options:
Option 1: Hopefully the library provides a way to disable console output. Look for something like setLogLevel() or suppressWarnings().
Option 2: If the library is open source, you could just modify it yourself to get rid of the print statements.
Option 3: You could also modify the System.out variable to point to your own custom class that filters messages you don't care about.
Related
I'm trying to use the package bambu to quantify gene counts from bam files. I am using my university's HPC, so I have written an R script and a batch submission file to launch it.
When the script gets to the point of running the bambu function, it gives the following error:
Start generating read class files
| | 0%[W::hts_idx_load2] The index file is older than the data file: ./results/minimap2/KD_R1.sorted.bam.bai
[W::hts_idx_load2] The index file is older than the data file: ./results/minimap2/KD_R3.sorted.bam.bai
[W::hts_idx_load2] The index file is older than the data file: ./results/minimap2/WT_R1.sorted.bam.bai
[W::hts_idx_load2] The index file is older than the data file: ./results/minimap2/WT_R2.sorted.bam.bai
|================== | 25%
Error: BiocParallel errors
element index: 1, 2, 3
first error: cannot open the connection
In addition: Warning message:
stop worker failed:
attempt to select less than one element in OneIndex
Execution halted
So it looks like BiocParallel isn't happy and cannot open a certain connection, but I'm not sure how to fix this?
This is my R script:
#Bambu R script
#load libraries
library(Rsamtools)
library(bambu)
#Creating files
bamFiles<- Rsamtools::BamFileList(c("./results/minimap2/KD_R1.sorted.bam","./results/minimap2/KD_R2.sorted.bam","./results/minimap2/KD_R3.sorted.bam","./results/minimap2/WT_R1.sorted.bam","./results/minimap2/WT_R2.sorted.bam","./results/minimap2/WT_R3.sorted.bam"))
annotation<-prepareAnnotations("./ref_data/Homo_sapiens.GRCh38.104.chr.gtf")
fa.file<-"./ref_data/Homo_sapiens.GRCh38.dna.primary_assembly.fa"
#Running bambu
se<- bambu(reads=bamFiles, annotations=annotation, genome=fa.file,ncore=4)
se
seGene<- transcriptToGeneExpression(se)
#Saving files
save.file<-tempfile(fileext=".gtf")
writeToGTF(rowRanges(se),file=save.file)
save.dir <- tempdir()
writeBambuOutput(se,path=save.fir,prefix="Nanopore_")
writeBambuOutput(seGene,path=save.fir,prefix="Nanopore_")
If you have any ideas on why this happens it would be so helpful! Thank you
I think that #Chris has a good point. Under the hood it seems likely that bambu is running htslib based on those warnings. While they may indeed only be warnings, I would like to know what the results would look like if you ran this interactively.
This question is hard to answer right now as it's missing some information (what do the files look like, a minimal reproducible example, etc.). But in the meantime here are some possibly useful questions for figuring it out:
what does bamFiles look like? Does it have the right number of read records? Do all of those files have nonzero read records? Are any suspiciously small?
What are the timestamps on the bai vs bam files (e.g. ls -lh /results/minimap2/)? Are they about what you'd expect or is it wonky? Are any of them (say, ./results/minimap2/WT_R2.sorted.bam.bai) weirdly small?
What happens when you run it interactively? Where does it fail? You say it's at the bambu() call, but how do you know that?
What happens when you run bambu() with ncores=1?
It seems very likely that this is due to a problem with the files, and it is only at the biocParallel step that the error is bubbling up to the top. Many utilities have an annoying habit of being happy to accept an empty file, only to fail confusingly without informative error messages when asked to do something with the empty file.
You might also consider raising an issue with the developers.
(why the warning is only possibly a problem: The index file sometimes has a timestamp like that for very small alignment files which are generated and indexed programmatically, where the indexing step is near-instantaneous.)
I am using JupyterLab to build a bioinformatics pipeline that uses both bash and python scripts.
The first bash script results gives a lot of feedback on every step of the process. However, this feedback is not helpful (unless there was an error) and makes the document less readable.
I would like to be able to hide this cell's output by default, but also to be able to open it when necessary to troubleshoot. I know it's possible to click 3 times on the output to collapse it; I was just wondering whether there is a way to do so by default.
I tried to add the tag specified on here (https://jupyterbook.org/features/hiding.html#Hiding-outputs) to the cell, but it does not seem to work for me.
Thanks for your help.
You may just want to suppress the output using %%capture cell magic as illustrated here. Then you simply remove that magic command from the first line of the cell for times you want to see the output, such as when troubleshooting.
If you want to make it so every time you run the cell, you can later decide to review what was captured you can use the %%capture magic command more as it was meant to be used. By assigning what is captured you can also do something like what the %%bash cell magic allows with handling output streams (see here), too. As described and illustrated here using the utils object you can easily get the stdout and/or stderr as a string, see http://ipython.readthedocs.io/en/stable/api/generated/IPython.utils.capture.html.
So say you put the following at the top of you cell to assign what was captured to out:
%%capture out
You can review the stdout stream later with the following:
print(out.stdout)
Or if you just want part of it, something like print(out.stdout[1:500]). I have some fancier handling illustrated in some blocks of code here.
I have been using RDCOMClient for a while now to interact with vendor software. For the most part it has worked fine. Recently, however, I have the need to loop through many operations (several hundred). I am running into problems with the RDCOM.err file growing to a very large size (easily GBs). This file is put in C: with no apparent option to change that. Is there some way that I can suppress this output or specify another location for the file to go? I don't need any of the output in the file so suppressing it would be best.
EDIT: I tried to add to my script a file.remove but R has the file locked. The only way I can get the lock released is to restart R.
Thanks.
Setting the permissions to read only was going to be my suggested hack.
A slightly more elegant approach is to edit one line of the C code in the package in src/RUtils.h from
\#define errorLog(a,...) fprintf(getErrorFILE(), a, ##__VA_ARGS__); fflush(getErrorFILE());
to
\#define errorLog(a, ...) {}
However, I've pushed some simple updates to the package on github that add a writeErrors() function that one can use to toggle whether errors are written or not. So this allows this to be turned on and off dynamically.
So
library(RDCOMClient)
writeErrors(FALSE)
will turn off the error logging to the file.
I found a work around for this. I created the files C:\RDCOM.err and C:\RDCOM_server.err and marked them both as read-only. I am not sure if there is a better way to accomplish this, but for now I am running without logging.
As a project I am working on is getting bigger I am getting tired of writing comprehensive log messages, needed to find out what went wrong and where.
So it would be extremely useful if I can incorporate that information into the messages automatically. For C++ we have the convenient __FILE__, __LINE__ and __FUNCTION__ macros, but I don't seem to find any for QML.
Note that there is console.trace() which outputs a trace in the console in the following format:
onCompleted (qrc:/main.qml:72)
So it includes function, file and line, which is all I need, therefore I assume there already exists a way to get those. Natural, console.trace() doesn't really quite cut it, because it directly outputs to the console, whereas I need those as strings to incorporate in my log messages.
So is there any way to get those?
Naturally I don't want to get them in the actual QML source, but the same way console.trace() does - on the spot where my Log.error() is invoked, so I can just Log.error("some error") instead of Log.error("some error in " + file + ", at " + line + " while executing " + func) which will actually be even more tedious than writing the whole thing manually.
Alternatively, I'd also appreciate if someone can point me to the implementation of the qml console, because I combed through the entire qtdeclarative code base for "console" and found nothing.
Note that I already found this, however it isn't of use to me, because I need that for a specific subset of messages and don't want to override the default message handler for all output.
console.log, console.debug, console.info, console.warn and console.error can be used to print debugging information to the console. The output is generated using the qDebug, qWarning, qCritical methods in C++ (see also Debugging Techniques and how such functions are implemented, especially this internal function). Setting the environment variable QML_CONSOLE_EXTENDED also prints the source code location of the call. For example,
export QT_MESSAGE_PATTERN="[%{type}] %{appname} (%{file}:%{line}) - %{message}"
Now the output looks like this,
This link contains details about customizing the QT_MESSAGE_PATTERN environment variable.
Basically, I want to avoid visiting a browser to get the detailed test results.
I had similar requirements, as I want to run "drush test-run" from within vim and get the results traversable in vim.
So I started a small and rough project https://github.com/DirkR/junitlog2vim. It takes the xml results file and generates line by line report. The script junitlog2vim.py requires python3.
As a convenience I created a Makefile. It takes the optional arguments "CASE" and "METHODS" to define the proper arguments for "drush test-run" and it has sensible defaults. You only have to provide an argument SITE_ALIAS or edit the Makefile.
if you run
make SITE_ALIAS=#mysite CASE=MyTestCase
then you get linewise error report with filename, line number and error message.
I hope it helps. Feel free to hack or adopt it.