We had a third Hackathon where a few new people showed up. Although I couldn't attend the entire thing, it did seem to go very well. We were able to complete the symptoms database and figure out the direction that we wanted to go from that point. Currently I'm focusing on getting a page setup for users to edit their profile. This shouldn't take too long, but time is always short near the end of the semester. Some other people are working on getting the Add symptom page setup. While this isn't conceptually difficult, doing it in a user friendly manner will prove challenging, not everyone will know scientific terms for symptoms and therefore a middle ground will need to be found. This project will continue into the next semester, so it hopefully won't die as the semester ends.
Like Avisynth, Mkvsynth is operated via a custom scripting language, one specifically geared for operating on video files. Mkvsynth parses this language and turns it into FFmpeg function calls. This means that the scripting language is at least as important as the video processing side of the project.
Much thought was given to the syntax and semantics of the language. Over time it has shifted between a purely object-oriented model, to a more functional-programming inspired model, and finally back to something entirely generic and not groundbreaking in the least. But that's okay: scripting languages aren't supposed to be particularly elegant; they're supposed to be practical and concise. So the end result is something that looks a lot like "C without types and semicolons," though of course this (and every other aspect of the project) is subject to change.
The Mkvsynth interpreter is named "delbrot," and it has had a rough life. From the beginning of the project, I was tasked with implementing the scripting language. The problem was that I had no formal education or experience in compiler or interpreter design. So the initial prototype of delbrot was actually a C transpiler, written in Perl. It was an utterly shameful hack, but it worked well enough for us to demo it at the end of the spring semester.
Over the following summer my father introduced me to Lex (a lexical analyzer) and YACC, (a so-called "compiler-compiler"). These tools, along with their modern equivalents Flex and Bison, are capable of generating a complete parser from just a grammar definition, using what is called "Backus-Naur Form." This allows for the creation of either a compiler or an interpreter: in either case, whenever a grammar rule is matched, some corresponding code is executed. In a compiler, that means writing some assembly code to a file. In an interpreter, that means immediately performing whatever action is associated with that grammar rule. For example, when a "PRINT" token is matched, the C function "printf" is called on the subsequent arguments.
Simple grammars can be parsed in this "1-1" fashion, but more complex grammars need to be more robust. They need to be capable of handling hundreds of levels of nested expressions, as well as types, function calls, etc. To enable this, these grammars use an abstract syntax tree, or AST. The AST is a simple tree data structure, containing the parsed tokens and their relationships to each other. An expression like "x = 5 + 2" is represented in the AST as "= has children x and +, and + has children 5 and 2." Then, when the expression is fulled parsed into the AST, it can be evaluated recursively. For a more in-depth explanation of how delbrot functions, check out the documentation in the Mkvsynth repository.
I worked extensively on delbrot over the summer -- completely rewriting it from scratch several times -- and I learned a whole lot about interpreter design in the process. I'm proud to say that delbrot now supports user-defined functions, plugins, recursion, and optional arguments. My strongest piece of advice coming out of this experience is: don't reinvent the wheel! I wasted nearly a whole semester's worth of effort simply because I was unaware of the tools available to me. Oftentimes, a bit of googling can save you a lot of effort.
This semester's example of Smith will be a very simple program. Showing off web programs will be difficult for the next year because Smith relies on some standards that aren't yet, well, standard. Now is the time to think of more examples that might show it off better:
Framework for simple text-based games that are served. Simple client written in CoffeeScript responsible only for sending and displaying text. A chat room could use this architecture.
Eh, don't rewrite what (mostly) ain't broken.
This is an entirely different project but could be written in Smith. The idea is a human language that produces perfect graphs of the concepts involved. It could come with a dictionary and simple ontology.
Don't know how long this might take. Currently @eg tags just sit there. It would be nice to run through all them.
Due to internship/ job related activities, the team has had a busy schedule off campus the past few weeks so little was done.
For the remainder of the 3 weeks (semester almost over!) we will focus on refining the filter for the program and the output points so next year we can work on creating an attractive visual element as well as an user interface for analytic uses.
The RAID10 array storage we used for hosting the development site died last week. We've been working on rebuilding the setup. We're switching to raidz2 for better data integrity and scalability.