nevans

IMAP specifications

(TODO) All IANA registered IMAP capabilities, response codes, keywords, mailbox attributes, the most relevant SASL mechanisms, and other relevant specifications.

• ⛔️: obsolete specifications that have been deprecated or replaced
• ⏭️: extensions that have been completely or partially included in [IMAP4rev2].
• ✨: extensions that are recommended for [IMAP4rev2] servers and clients. The IETF EXTRA WG decided that requiring them as a part of IMAP4rev2 would push the bar to implement too high for new implementations.
• 🗑: extensions that have been completely or partially deprecated or removed in [IMAP4rev2].
• 🍋: extensions that are included in the "Lemonade" profile [RFC5550].

nevans

# frozen_string_literal: true

require 'cgi'
require 'json'
require 'active_support'

def verify_and_decrypt_session_cookie(
  cookie,
  escaped: false,
  key_generator:   Rails.application.key_generator,

nevans

# Pass in an enumeration of data and
# (optionally) a block to extract the grouping aspect of the data.
#
# Optional: sort_by lambda (operates on group key and count)
#
def puts_hist(data, sort_by:nil, &blk)
  data   = data.map(&blk) if blk
  counts = data.each_with_object(Hash.new(0)) {|k,h| h[k]+=1}
  max    = counts.values.max
  width  = Pry::Terminal.size!.last

nevans

# frozen_string_literal: true
# requires ruby 3.1+

# Ractor.make_shareable(proc) only succeeds if everything on the proc's binding is shareable.
#
# This makes it difficult to create wrappers around Ractor.new that accept an arbitrary block.
# Even this would still require the block declare any outer variables as block-locals, even if
# they aren't used.
class ProcFreezer
  def initialize = freeze

nevans

TEXT-CHAR        = %x01-09 / %x0B-0C / %x0E-7F
			; <any CHAR except CR and LF>
			; %x01-09 / %x0B-0C / %x0E-7F

any-TEXT-CHAR-except-quoted-specials = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / %x5D-7F
			; <any TEXT-CHAR except quoted-specials>
			;   '"' = %x22
			;   '\' = %x5C

ATOM-CHAR        = %x21 / %x23-24 / %x26-27 / %x2B-5B / %x5E-7A / %x7C-7E

nevans

def unpack_ip(packed_ip)
  octets = []
  4.times do
    octet = packed_ip & 0xFF
    octets.unshift(octet.to_s)
    packed_ip = packed_ip >> 8
  end
  ip = octets.join('.')
end

nevans

# Run on an Intel(R) Core(TM) i7-1065G7
# using ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]

# n.b. when running these benchmarks, I did not shut down other
# processes (including web browser) nor did I run the benchmark
# multiple times (using "--repeat-count").  The numbers would be
# slightly faster and more stable/reliable if I'd done that.
# Maybe (maybe) I'll re-run them later.

Warming up --------------------------------------

nevans

#!/usr/bin/env bash
set -eo pipefail

bundle show |
  grep -v '^Gems' |
  sed 's/^  \* \|(\|)//g' |
  while read -r line; do
    gemname=$(echo "$line" | cut -f1 -d" ")
    version=$(echo "$line" | cut -f2 -d" ")
    gitsha1=$(echo "$line" | cut -f3 -d" ")

nevans

# frozen_string_literal: true

require "fiber" # needed for transfer

RootFiberException  = Class.new(Exception)
RootFiberTestSignal = Class.new(RootFiberException)

# Warning: this is only safe to call from the root fiber for a thread.
# Unfortunately, your code may not know if it is in the root fiber.  This will
# raise an exception in the root fiber of the current thread.  If you are in the

nevans

A common pattern in my CouchDB view reductions is to "merge" together the objects generated by the map function while preserving the original form, and only query that view with group=true. It's easiest to write the view reductions naively, so they continue merging the data all the way up to the top-level reduction (group=false).

But because CouchDB stores its b+trees with the reduction for each b+tree node stored in that node, moderately sized objects can result in a lot of extra writes to disk, and moderately complicated functions can cause a lot of wasted CPU time in the indexer running merge javascript that is never queried. Re-balancing the b+tree compounds this problem. This can cause the initial creation of large indexes to slow down tremendously. If the index becomes terribly fragmented, this will also affect query speed.

One solution: once the reduction is beyond the keys at the group level I care about, stop running the merge code and return the simplest data that works (e.g. null or