Jason Xiong: xiongjj
Matt Lee: leeml2

//=================================================
Project Description:
//=================================================


Vim Plugin tool.
    - Used to determine what plugins, if any, are significantly affecting the
      speed of vim.
    - Runs and analyzes vim/ vim plugin function calls next to CPU usage and
      reports back on total cost of certain function calls
    - Starts vim with and without specified plugins and reports back on
      startup time differences to identify particularly expensive plugins

Architecture:
Run vim within a sandbox (much like valgrind) in order to load in the proper
    scripts and functions. The main process will first use a seperate thread to
    gather --startup information and display it somewhere (possibly within
    another buffer), along with running :profile in vim in order to collect
    data for future use (program should display usage statistics of different
    plugin functions along with their call times) .
    It will then create another process to display data taken
    from the main process (such as function calls), along with its own thread
    to get information from the os itself (CPU/RAM usage of vim [side note
    i think only YCM has seperate python process due to their client-server
    architecture]). The main process will load up vim and use it as normal,
    but intercepting VimL function calls to call a python function (possibly
    through a new thread each time? seems cumbersome) to send data about that
    function to a message queue, which is the analyzed and displayed by the
    aforementioned seperate process. By the way the other process will use
    a seperate thread to handle user input in order to ensure user input goes
    through even when intense (super intense) calculations are being done.


UPDATED PROJECT DESCRIPTION: (Email sent to Otte)

Our current plugin does the following:
1. Live monitors CPU usage and vim functions (ie. exit buffer) to look for
    correlations between high CPU usage and certain function calls
2. Analyzes vim startup times with and without loading certain plugins to look
for slow plugins (ie. YouCompleteMe slow down vim startup a lot compared to supertab)
3. Analyze total time spent using function calls after an instance of vim closes

We use named pipes to send information to and from our main function; other
threads are responsible for things like listening to vim and reporting back on
commands, and we use an exec equivalent to start vim instances along with signal
handling to kill children.


//=================================================
Build Instructions:
//=================================================
1. Currently only tested in Ubuntu/Xubuntu

2. Run an instance of vim with vundle managing your plugins.

3. in CS281-Final/vimprofiler,
    - run the following: "python3 main.py"

4. Options are as listed

//=================================================
Error Conditions:
//=================================================
Possible race conditions between threads
Don't really know what to say here

//=================================================
Milestones:
//=================================================

1. get program to spawn child process that runs vim

2. Get child process to report back to parent program
    a. Intercept commands sent by vim/youcompleteme
    b. Pair commands with spikes in CPU/MEM usage
        -ps grep
    c. report back (using message queue)

3. Display in Parent process


//=================================================
Expected Schedule/Timeline
//=================================================
Milestone # :: Date
________________________
1     :: March 28
2a    :: April 4
2b/c  :: April 11
3     :: April 17

Done by April 21

//=================================================
Language and operating system:
//=================================================
Python/VimL on Unix systems (our machines being Ubuntu 14.04 and OSX Yosemite)

//=================================================
Questions:
//=================================================
How low-level should we be working in? e.g. in the case of a message queue,
would we be implementing the actual message queue system or could we use
things like RabbitMQ or Celery?

//=================================================
IP Mechanisms:
//=================================================

https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Queue
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Pipe
http://semanchuk.com/philip/posix_ipc/