sprint_log.txt

Sprint 1 (September 1st - September 15th):
	What we did: 
	- Worked on tutorials (documentation here: https://docs.google.com/document/d/1x6t-Pq1oxTK9XnScjBpLIkc_lYCbqqZQK9jvVVxePbM/edit?usp=sharing
	Advantages:
	- This helped us learn some features of Ptrace. We had trouble with understanding all the hardware support needed initially (which registers arguments were saved in, system call, etc) since some of them were made for 32 bit systems which use different registers
	Problems faced:
	- There was not a lot of documentation available on Ptrace which helped us understand its function calls. We mostly had to use the man page for it to see what was happening
	- We did not commit tutorial files since all of us worked on this seperately and had seperate files. 

Sprint 2 (September 16th - October 31st):
	What we did:
	- Worked on making a basic tracer ready to trace system calls and print them to the console
	- Added data structures (AVL trees and Dead node linked lists) to record data collected 
	- Added some basic test cases to test our code with
	Advantages: 
	- We started tracing simple processes, and seeing whether we are collecting process data correctly
	- Learned about what data we needed to discard: for instance, reads/writes to fds not common between processes, open/close calls made by program when the program first starts executing, etc	
	- Gave us ideas about collecting additional information which might be useful for students
	
	Problems faced: 
	- Memory leaks at first because we weren't cleaning up data structures correctly
	- Tracer had issues with complex examples. Order of function calls was misleading in some traces 	(for instance: a process appeared to have written to a pipe after it exited)

Sprint 3 (October 31st - November 15th):
	What we did:
	- We worked on fixing a bug which gave us misleading traces for processes. It took a lot of time for us to understand what was going wrong, and during this time we tried to make many changes in the hope of fixing the bug. We finally had to read the man page for ptrace thoroughly to figure out that we only needed to look for specific signals from processes when tracing system calls (specifically sigtrap) 
	- Wrote functions to write the traced data from the data structures to a csv file which could be parsed in Python
	Advantages:
	- Fixing the bug helped trace complex programs better, and recieve predictable output everytime 
	Problems faced:
	- We initially considered checking if the signal that a child stopped with was equal to a hard coded number (that worked on the lab machines) but talking to our supervisor, we realized that we needed to take hard coded values out and understand why that number worked correctly by going through ptrace's documentation
	- At first we were only writing printable strings that a process could have written to / read from a pipe. Finding a way to generalize this was difficult. We ended up using hex to represent strings that were not printable.
Sprint 4 (November 15th - November 27th):
	What we did:
	- Worked on parsing traces generated by our pdt.c file in python and saving this data to a dictionary
	- Worked on generating process graphs for these traces in Python using Pyvis and Plotly
	- Added additional features to the process graph such as segmentation fault detection and red file pointers for specific fds that were left open (read end or write end) 
	Problems faced: 
	- Since Pyvis and Plotly were not downloaded on lab machines, we could not test our visualization code on them. We had to generate traces on lab computers everytime, and parse those traces on our native machines to see if the visualization was correct. Though this did not hamper our program's correctness (as python worked the same way on both machines) it was a tedious task as we had to do it everytime we tested 

Sprint 4 (November 16 - December 4th):
	What we did: 
	- Worked on a testing suite to test all of our code 
	- Worked on documenting our code, and writing a presentation 
	- Worked on a module which could use our tool to compare two traces. This can be useful for students to compare solutions and for instructors to test their code 

	Advantages: 
	- The testing suite helped us assure that we didn't have any bugs in our code and gave us ideas on how to make it better for students (discussed in documentation)
	- Presenting our ideas to students helped get their opinions on our project and new ideas from them on what could be useful 
	Problems faced: 
	- None