Cleaned up unused files
This commit is contained in:
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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
|
||||
@@ -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}}
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user