griver

tmux and screen commands

Action	tmux	screen
start a new session	`tmux` `tmux new` `tmux new-session`	`screen`
start a new session with a name	`tmux new -s name`	`screen -S name`
re-attach a detached session	`tmux attach` `tmux attach-session`	`screen -r`
re-attach a detached session with a name	`tmux attach -t name` `tmux a -t name`	`screen -r name`
re-attach an attached session (detaching it from elsewhere)	tmux attach -dtmux attach-session -d	screen -dr

If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.

To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.

Clone some repo (you've probably already done this step).
```
git clone [email protected]
```

	import gym
	import tensorflow as tf
	import numpy as np
	import itertools
	import tensorflow.contrib.layers as layers
	from tqdm import trange
	from gym.spaces import Discrete, Box

	def get_traj(agent, env, max_episode_steps, render, deterministic_acts=False):
	'''

	@classmethod
	def update_from_checkpoint(Cls, save_folder, network, optimizer=None,
	use_best=False, use_cpu=False, ignore_layers=tuple()):
	"""
	Update network and optimizer(if specified) from the checkpoints in the save folder.
	If use_best is True then the data is loaded from the Cls.CHECKPOINT_BEST file
	otherwise the data is loaded from the Cls.CHECKPOINT_LAST file
	Returns the number of global steps past for the loaded checkpoint.
	Arguments:
	save_folder (str): a path to a folder containing summaries and weights