Discover gists
| import PostgresNIO | |
| import Foundation | |
| /// A vector of floats. This is a custom type mirroring the `vector` type from | |
| /// [pgvector](https://github.com/pgvector/pgvector/). | |
| struct Vector: Codable { | |
| /// The vector's values. | |
| let value: [Float] | |
| /// Creates a new `Vector`. |
| # Libraries and infrastructure | |
| sudo apt update -y | |
| sudo apt install -y \ | |
| docker.io docker-buildx \ | |
| build-essential pkg-config autoconf bison rustc cargo clang \ | |
| libssl-dev libreadline-dev zlib1g-dev libyaml-dev libreadline-dev libncurses5-dev libffi-dev libgdbm-dev libjemalloc2 \ | |
| libvips imagemagick libmagickwand-dev mupdf mupdf-tools \ | |
| redis-tools sqlite3 libsqlite3-0 libmysqlclient-dev \ | |
| rbenv apache2-utils |
This a collection of notes and files used in my quest to create "Reboot to Windows" and "Reboot to Linux" scripts (and desktop shortcuts) for Linux and Windows respectively that automatically reboot my system and instruct rEFInd to auto-select the appropriate OS entry.
The key for achieving this is to modify the EFI Variable PreviousBoot with GUID 36d08fa7-cf0b-42f5-8f14-68df73ed3740, which rEFInd uses to store the last entry selected in the menu and, if using the + default entry, will be used to select the default OS. By doing this, we trick rEFInd into booting the OS we choose without having to be physically there to press the keyboard.
Made this example to show how to use Next.js router for a 100% SPA (no JS server) app.
You use Next.js router like normally, but don't define getStaticProps and such. Instead you do client-only fetching with swr, react-query, or similar methods.
You can generate HTML fallback for the page if there's something meaningful to show before you "know" the params. (Remember, HTML is static, so it can't respond to dynamic query. But it can be different per route.)
Don't like Next? Here's how to do the same in Gatsby.
| { | |
| "dns": { | |
| "servers": [ | |
| { | |
| "tag": "dns_proxy", | |
| "address": "https://1.1.1.1/dns-query", | |
| "address_resolver": "dns_resolver", | |
| "strategy": "ipv4_only", | |
| "detour": "select" | |
| }, |
CMake를 왜 쓰는거죠?
좋은 툴은 Visual Studio 뿐입니다. 그 이외에는 전부 사도(邪道)입니다 사도! - 작성자
- 이 문서는 CMake를 주관적으로 서술합니다
- 이 문서를 통해 CMake를 시작하기엔 적합하지 않습니다
https://cgold.readthedocs.io/en/latest/ 3.1 챕터까지 따라해본 이후 기본사항들을 속성으로 익히는 것을 돕기위한 보조자료로써 작성되었습니다
| --[[-- | |
| Camera Sensor Database v1 - 2024-05-28 11.04 PM (UTC -3) | |
| Database By: Jacob Danell <jacob@emberlight.se> | |
| Fusion Studio GUI By: Andrew Hazelden <andrew@andrewhazelden.com> | |
| Overview: | |
| Apply camera sensor information to Camera3D, uCamera, CameraTracker, Renderer3D, and uRenderer nodes. | |
| """ | |
| file: torch_worker_pool.py | |
| author: Seth Isaacson (sethgi@umich.edu, sethisaacson.me) | |
| Description: Allows parallelizing arbitrary pytorch tasks across multiple GPUs. | |
| It's useful in the case that you want to call one function many times on a lot of data. | |
| It works by implementing a simple pool of workers, one per GPU. Each worker | |
| pulls tasks off a job queue, and puts the results in the result queue. | |
| First, implement my_function to do the work you're trying to split across GPUs. |