Shiryel shiryel

✏️ Overview

Note

A more bleeding-edge version of this is available here.

A pretty simple custom LSP hover window that tries to solve the issues I face with the built-in one.

Automating Daily Reports, because fuck it, really...

Each day at our company, developers are required to document their activities, painstakingly jotting down their daily work and future plans. A monotonous chore that I just really dislike.

So now, there's a scribe for that :

Code

set -e, -u, -o, -x pipefail

The set lines

These lines deliberately cause your script to fail. Wait, what? Believe me, this is a good thing.
With these settings, certain common errors will cause the script to immediately fail, explicitly and loudly. Otherwise, you can get hidden bugs that are discovered only when they blow up in production.

set -euxo pipefail is short for:

set -e
set -u

Developer experience, libraries, performance… (2021/11)

I'll preface this with three things. 1. I prefer schemes over Common Lisps, and I prefer Racket of the Schemes. 2. There is more to it than the points I raise here. 3. I assume you have no previous experience with Lisp, and don't have a preference for Schemes over Common Lisp. With all that out of the way... I would say Common Lisp/SBCL. Let me explain

SBCL Is by far the most common of the CL implementations in 2021. It will be the easiest to find help for, easiest to find videos about, and many major open source CL projects are written using SBCL
Download a binary directly from the website http://www.sbcl.org/platform-table.html (even for M1 macs) to get up and running (easy to get started)
Great video for setting up Emacs + Slime + Quick Lisp https://www.youtube.com/watch?v=VnWVu8VVDbI

Now as to why Common Lisp over Scheme

Rust maintainer perfectionism, or, the tragedy of Alacritty

I did not submit this to Hacker News and did not intend that this post would have high circulation but have no real problem with it being there or with it having such. I have more recent comments below. This post is from January 2020 and predates the Modular Font Editor K (MFEK) project.

I have not worked on Rust projects in quite a while, and don't know if I ever will again. I feel many crate maintainers are way too perfectionist, for example, despite all the developer hours that went into this PR, it took the effort within years to be (halfway) merged.

There's always a reason not to merge, isn't there? It would be better done with a new nightly language feature, or the function signature should have a where clause, or the documentation is not perfect. There's always a new nit to pick in the world of Ru

VFIO Setup on NixOS

Disclaimer: Nobody else tested my setup so far, so this is a "works on my machine" scenario. I am not responsible for anything you break on your machine (although I'd not expect much harm).

Hardware

My system has the following hardware:

Board: ASRock X570 Pro4

	# Created with: $ diagtool tree

	-Wall
	-Wextra
	-Wpedantic

	-Warray-bounds-pointer-arithmetic
	-Wbind-to-temporary-copy
	-Wcalled-once-parameter
	-Wcast-align

	{ config, pkgs, lib, ... }:

	let
	nvidia-offload = pkgs.writeShellScriptBin "nvidia-offload" ''
	export __NV_PRIME_RENDER_OFFLOAD=1
	export __NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0
	export __GLX_VENDOR_LIBRARY_NAME=nvidia
	export __VK_LAYER_NV_optimus=NVIDIA_only
	exec -a "$0" "$@"
	'';

	:def hoogle \x -> return $ ":!hoogle --count=15 \"" ++ x ++ "\""
	:def doc \x -> return $ ":!hoogle --info \"" ++ x ++ "\""
	:set -Wall
	:set -fno-warn-type-defaults -ferror-spans -freverse-errors -fprint-expanded-synonyms
	:set prompt "\ESC[0;32m%s\n\ESC[m[ghci]\ESC[38;5;172mλ \ESC[m"
	:set prompt-cont " \ESC[38;5;172m> \ESC[m"

	[package]
	name = "test-rust"
	version = "0.1.0"
	authors = ["yihuang <[email protected]>"]
	edition = "2018"

	# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

	[dependencies]