Xpdf may be fugly as hell (it's a motif/lesstif app), but there really isn't any replacement for it yet.
How about KPDF? Based on the xpdf engine, integrates nicely with KDE, more compatible than Acrobat Reader 7 in my experience (either that, or my students use really weird PDF generators).
What level of class was this? Based on what I've heard from my colleagues, freshman programming courses at our university have had the most (detected) dishonest activities, with 12 % of students being caught cheating at most (Basics of Programming ten years ago, using Scheme). On third-year or later courses, 3 % (as in the concurrent programming course I TAed) is considered quite a lot, and to find those I had to look for equivalent structures and small editing mishaps (the Chinese student submitting code with Danish comments ended up exposing five of his compatriots who edited the same code found on the web when I used an in-house JPlag derivative to check for students copying each other's code).
While Alice may initially seem to provide a really nice graphical programming environment for beginners, it has, in my experience and that of some of my co-workers, a few limitations that will quickly stifle budding programmers:
Using a variable as an array index instead of a constant causes the interpreter to fail mysteriously with a stack dump. Good luck using arrays for anything interesting.
There doesn't seem to be any way for a program to dynamically create objects; you have to statically define them at startup.
Debugging features seem to be limited to the 3D universe view and a crude print function (which is really odd considering that Andrew Ko at CMU has used Alice as a foundation for a ground-breaking debugging tool).
Now, even if the aforementioned features exist, they're not much use if you can't find them! This is a shame, as the whole 3D environment thing seems to be helpful in motivating students and concretising program behaviour. However, with the limitations above, Alice is only really good for toy examples.
One of my older machines has a 24x CD-ROM drive with an odd tendency to refuse to stay closed (no matter how I close the tray, it pops out again after a few seconds). The solution to that problem turned out to be to forcefully hold the tray shut for about half a second when it tries to eject. After that, it closes just fine and reads CDs without any trouble for quite a while.
That drive replaced a 4x one with a tendency to spin down and cause a timeout before it managed to get started again (especially on CD-R disks; it didn't read CD-RW) which resulted in a rather interesting Linux installation process: boot machine; press [Pause] while CD drive spins up and reads CD; unpause to allow boot sequence to start; during installation process, every time CD activity stops, switch to a command prompt and start copying random files from CD to/dev/null to keep the drive from spinning down.
Personally, I use the KDE 4 modifier keys layout; almost all the window manager and other KDE shortcuts that used to be Alt-something and conflict with applications are Win-something instead. Having an extra modifier key that few applications dare to use is great for window managers.
That's why you go through and apply weights to the various things you're scoring. "Consistent indentation" might be worth, oh, 3 points ( 3 = consistent indentation, 2 = minor lapses, 1 = made an effort, 0 = randomness ), while "accomplishes the task" might be worth 30 points.
... Which is exactly the point I was trying to make (and pretty much the way I grade, too).
Finally, it's in the grader's best interest to look at readable -- read, well-formatted -- code. More time can be spent on figuring out where the student almost got it right. A grader's time is limited, wasting it on trying to parse ugly code isn't what the grader is being paid for. A student who tries to make a grader's life more difficult than it needs to be should reap what they sow.
Formatting is only a minor part of coding conventions. I'm not saying that descriptive variable names, sensible division into classes/functions and so on are unimportant; quite the opposite. Students who convert a simple problem into 700 lines of gratitious bit-shifting (for no apparent reason other than a desire to save a few dozen bytes of data space!) will only be told that their program doesn't work, I don't understand why and I don't care about finding out as long as it's unreadable (except in the unlikely case in which it works, of course). I can fix sloppy indentation in about five seconds (assuming I even see it in the first place!); figuring out a confusing design can take hours or even days and I don't have that sort of time.
I don't see any point in trusting students to indent properly; I prefer to reindent their code before reading it. If they've been indenting manually, the place where their program logic breaks due to a missing set of curly brackets (for example) is likely to be the place where their indentation is also wrong. The problematic students aren't going to follow coding conventions anyway, and student/assistant relations are certainly not going to get any better by imposing strict coding conventions.
Enforcing indentation rules manually becomes more or less obsolete once version management systems and/or editors with built-in formatting abilities become more prevalent. indent, for example, happily converts between brace placement styles and suchlike, too. Even though programs have been traditionally expressed as character streams, it may become more useful to work in terms of abstract syntax trees (visual programming systems have been doing something like this for ages, but have little mainstream support for many other reasons). In this case, indentation is an aspect of the editor, not the code.
Coding conventions can, in my view, be divided into fully automatable rules (whitespace, indentation, capitalisation, brace positioning, suchlike) and requirements for design knowledge to be visible in the code (descriptive naming, commenting, etc.). The former are the sort of thing that editors or some other program really should handle for us and probably will in the future (and, with some configuration, already do!); the latter need human input that can't be avoided without a complete rethink of the whole way we program. Which sort of skill do you think we as teachers should be concentrating on promoting?
You're missing the point entirely. The grading is supposed to evaluate a student's skills and provide feedback for his development, not evaluate whether he can follow an arbitrary set of instructions that are mostly subjective in origin to begin with that can be performed by a reasonably simple program.
As far as I can remember, I've only had one programming course where whitespace conventions were enforced and, even then, the effect on the grade was much less than the penalties mentioned here. Over here in Finland, a TA trying to punish students for using the wrong indentation would almost certainly find himself swamped by students' complaints irrespective of whether the grading scheme were known before submission or not. This, of course, doesn't prevent me from being a stickler for correct indentation, but it makes it unreasonable for me to demand it of others.
Giving the students some of the tests does decrease the chances of irrelevant errors; however, you run the risk of students writing programs to fit the tests instead of the specs; in other words, their mistakes are going to be ones that your tests don't find. At a minimum, I'd keep the more complex tests to myself.
Of course, it's possible to run the source code or some suitable intermediate form (Java bytecode is very nice for this sort of thing) through a program that checks for illegal constructs (for example, for or do/while loops in your recursion example) and checks for adherence to coding conventions. Writing this program is left as an exercise for the student... I mean, assistant.
As I already mentioned, a good sandbox (OS or VM level) should handle the security aspects.
The real reason to read the code is that testing doesn't (usually) tell you what the actual bug is, just its symptom(s). Unless you know this, you can't give proper feedback or grades.
Having formatting requirements is one thing; punishing students equally or worse for (for example) indenting incorrectly and writing broken code is another. In my opinion, errors that can be fixed by a well-known script or program (e.g. indent) with no harmful effect on the functioning of a program should under no circumstances be conflated with anything that leads to incorrect behaviour of the program. Both my superiors and my students agree with this sentiment.
The last thing we need in the software business is an influx of programmers with obsessive attention to formatting detail who don't really care whether their code works!
Fully automatic grading breaks down quite badly if there is a possibility of students making small mistakes that cause large amounts of tests to fail (or, conversely, big mistakes that cause few tests to fail); in this sort of scenario (and concurrent programming is one of them), you really want a human to assign the final grade by identifying the underlying mistake/bug instead of the symptom/failure. However, having automated tests that are designed to expose common problems is a good thing.
Of course, if you like giving out failing grades for messing up input or output formats while letting blatant errors in mutual exclusion pass by with minimal impact, you can do automated grading based directly on test results. Trying to make the computer deduce the actual mistake from the test results, on the other hand, can be quite painful (this is essentially automated debugging, which may be possible to some extent; see Andreas Zeller's work on Delta Debugging).
Considering that this is a Java course we're talking about, setting up a sandbox is easy and effective; use a policy file with only the permissions the student's code needs (for simple programs that don't need file I/O, a blank policy file could even be enough). The result should be roughly as safe as running Java applets on the net and for the same reasons.
Pörsønøli, ai fiil dvät inglish häs lost träk ov its ruuts änd shud ri'introdjuus dvø gud ould nors käräktørs. DVis wud, in mai øpinjøn, meik it mutsh iisiør tu lörn tu prønaons før non-neitiv spiikørs. Ät dvø seim taim, wii cud duu sumðing øbaot ool dviis sili kombineishuns ov konsønønts bai stiiling sum letørs frøm iistørn Juurøupiiøn längwidshis.
DVø bladi Slashcode mesd ap mai juus ov speshøl käräktørs, sou ai häd tu sabstitjuut sam daigrafs. Ai houp dvät dasnt bovør juu tuu matsh.
In many European countries' postal systems, sending packages or letters abroad is not much more expensive than domestic delivery. In some cases, sending a package from another country may even be cheaper.
For example, in Finland, electronics store Verkkokauppa avoids a similar tax on storage media (currently on blank CDs, DVDs and media players (e.g. DVB and MP3 players with built-in storage)) by selling these products through their Estonian subsidiary, who simply mails them to the customer from Tallinn.
If your camera puts EXIF metadata in its JPEG files, you could use something like the following to extract the correct dates from the files and change the file system's date stamp (requires exif, tested on v0.6.13-2 on SuSE 10.0):
for a in *.JPG; do touch -t `exif -m -t "Date and Time (original)" $a | sed "s/://;s/://;s///;s/://;s/:/./"` $a; ls -l $a; done
I wrote this to fix modification dates corrupted by using HP PhotoSmart software on Windows XP (surprisingly, it worked fine under Windows Me).
Actually, cracking a program you've acquired legally for personal use is (as far as I can tell by reading the copyright law, paragraph 25 j) explicitly permitted by law in Finland, and I've never heard of a EULA sticking in court (especially if the hypothetical cat or whatever clicks "I accept" in the installer instead of the user); clicking a button in a program you've already paid for in order to use it in response to an illegible tirade in a foreign language is hardly a binding contract. I believe several other European countries have similar laws.
Seriously, making it harder for legitimate users to use the software they've paid for is just plain silly, and I'm surprised that US law actually gives these "copy protection measures" legal protection.
Am I the only one who has wasted the last 15 years of my life for a sequel to Maniac Mansion and The Secret of Monkey Island?
Have I misunderstood something, or have you missed Day of the Tentacle, Monkey Island 2: LeChuck's Revenge, the Curse of Monkey Island and Escape from Monkey Island? See, for example, Wikipedia's article on LucasArts adventure games.
Aren't DVD subtitles stored as images anyway, making font availability and coding irrelevant? A quick search turns up a page describing the DVD subtitle format.
Actually, BMW stands for "Bayerische Motoren Werke", which translates as "Bavarian Motor Works", which is a pretty accurate description of what BMW is.
Acronyms and abbreviations, of course, only make sense if you know what they're short for.
Having grown up with a CPC 464 myself, I'd like to clarify a few details. The Amstrad CPC has the same CPU as the Spectrum (and the same sound chip as the Spectrum 128 and later), so converting Spectrum games was often simply a matter of kludging the graphics to use the Amstrad's medium resolution (320x200) 4-colour mode (from the system's 27 colour palette; RGB off/half/on) instead of the Spectrum's awful 1-bit display with colours selected per character block and hacking the rest of the I/O a bit. Naturally, the result was usually slow and even uglier than the Spectrum original. Many other games ran in low resolution (160x200, 16 colours) instead, and some cool ones (e.g. Short Circuit) used mixed resolutions (status bar in 4-colour medium res, gameplay in 16-colour low res). Original games and games ported from the C64 or directly from the arcade tended to be a lot better than Speccy ports. Unfortunately, the C64 and Spectrum, and later on the Amiga, pretty much dominated the market (especially here in Finland), leaving us Amstrad users with very little software that used the machine to its full potential.
It was also a shame that the floppy discs (sic) were so expensive that a lot of games were on tape (that 3" floppy drive was _fast_, especially compared to the slower-than-tape Commodore drives).
I learned BASIC programming from that thing's manual (which contained extensive BASIC tutorials). I remember thinking that C64 BASIC was quite broken as you had to use POKE for almost everything interesting; the CPC BASIC had decent sound and graphics support.
I did some checking. Apparently, ALSA does lots of stuff (including dmix) in user space as part of the ALSA library, meaning that using the OSS devices bypasses dmix unless you do some funky stuff to override the system calls to send the data to the OSS library (aoss).
I wonder if it would be possible to change the OSS emulation devices to feed data into the ALSA library instead of directly into the kernel-level sound drivers. This would allow multiple open of OSS/dev/dsp just like on hardware mixed cards.
The Audigy may have hardware mixing, but if multiple programs can coexist on a sound card with hardware mixing, software mixing can be used in the driver to achieve the same thing. dmix in ALSA does this, more or less.
However, I will concede that the equivalent experiment failed on a machine with an integrated AC97-compliant Intel chip (RealPlayer blocked everything else). There is still room for improvement. However, the software and API used by the software do not, in my estimation, need to be rewritten.
Slashdot Mirror
How about KPDF? Based on the xpdf engine, integrates nicely with KDE, more compatible than Acrobat Reader 7 in my experience (either that, or my students use really weird PDF generators).
What level of class was this? Based on what I've heard from my colleagues, freshman programming courses at our university have had the most (detected) dishonest activities, with 12 % of students being caught cheating at most (Basics of Programming ten years ago, using Scheme). On third-year or later courses, 3 % (as in the concurrent programming course I TAed) is considered quite a lot, and to find those I had to look for equivalent structures and small editing mishaps (the Chinese student submitting code with Danish comments ended up exposing five of his compatriots who edited the same code found on the web when I used an in-house JPlag derivative to check for students copying each other's code).
- Using a variable as an array index instead of a constant causes the interpreter to fail mysteriously with a stack dump. Good luck using arrays for anything interesting.
- There doesn't seem to be any way for a program to dynamically create objects; you have to statically define them at startup.
- Debugging features seem to be limited to the 3D universe view and a crude print function (which is really odd considering that Andrew Ko at CMU has used Alice as a foundation for a ground-breaking debugging tool).
Now, even if the aforementioned features exist, they're not much use if you can't find them! This is a shame, as the whole 3D environment thing seems to be helpful in motivating students and concretising program behaviour. However, with the limitations above, Alice is only really good for toy examples.One of my older machines has a 24x CD-ROM drive with an odd tendency to refuse to stay closed (no matter how I close the tray, it pops out again after a few seconds). The solution to that problem turned out to be to forcefully hold the tray shut for about half a second when it tries to eject. After that, it closes just fine and reads CDs without any trouble for quite a while.
/dev/null to keep the drive from spinning down.
That drive replaced a 4x one with a tendency to spin down and cause a timeout before it managed to get started again (especially on CD-R disks; it didn't read CD-RW) which resulted in a rather interesting Linux installation process: boot machine; press [Pause] while CD drive spins up and reads CD; unpause to allow boot sequence to start; during installation process, every time CD activity stops, switch to a command prompt and start copying random files from CD to
Personally, I use the KDE 4 modifier keys layout; almost all the window manager and other KDE shortcuts that used to be Alt-something and conflict with applications are Win-something instead. Having an extra modifier key that few applications dare to use is great for window managers.
Formatting is only a minor part of coding conventions. I'm not saying that descriptive variable names, sensible division into classes/functions and so on are unimportant; quite the opposite. Students who convert a simple problem into 700 lines of gratitious bit-shifting (for no apparent reason other than a desire to save a few dozen bytes of data space!) will only be told that their program doesn't work, I don't understand why and I don't care about finding out as long as it's unreadable (except in the unlikely case in which it works, of course). I can fix sloppy indentation in about five seconds (assuming I even see it in the first place!); figuring out a confusing design can take hours or even days and I don't have that sort of time.
I don't see any point in trusting students to indent properly; I prefer to reindent their code before reading it. If they've been indenting manually, the place where their program logic breaks due to a missing set of curly brackets (for example) is likely to be the place where their indentation is also wrong. The problematic students aren't going to follow coding conventions anyway, and student/assistant relations are certainly not going to get any better by imposing strict coding conventions.
Enforcing indentation rules manually becomes more or less obsolete once version management systems and/or editors with built-in formatting abilities become more prevalent. indent, for example, happily converts between brace placement styles and suchlike, too. Even though programs have been traditionally expressed as character streams, it may become more useful to work in terms of abstract syntax trees (visual programming systems have been doing something like this for ages, but have little mainstream support for many other reasons). In this case, indentation is an aspect of the editor, not the code.
Coding conventions can, in my view, be divided into fully automatable rules (whitespace, indentation, capitalisation, brace positioning, suchlike) and requirements for design knowledge to be visible in the code (descriptive naming, commenting, etc.). The former are the sort of thing that editors or some other program really should handle for us and probably will in the future (and, with some configuration, already do!); the latter need human input that can't be avoided without a complete rethink of the whole way we program. Which sort of skill do you think we as teachers should be concentrating on promoting?
You're missing the point entirely. The grading is supposed to evaluate a student's skills and provide feedback for his development, not evaluate whether he can follow an arbitrary set of instructions that are mostly subjective in origin to begin with that can be performed by a reasonably simple program.
As far as I can remember, I've only had one programming course where whitespace conventions were enforced and, even then, the effect on the grade was much less than the penalties mentioned here. Over here in Finland, a TA trying to punish students for using the wrong indentation would almost certainly find himself swamped by students' complaints irrespective of whether the grading scheme were known before submission or not. This, of course, doesn't prevent me from being a stickler for correct indentation, but it makes it unreasonable for me to demand it of others.
Giving the students some of the tests does decrease the chances of irrelevant errors; however, you run the risk of students writing programs to fit the tests instead of the specs; in other words, their mistakes are going to be ones that your tests don't find. At a minimum, I'd keep the more complex tests to myself.
Of course, it's possible to run the source code or some suitable intermediate form (Java bytecode is very nice for this sort of thing) through a program that checks for illegal constructs (for example, for or do/while loops in your recursion example) and checks for adherence to coding conventions. Writing this program is left as an exercise for the student... I mean, assistant.
As I already mentioned, a good sandbox (OS or VM level) should handle the security aspects.
The real reason to read the code is that testing doesn't (usually) tell you what the actual bug is, just its symptom(s). Unless you know this, you can't give proper feedback or grades.
Having formatting requirements is one thing; punishing students equally or worse for (for example) indenting incorrectly and writing broken code is another. In my opinion, errors that can be fixed by a well-known script or program (e.g. indent) with no harmful effect on the functioning of a program should under no circumstances be conflated with anything that leads to incorrect behaviour of the program. Both my superiors and my students agree with this sentiment.
The last thing we need in the software business is an influx of programmers with obsessive attention to formatting detail who don't really care whether their code works!
Fully automatic grading breaks down quite badly if there is a possibility of students making small mistakes that cause large amounts of tests to fail (or, conversely, big mistakes that cause few tests to fail); in this sort of scenario (and concurrent programming is one of them), you really want a human to assign the final grade by identifying the underlying mistake/bug instead of the symptom/failure. However, having automated tests that are designed to expose common problems is a good thing.
Of course, if you like giving out failing grades for messing up input or output formats while letting blatant errors in mutual exclusion pass by with minimal impact, you can do automated grading based directly on test results. Trying to make the computer deduce the actual mistake from the test results, on the other hand, can be quite painful (this is essentially automated debugging, which may be possible to some extent; see Andreas Zeller's work on Delta Debugging).
Considering that this is a Java course we're talking about, setting up a sandbox is easy and effective; use a policy file with only the permissions the student's code needs (for simple programs that don't need file I/O, a blank policy file could even be enough). The result should be roughly as safe as running Java applets on the net and for the same reasons.
Pörsønøli, ai fiil dvät inglish häs lost träk ov its ruuts änd shud ri'introdjuus dvø gud ould nors käräktørs. DVis wud, in mai øpinjøn, meik it mutsh iisiør tu lörn tu prønaons før non-neitiv spiikørs. Ät dvø seim taim, wii cud duu sumðing øbaot ool dviis sili kombineishuns ov konsønønts bai stiiling sum letørs frøm iistørn Juurøupiiøn längwidshis.
DVø bladi Slashcode mesd ap mai juus ov speshøl käräktørs, sou ai häd tu sabstitjuut sam daigrafs. Ai houp dvät dasnt bovør juu tuu matsh.
In many European countries' postal systems, sending packages or letters abroad is not much more expensive than domestic delivery. In some cases, sending a package from another country may even be cheaper.
For example, in Finland, electronics store Verkkokauppa avoids a similar tax on storage media (currently on blank CDs, DVDs and media players (e.g. DVB and MP3 players with built-in storage)) by selling these products through their Estonian subsidiary, who simply mails them to the customer from Tallinn.
If your camera puts EXIF metadata in its JPEG files, you could use something like the following to extract the correct dates from the files and change the file system's date stamp (requires exif, tested on v0.6.13-2 on SuSE 10.0):
I wrote this to fix modification dates corrupted by using HP PhotoSmart software on Windows XP (surprisingly, it worked fine under Windows Me).
Actually, cracking a program you've acquired legally for personal use is (as far as I can tell by reading the copyright law, paragraph 25 j) explicitly permitted by law in Finland, and I've never heard of a EULA sticking in court (especially if the hypothetical cat or whatever clicks "I accept" in the installer instead of the user); clicking a button in a program you've already paid for in order to use it in response to an illegible tirade in a foreign language is hardly a binding contract. I believe several other European countries have similar laws.
Seriously, making it harder for legitimate users to use the software they've paid for is just plain silly, and I'm surprised that US law actually gives these "copy protection measures" legal protection.
Am I the only one who has wasted the last 15 years of my life for a sequel to Maniac Mansion and The Secret of Monkey Island?
Have I misunderstood something, or have you missed Day of the Tentacle, Monkey Island 2: LeChuck's Revenge, the Curse of Monkey Island and Escape from Monkey Island? See, for example, Wikipedia's article on LucasArts adventure games.
Aren't DVD subtitles stored as images anyway, making font availability and coding irrelevant? A quick search turns up a page describing the DVD subtitle format.
Actually, BMW stands for "Bayerische Motoren Werke", which translates as "Bavarian Motor Works", which is a pretty accurate description of what BMW is.
Acronyms and abbreviations, of course, only make sense if you know what they're short for.
In this sort of situation, you should remember Rules of Acquisition 112 and 113.
Having grown up with a CPC 464 myself, I'd like to clarify a few details. The Amstrad CPC has the same CPU as the Spectrum (and the same sound chip as the Spectrum 128 and later), so converting Spectrum games was often simply a matter of kludging the graphics to use the Amstrad's medium resolution (320x200) 4-colour mode (from the system's 27 colour palette; RGB off/half/on) instead of the Spectrum's awful 1-bit display with colours selected per character block and hacking the rest of the I/O a bit. Naturally, the result was usually slow and even uglier than the Spectrum original. Many other games ran in low resolution (160x200, 16 colours) instead, and some cool ones (e.g. Short Circuit) used mixed resolutions (status bar in 4-colour medium res, gameplay in 16-colour low res). Original games and games ported from the C64 or directly from the arcade tended to be a lot better than Speccy ports. Unfortunately, the C64 and Spectrum, and later on the Amiga, pretty much dominated the market (especially here in Finland), leaving us Amstrad users with very little software that used the machine to its full potential.
It was also a shame that the floppy discs (sic) were so expensive that a lot of games were on tape (that 3" floppy drive was _fast_, especially compared to the slower-than-tape Commodore drives).
I learned BASIC programming from that thing's manual (which contained extensive BASIC tutorials). I remember thinking that C64 BASIC was quite broken as you had to use POKE for almost everything interesting; the CPC BASIC had decent sound and graphics support.
FYI, MPlayer plays it on my system: MPlayer-1.0pre7-pm.3 from PackMan on SuSE 10.0.
I did some checking. Apparently, ALSA does lots of stuff (including dmix) in user space as part of the ALSA library, meaning that using the OSS devices bypasses dmix unless you do some funky stuff to override the system calls to send the data to the OSS library (aoss).
/dev/dsp just like on hardware mixed cards.
I wonder if it would be possible to change the OSS emulation devices to feed data into the ALSA library instead of directly into the kernel-level sound drivers. This would allow multiple open of OSS
The Audigy may have hardware mixing, but if multiple programs can coexist on a sound card with hardware mixing, software mixing can be used in the driver to achieve the same thing. dmix in ALSA does this, more or less.
However, I will concede that the equivalent experiment failed on a machine with an integrated AC97-compliant Intel chip (RealPlayer blocked everything else). There is still room for improvement. However, the software and API used by the software do not, in my estimation, need to be rewritten.