Cleaned up unused files

This commit is contained in:
2015-05-06 21:28:44 -04:00
parent 1c68deb03e
commit 46af7125da
9 changed files with 0 additions and 150 deletions

View File

@@ -1,7 +0,0 @@
Approach
The approach section contains our methodology, how we plan to implement the project, and our project schedule, the timeline we plan to adhere to. The methodology outlines the specific tools we will use to complete the project in a timely manner whereas the schedule outlines the deadlines by which we hope to have certain tasks completed.
Methodology
C$_0$ Cement is a Debugger designed for the CMU teaching language, C$_0$. It will be hosted on <BLANK> with the website itself designed in CSS and HTML, using Node.js to run most of the core functionality. We will first deploy a blank template website after which half of the team wil work on parsing C0 bytecode and the other half will work on creating a meaningful user experience. Once both teams have made reasonable progress, they will combine the two units to complete the basic outline of the project.
Project Schedule
The project will be separated into five main phases: Basic Website Design, Backend implementation, Frontend Implementation, User Testing, and Revisions. The first phase should take <POSSIBLY CHANGE THIS> less than a week with the next two phases occurring simultaneously and composing the rest of the month's work. User implementation and revisions will then hopefully take up the remainder of the alloted time, with extra time padded in case implementation or revisions are more extensive than we have predicted.

View File

@@ -1,11 +0,0 @@
This project will benefit students in 15-122 Principals of Imperative
Computation at Carnegie Mellon University by helping them create correct
programs. The C0 Debugger will enable students to understand how their programs
execute and find where problems originate more easily than with existing tools.
In addition to debugging, students will have better knowledge for how the
underlying computation model works when evaluating their code.
The C0 Debugger will also enable students to test simple programs with little
setup, using only a web browser. They will no longer have to set up and become
familiar with a Unix environment before they can program, making C0 accessible
to more people.

View File

@@ -1,4 +0,0 @@
Evaluation Criteria
The goal of our website, as mentioned earlier in the proposal, is to provide a tool for 15-122 students to easily step through their C$_0$ code as a means of debugging and to gain a deeper level of understanding for the steps their code is actually taking.
In order to evaluate our final project, we would test the product on various groups of students. Both those who have completed 15-122 in the past and those currently enrolled. Unfortunately, due to the time constraints of the project, these students will no longer actively code in C$_0$ by the time they see our product, but their interactions with it will still have been recent enough for them to provide meaningful feedback. With their feedback, we will determine how well our product succeeds at its aforementioned objectives and plan a series of modifications based on the comments we receive. We will make sure that the stepping tool and GUI are fully functional before the group testing phase so that uninformative bugs do not catch the attention of our test subjects, and they instead provide us with information to improve the user experience as a whole.
Our main goal is to provide these students with a useful debugging tool, so their feedback is invaluable in slowly modifying our project to better suit their needs.

View File

@@ -1,15 +0,0 @@
\BOOKMARK [1][-]{section.1}{Introduction}{}% 1
\BOOKMARK [2][-]{subsection.1.1}{Background}{section.1}% 2
\BOOKMARK [2][-]{subsection.1.2}{Project Overview}{section.1}% 3
\BOOKMARK [2][-]{subsection.1.3}{Analysis of Literature Review}{section.1}% 4
\BOOKMARK [2][-]{subsection.1.4}{Successes}{section.1}% 5
\BOOKMARK [1][-]{section.2}{Approach}{}% 6
\BOOKMARK [2][-]{subsection.2.1}{Phase 1}{section.2}% 7
\BOOKMARK [2][-]{subsection.2.2}{Phase 2}{section.2}% 8
\BOOKMARK [2][-]{subsection.2.3}{Phase 3}{section.2}% 9
\BOOKMARK [2][-]{subsection.2.4}{Phases 4 and 5}{section.2}% 10
\BOOKMARK [1][-]{section.3}{Results}{}% 11
\BOOKMARK [1][-]{section.4}{Discussion}{}% 12
\BOOKMARK [2][-]{subsection.4.1}{Reflection}{section.4}% 13
\BOOKMARK [2][-]{subsection.4.2}{Future}{section.4}% 14
\BOOKMARK [1][-]{section.5}{Sources Cited}{}% 15

View File

@@ -1,37 +0,0 @@
\relax
\providecommand\hyper@newdestlabel[2]{}
\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
\global\let\oldcontentsline\contentsline
\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}}
\global\let\oldnewlabel\newlabel
\gdef\newlabel#1#2{\newlabelxx{#1}#2}
\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
\AtEndDocument{\ifx\hyper@anchor\@undefined
\let\contentsline\oldcontentsline
\let\newlabel\oldnewlabel
\fi}
\fi}
\global\let\hyper@last\relax
\gdef\HyperFirstAtBeginDocument#1{#1}
\providecommand\HyField@AuxAddToFields[1]{}
\providecommand\HyField@AuxAddToCoFields[2]{}
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{section.1}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Background}{1}{subsection.1.1}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Project Overview}{1}{subsection.1.2}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Analysis of Literature Review}{2}{subsection.1.3}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}Successes}{3}{subsection.1.4}}
\@writefile{toc}{\contentsline {section}{\numberline {2}Approach}{3}{section.2}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Phase 1}{3}{subsection.2.1}}
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Revised project Gantt chart}}{4}{figure.1}}
\newlabel{gantt}{{1}{4}{Revised project Gantt chart}{figure.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Phase 2}{4}{subsection.2.2}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Phase 3}{5}{subsection.2.3}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Phases 4 and 5}{5}{subsection.2.4}}
\@writefile{toc}{\contentsline {section}{\numberline {3}Results}{5}{section.3}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Revised project Gantt chart (copied from above for convenience)}}{6}{figure.2}}
\newlabel{gantt}{{2}{6}{Revised project Gantt chart (copied from above for convenience)}{figure.2}{}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Discussion}{6}{section.4}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Reflection}{6}{subsection.4.1}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Future}{7}{subsection.4.2}}
\@writefile{toc}{\contentsline {section}{\numberline {5}Sources Cited}{7}{section.5}}

View File

@@ -1,17 +0,0 @@
Introduction
===
One of Carnegie Mellon University's most widely attended class is 15-122,
Principles of Imperative Computation. 15-122 contains a capstone assignment
called the C0 Virtual Machine, which involves implementing a program that
allows the user to run arbitrary code in the language in which 15-122 is
taught, C0. The implementation of the virtual machine (C0VM) is not an easy
task - it involves higher level thinking and a deep understanding of the
abstractions associated with running arbitrary code. Because it is difficult,
the CDB (C0 Debugger) hopes to improve the learning process by making
visualization and interaction with a working implementation of the C0VM more
accessible to 15-122 students. This involves creating a working Javascript
version of the C0VM, implementing visualizers for relevant parts of the
assignment, and developing the interface for student-based interaction with
the application. With development time and effort, the CDB has the opportunity
to change the future of imperative computation education.

View File

@@ -1,47 +0,0 @@
* Building an In-Browser JavaScript VM and Debugger Using Generators
http://amasad.me/2014/01/06/building-an-in-browser-javascript-vm-and-debugger-using-generators/
In this blog post, Amjad Masad describes how he implemented debug.js, a
JavaScript debugger running inside the web browser. Since we wish to implement a
c0 debugger running inside the web browser, Masad's notes seem to be relevant.
Specifically, this post discusses the architecture of debug.js, as well as
various challenges Masad faced in developing it. Debug.js was designed in two
separate parts: a virtual machine and a debugger. The virtual machine handled
the task of evaluating the JavaScript program being debugged, adding support for
stopping, starting, and analyzing the program. The debugger was the visual
interface to the virtual machine, allowing users to control the virtual machine
and see its output.
Masad also discusses challenges he overcame while writing debug.js. These
included being able to step line-by-line through a program, keeping track of a
call stack, handling errors and exceptions, implementing native APIs, and
dealing with events. While many of the details will be different when working
with c0, we must still consider all of these challenges in developing our
project.
* The Architecture of Open Source Applications (Volume 2): Processing.js
http://www.aosabook.org/en/pjs.html
In Chapter 17 of Mike Kamermans' book The Architecture of Open Source
Applications, he discusses the design of Processing.js. Processing is a
Java-based programming language designed to help teach computer programming in a
visual context. Processing.js is a project designed to run Processing programs
in the web browser using only JavaScript. This was done by writing a own
Java-to-JavaScript compiler, and running the resulting code attached to a HTML
canvas. Along the way, the developers ran into several different challenges,
mostly due to differences between the Java and JavaScript languages. The
largest difference between the languages was that JavaScript programs do not get
their own thread; the browser freezes if a JavaScript program tries to run for
too long. We must consider this issue among others for our project.
* Node.js Documentation
http://nodejs.org/documentation/
This is the documentation for the node.js platform. We plan to use node.js to
write the server-side code for our project. We believe that node is a good fit
for our project since we are writing JavaScript for the client side of our code,
so this will let us work in the same language on the server and client side.
Also, we can make use of the existing cc0 compiler to translate c0 source code
to the bytecode our virtual machine will run. This is the same compiler used in
15-122, and integrating it with our server will make it feasible to run actual
c0 source code.

View File

@@ -1,12 +0,0 @@
Our goal is to build a web application that can debug c0 code.
The user will type in or upload c0 source files.
Once this is done, these files will be transferred to our server, where the cc0 compiler will be used to
generate bytecode corresponding to the user's source code.
This bytecode will be sent back to the user's web browser, where we will be running a c0 virtual machine.
The user will be able to control this virtual machine as it executes their code.
This will give the user the ability to run their code line-by-line,
to set breakpoints, view stack traces, and see the values of variables.
By providing access to all this information, we hope to make it easier for users to write and debug c0 programs.
For version control, we will use a git repository hosted on GitHub.
We will use a Gantt chart, shown later in this proposal, to stay on schedule.

View File