icyveins7

In light of the recent Anaconda commerical license changes, the most obvious way around this is to move entirely to using the free PyPI repositories using pip alone.

This method outlines the steps succinctly to reproduce somewhat a starting conda environment, without ever having to visit the Anaconda website.

1. Download your python from here.

2. During install for Windows, remember to click the option 'Add to environment variables' (NOT 'add to PATH') This will essentially turn your cmd.exe into Anaconda Prompt.

icyveins7

On multiple monitor setups, pyqtgraph may fail to align some pixels when figures are shown on the secondary monitors. Refer to (spyder-ide/spyder#12990 (comment)) and go to spyder.exe in your Scripts folder under your environment to fix this. This manual override was the only one that worked.

icyveins7

Introduction

This guide is meant to serve as a source of stupid 'tricks' needed to get a GNURadio installation working when built from source, but not via PyBOMBS. For now, this guide will focus on Linux systems, as getting it working on Windows is a whole other nightmare.

Who should read this?

1. You don't want to use PyBOMBS because you prefer to know what you're installing and where.
2. You want to integrate the GNURadio libraries into an existing Python virtual environment, NOT the system-wide Python environment.
3. You don't want to have to resort to using sudo when running things.

Caveats

icyveins7

INCOMPLETE. Unable to Resolve Linker Errors.

Versions Tested

1. UHD 3.15.0
2. Boost 1.72.0
3. msys2-runtime 3.2.0-15 (probably doesn't matter)
4. msys2-runtime-devel 3.2.0-15 (only used for the header error listed below)
5. mingw-w64-x86_64-gcc 10.3.0-5

Setup

icyveins7

All UHD sources downloaded from Releases page (appropriate tar.gz or other zipped format in the assets). All Boost sources downloaded from their archive (or for latest version just from the Downloads, built libraries done by bootstrap.sh for Linux or pre-compiled libraries for Windows).

Windows

1. UHD 3.15.0 / Boost 1.72.0 (Working)
2. UHD 4.0.0.0 / Boost 1.75.0 (Working)
3. UHD 4.5.0.0 / Boost 1.83.0 (Working)

Note for UHD 4.5.0.0

Python API is extremely finnicky. If you wish to enable the Python API, please see this for my hotfixes.

icyveins7

https://github.com/falkenber9/falcon Tested on 1.3.0 release source tar.gz. Tested with 3.15.0 UHD/1.72.0 Boost.

In order to use your own self-built UHD + self-built Boost, simply attach the similar CMake variables in cmake-gui when prompted, for both UHD and Boost.

However, the boost includes are not properly set up when the generation of makefiles is done. So during the build, for any files that error on boost includes, open the corresponding flags.make file and append the boost directory yourself accordingly. The following files were the culprits for me:

1. build/srsLTE-build/lib/src/phy/rf/CMakeFiles/srslte_rf.dir/flags.make (add to both C_INCLUDES and CXX_INCLUDES)
2. build/src/gui/model/CMakeFiles/model.dir/flags.make

icyveins7

Who This Is For

If you're like me, you have some (or most) of your github repositories stored in some parent folder like ~/gitrepos. Sometimes you want to just update multiple repositories together without having to git pull each one individually. Hopefully this will help you.

Setting It Up

First off, SSH access is required for private repos, so we'll assume you have this set up already. Github has enough documentation to cover this.

If your keys are password locked (as they should be), you should run

Linux

icyveins7

Purpose

This gist serves to document certain cupy calls and the wall-clock timings associated with them. For each code snippet (usually timed simply by %%timeit), the corresponding timing output will be provided. For most/all calls, -n 100 is added because the processing time taken increases exponentially when the GPU is flooded with too many loops from %%timeit (not sure why, but probably tries to queue too many kernel calls together).

Yes, wall-clock time is not the correct way to measure GPU processing times, but usually when control switches between the interpreter back and forth, this is the more 'reasonable' time to look at.

Windows 10, Ryzen 5 1600X, GTX 1080, cupy-cuda112 (9.2.0)

Allocation

icyveins7

Introduction

This gist may be helpful to those who often construct and/or deal with datetimes in different timezones using Unix epoch seconds.

The Somewhat Obscure Problem in Python

There is a distinct difference between the following two snippets of code in Python:

import datetime as dt

icyveins7

Pre compute capability 8.0

Just look at this directly.

For compute capability 8.0 and above

Using nsys

This seems like a better replacement for nvprof than ncu. Had to add this to PATH myself to find it though..