| """ | |
| From Luiz Irber. | |
| Takes an SRA accession and determines the location of the .sra data file for automated or downloading. | |
| Follows this format: ftp://ftp-trace.ncbi.nih.gov/sra/sra-instant/reads/ByRun/sra/{SRR|ERR|DRR}/<first 6 characters of accession>/<accession>/<accession>.sra | |
| Format according to NCBI utility handbook: https://www.ncbi.nlm.nih.gov/books/NBK158899/ | |
| """ | |
| def sra_url(accession): | |
| """Returns predicted URL given SRA accession as input.""" | |
| accession = accession.upper() |
rr is a great debugging tool. it records a trace of a program's execution, as well as the results of
any syscalls it executes, so that you can "rewind" while you debug, and get deterministic forward and reverse
instrumented playback. it works with rust, but by default if you try it out, it could be pretty ugly when you
inspect variables. if this bothers you, configure gdb to use a rust pretty-printer
rr is probably in your system's package manager.
What is strict aliasing? First we will describe what is aliasing and then we can learn what being strict about it means.
In C and C++ aliasing has to do with what expression types we are allowed to access stored values through. In both C and C++ the standard specifies which expression types are allowed to alias which types. The compiler and optimizer are allowed to assume we follow the aliasing rules strictly, hence the term strict aliasing rule. If we attempt to access a value using a type not allowed it is classified as undefined behavior(UB). Once we have undefined behavior all bets are off, the results of our program are no longer reliable.
Unfortunately with strict aliasing violations, we will often obtain the results we expect, leaving the possibility the a future version of a compiler with a new optimization will break code we th
Implement contig contamination analysis as in (blog post)
The official installation guide (https://wiki.archlinux.org/index.php/Installation_Guide) contains a more verbose description.
| import dask | |
| import dask.array as da | |
| import dask.dataframe as dd | |
| import sparse | |
| @dask.delayed(pure=True) | |
| def corr_on_chunked(chunk1, chunk2, corr_thresh=0.9): | |
| return sparse.COO.from_numpy((np.dot(chunk1, chunk2.T) > corr_thresh)) | |
| def chunked_corr_sparse_dask(data, chunksize=5000, corr_thresh=0.9): |
| #!/bin/bash | |
| # This script will install AMDGPU-PRO OpenCL and Vulkan support. | |
| # | |
| # For Ubuntu and it's flavor, just install the package using this command | |
| # in extracted driver directory instread. | |
| # | |
| # ./amdgpu-pro-install --opencl=legacy,pal --headless --no-dkms | |
| # | |
| # For Arch Linux or Manjaro, use the opencl-amd or rocm-opencl-runtime on AUR instread. |
SAT and Satisfiability Modulo Theories (SMT) solvers have many important applications in PL, including verification, testing, type checking and inference, and program analysis – but they are often a mysterious black box to their users, even when those users are PL researchers with lots of solver experience! This talk will be partly a tutorial introduction to the inner workings of SAT and SMT solvers, and partly an extended analogy to navigating life as a researcher: making decisions when you have only incomplete information to go on, learning from decisions that turned out to be bad, and determining when to give up and when to try again. I’ll also highlight a variety of papers in this year’s POPL program that make use of SAT and SMT solving, and discuss why I think it’s worthwhile to learn about solver internals.
| name: Binder | |
| on: | |
| pull_request: | |
| types: [opened, reopened] | |
| jobs: | |
| Create-Binder-Badge: | |
| runs-on: ubuntu-latest | |
| steps: |
| import asyncio | |
| import time | |
| from unsync import unsync | |
| @unsync | |
| async def heartbeat(): | |
| while True: | |
| start = time.time() |
