yzdbg

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

GavinRay97

# Created with: $ diagtool tree

-Wall
-Wextra
-Wpedantic

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

Strum355

{ 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" "$@"
  '';

rpearce

: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"

vncsna

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

yihuang

[package]
name = "test-rust"
version = "0.1.0"
authors = ["yihuang <yi.codeplayer@gmail.com>"]
edition = "2018"

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

[dependencies]

vindarel

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

1. 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
2. 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)
3. Great video for setting up Emacs + Slime + Quick Lisp https://www.youtube.com/watch?v=VnWVu8VVDbI

Now as to why Common Lisp over Scheme

ctrlcctrlv

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

CRTified

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

eenblam

Linux Networking Reading List

Currently in no particular order. Most of these are kind of ancient.

Where's all the modern documentation? So much of what I've turned up searching is other folks complaining about having few options beyond reading source code.

The OREILLY books, while dated, seem to be some of the best available. Note that these can be read with a 7-day trial. Do this! At least get through the introduction section and first chapter of each to see if it's what you're after.

https://www.netfilter.org/