Forem: Chris Wendt

How to auto-shutdown GCP VMs and save $

Chris Wendt — Fri, 02 Dec 2022 03:41:32 +0000

The following script will shut down an instance that hasn't had any SSH connections in a while. The debounce defaults to 300 seconds.

Copy these files into your VM:

/usr/bin/auto-shutdown.py:

#!/usr/bin/env python3

import json
import math
import os
import subprocess
from pathlib import Path
import time
from datetime import datetime

def main():
    timeout = int(os.environ.get("IDLE_TIMEOUT", "600"))
    interval = 60

    idle_since = getBootTime()

    while True:
        out = subprocess.check_output("last -F | jc --last", shell=True)
        for user in json.loads(out):
            if user.get("logout", None) == "still logged in":
                idle_since = max(idle_since, datetime.now().timestamp())
            elif "logout_epoch" in user:
                idle_since = max(idle_since, user["logout_epoch"])

        idle = round(datetime.now().timestamp() - idle_since)
        if idle > timeout:
            print(f"Idle for {idle}s, shutting down...")
            subprocess.check_call("shutdown now", shell=True)
        else:
            print(f"Idle for {idle}s, checking again in {interval}s...")
            time.sleep(interval)


def getBootTime():
    uptime = float(Path("/proc/uptime").read_text().split()[0])
    return datetime.now().timestamp() - uptime


if __name__ == "__main__":
    main()

/etc/systemd/system/auto-shutdown.service:

[Unit]
Description=Auto-shutdown VM

[Service]
ExecStart=/usr/bin/auto-shutdown.py
Restart=always
Environment=PYTHONUNBUFFERED=true

[Install]
WantedBy=multi-user.target

pip3 install jc and if which jc shows conda, then sudo ln -sf /opt/conda/bin/jc /usr/bin/jc
sudo chmod u+x /usr/bin/auto-shutdown.py
sudo systemctl daemon-reload
sudo systemctl enable auto-shutdown.service
sudo systemctl restart auto-shutdown
systemctl status auto-shutdown.service

Inspiration.

Faster builds with VMs than with Google Cloud Build

Chris Wendt — Fri, 02 Dec 2022 03:36:26 +0000

Google Cloud Build has to pull your Docker image on every build, which can be slow if the image is 1GB+ (e.g. when using cutting edge Wasm tooling that doesn't work on all OSes/architectures yet).

Here's how to speed up your builds using plain VMs instead:

initiate-build.sh creates/starts/resumes the build VM if it's nonexistent/stopped/suspended, copies a Dockerfile and context, then runs build.py on the VM and copies the artifact back to your local machine:

set -xeuo pipefail

cd "$(dirname "${BASH_SOURCE[0]}")"

: "${INSTANCE:=some-build-vm}"

status() {
  gcloud compute instances list --format="value(status)" --filter="name=$INSTANCE" | tr -d '\n'
}

state="$(status)"
case "$state" in
"")
  gcloud compute instances create "$INSTANCE" --machine-type=n2-standard-2 --create-disk=boot=yes,image=projects/ubuntu-os-cloud/global/images/ubuntu-2210-kinetic-amd64-v20221101,size=100
  ;;
"SUSPENDED")
  gcloud compute instances resume "$INSTANCE"
  ;;
"STOPPED")
  gcloud compute instances start "$INSTANCE"
  ;;
"RUNNING") ;;
*)
  echo "Unrecognized instance state $state"
  exit 1
  ;;
esac

rm -rf scratch
mkdir scratch
cp setup.py auto-shutdown.py auto-shutdown.service Dockerfile otherfiles scratch
gcloud compute scp --recurse scratch "$INSTANCE":"~"
gcloud compute ssh "$INSTANCE" -- 'bash -c "( cd scratch && python3 setup.py ); rm -rf scratch"'
gcloud compute scp "$INSTANCE":"~/artifact" artifact

build.py installs Docker if needed, sets up an auto-shutdown after 5mins of inactivity (to mimic the serverless nature of Google Cloud Build), builds the Docker image, then copies the artifact out:

#!/usr/bin/env python3

import subprocess
from subprocess import check_call


def main():
    ensure("jc", "jc")
    ensure("docker", "docker.io")

    check_call("sudo chmod 755 auto-shutdown.py", shell=True)
    check_call("sudo mv auto-shutdown.py /usr/bin", shell=True)
    check_call("sudo mv auto-shutdown.service /etc/systemd/system", shell=True)
    check_call("sudo systemctl daemon-reload", shell=True)
    check_call("sudo systemctl restart auto-shutdown", shell=True)

    check_call("sudo docker build -t img .", shell=True)

    check_call(
        f"sudo docker run --rm --entrypoint cat img /artifact > ~/artifact", shell=True
    )


def ensure(command, pkg):
    try:
        check_call(["which", command])
    except subprocess.CalledProcessError:
        check_call("sudo apt-get update", shell=True)
        check_call(["sudo", "apt-get", "install", "-y", pkg])


if __name__ == "__main__":
    main()

See auto-shutdown.

The state of Wasm in Rust, Haskell, and Go

Chris Wendt — Thu, 01 Dec 2022 05:18:57 +0000

2023

Haskell

Use ghc.nix to build a GHC version that targets Wasm
It supports WASI
It works on Mac M1

Go

Go 1.21 added experimental support for WASI (GOOS=wasip1, GOARCH=wasm)
tinygo: JSON packages now work (tested on 0.29.0)

2022

Compiling to Webassembly (Wasm) is still rather difficult IMO in 2022. Here I document some of my findings:

Haskell

Compiling to Wasm requires an early release of GHC, slated for GHC 9.6
It supports WASI
It does not work on ARM, such as Mac M1

Rust

The wasm32-unknown-unknown target works, but requires low-level memory management and unsafe blocks
A bunch of packages like tokio don't work because they transitively depend on net, and WASI doesn't have networking yet (networking is in phase 1 of 5), and it doesn't seem possible to turn off the net feature of transitive dependencies

Go

The main Go compiler doesn't yet support WASI, it only supports targeting JavaScript environments (see how the only GOOS/GOARCH pair is js/wasm)
TinyGo supports WASI tinygo build -target wasi ., but a ton of packages like encoding/json don't work because not all of the reflect stdlib package has been implemented in the TinyGo runtime. I tried these alternative JSON packages:
- ✅ easyjson worked
- ❌ ffjson failed to compile, last commit 2019
- ❌ go-codec depends on reflect
- ❌ fastjson can decode, but can't encode
- ❌ jsonparser can decode, but can't encode
- ❌ gabs depends on reflect

How to give Docker Desktop more RAM/swap than the limit

Chris Wendt — Sat, 26 Nov 2022 21:28:41 +0000

Docker Desktop on Mac has a limit of 8GB RAM and 4GB of swap:

You can allocate even more swap space by running these commands:

host$ docker run --rm -ti -v swap:/swap --privileged
root@91dd1647484a:/# fallocate -l 4G /swap/file
root@91dd1647484a:/# chmod 600 /swap/file
root@91dd1647484a:/# mkswap /swap/file
Setting up swapspace version 1, size = 4 GiB (4294963200 bytes)
no label, UUID=2e028e57-9572-4bed-94c8-093ae1af1211
root@91dd1647484a:/# swapon /swap/file
root@91dd1647484a:/# free -m
               total        used        free      shared  buff/cache   available
Mem:            7951         280        7083         321         587        7191
Swap:           8191           0        8191
root@91dd1647484a:/#

The swap space will be available to all containers. It also persists across restarts.

To delete the swap space, run docker volume rm swap then restart Docker Desktop. You will get an error saying it couldn't be deleted, but after the restart it will be gone.

How to consolidate cleanup logic using the "with" function pattern

Chris Wendt — Sat, 16 Jul 2022 04:19:00 +0000

A few of my teammates have liked the "with" function pattern and how convenient it is for ensuring proper cleanup of resources.

A "with" function takes a callback and performs some initialization, calls the callback, then performs some cleanup.

For example, instead of manually doing a COMMIT or ROLLBACK for every SQL transaction like this:

tx, err := db.Begin()
if err != nil {
    return err
}

err = tx.Exec("INSERT ...")
if err != nil {
    // 💥 Oops, forgot tx.Rollback(), tx remains open!
    return err
}

// execute more statements...

err = tx.Commit()
if err != nil {
    return err
}

We can create a withTx() function:

func withTx(db DB, callback func(Tx) error) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }
    defer tx.Rollback()

    err = callback(tx)
    if err != nil {
        return err
    }

    return tx.Commit()  
}

And use it like this:

err := withTx(db, func(tx Tx) error {
    err = tx.Exec("INSERT ...")
    if err != nil {
        // 🙂 No need to remember to call tx.Rollback()
        return err
    }
    // execute more statements...
})
if err != nil {
    return err
}

At a glance, ~5% of calls to Begin() appear to be missing a corresponding Rollback() on error (likely example). Using a withTx() function would help eliminate those bugs.

And with Go generics we can return a value from withTx:

-func withTx(db DB, callback func(Tx) error) error {
+func withTx[T any](db DB, callback func(Tx) (*T, error)) (*T, error) {
    tx, err := db.Begin()
    if err != nil {
-       return err
+       return nil, err
    }
    defer tx.Rollback()

-   err = callback(tx)
+   t, err := callback(tx)
    if err != nil {
        return err
    }

-   return tx.Commit()
+   return t, tx.Commit()
 }

Benefits of the "with" function pattern:

Automatic initialization and cleanup
Less code
In some cases, there's no need to check if the operation succeeded and do something different if it didn't

One caveat to bear in mind: you have to make sure the callback does not return the resource, otherwise that resource could be used after the clean up runs and cause an error! I don't think it's possible to enforce correct use at compile time in Go. It is possible (but not ergonomic) in Haskell and it's convenient in Rust by piggy-backing on the built-in value lifetime machinery.

Ergonomic error handling in Go using generics

Chris Wendt — Thu, 07 Jul 2022 01:58:35 +0000

Now that Go has generics, I discovered that you can implement ergonomic exception-like error handling as a library. Here's my take on the idea:

https://github.com/chrismwendt/go-exceptions

Typical error-handling in Go looks like this:

func f() error {
  err := g1()
  if err != nil {
    return err
  }

  v1, err := g2()
  if err != nil {
    return err
  }

  // ...
}

There are a few downsides to handling errors like this:

if err != nil { return err } takes 3 extra lines
You need to explicitly store the errors in variables and conditionally return them every time you call a function that returns an error
Error handling ends up cluttering the code and making it harder to focus on the domain logic
You can't do f(g()) if g() returns a value and an error and f() expects only a value, which forces you to split up the code, add temporary variables, add an if, and manually handle the error

How can we make this more ergonomic? Perhaps ideally, Go would add support for Rust's ? operator, but we can get pretty close using panic() and recover() to have errors bubble up without needing to explicitly store them in variables.

Here's what usage of go-exceptions looks like:

import ex "github.com/chrismwendt/go-exceptions"

func f() (err error) {
  // Catch() calls recover() and assigns the error to &err
  defer ex.Catch(&err)

  // Throw() calls panic() if the error argument is not nil
  ex.Throw(g1())

  // Throw() also accepts a label
  ex.Throw(g2(), "g2")

  // Throw1() returns 1 value, Throw2() returns 2 values, etc.
  v1 := ex.Throw1(g3())

  // Passing arguments is easier
  v2 := ex.Throw1(g4(ex.Throw(g5())))

  // ...
}

This is more ergonomic in a few ways:

It eliminates a bunch of temporary err variables
You can more easily pass the result of one function into another
The code is more compact
Once you learn about the library, IMO the code is more readable

Internally:

Throw(err) is basically: if err != nil { panic(err) }.
Catch(*error) recovers from any panic and stores the recovered value in the given error

You could go a bit further and adopt a convention of panicking rather than returning errors, but that begins to depart from typical Go calling conventions and could cause friction when calling or being called by other code.

Limitations of Go generics

Chris Wendt — Mon, 13 Jun 2022 00:00:00 +0000

Go does not allow type parameters (generics) in method declarations, and that limits the APIs you can make.

Here's an example when you might encounter that problem and how to work around it:

Say you're building a library to process streams of values, and you start with this type:

// Stream receives In values from upstream and
// sends Out values downstream.
type Stream[In, Out] ...

Ideally, we could write the following generic .connect() method:

//                           vvvvvvv ❌ not allowed by Go!
func (s Stream[A, B]) connect[C any](o Stream[B, C]) ...

But Go does not allow type parameters in method declarations. That means the .connect() method can't introduce any new types:

//                                                  vvvvvv ✅ OK
func (s Stream[A, B]) connect(o Stream[B, B]) Stream[A, B]

That restricts the kinds of processing we can do by chaining .connect() methods together:

lines
    .connect(omitEmpty) // ✅ (string -> string) same type
    .connect(getLength) // ❌ (string -> int   ) new type
    .connect(print)

We can get around this limitation by converting .connect() into a top-level connect() function that can change the stream type 🎉:

func connect[A, B, C any](
    s1 Stream[A, B],
    s2 Stream[B, C],
) Stream[A, C]

Unfortunately, readability suffers a little:

connect(connect(connect(lines, omitEmpty), getLength), print)

Or written with right-associativity:

connect(lines, connect(omitEmpty, connect(getLength, print)))

Or on separate lines:

s1 := lines
s2 := connect(s1, omitEmpty)
s3 := connect(s2, getLength)
s4 := connect(s3, print)

We need separate variables for each step in the stream, but other than that it's not much different from method chaining above!

Cleaning up threads in Haskell

Chris Wendt — Sun, 31 May 2020 00:00:00 +0000

When you press Ctrl+C in ghci or when your code gets reloaded in ghcid, only the main thread is killed (via a UserInterrupt exception). All other spawned threads continue to run. Here's how to clean them up:

Since the addition of listThreads in GHC 9.6.1, you can label your threads with labelThread then list all, filter, and kill them later. This won't work for threads spawned by dependencies since they're probably not labeled. Perhaps a labeling convention could emerge to support this use case, or GHC could apply descriptive labels to all threads to enable user code to disambiguate between user threads and runtime threads (e.g. the IO manager). One hacky idea that doesn't need labels is to sort the list of threads, drop the first 3 (which probably correspond to runtime threads, dangerous assumption though), and kill the rest.

Prior to GHC 9.6.1, it was not possible to list threads, so it was up to you the programmer to clean up. Here's an idea for cleaning up at least some threads (although it suffers from the same shortcoming as above in that it can't catch threads spawned by dependencies):

Keep track of all currently-running threads in an IORef (Set (Async a))
When an exception occurs in any thread, hand it to the main thread with putMVar exceptionVar exception
Have the main thread wait for an exception then kill all currently-running threads

Implementation:

main = do
  safeAsync $ runApp

  dieOnException

-- NOINLINE ensures that there is only one MVar
{-# NOINLINE errorVar #-}
errorVar = unsafePerformIO $ newEmptyMVar :: MVar SomeException

-- Set of currently-running threads
{-# NOINLINE asyncsRef #-}
asyncsRef = unsafePerformIO $ newIORef Set.empty :: IORef (Set (Async a))

-- Waits for an exception the kills all threads
dieOnException = (readMVar errorVar >>= print) `finally` (do
  mapM_ cancel =<< readIORef asyncsRef
  putStrLn "exiting entire Haskell process"
  exitFailure)

-- A version of `async` that additionally stores itself in the currently-running threads.
-- It also notifies the main thread when there's an exception.
safeAsync a = do
  asyncValue <- async a
  forkIO $ do
    (wait asyncValue `finally` (atomicModifyIORef' asyncsRef (Set.delete asyncValue))) `catches`
      [ Handler $ \(e :: AsyncCancelled) -> return ()
      , Handler $ \(e :: SomeException) -> putMVar errorVar e
      ]
  atomicModifyIORef' asyncsRef (Set.insert asyncValue)
  return asyncValue

The cost of enforcing purity in Haskell

Chris Wendt — Wed, 27 May 2020 00:00:00 +0000

"Effect Tracking Is Commercially Worthless" argues that enforcing purity is not commercially valuable, and this struck a chord with with me because I had already recently started to question the usefulness of enforcing purity in the context of a commercial project CodeWyng that I'm working on.

Looking past the distractions (the tongue-in-cheek sales rhetoric, the conspicuous advertisement for the ZIO project, and the vacuous is-Haskell-really-pure debate), there are some compelling arguments against enforcing purity that I've never heard before. The novelty of the counterarguments has drawn my attention to studying this subject further.

Because "effect tracking" is ambiguous and causes confusion, these terms might be useful in discussion:

Enforcing purity prevents the use of functions that interact with the world to be used in any context that doesn't allow it. The mechanism by which purity is enforced in Haskell is a combination of the type system (e.g. you can't use IO Int in a function like sum :: [Int] -> Int) and the specific interface to IO exposed to the programmer (i.e. all functions that interact with the world return something wrapped in IO and there is no IO a -> a to circumvent the intended interface, except for the backdoor unsafePerformIO).
Dependency injection is a technique where the implementation of dependencies of a function can be changed at the call site. For example, the dependency on the database can be swapped out for a mock implementation in tests. Some mechanisms by which dependency injection can be performed include: passing an explicit argument runApp :: DB -> IO (), adding a type class constraint runApp :: (HasDB m, MonadIO m) => m (), or mutating the global DB variable to set it to a mock implementation prior to running tests.

As an aside, I don't think John is saying that the dependency-injection-like property of effects systems is worthless, but rather that any restriction-of-side-effects property (just like IO has) is worthless.

Original motivation for IO in Haskell: ensure that expressions that describe interactions with the world are evaluated in a deterministic order (specified by the programmer) even under lazy evaluation and in the presence of an optimizing compiler, while maintaining purity. Paper for reference: Imperative functional programming

Mechanism by which IO enforces purity: the IO data type is essentially the state monad where the world is the state data IO a = IO (World -> (a, World)) and the >>=+return interface exposed to the programmer only enables chaining IO values together such that each value of type World is used exactly once, passing it from one IO action to the next in sequence. In other words, each function that takes a World (e.g. getLine :: IO String, getLine :: World -> (String, World)) is never called with the same World value twice. All function calls that interact with the world take a different World value, and therefore it's impossible to observe the same function applied to the same arguments returning a different value. That's precisely the definition of referential transparency, A.K.A. purity.

Motivation for enforcing purity: I found less information on this topic, so I'm mostly going off of intuition here.

STM is guaranteed to be correct
Equational reasoning always holds (i.e. factoring out common code into a binding never changes program behavior)
The type of a function documents whether or not it interacts with the world
Programs tend to be written in such a way that interactions with the world are more separated from logic than they would be without enforced purity
It's the only lazy+pure language and a lot of learning has come out of programming with that mind-bending combination of properties (myself included)
There's a pervasive undercurrent of "it's good for you" in a "slavery is freedom" sort of way, and that programmers lack the discipline required to architect large programs without the enforcement of purity
Restrictions like purity or linear types enable mathematical reasoning by way of connection to logic, category theory, and algebra. Constraints Liberate, Liberties Constrain explores this tradeoff.

Motivation for not enforcing purity: Starting with John's reasons, with a few I thought of:

If it were worthwhile, annotation processors would be in widespread use for mainstream languages and have IDE support (proof by contradiction)
Tooling alone using static call tree analysis would achieve the same goal without placing a burden on the programmer
The Checker framework has no commercial traction
PureScript went from pure+tags to pure (still enforces purity, but with less granularity)
Almost every other aspect of FP has been widely adopted while enforced purity has not: first-class and anonymous functions (e.g. in Java 8), lexical scoping (e.g. arrow functions for this and let vs var in JavaScript), immutable annotations (e.g. const vs let in JavaScript), option chaining (e.g. C#'s and TypeScript's ?. operator), the Maybe data type (e.g. Optional in Java), parser combinators, QuickCheck, STM, list comprehensions, pattern matching, parametric polymorphism (A.K.A. generics), type inference, the list goes on...
Programmers already know using intuition with a high degree of certainty whether or not a function interacts with the world. Functions that violate that intuition are avoided and are quickly rectified or worked around (e.g. java.net.URL#hashCode/equals
Enforcing purity places burdens of boilerplate and ceremony on programmers (e.g. when to use let vs <-, doing acrobatics with <$>/fmap/=<</>>=/<*>/etc. to satisfy the type checker, the need to add an import of Debug.Trace and use special functions to be able to inspect the execution of functions that definitely don't interact with the world, and the need to create a new variable binding for many trivial values such as count <- readIORef countRef)
Telling beginners "don't worry, you don't need to understand what IO is or how it works, just use these combinators you won't understand for the first 20 hours of learning Haskell" is Haskell's equivalent of "oh just ignore all that public static void main String[] args stuff for now and don't forget to wrap your hello world in a class"
I can't remember ever accidentally running IO at all or in the wrong order in any language (not just Haskell). It just doesn't seem to happen. I've been bitten by mutation quite a few times, but they were always a conscious choice of tradeoffs or something silly like JavaScript's array.reverse() which both mutates the array and returns a reversed shallow copy.

Experiment with strict impure Haskell To get another data point, I'm considering modifying the Haskell backend of CodeWyng to use LANGUAGE Strict and insert unsafePerformIO in a bunch of places, especially at usages of IORefs and MVars to see 1) if it works 2) if there are any bugs 3) if it's easier or more intuitive to program that way. Will post back here if/when I do. Update:

Adding {-# LANGUAGE Strict #-} worked right away, I didn't notice any bugs
While replacing IO functions with impure non-IO versions, I replaced withMVar with an impure version and doing so caused an infinite loop, so I reverted that one
I found some dead code that was doing the equivalent of x <- readMVar xVar
Inlining variables into pure expressions helped align the code and prettify it
Some control functions like unlessM broke in unexpected ways
All I could think about for the last 25% was "man, all these tricks with >>=/<-/<$>/=<< to retain purity are completely unnecessary"

Value of enforcing purity in CodeWyng The first version of the part of CodeWyng that is now written in Haskell was originally written in TypeScript, and I switched exclusively for Haskell's vastly superior runtime support for concurrency and the Haskell ecosystem's stream parsing libraries. I definitely didn't switch in order to prevent myself from inadvertently mixing pure/impure code, and if it were to be rewritten in some other language (TypeScript/Go/etc.), I wouldn't consider the loss of enforcement of purity a downside.

Conversation on Zulip

Haskell strings field guide

Chris Wendt — Mon, 15 Oct 2018 00:00:00 +0000

Here's how to convert between byte, string, and character types in Haskell:

Function	Type
encodeUtf8	Text -> ByteString
unpack	Text -> String
decodeLatin1	ByteString -> Text
decodeUtf8With lenientDecode	ByteString -> Text
BC.unpack	ByteString -> String
UTF8.toString	ByteString -> String
B.unpack	ByteString -> [Word8]
UTF8.fromString	String -> ByteString
pack	String -> Text
w2c	Word8 -> Char
B.pack	[Word8] -> ByteString
c2w ❌ partial	Char -> Word8
BC.pack ❌ partial	String -> ByteString
BSC.string ❌ stops streaming	String -> BSC.ByteString

Note that Char is finite:

toEnum 10000000 :: Char
*** Exception: Prelude.chr: bad argument: 10000000

Chrome extension for highlighting variables on GitHub

Chris Wendt — Fri, 30 Mar 2018 00:00:00 +0000

https://github.com/chrismwendt/github-highlight-variables highlights variables on hover on GitHub:

Auto import for Haskell in VS Code

Chris Wendt — Sun, 25 Mar 2018 00:00:00 +0000

Today, I hacked together auto imports for Haskell in VS Code: https://github.com/chrismwendt/Auto-Import based on https://github.com/soates/Auto-Import (which currently only supports TypeScript). The code is very rough, and there is a lot of room for improvement. Currently, it only searches for variables on Hoogle.

It's cool to discover other packages and modules that export the same variable name, for example concurrently appears in async (what I would expect), but also appears in other libraries that generalize async's types: