rogpeppe

// derived from the doc in https://atproto.com/specs/lexicon
package lexicon

#LexiconDoc: {
	lexicon!:     1
	id!:          string
	revision?:    number
	description?: string
	defs!: [string]: 	#LexUserType |
		#LexPrimitive |

rogpeppe

2020/09/26 09:18:20 pprof on localhost:12345
2020/09/26 09:18:21 crasherQueue 0xc0000ca2a0 len 0; space 0 (data 0; error 0; suppression 0)
2020/09/26 09:18:21 crasherQueue 0xc0000ca2a0 len 1; space 659 (data 34; error 466; suppression 159)
2020/09/26 09:18:21 crasherQueue 0xc0000ca2a0 len 2; space 1306 (data 68; error 926; suppression 312)
2020/09/26 09:18:21 crasherQueue 0xc0000ca2a0 len 4; space 2619 (data 135; error 1856; suppression 628)
2020/09/26 09:18:21 crasherQueue 0xc0000ca2a0 len 8; space 5215 (data 267; error 3702; suppression 1246)
2020/09/26 09:18:21 crasherQueue 0xc0000ca380 len 0; space 0 (data 0; error 0; suppression 0)
2020/09/26 09:18:21 crasherQueue 0xc001774000 len 0; space 0 (data 0; error 0; suppression 0)
2020/09/26 09:18:21 crasherQueue 0xc0000ca460 len 0; space 0 (data 0; error 0; suppression 0)
2020/09/26 09:18:21 crasherQueue 0xc0000ca380 len 1; space 632 (data 19; error 460; suppression 153)

rogpeppe

syntax = "proto3";

package main;

option go_package = "main";

service Chat {
	// NewUser creates a new user account.
	// It returns a token that acts as a password for
	// the user and the IP address of the user client.

rogpeppe

Go Modules Workshop

The aim of this workshop is to familiarise you with the basics of Go modules. By the end, you should know how to:

• build a project that uses modules
• create a project that uses modules
• keep module dependencies up to date
• manage module dependencies, exclusions and replacements
• deal with dependencies that don't use Go modules

rogpeppe

Some thoughts about the draft Go error inspection design

Some error packages intend for programs to act on a single error (the “Cause”) extracted from the chain of wrapped errors. We feel that a single error is too limited a view into the error chain.

It might not feel that way initially, but I believe that a single error is almost as expressive as iterating down the stack looking for an error that fits some criteria, and considerably easier to reason about.

rogpeppe

#!/bin/sh
# This command installs binaries at specified versions
# into $GOBIN, $GOPATH/bin or $HOME/bin.
# It assumes Go 1.11.
if [ $# = 0 ]; then
    usage: vgoget cmdpackage[@version]... >&2
    exit 2
fi
d=`mktemp -d`
cd "$d"

rogpeppe

Go contracts as type structs

Roger Peppe, 2018-09-05

In my previous post, I talked about an issue with a real world use case for contracts - the fact that all type parameters must be mentioned every time a contract is used in a definition. In this post, I introduce an idea for a possible way to fix this.

The most important feature of contracts, in my view,

rogpeppe

Go contracts use case: generic mgo

Roger Peppe, 2018-09-05

Most of the discussion about the new Go contracts proposal has been centred around hypothetical or small-scale examples. As Go is a language that's designed for programming in the large, I thought it might be interesting to see how contracts fitted with a more real-world example.

Background

rogpeppe

Go generics at runtime (part 2 of 2)

In my previous post, I talked about some of the underlying runtime concepts behind generics in Go.

Here I'll go a bit deeper into how we might, in principle, be able to compile a generic function once for many instantiated types.

What functions do we need to compile?

rogpeppe

Go generics at runtime (part 1 of 2)

From the design document:

Generic functions, rather than generic types, can probably be compiled using an interface-based approach. That will optimize compile time, in that the package is only compiled once, but there will be some run-time cost.

Generic types may most naturally be compiled multiple times for each