So we haven't had a meeting for three weeks, which is all my, colin's, fault since I've been interviewing all over the place. 4 job offers so far so it was worth it.
At the end of our last meeting 3 weeks ago, docker managed to break their entire API. Most of our work today was fixing skeleton so it worked again and people could work on their individual components.
We're making progress on the https connections, the calcUpdate improvements are written if not finished, and we're doing an initial sketch of logstash.
I've recreated a part of the App Store app to demonstrate another potential use for the color library I am developing. These are not mockups. These are real screenshots. The color algorithm applies so quickly that it does not appear to affect animation performance at all.
Player stat cards are a neat aspect of what our titling system is capable of doing; however, there are some definite shortcomings in their original implementation. The database that holds this information is very rigid, very static, and very vague. The database looks like: Num, FN, LN, Position, Height, Weight, Year, stattype, S1, S2, S3, ... S8; so you can see that 1) we are very limited in what we can enter in, and 2) we have very limited flexibility because the database knows nothing of the actual stats. We only later 'define' the stats by labeling them before they are rendered.
We've decided that, instead of using static columns to throw stats into, we will move to a more flexible key:value configuration in the database. This will allow us to add whatever stats/facts/other information about a player that we want, with no bounds. Looking into the future, this would allow us to very easily create a career stats page, or really anything our hearts desire. Further, this allows usage of this stats outside of our standard player stats cards.
There are still a few things we haven't fully worked out. We haven't decided what the user interface will look like to select stats for use yet. This doesn't stop us from implementing it, it simply means that for the time being, we will have to hard code what stats we would like to use for players. Another consideration we must make is how to best do manual data entry. Now our data is entered in three ways. Players uploaded into the database via CSV, and this change does relatively little to affect that. Secondly, data is scraped from various website to make our lives much easier, and again, this does little to change this. But, finally, the unfortunate case where data entry must be manual, now becomes even more difficult. Because the data becomes harder to tabularize. There are a few things we've considered, but nothing that stands out to us as being the obvious right answer. Hopefully some testing gives us more answers.
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.