Presentation Plans

My focus this year has been on compilers, with a slight deviation into cookies. The heart of compilers is the translation of code that humans understand into instructions that the computer understands.

To illustrate this idea, I think the best activity is to cosplay as a computer. Paired up by improv partners, we will take turns writing instructions to guide the other to decorate a cookie to our liking. Thankfully, we understand instructions more complex than binary, yet to add some level of difficulty we will pretend that we do not understand basic English. Rather, there will be a specific language that our cookie-decorating-robots will speak, and anything else will be ignored by the temporarily mindless machine.

To set up this activity, I need to create the UI (user interface) as well as the API (application program interface)

The following graphic depicts how our robot will start every single decorating attempt:

The sugar cookie lies in the center of the plate, with sprinkles in the top left and frosting with a knife in the top right.

The chart below provides all valid commands for our robot:

Command	Example Usage	Helpful Constants
moveHand(hand, loc)	moveHand(RIGHT, CENTER) -move right hand to center of plate	hand: RIGHT, LEFT loc: NW, NE, SE, SW, CENTER
toggleGrab(hand)	toggleGrab(RIGHT) -if the right hand is clenched, then unclench, and vice versa (hand starts in relaxed position)
spread(hand)	spread(RIGHT) -the right hand does a spreading motion, regardless of whether it is holding a knife or if a cookie is present beneath

Imitation game soundtrack during activity: https://www.youtube.com/watch?v=eN0rD9BezjE&list=PLquX2bTG1Wm2g4nGNDHTKf8eN4sIAZVTs

Materials:
Cookies, frosting, sprinkles w/ communal spoon, individual plates and knives, 2/3 printouts of diagram and chart per table

COOKIES

New topic!

Here are 3 reasons why you should care about cookies (the computer kind):
0) They are small and full of value (just like regular cookies)
1) They allow you to not sign in every single time you go to a website
2) They also might be used to track your online activity

Summarized and paralleled in table form:

	Cookies	Cookies
Ingredients	Made of flour, sugar, butter, eggs, and chocolate chips to taste	A small text file compromised of (key, data) pairs
Pros	Taste and happiness elicited	Convenient method to store/remember data between sessions (either connections to website or opening a browser)
Cons	After inevitably eating more than you should, your stomach hurts and you depart on your guilt trip	Third-party cookies, often from advertising sites, can be used to track your activities online

Cookies can be found through 2 ways:

1. Go to chrome://settings and click on Show advanced settings... at the bottom
Under Privacy click Content settings... and click All cookies and site data...
This will show  a list of websites and the number of cookies stored by each.
However, this doesn't allow you to actually view the contents.

2. In File Explorer, go to C:\Users\[NAME]\AppData\Local\Google\Chrome\User Data\Default
Inside, you see many files. This is where the cookies seen before are stored.

I checked out a file named "Current session" in notepad, and found this file. 

While the file is full of gibberish and white space (it is slightly encrypted/modified before storing), we can see that Google Chrome uses this file to "remember" which tabs I had open (stackoverflow.com). This is useful if I accidentally close a tab and want to Ctrl + Shift + T it back to life.

I ventured deeper into my folder and found a file "33" in the folder for Google Calendar's cookies. (Most of the other folders were similar, with numbered files.)

 

The most striking part of this file was the emptiness. Here I show the most exciting section of it. The majority of this large file (see the small scrollbar) was simply empty:

One thing you see consistently in the text is "sqlite". This is the library Google uses to store the cookies on the hard drive. 

My guess is that this "33" cookie is used for Google Calendar to remember my specific preferences, such as which calendar views to enable.

Finding real cookies on my computer took some of the magic out of Google Chrome - akin to finding out that Santa had not been eating the cookies each year. Oh well, it was about time to grow up in the computer science world anyways.

Sources:

http://www.whatarecookies.com/

https://www.quora.com/What-does-the-code-for-a-tracking-cookie-look-like

http://stackoverflow.com/questions/31021764/where-does-chrome-store-cookies

Compil-- COOKIE BREAK!

So. My experience researching compilers has been rocky, with learning Flex and Bison while dealing with the constrained languages and profuse errors. I eventually got my simple compiler for LC-3 Assembly to work.

Flex code:

This code identifies the tokens (see previous posts) in the LC-3 language

Bison code:

This code specifies and identifies statements, valid sequences of tokens

This code took code from a simple version of Assembly adapted for LC-3, a simplified model of a computer, and turned it into binary (0s and 1s). Here you can see my output versus the output of an online LC-3 compiler.

(^The result of 30+ hours of toil and tribulation)

Even with this (small) success, I've barely made progress on my overall project of making a compiler.


Referring to the above diagram, I have only researched and coded for the "Front End", and especially simple code at that. Starting the year, I knew this was an ambitious project, normally undertaken only by upperclassmen undergrad students. At my rate, it doesn't appear that I can finish a full compiler.
Instead, I will switch to a different (and tastier) topic in computer science that I have been interested in for a while:

COOKIES 

(coming at you next time!)

Sources:

Blood

Sweat

Tears

http://dinosaur.compilertools.net/

COMPILER CRAP RECAP RAP

My side-life as a Christian rapper, MC Prophet, has finally debuted. This week, the slick lyricist in me took over and created a rap song to recap the compiler facts we've attacked.

soundcloud

Lyrics:
This journey started out in computer science with mickel
He taught about compilers which were cool like icicles 
All that knowledge just flowing down, flowing down trickle trickle
It tickled my mind like a fuzzy pickle got to earn them nickels

Uh, what even's a compiler huh?
It's just a program, microsoft word, word
It takes your code, translates a bit
ni hao to hi, caca to ______

The parts of the compiler are easy to tell
Just look at my blog post you dumb-bell
There's the pre processor compiler assembler and linker
(Then the) loader and memory we're done hook line and sinker

Chorus
Uh, compilers are the very best
Reppin' from the wood of west
Didn't study for the test (what?)
Doesn't matter cuz im blessed

The tools I use for compiling are bison and flex
Hexidecimal, lexical, tex mex, regex
Now I'm learning how to compile LC3
Stands for Little Computer and it's online for free

Chorus
Uh, compilers are the very best
Reppin' from the wood of west
Didn't study for the test
Doesn't matter cuz im blessed

The Imagination of Computer Scientists

As I've worked with various computer software, I've realized that computer scientists are embarrassingly dorky in many ways. Most directly, I've observed this through Yacc, the syntax analyzer I have been working with. Its acronym means Yet Another Compiler Compiler, alluding to the fact that it compiles code to make compilers. This amusing and endearing name reminded me of similar naming schemes used by other computer scientists.

Researching amusing computer science names led me into the world of acronyms and naming schemes. I learned about recursive acronyms, in which the expansion of the acronym contains the acronym itself. 

GNU = GNU's not Unix!

While GNU's amusing acronym was its initial name, most of the funny names I found were created later on, as humorous takes on the acronym. These are called backronyms, when the expanded name is created from an existing acronym.

Original                                Acronym        Recursive backronym!

Mash Until No Good ==> MUNG ==> MUNG Until No Good.

WINdows Emulator  ==> WINE   ==> WINE Is Not an Emulator

Personal Home Page ==> PHP      ==> PHP: Hypertext Preprocessor

These computer scientists actually kill me. They really do. Anyways, I was inspired to create a couple of my own acronym ideas after researching these hilarious names.

BANANA = BANANA: A Nonsensical And Natural Acronym

POTATO = Population Of Teens All Too Overweight

COMPUTER = Can Only Manage Programs Under The Expected RAM 

-RAM is Random Access Memory

NOODLE = Normal Or Ordinary Dinner Leftists Eat

Sources:

https://en.wikipedia.org/wiki/Backronym

https://en.wikipedia.org/wiki/Recursive_acronym

Alternatives to Compiling Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TIME CAPSULE:
Hi, me in the future! You're probably super embarrassed by me right now but I'm super bored in calc. I hope you are going to graduate
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My topic for the year is "Compilers".
I've said before that a compiler is a program that turns the code that humans type (public static void main....) into the code that computers can understand (0's and 1's). However, I am generalizing somewhat.
Any code that will be run will need to be translated into 0's and 1's eventually. A compiler is simply one of the methods of translation. Other methods include interpretation and a blend of compilation/interpretation. What differentiates these methods is the time at which translation is completed.

1. Compilation: The entire program is translated before you want to run the code. The translation is done by a compiler, a program that takes your code as an input and produces the "0's and 1's" as an output. 
2. Interpretation: The entire program is translated when you want to run your code. The translation is done by an interpreter, a program that takes your code as an input, analyzing it and mimicking its function with its own pre-written code of "0's and 1's". 
3. Hybrid: The program is partially translated before run-time and is fully translated during run-time. A compiler will convert the code into an intermediate form, and the interpreter will interpret the intermediate form.

Compiling code and interpreting code have their own advantages and disadvantages, and the third method seeks to find "the best of both worlds" (-1 pt, cliche). 

Advantages of Compiling Code

1. Running the code is faster. The 0's and 1's produced by the compiler are in the processor's native language. An interpreter acts as an intermediary between the code and processor, and adding a third party always takes a longer time.
2. Compilers error-check your program. When translating into machine language, the compiler checks syntax to make sure nothing obviously wrong happens when you run the program. If there is an error, the compiler will tell you and there will not be code generated. However, an interpreter will not check the code before it tries to run it, leading to situations where code will be almost fully run before the blatant error at the end is encountered (a great inefficiency).

Advantages of Interpreting Code

1. Interpreting code is platform-independent. You can use the same code on different computers and have everything work fine. The interpreter (remember, simply a program) will compensate for differences in processors, etc. However, with compilers, the generated machine code is specific to the computer it was compiled on. This means that if you take the output (0's and 1's) from one computer to another, the new computer will quite likely not understand the program.
2. Interpreters are simple to use. With a compiler, you must run a program (the compiler) to convert your code, then run the executable produced. With an interpreter, you simply give the interpreter your code, and the program will run it for you.

Before we move on to the hybrid method, let's look at a diagram (above) that may help show the difference between compilers and interpreters. Our inputs to both are the same. However the compiler outputs further code (the code above is one step away from 0's and 1's) while the interpreter outputs the result of running the code (basically runs the code). If we were to run the compiler's output, we would also get 12.

~

Now, on to the hybrid method. This is employed by one of the most common programming languages in the world: Java.
We can see on the left that both a compiler and interpreter are utilized for the running of the program. The compiler turns the code into an intermediate form, byte-code, that is neither the human form nor computer form. The interpreter (specifically the Java Virtual Machine) then takes the byte-code and runs it.



Advantages of the Hybrid Method

1. Relatively fast: slower than compiling but faster than interpreting
2. Machine-portable: The byte-code can be transferred between computers and still work, since the interpreter handles hardware differences between systems

This research has shown me that "Compilers", my topic, has much more depth than previously thought. I might expand my yearlong project to encompass this Hybrid Method that has shown itself to be very efficient.

Sources:
http://stackoverflow.com/questions/3265357/compiled-vs-interpreted-languages
http://www.programmerinterview.com/index.php/general-miscellaneous/whats-the-difference-between-a-compiled-and-an-interpreted-language/
https://thesocietea.org/2015/07/programming-concepts-compiled-and-interpreted-languages/
http://stackoverflow.com/questions/95635/what-does-a-just-in-time-jit-compiler-do
https://www.upwork.com/hiring/development/the-basics-of-compiled-languages-interpreted-languages-and-just-in-time-compilers/

Lexical Analysis

Woah, what a weird phrase! Let's define that.

A lexicon is a dictionary, so lexical pertains to words and vocabulary of a language.

Well, what are the "words" of a programming language? 

They're the smallest sequence of characters that have meaning.

Looking at the example above, "public" could be one of our words. You see, we can't split it up any more without it becoming nonsense.

Lexical analysis concerning itself with recognizing basic patterns, or tokens, in the code and dividing the code into a list of tokens.

For example, the code above might be split as "public", "class", "Dog", "extends", "Animal", "{", "public", etc.

For humans, this splitting of the code is intuitive, but computers need a little more guidance.

Lexical analysis and its rules can be implemented by a tool called lex, which is a program that makes programs. Confused? Yeah, I was too. Hopefully this helps.

In this diagram, the boxes represent programs and "patterns" is a text file. 

"patterns" contains rules on how to divide the tokens. These rules are passed into the lex program, which generates code for a program that will process input according to the rules in "patterns".

So, lex does not deal with analyzing your code, but creates a program that does.

This is really handy, because you don't need to write code to go through the input - all you need to do is specify some rules and lex will create a lexical analyzer that will split up the code into tokens for you. I love how programmers are so lazy!

One thing is still unclear: how do we write the rules? We will explore regular expressions next post.

Sources:

http://dinosaur.compilertools.net/flex/index.html

http://epaperpress.com/lexandyacc/download/LexAndYaccTutorial.pdf