Ensign's Log

Here's a rundown of the languages select by the compiler groups of Winter 2007: Lisp, Scheme, Haskell, Python, Java, C++.

I think it's kinda cool.

Tonight's topic are logs and here's a breaking down of one of our teammates thanks to our all-nighter:

Changeset [164] by ianwjhalliday@gmail.com

I'm gonna pull a Dimitri/Rob and not actually comment about my check in... well, ok, symbol_table was rewritten a fair bit, and we now throw package names into the symbol table and can detect the simple error in test-declare-3.adb.

Changeset [173] by ianwjhalliday@gmail.com

Poopy pants

Changeset [174] by ianwjhalliday@gmail.com

Buncha changes. I don't know whats in here, but I know it works on my system.

Despite his breakdown I think this opens an interesting avenue of discussion:

What do you think makes a reasonable log?

I think what makes a good log is to first start by thinking who and how someone would use your log. This leads to me believe a log has two major purposes: 1) to mark progress 2) to note changes that will be useful for bug fixing later on. I'm under the opinion that one should keep an svn log message brief but concise. That means that one would want to note the changes that they've made at a high-level. And if the verbosity of a log is in question then I'd prefer to err on the side of simplicity. Reparation details about how you fixed a bug and why should be left for bug reports. The case number can be referenced from the log itself if needed. And that sums up my thoughts of logs but it reeks of generalization so ...

Here are some of my logs:

04:40 Changeset [172] by robert.luong@gmail.com
Added the final touches to the testsuite.
04:39 Changeset [171] by robert.luong@gmail.com
Added in last few test cases for the night.
04:17 Changeset [170] by robert.luong@gmail.com
Updated scope arrays and scope overloading test cases.
04:11 Changeset [169] by robert.luong@gmail.com
Add duplicate procedure and package test cases.
04:06 Changeset [168] by robert.luong@gmail.com
Added 'panic mode error recovery' test case.

Those are rather poor because those are just updates to our document but here's one:

Changeset [148] robert.luong@gmail.com

Added support for rules to the state struct in parser.lisp. Now complete with debug-messages

And finally, here's one that I'll contrast with one of Ian's own logs

Changeset [134] robert.luong@gmail.com

Fixed bugs
#13 - added char literals, trimmed first and last character from characters and strings, and double "" from strings
#17 - fixed handling the case for scanning 1..9 by adding two buffers: one for handling last acceptable case and the amount that needs to be read

Here's Ian's.

Changeset [151] ianwjhalliday@gmail.com

Turns out that the compile-file function implicitly loads the file it is compiling. This makes sense. Thus, the following (load objfile) in our build-file function was unnecessary. It actually caused errors when using defconstant.

Anyways, what do you think constitutes a good repository log message?

Irreducible Complexity

Ian has spent some time on the grammar thus far. I'm not sure as to what the status of it is but its been grueling dealing with it apparently.

We have had some great issues in dealing with the symbol table, the parse tree, and panic-mode error recovery.

(Draft post, releasing two years later)

Amateur-Ductivity

Individual Rant:

Snow Day!

I have been totally destroyed because of Snow Day. Thanks to the MS interviews during reading week I am now behind in both Programming Languages and my Compiler. Snow Day has now pushed my midterm and assignment into one fatal week.

Monday - Crypto Assignment
Tuesday - Compilers Assignment
Wednesday - Programming Languages Assignment | Crypto Midterm
Thursday - Programming Languages Midterm

BUT thanks to saving one late for programming languages, I get to do this!

Monday - Crypto Assignment
Tuesday - Compilers Assignment
Wednesday - Crypto Midterm
Thursday - Programming Languages Midterm
Friday - Programming Languages Assignment

I'm only taking three courses this term. That should be indicative of how much crap I have to do. I'm strangely calm about it though. I think after having a talk with Ian; I've tried to tame my stress a lot more.

Items Completed:
I got simple error recovery and the parse tree done. It should have only took a bit of time because I haven't worked much with the parser.

The parse tree is very simple. When we perform a shift, we create a new 'state' and push it onto the parse stack. When we perform a reduce, we pop the number of states that are required and put them into a list. We then create a new state, add those states as its children and then push it back into the parse stack. Bam, simple as that. There's one mention of it in the Compiler in C.

Simple error recovery is basically massaging the parse stack ok nce again. If we reach invalid input, we pop a state from the stack and try the input again. We do this until we run out of states. If we do, we through away that input and then reset our stack to this before hand. Very neat stuff with great results.

-- < fifteen minutes past> --

Someone broke the build.

@*#($&!!

-- < two minutes past > --

Ian ran a function I believe that had some archaic code left by Dim that referenced str. You can view this on changeset #138.


Anyways, Ian has been going through the grammar bit by bit perfecting it. We're hitting a trade-off area. Ian has been doing research for a good form of error recovery on suffix grammars. This allows us to parse in reverse order to find a proper match on the suffix. It's a lot better this way because then we can ignore an error and continue parsing on the suffix. The problem is that this is based on using the SLR tool for our grammars. Ian just ran into a portion in our grammar that requires using LALR grammars to sort it out. We could use the ILALR tool but then we can no longer find an easy way to perform our little fix.

Executive decision? We're going with LALR.


Devjavu Feature:

If you type #33 in a log for SVN. When you go to view it in Devjavu, it will directly link you to the bug list. Nifty!

SBCL Was a Problem, but the Run Script?

So I got an email from Tyrel Russell, our CS 444 TA. He says he can't run our program, gets some "fatal error in SBCL pid 12345" "can't find core file". I had no idea what that meant, so I said I'd come to his office to figure out what's wrong.

Well, we spent maybe 20 minutes trying to figure out what was wrong. Eventually, we tried setting the environment variables needed explicitly in his shell and then running the program without using the run script. Worked! Turns out his /usr/bin/sh shell wasn't sh, it was bash, and it required that the env vars be exported before they work.

What does this mean? Quickly hacked programs and scripts need to be tested on the environment they run in, or they need to be better written and understood (i.e. not quickly hacked). For assignment two Tyrel said we can just write in our documentation that he needs to set the environment variables before he is able to run our compiler. That's so much easier.

Suite Dreams are Made of This ...

Test Suite

I updated the test suite. It was a natural extension of yours Dimitri. Now it loads all test cases from /incorrect/ and /correct/ that are subdirectories of /testsuite/. There are few Lisp resources on how to navigate through the filesystem. I think it's dependent perhaps on platform but nonetheless it took a while to get this working on SBCL. This line of code did not work on clisp the last time I checked:

(setf correct-directory (directory (make-pathname :name :wild :type "adb" :directory '(:relative "testsuite/correct"))))

That pulls the pathname of every file matching adb filetype inside said directory. Now our testsuite checks whether a file passes or fails and then tallies it up at the end. I've added output suppression to the branch in 0.9 so that we can simply see the results of executing our program.

Also testsuite.lisp must be executed from one directory below. The reason is because the load files are executed using a relative path to the executing one. So they're one directory off. I couldn't find a variable that I could edit that'll solve it. I may look into the source for this but as of now, we can only do this this way.



Please note that now we are editing out of the trunk. We're doing small regression tests to ensure that all the changes to the branch have been made.

Cross-Coding

Hey people,

I'm going forward with my proposal. We already chose Lisp as our implementation language. That CANNOT be changed. So while we're here we may as well make the most of it. So I suggest that we switch tasks. We look at each other's code and critique them. The thing is that code review takes a long time and in school it's hard to justify the time spent. So after the first assignment Ian has went through certain bugs for the scanner and some other areas. What we're going to be doing is fix each other's bugs. The code reviewer is the creator and the reviewee is the person making the changes. So you must justify everything you changed to the previous person.

This makes sense to me and I hope everyone agrees. I think it's a great chance for us to get a better grasp of Lisp.

Anyways, all the best.

Ian's going to be looking at Dimitri's code.
Dimitri's going to be looking at my scanner.
I will be looking at the test suite and whatever else since Ian didn't produce any code ;)

Robert.

Test Suite

I have modified a test suite to take in a file. This will simplify writing of test cases. Robert's dream come true:)

sbcl --load testsuite/test_parser.lisp

runs all the Ada files and reports the results. Can be modified to look for ALL the files in the directory.

I also fixed a bunch of errors with the grammar.

Will be working on a parse tree next. I really like Compilers when there are no deadlines;)