This week

A lot of things need to be done this week, so I'm going to be pretty busy. Here's a quick run-down:

1. Homework: Not a lot of it, but I have some work that needs to be done by wednesday for my communications class. We talked a little bit about duobinary signalling and line codes, things that aren't too hard to simulate.
   
2. Grading: The first batch of lab reports are in, and I need to go over them with a fine-toothed comb. Also, I want to write up some solutions for the second lab, because a lot of students had trouble with it. I'll probably write more about this later.
3. Graduation: I need to apply for graduation this week, if I want to graduate in May. I do want to graduate in may. Applications are due on the 15th.
   
4. WritersUA Slides: They're mostly finished, but I have a little bit more work to do before I have to send them in on Friday. I also want to do a dry run of the presentation, to make sure that the information flows, and that I am not omitting anything.
5. Wikimedia Chapters: I have to draft up some proposals, or at least help draft them, concerning the role of chapters in the USA. Also, Wikimedia Canada is having another meeting on Wednesday that i'm going to attend. I'm supposed to review their bylaws beforehand, but I haven't seen a final copy of them yet.
6. Thesis: It's the elephant in the room, but I'm making regular progress, and need to keep up my motivation. A lot of finishing touches need to be completed now. I also need to start full-scale system testing eventually.

I'll be sure to post updates about all of these as the week progresses

Programming Lab

I'm teaching an embedded systems lab this semester, to senior and junior EE students. The lab covers C programming on embedded i386 hardware, and Verilog design on small FPGA boards. Programming is what I do. It's what I like to do, and it's something that I feel I've grown pretty good at over time. In the department I'm pretty well known as the "programming guy", and most people would think that I would relish the chance to teach what I love to my students. In reality, this course is shaping up to be the most depressing I've ever taught.

It's depressing to me to see how little my students know about computer programming, what their attitudes are towards it, and how poorly they perform on even simple tasks. Here's some background about our program. The EE department is broken down into two specialties: the "regular" EEs who have a smattering of programming background (1 low-level introduction to C "for non-majors", 1 class on microprocessors with some x86 assembly, and 1 class in digital logic with some verilog) and students taking the "computer option" who have it slightly better (The same classes as the "regular" group, and two additional classes in Java). Some students have also taken a course in MATLAB programming, although it's optional.

It's my experience that the "computer option" students do better when it comes to problem-solving, because they have experience in data structures and algorithms, and they've also taken classes that were devoted to programming. I also know that the CS department, which hosts the java courses, does a good job of instilling proper code formatting and some basic best practices. However, as has been said in other forums before, java programmers lack any kind of knowledge about basic constructs like pointers, strings ("what's null-terminated mean?"), binary operators & | and ^ ("Doesn't ^ mean exponent?"), basic console I/O, etc. I can always tell a java programmer in my class when they have well-formatted code, but a very convoluted algorithm that goes out of it's way to avoid low-level constructs. One student wrote:

printf("%c", &myChar);

He didn't know what the problem was. I asked him why he used the ampersand in front of "myChar", to which he replied "I don't know, don't you do that kind of stuff in C?". Yes, occasionally we do "that kind of stuff", but we don't do it everywhere.

The alternative are the "regular" EEs, who have only a basic introduction to C and x86 assembly, and write code that looks terrible, is filled with "goto" statements, and never use subroutines or loops. It's like they are programming in assembly, in C. These students have a slightly better conceptual understanding of pointers, but still can't use them properly in their code. "How do I pass an array to a function?", I was asked. "By reference", I replied automatically. "What does that mean?".

In a class of 14 students, I would guess that only two or three have any understanding of the fact that C code is converted into machine code, or that C code can be translated--by hand if needed--into equivalent assembly-language code. One student asked if he could just write the assignment in Java; I told him that he could if he could find the VM on our little embedded computer. He didn't know what a VM was.

It's depressing to me because many of these students are going to put "C Programming" on their resumes, and next time I apply for a job i'm going to get an email back saying "Sorry kid, the last engineer we hired from your school was dismally incompetent, we're not even going to give you an interview". Of course, nobody would ever send an email like that out, most people never send back a reply at all.

Work, Work, Work

Spent some time today working on my homework for communication's class. It took longer then expected because I was getting a strange error in my system that I was having difficulty explaining. The simulation in question involved a unipolar pulse train, passed through a band-limited lowpass channel. The problem came from the fact that I used a regular square wave for the input signal and not a PN sequence as I likely should have. For a narrow-enough band, all frequency components were filtered out, and I was left only with a steady state DC value. Needless to say, my simulation always had exactly 50% error, because the received signal was a constant. I spent some time helping one of my classmates with the assignment as well. This is my fifth semester of communications, but this poor girl is having a very rude introduction to it.

I spent some time working on my slides for Portland. They are due by 15 February. They are mostly done, and when I am finished I am going to convert them to a suitable format (PDF or ODP) and post them online. I didn't work on them too much today, but I spent a lot of time last night working on it, and am mostly done with them. I need to practice my presentation once or twice to make sure that all the information is being presented in a logical order, and that I am not omitting anything important. I'm going to sign up to give the presentation here at temple some time, probably in the beginning of march (3-4 weeks). That should make a great trial run of it, so I dont make a fool of myself 3000 miles from home.

Didn't get a lot of work done on my thesis today like I wanted, but I am going to try and get some work knocked out later tonight. Much of my remaining work involves writing some verilog modules to handle tasks that the system generator is not capable of. An ALU is pretty worthless if it can't set any flags. Once I get the verilog modules set up to finish these tasks, I need to go back over some of my older notes and make sure that all my control signals are set up correctly. I still don't have a concrete way to populate the instruction memory yet, but I'm not worried about details like that.

I received an email about the SMART fellowship today. The deadline has passed for applications and application materials, and now the decision process begins. "All submitted applicants will be notified of their award status" by March 31st, so I should know by then that I didn't get it.

LALR Parser Generator for Parrot

I've been kicking around the idea since last night about trying to implement an alternative grammar generator scheme for Parrot. The current implementation is based on a Recursive Descent parser, very similar to Parse::RecDescent (which is to be expected since they are both written by the same developer, Damian Conway). Recursive Descent here is an LL(0) technique, at least I assume so because I haven't looked deeply at how lookahead is implemented. LL grammars, with the exception of predictive parsers utilize "Backtracking" to try certain productions and return to the last good parse position if a particular production fails. Backtracking, as I know from experience, can be very costly especially in certain grammars. On the other hand, LALR parsers which are LR(1) are bottom-up, so they don't require backtracking and can be more efficient then LL parsers in many situations.

I would like to try my hand, in the coming months, at writing an LALR parser generator utility for Parrot, that would operate similarly (and possibly even plug-in seamlessly) with the current compiler generator tools. Maybe the two could be differentiated by some kind of argument or pragma. This will be, I think, good practice for me, and a good way to get my hands dirty in the Parrot project.

Microsoft Visual C++ Express Edition

I finally broke down and decided to install a "real" C/C++ compiler to my work laptop. I had an old version of Borland C++ (4.52) that I use to teach my students about embedded software development, but I would hardly say that compiler is enough to suit my modern needs.

I searched for "Microsoft C Compiler cl.exe Download", sorted through a million or so results, and found a link on MSDN for "Windows Server 2003 Platform SDK R2". Last time I downloaded the platform SDK, it was exactly what I wanted, and though that was several years ago, I figured that a package with the same name would be the same product. I was wrong. I tried to do the "web-install", but that didn't work. The small installer program would open, initialize for a few moments, and then die with the error "This program does not appear to be a valid Microsoft Windows Installer." It told me to verify the download and try again. So I did, I re-downloaded and tried to run the web installer three more times, all with the same error. So I switched strategy, and went for the "Full Download" install, which required downloading several hundred megabytes of CAB files, unpacking them to reveal another set of CAB files and then a setup program to install the software. After several minutes of install, I come to find out that this isn't what I wanted. The only C compiler in that package was the 64-bit variant. So, I deleted this package and started over.

Second time through, I found the right install: "Microsoft Visual C++ SDK Express Edition". So I download the installer, tried to run it and... Error. "Could not download .NET Framework 3.5. Please exit the installer and try again". In the installer, you have the option to install Microsoft's Silverlight SDK along with the Visual C++ SDK. I choose to not install the Silverlight SDK because I simply don't need or want it. The second time, I again de-selected this option, and again the install failed with the same message. Having my suspicions (and knowing enough to know that Microsoft likes to bundle software you don't want in with the software you do want) I decided to try the install again, this time choosing to install Silverlight as well. Surprise! it works this time, and the ".NET Framework 3.5" was able to download sucessfully now that the system knows i'm also installing silverlight.

This whole process has taken up just over an hour of my evening, and while that might not seem to be too much time, it's still just another annoying interaction with Microsoft.

Everybody has a cause

Everybody has their own cause, that's something I've been saying for a while now. People, in general, are willing to volunteer their time and their energy to specific causes. This is a lesson that people learn quickly on Wikibooks, because even though people are all ostensibly there to help write books, our volunteers will tackle that goal very differently. Some people write, some people edit, some organize, some protect against vandals, and some people do other tasks entirely. While it's tempting to say that having all these different jobs available reduces focus and causes unnecessary divisions in productivity, that's just not the case. If all our books were perfectly organized, the people who focus on organization would not switch over to become authors or editors. Put simply: if we had no need for organizers, they would likely all leave Wikibooks. People come to Wikibooks because they can perform the specific tasks that they are the most interested in performing. People leave when those tasks are available to be done.

I have a few personal problems that really prevent me from getting too involved in a project like Perl6, or MediaWiki, or any of the other cool open-source projects that I've grown interested in. The first, of course, is that I just don't have a lot of time to spare for these projects, so it's hard to justify getting involved in a half-assed kind of way. Once I have time, I plan to be spending more at Wikibooks anyway, so it probably won't free me up to do more coding work. Second, It's hard to jump into the middle of a big project. There is simply too much code to read through in projects like MediaWiki, Perl6, Parrot, Octave, or other similarly-sized projects. Many of these don't have accurate and prioritized lists of things that need to be done anyway, so in addition to familiarizing myself with the enormous code bases, I have to try and deduce the kinds of things that are considered "bugs" and the places where desired features are missing. I'd be willing to write documentation for projects like these, but I figure that if I'm going to be writing large amounts of documentation on these subjects, I may as well just cut to the chase and write a wikibook about it.

I would like to write books about Parrot, Perl6, and MediaWiki, and once I have more time I will likely try to get into projects like these. I am still interested in getting into Perl6/Parrot eventually, but it just isn't feasible until my thesis gets complete.

Textbook Season

Regardless of all my work on Wikibooks, we still aren't at a point yet where when the semester starts I can expect to be downloading the required textbooks for free. However, despite the ridiculous price of modern textbooks, I'm still always a little bit happy when textbook season rolls around. I get a lot of my purchases through Amazon, so I do save some money off the sticker price, and that always helps the situation. It certainly beats giving more of my hard-earned money to Temple.

I'm taking a communications-heavy semester (relatively speaking), with both my classes being based in that subject. "Analog and Digital Communications" and "Communications Networks" are likely to have significant overlap in many areas. The latter course is focusing more heavily on particular implementation technologies (WiFi, WiMax, 3G, etc) while the former is going to be more theoretical. I expect to spend a lot more of my life sitting in front of computers running endless numbers of simulations.