<D <M <Y
Y> M> D>

%left BLEAH: My parser works, kinda. I can't get the operator precedence declarators to do anything, though, so I've got 26 shift-reduce conflicts. I know it's ignoring the precedence declarators because I can, eg., make + nonassociative and it'll still parse 1+1+1. Nonetheless, it parses all the example programs, although it's still probably got bugs (I thought my lexer was perfect, but the writing of the parser uncovered four new bugs in it). It's due at noon.

When copywriters make technical decisions: My camera's three settings of picture quality: "Best", "Better", and "Good". Stop it! For one thing, I don't need to be reassured that even though I'm taking pictures on the lowest quality setting, the quality is still acceptable. For another, "Better" is not an identifier. "Better" is a function. Knock it off, marketing people!

In other news, I now have only 4 shift-reduce conflicts.

Uh-oh...: Not good. The SEAS network is inaccessible from outside. My parser is due at 12. This basically means I'm turning it in as-is. But how? I can go on-campus now and do it and then waste a whole lot of time until my class at 2. I can wait til 11 and then go and fight for a place in the lab. I suppose I'd better go now. This class is very strict about deadlines and I don't think "The SEAS network was down" will be accepted as an excuse.

I hate thinking up titles for everything: I'm in the lab now. I finally figured out how to do {chicken, precedence} right, so I am rid of all the conflicts. I've submitted my project now. I don't know if it works 100%, but it should at least pass all the tests. This is all I need, since I won't be using my own syntax to do the rest of the projects. At noon, we'll get a standard syntax which we are all to use so that it will be easier to grade the other projects.

I like the way our projects are graded in this class. The TA writes a bunch of test programs (which we don't get to see) and then tries to clobber our lexer/parser/compiler/bytecode generator with them. Your grade is based on how well your program avoids clobberation. It's very objective, in contrast to the lower-division classes in which you had to turn in your source code in a manilla folder and the TA would go through it and dock you points if you didn't have enough comments (I once got docked for having too many comments!).

Sissy email worms must go!: Enough with these sissy email worms! I'll tell you how to write an email worm, dammit. Don't just look in the victim's address book. Look in their mail archive. Use the mail archive to a) find more emails to send the worm to, and b) create a plausible subject line for each address. If you can't find a plausible subject line (if there's no recent thread for that address), generate one at random. Use a CFG that can do a couple million different subject lines of twenty different major types.

Don't make someone run an application to do all this for you; hijack Outlook and do it yourself. Melissa had the right idea.

Scan for interesting keywords and send messages that match to a randomly selected set of 1-3 email addresses (out of of 10,000) 100 of those email addresses are controlled by you, throwaway accounts and whatnot. The other 9900 belong to random people. You now get lots of juicy email and implicate lots of innocent bystanders.

Encrypt all these lists of email addresses, fragments of subject lines, etc. Use real encryption and not pansy XOR encryption so that it will take a couple days instead of a couple minutes to get your plaintext.

Is this so difficult? I can figure out how to do a good email worm and I'm not even particularily evil. What's up with these evil people who foist lame email worms upon the Windows world?


Unless otherwise noted, all content licensed by Leonard Richardson
under a Creative Commons License.