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;)

Job Positions Available: 1 Architectual Astronaut; 1 Python Evangelist; 1 Quality Assurer

So we're a weird team. We successfully handed in our first assignment. Here are some random stats:

114 revisions

109 build_table.lisp
34 compiler.lisp
32 error.lisp
90 parse_table.lisp
145 parser.lisp
13 run
309 scanner.lisp
21 start.lisp
101 symbol_table.lisp
117 utility.lisp
971 total lines of code
17 page documentation
29 hours awake
25 test cases

I'm a bit beat.

Anyways we got it done. We're going to have to rewrite the parser and fix a bug in the scanner. We also have to merge the changes from the branch into the trunk and then fix the trunk. The grammar is also broken.

I may suggest that we revolve our tasks. Perhaps have Dimitri look at the scanner, Ian at the parser, and I at the grammar. This is so that everyone is familiar with everyone else's code. We may also be able to code review and make relevant suggestions.

I personally want to write some good unit tests and a sexy testing suite. I know that no one else is on board with this so this will be spent during lobut-time.



So ... teamwork. A group of people working towards a common goal. It's strange. I think we all have a common goal but just different paths to getting there. Ian would be our architectual astronaut at one extreme. Dimitri would be the coder whom wants to get things done. I think I'm somewhere in the middle. So we have conflicting approaches to tasks when it comes to our compiler.

I'm not exactly sure where my astronaut and python stand but here's where I do. There should be no disagreement that you should know what you're doing before you code. The real issue to me is how much is enough thinking before we code? How much time do we take to model and think before we code? How many times should we refactor? My answer? It all depends. If you ample time and the model is unclear then I think it's wise to learn more about the facets of the language that would be helpful. Take some time to push the borders of your knowledge and try something new. If ever you feel as though you know your model then you should start coding. If it's crunch time then you get your ass over the computer and hack like a biotch. Those are the guidelines that I follow. It hardly ever always works out for me but I think it's reasonable.

It's 2AM and She Calls Me 'Cuz I'm Still Awake

Alright, the scanner went through a number of revisions. The latest one that we have right now, I am most satisfied with. It handles error-detection for a lack of a better term sex-tastically.

Unfortunately, Ian and I performed a conversion for the scanner and lisp for greater readability and maintainability. The tokens were originally in lists and we converted them into defstructs. During this conversion Ian ran into an error that bypassed Dimitri's eye in the grammar. Unfortunately, Ian was not able to resolve this error. The changes that Ian and I made were trashed. Huge amount of time was lost due to this.

So we had to branch our code and go back from revision 81 to 74. During this branch I accidentally removed my directory with my copies of an error formatter that were not checked-in and I lost a decent amount of work.

Dimitri realized that he had been running one of Cormack's tool with the command

./slr -c -l [file]

What this does is use the slr tool to generate tables for our grammar. The -l tag outputs human readable output. The problem with that? The errors are printed at the top and not the bottom. Our SLR grammar has been unreadable for who knows how long.

Ian's implementation of the umm ... error recovery has been deemed infeasible given time constraints. Ian's working on writing the document. I personally am working on the writing up the scanner and writing tests for the scanner. Even though Dimitri is against this I would prefer a robust scanner but Dimitri wants me to run tests on the parser. I am alotting myself a 30 minutes to recreate the error reporting module that was destroyed. 20 minutes to make the scanner more robust.

After that, I am going to join Dimitri on the parser until sunrise. After submission however I am not going to compilers. I'm going to be catching up on PL.

Some bad design decisions were made. Ian realized that his archaic executable ways were no longer welcome =). Dimitri is still all about getting it done. I am working along as always. I don't feel so bad though. When I look to the left I see some facebook and cyber-loafing. It's 3am on the dot. By 4am hopefully I'll be joining Dimitri.

Wish me luck.

It Is A Good Day to Code

We're making decent progress.

I'm working on making the scanner more robust. Ian made a lotta grammars for the parser. The parser's a block box to me right now. I have two more DFAs to finish. Afterwards I'm going to ship it to Dimitri and he can include this into his project. After that I'm going to finish the last two DFAs, then do unit tests, then do error handling.

Poor modelling had cost me over a day. My abstract model for the scanner was a bit poor and Ian helped me out.

(Was a draft post but I am now releasing it ... 2 years later)

Vent Re: Lisp Suckage; Screw packages

Common Lisp is terrible. Terrible programming language. I don't care if its functional and dynamically typed, its libraries suck and its symbol/package system is a huge pain in the ass to work with.

I understand that its typically used from a lisp top level environment, but no one in the real world uses programs like that. No real programs require you to modify your runtime's initialization configs/scripts. No real programs require you to run them from within a toplevel or require the source/object files to be loaded in the correct order by you (or some script).

Maybe I'm wrong, maybe real world programs do require all that. Maybe thats what deployment means in web applications *shudder*.

Dependencies in Lisp seem to be a nightmare. Building a self contained executable seems impossible, and building an executable that works with multiple modules and packages seems not to work at all. The best I can come up with is not using packages at all. Essentially all our sources will be concatenated together into one big source file. Awful. Just awful.

I'm going to leave it at that for now. There isn't any more time available to spend on figuring out how to do this right. Next step, command line arguments.

A Compiler by any Other Name

So ... this is what brainstorming gives us.

The language that we're compiling is ADA/CS. I've decided to call is DAD. It's ADA spelt backwards!!! (ahem)

Anyways, if you take the first letter of our names: Dimitri, Ian and Robert, you get. DIR.

So, naturally we came to Dirty as our name. You put it all together and you have the "Dirty Dad Compiler" or DDC for short.