Author(s):	Armin Rigo
Location	Congo Room
Date	oct Thu 06	Days Raw Files
Start	13:30	First Raw Start	error-in-template
Duration	00:45:00	Offset	None
End	14:15	Last Raw End
Chapters
Total cuts_time	None min.

https://za.pycon.org/talks/42/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf RevDB_a_reverse_debugger.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	RevDB is an experimental "reverse debugger" for Python, similar to UndoDB-GDB or LL for C. You run your program once, in "record" mode, producing a log file; once you get buggy behavior, you start the reverse-debugger on the log file. It gives an (improved) pdb-like experience, but it is replaying your program exactly as it ran---all input/outputs are replayed from the log file instead of being redone. The main point is that you can then go *backward* as well as forward in time: from a situation that looks really buggy you can go back and discover how it came to be. You also get "watchpoints", which are very useful to find when things change. Watchpoints work both forward and backward. I will show on small examples how you can use it, and also give an idea about how it works. It is based on PyPy, not CPython, so you need to ensure your program works on PyPy in the first place (but chances are that it does). markdown
Comment:	production notes