the body of a very slow loop
Example A: Pointless application of present progressive tense.
We would appreciate it if you would visit our website and fill out the proper information that we are needing to keep you as an eBay member.
Uhh, yeah. You almost got me.
Example B: Use of uncommon / incorrect adverb.
One of our Customer Service employees has already tryed to telephonically reach you.
It would actually have been more convincing had it said “telepathically”.
I’m very sorry to hear that John Vlissides, GoF member and Software Engineering luminary, passed away last week after a long illness.
I had the pleasure of learning from John at OOPSLA 2004 in Vancouver. Like all great teachers, he could make the complicated apear obvious. (My notes on his lecture are here.)
I consider myself lucky to have met him.
So I’ve begun to learn Lisp, and I’ve been quite pleased by the abundance of free (as in beer) resources.
The full-texts to the books Practical Common Lisp and On-Lisp (by Peter Seibel and Paul Graham, respectively) are available on the web.
You can also take MIT’s 6.001 course online. This is an introductory CS class which is based on the legendary text Structure and Interpretation of Computer Programs. The SICP site contains the full-text of the book, sample programming assignments, and a complete set of videotaped lectures for the course (text, lectures).
The internet is freaking amazing. 10 years ago, my less-than-stellar grades precluded any possiblity of ever viewing an MIT lecture.
(SICP lectures found via LtU)
Update: There’s a much more complete list of freely available Lisp resources here.
(Thanks again, LtU)
When you call an 800 number these days, chances are pretty good you’ll get an Interactive Voice Response (IVR) system. You know, those annoying automata that say, “For [insert thing you couldn't possibly give a crap about], press 1.” God, I hate those things. Back in August, I blogged about one potential way around them: calling the sales number.
But here’s something even better. It turns out that, on many of these systems, you can skip all the pre-recorded crap and get right to an actual human person. Of course, there’s a catch: you have to know the secret code.
Hah! The internet eats problems like this for breakfast.
Check out Paul English’s killer cheat-sheet, which contains the magic key sequences you can use to end-run around the automated phone systems for over 100 companies.
(Found via digg)
I’ve been learning Lisp recently (I’ll eventually post something about how and why) but, oddly enough, all this Lisping has got me thinking about C++.
So, without further ado, a higher-order function in C++:
#include <boost/lambda/lambda.hpp>
#include <boost/function.hpp>
#include <iostream>
using namespace std;
using namespace boost::lambda;
template< typename T >
boost::function foo( T n_ )
{
// Old code. Leaks memory.
//T *n = new T( n_ );
//return ( *n += _1 );
boost::shared_ptr pn( new T(n_) );
return ret< T& >( *constant(pn) ) += _1;
}
int main()
{
// start with one
boost::function accum = foo(1);
cout << accum(2) << endl;
cout << accum(10) << endl;
}
This blows my mind on so many levels, I don’t know where to start. The gist is that foo is a function which generates new functions (ok technically it generates functors, but if you squint, you can’t tell the difference).
Neat.
(Inspired by Paul Graham’s Revenge of the Nerds.)
Update: I originally declared n as a static local, but then I realized what this actually meant (all generated accumulators share n). The current code leaks, but at least it works for multiple accumulator functions. I’m still trying to figure out how to use a smart pointer to plug the leak.
Update: Thanks to Peter Dimov on boost-users, the code above now uses a boost::shared_ptr and is leak-free. For some reason, it won’t build with gcc 4.0.2.
Given a C or C++ program, can you write a script that will inline all the #includes, so that compiling its output is identical to compiling the program directly?
I call this ‘the flattening problem,” and it sounds much easier than it actually is. My first attempt, for example, was foiled by include guards.
To overcome infinite include loops, everyone’s first inclination is to remember which files are already included, and include them only once. This seems reasonable, but it assumes that no header file can usefully be included more than once, which is generally untrue. Instead, you need to keep track of defined preprocessor symbols (and their values), so that you can simply elide unreachable #includes. If you do this, you’re left with two problems:
__cplusplus and __FILE__, or external, via the compiler’s -D switch.#include statements can take preprocessor symbols as their arguments. There is a rather famous IOCCC winner, (vanschintz.c) that The combination of 1 and 2 means you may actually encounter include directives with externally-defined arguments. This makes the problem impossible, in the general case.
You can, however, get an approximate solution with some shortcuts. First, you can make assumptions about automatic preprocessor defines (for example, you assume that .cpp files implicitly define __cplusplus). Second, you must be willing to simply fail on any #include statement that takes an externally-defined preprocessor symbol as its parameter.
(Thanks to Weimin Chen, Wendy Thrash, and Jonathan Caves for their help on this one.)
The CNN.com video experience is optimized for Windows Media Player 9 or above. No Windows Media Player detected.
This is the message which greets Linux users who attempt to view CNN news streams. I guess optimized for is officially euphemistic technobabble for restricted to.
What’s next? Restrooms “optimized for customers only?”
Luckily, we can out-nerd these dopes:
mms: link from the plain-text .ASX file and feed it to MPlayerFeel free to add the --dumpstream switch to archive the stream. Indeed, feel very free.
Latest Comments
RSS