publishing a new version
	try clippy (requires nightly for now)
	make sure tests work
	make sure examples work
	change the version number 
		dependencies auto-update if the first non-zero number doesn’t change
	update categories (after slug pull request)
	git tag version-0.X.0
	cargo package
		optional, allows you to inspect the target/package/*.crate file
	cargo publish

https://github.com/brson/rust-api-guidelines
https://deterministic.space/elegant-apis-in-rust.html
https://pascalhertleif.de/artikel/good-practices-for-writing-rust-libraries/
  
https://rust-lang.github.io/book/second-edition/index.html
https://doc.rust-lang.org/stable/nomicon/README.html
https://rust-leipzig.github.io/architecture/2016/12/20/idiomatic-trees-in-rust/
https://github.com/rust-unofficial/patterns
 https://github.com/brson/rust-cookbook

https://thesquareplanet.com/blog/rust-tips-and-tricks/
https://danielkeep.github.io/itercheat_baked.html

rouille	really simple, active
rustful	fairly light weight, built on top of hyper
		lot of docs, active
iron	pretty heavy weight
		very active
		https://www.jamestease.co.uk/blether/writing-a-basic-json-web-server-in-rust-using-iron
nickel	fairly light weight, built on top of hyper
		lot of examples, iffy docs, inactive
pencil	very light weight, built on top of hyper
		inactive

curl http://127.0.0.1:9000/log/all

curl -X PUT http://127.0.0.1:9000/set/time/10

http://es6-features.org/#Constants

Mon 4:30-5:30
Sun 3rd

publishing a new version
	cargo package
		optional, allows you to inspect the target/package/*.crate file
	cargo publish

* Cat sitter
* Start working on snet
	- can we save off pcaps?
* Start using clippy
* Add persistence?
	- maybe with some simple viewer tools
* Check parallelism:
	- maintain a list of buckets where the bucket number is how many threads executed
	- log that at debug
	- counting should only be done if should_log
* Try #[warn(unused_must_use)]
* Try separate executioners
* Probably should have make targets to check finger prints
* Could have optimistic parallelism:
	- default to scheduling num cores components
	- commit those that didn’t do a read from a key that a later time slice wrote to
	- otherwise commit those that executed at the same time slice
	- maybe self-adapt to scale back optimism
* could have reflected tables to encode meta info: units, blurb, default value, maybe ranges
* might also want some static sort of reporters
	- maybe a version that spits out escaped text for console runs
	- another could do rtf or markdown
* have to pay close attention to reproducibility, even across architectures
* Should be a way to collect results over runs
* support multiple cores but not the cloud
* probably just want to use code to configure
* wonder if es could be sucked into the store
* Would be cool to have a checkbox for animated runs
	- could have a checkbox under the run until button
	- would need to change Run Until to Stop
	- would need to disable Run Until Changed
* Could have a specialized project just to show log files:
	# comments are hash mark in first column
	# =~ is a case insensitive regex match
	# !=~ is a case insensitive regex non-match
	# expressions are applied in the order they are listed
	# to be really cool could have an option to persist these
	#time >= 0.0
	level >= Debug
	#show path =~ .+
	#hide message =~ xxx
	#color path red =~ error
	#back color path gray =~ blah