Finn Bear finnbear

Policy draft: https://docs.google.com/document/d/1ErZlwz9bbSI43dNo-rgQdkovm2h5ycuW220mWSOAuok/edit?usp=sharing Comment form: https://docs.google.com/forms/d/e/1FAIpQLSdaM4pdWFsLJ8GHIUFIhepuq0lfTg_b0mJ-hvwPdHa4UTRaAg/viewform

(Obvious) Disclaimer: The material in these notes have not been reviewed, endorsed, or approved of by the Rust Foundation, but they have been submitted and hopefully will be reviewed. The current policy can be seen here: https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/

The comment, exactly as submitted, is reproduced below:

TL;DR: The proposed policy places significant new restrictions on the use of the Rust® name which are not present in the current policy. This extension to the policy is unnecessary and presupposes that a simple mention of the Rust® Programming Language could be misconstrued as implying endorsement from the Rust® Foundation.

I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.

But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.

Svelte is a language.

Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

A few projects that have answered this question:

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

Install ipset:

apt-get install ipset

Create new ipset:

ipset create tor iphash

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

~~Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.~~

Upload a file with $.ajax to AWS S3 with a pre-signed url

When you read about how to create and consume a pre-signed url on this guide, everything is really easy. You get your Postman and it works like a charm in the first run.

Then you open your browser, try your usual $.ajax() and send your PUT operation, and you hit the cold iced wall of AWS error message, a simple <Code>SignatureDoesNotMatch</Code> that will steal hours from your productivity.

So here I come to save you and give you a free working example of how to upload a file directly to AWS S3 from your browser. You are wellcome :).

	[package]
	name = "bitcode_packet_packer"
	version = "0.1.0"
	edition = "2021"

	[dependencies]
	bitcode = "0.6.0"
	rand = "0.8.5"
	rand_chacha = "0.3.1"
	lz4_flex = { version = "0.11.2", default-features = false }

	from PIL import Image, ImageEnhance
	import os
	import subprocess
	import sys

	# Requires ffmpeg https://www.ffmpeg.org/ffmpeg.html

	# Run script as
	# python movie_color_bar.py input_video output_frame_folder output_image

	from keras.models import Sequential
	from keras.layers.core import Dense, Dropout, Activation
	from keras.optimizers import SGD
	import numpy as np

	X = np.array([[0,0],[0,1],[1,0],[1,1]])
	y = np.array([[0],[1],[1],[0]])

	model = Sequential()
	model.add(Dense(8, input_dim=2))

	This is an attempt to show that Raft's safety is
	preserved with single-server membership changes as
	described in the dissertation plus the patch that a
	leader may not append a new configuration entry to
	its log until it's committed an entry from its
	current term.

	This extends the safety argument in the
	paper/dissertation. The only part that's different
	(as far as I can tell) for membership changes is Step