Vim has a feature which allows you to jump from the use of a C function to the declaration of that function and back. It's really quite handy when your source base is as big as ours. I don't use vim, though. During C code reviews, my reviewer inevitably asks me to jump into a function, and when I can't, he shakes his head sadly.

With NetBeans 4.0 and ALT-G|K|L, I can now jump back and forth in Java. (I know ALT-G has been there for a while.) There is, however, no module plugin for NetBeans 4.0 for C. (I currently use 4.0 for Java and 3.6 with IBM's OpenVMS C module plugin for C.) Is it so wrong that I just want to jump back and forth like all the other kids? Won't someone please code me a C editor for NetBeans that is as cool as the Java editor? I don't even need built-in compiler or debugger support. Just an editor, please. With back and forth jumping. And code folding. And maybe some refactoring. Thank you. I'll be waiting.

Before I start, let me make clear that I live in Regensburg in Bavaria. My experiences may not be consistent with the experiences of other Americans in other parts of Germany. Regensburg is rather provincial, and Bavaria is traditionally agrarian, so I've gotten the "deep south" German experience.

When I first moved here, I was told that when dealing with people, it will be obvious that I'm not a native speaker, and that I should immediately announce myself as an American. I was told that as a rule of thumb Germans don't like foreigners, except for Americans, who are the only good foreigners. So, while calling about apartments and used cars and while trying to gets the reems of paperwork done so I could be an official German resident, I always introduced myself as an American. I had zero problems.

After a couple of months, my German improved, and I didn't feel quite so much like a fish out of water. I stopped announcing myself as American. I still had zero problems. To this day, I've yet to have any actual ill sentiments tossed my way just because I'm American. I get picked on at the office, but it's done in fun. And I pick back.

Having been here a while and watched Germans' reaction to German and international politics, I have developed a theory. In my experience, Germans think of politics as something over which they have no control. It's people they didn't elect doing things of which they don't approve, until someone else gets elected to do something different but equally as bad. Pretty much the exact opposite of "for the people, by the people." Fortunately for me, that philosophy extends to other countries' governments as well. Folks here may disapprove of Iraq. They may not like Bush. They all clearly understand, though, that none of that has anything to do with me. They assume I'm a victim of my government, just like they feel they are of theirs.

I'm not even going to attempt to address how Germans tend to feel about Bush and Iraq and why. It's a complicated and potentially very heated debate.

We're planning on going. At a minimum there's supposed to be BBQ and beer. That's enough for me.

So, as I said, I'm assuming that the job has already been submitted, the scheduler has decided where to put it, and the qmaster has sent it off. We'll start with the execution order arriving at the execution daemon. Also, I'm assuming non-PE jobs. For PE jobs, the process is the same, except that there are a few additional steps.

After the execution daemon starts up, it sits in a loop, reading incoming orders and dispatching them appropriately. This is the first hurdle for understanding the code. The loop in main() in execd.c calls dispatch() in dispatcher.c. dispatch() reads incoming orders and uses the dispatch_table in execd.c to decide how to handle them. If the incoming order is a TAG_JOB_EXECUTION order, execd_job_exec() in execd_job_exec.c gets called, which unpacks the job from the order and adds it to the master job list.

Now we come to the second hurdle. In cycles where there are no incoming orders, the dispatch_table directs dispatch() to run execd_ck_to_do() in execd_ck_to_do.c. execd_ck_to_do() runs through some basic house keeping tasks. Among those tasks is checking whether there are idle jobs waiting to be run. If so, execd_ck_to_do() calls sge_start_jobs() in execd_ck_to_do.c, which calls exec_job_or_task() in execd_ck_to_do.c, which calls sge_exec_job() in exec_job.c.

Third hurdle. sge_exec_job() writes out two very important files. The first contains all of the environment variables that should be set for the job and their values. The second contains all of the configuration information the shepherd needs to know to execute the job. It then forks and execs the shepherd.

The shepherd main() function in shepherd.c reads in the configuration file and uses the contents to initialize itself. It then runs the prolog, if there is one, with do_prolog() in shepherd.c. If that succeeds, it execs the job by calling start_child() in shepherd.c. After start_child() returns, it runs do_epilog() in shepherd.c.

start_child() does a little setup and then forks and waits for the child to exit. After the child exits, start_child() cleans up after the job, including writing out the usage report. It's worth noting that do_prolog() and do_epilog() also use start_child() for running the prolog and epilog scripts, respectively.

The child of start_child() runs son() in builtin_starter.c. son() sets up the job's environment, including setting the variables in the environment file (done by sge_set_environment() in builtin_starter.c), redirecting the stdin, stdout, and stderr streams, and changing to the appropriate user. It then calls start_command() in builtin_starter.c. start_command() prepares the argument list for the job and then execs the shell to run the job or execs the job itself if the job is binary.

When the job ends, start_child() does some clean up, and when it finishes, the shepherd exits. The execd is notified via a SIGCHLD that the shepherd exited. The job then gets added to the list of finished jobs needing to be reaped. The next time that the execd's main loop calls execd_ck_to_do(), the job will be reaped, and the qmaster will be notified of the job's status.

In the article, he discusses his experiences using SWT for real development. His findings are essentially that SWT is not the widget panacea that it is made out to be. Developers who are interested in the more useful technology, as opposed to the "cool" technology, should just stick with Swing. It's solid; it's JCP-approved; it's a known-evil; it's 6 years further along in the development cycle. Sounds good to me.

The Danube River and the "Stone Bridge", built in the 1200's

The Danube River, the other end of the "Stone Bridge," and the cathedral (also from the 1200's)

A view down the "Stone Bridge" towards the cathedral

The story goes that the architect of the Stone Bridge and the architect of the cathedral bet on whose project would be completed first. Not one to lose, the architect of the Stone Bridge made a pact with the Devil, that if his bridge was completed before the cathedral, the first three souls to cross the bridge would belong to the Devil. (I think we made a similar pact about releasing Grid Engine 6.0...)

With the Devil's supernatural help, the bridge was completed first. The bridge's architect, however, being a clever lad, decided to cheat the devil. Instead of the heads of state the devil had hoped would be the first to cross the bridge, the architect sent two chickens and a dog. Outraged, the devil grabbed the critters and dove over the side of the bridge. His anger was so intense that the water still swirls around the spot where he dove in, even to this day!

Not at all happy about being cheated, the devil tried to destroy the bridge. He squeezed under it, with his feet on the river bed and his back against the bridge, and pushed up with all his might. The bridge bowed upwards, but it held. He tried again and little further down. The bridge bowed upwards again but still held. He tried several more times, each time creating an arch, but the bridge still held. Eventually, he gave up and fled back to the underworld, but the arches of the bridge remain to this day as a lasting reminder of the Devil's anger.

At least that's what the tour guide said.

To start with, let's review the two goals for using a knife in the kitchen, in order of priority:

1. Don't cut off anything that won't grow back.
2. Make the big bits into little bits

Your primary goal in any cooking adventure should be to not cut off any of your fingers or toes. An occasional grated knuckle is OK, but anything that requires stiches or a tetnis shot is best avoided. To that end, there are a couple of simple safety tips I can offer.

• Keep your knives sharp! I know that sounds like it would make them more dangerous, but it doesn't. The way to hurt yourself with a knife is when you lose control of it. You lose control of your knife when you apply too much force to it and what you're cutting suddenly gives way. If your knife is nice and sharp, you won't need so much pressure and hence are less likely to lose control.
• If you find yourself putting your weight behind the knife, stop. See the previous point. Find another way to do it.
• Always curl the fingers of the hand holding the vegetable (or whatever). Pretend you're making fun of your grandmother's arthritis. If your fingertips are curled under, you can't cut them off. When using a knife, I regularly nick my fingernails. If I didn't have my fingers curled, I would be slicing the tops of my fingers.
• Use the right knife for the job. Coring an apple with a chef's knife is bad. Dicing with a paring knife is bad. Slicing bread with cooking shears is bad. Using a Dremel in the kitchen, except in certain emergencies, is bad.

Another important part of knife work is having an appropriate cutting surface. The counter top is not it. You really will be less than happy when you have to replace the counter top. They're not cut-proof, and they're not cheap. (There are some that are cut-proof, and obviously what I just said doesn't apply to those countertops.)

Not every cutting board is created equal. I have three. One is a soft plastic, one is hard plastic, and one is wooden. I don't like the hard plastic one because it seems to dull my knives quicker. The wooden one is great for the knives, but is a real pain to clean, and it scars easily. The soft plastic one is my favorite. (By soft plastic, I don't mean that it's pliable. The best way I can come up with to describe it is this. If I hit the knife against the hard plastic board, it goes "clack!" If I hit the knife against the soft plastic board, it goes "thud." Got it?)

On to the actual cutting. You will encounter a variety of cuts requested in various recipes. Here's a list of the most popular with quick descriptions. For links to demo videos, see FoodNetwork's Cooking Basics: Knife Skills.

• Chop -- this is the classic "making one big thing into lots of little things"
• Slice -- not surprisingly used to make slices; think tomatoes on a hamburger
• Dice -- a fine chop
• Mince -- a very fine chop, usually reserved for onions, garlic, and shallots
• Chiffonade -- making thin strips out of leafy herbs and veggies like basil

That's it for now. I'm off to the flea market. Next time we'll talk about how to tackle specific veggies.

1. Book tickets to the Alhambra in advance. If you've never been to the Alhambra before, or if your guide book doesn't explain it, ticketing at the Alhanbra can be a mystery. Let me shed some light on it.

   First off, there is a free admission part and a paid admission part. The free admission is really just the main grounds and the palace of Charles V. The paid admission includes the Nasrid palace, the Generalife gardens, and the old castle. They allow around 7000 people into the paid admission part a day. Of those, around 1500 are sold at the walk-up ticket counter. The rest are booked in advance, either over the Internet or through BBVA. If you're already in Spain or Portugal, just go to any BBVA. If you're still home, use the Internet. Do not attempt to buy tickets when you get there. There's a chance you'll succeed, but if you don't, you'll be very sorry. Trust me. I know from experience. This is why Granada showed up twice on our itinerary.

   What you're actually reserving when you buy tickets is your time to view the Nasrid palace. You will be assigned a 30 minute window, during which you must show up at the palace entrance. If you miss your timeslot, you're out of luck. Once you get in, you can take as long as you want. If your timeslot is in the morning, you also get admission to the Generalife and castle until 2pm. If your timeslot is in the evening, you get admission to the Generalife and castle after 2pm.

2. When driving in Spain, think USA, not Europe. I found that the roads and drivers in Spain had much more in common with those in the US than what I'm used to in Europe. The cities are relatively far apart with next to nothing between them. The roads a decent, but the speed limit is 120kph (~70mph). That's OK, though, because everyone ignores the speed limits.

   The city steets are also more like the city streets in the USA than in the rest of Europe. At first we thought we were just incompetent. Then we finally proved in Sevilla that city streets in Spain are simply impossible to navigate, even with a complete and accurate map. Even with several. If you're ever tried to bypass the Chicago tollway by detouring through downtown Chicago while the roads are under construction, you're ready for driving in cities in Spain. My advice is to pick a hotel on the edge of the city and take the bus to the center. We did that in Granada and Sevilla, and it worked beautifully.

3. Eat on the road. We loved absolutely every roadside greasy spoon we stopped at. Each one has character. They all have good food. Plus, with tapas (snack sized portions), you can get enough variety that you're sure to find something you like.

4. TravelOverland "fly and drive" deals can be really sweet. We got two round trip flights on LTU and a 9-day car rental from Centauro for 488 Euros, or around $650.

5. Ask the hotel staff for restaurant recommendations. We had a 100% success rate with that, even in Faro where there is little to recommend that isn't hopelessly touristy. The folks working in the hotels will usually tell you where they would eat.

6. My personal opinion is that you should not plan a trip to Spain for a beach vacation. They problem is not the Spanish beaches. They're great. The problem is the ridiculous quantity of tourists that flood the place as soon as it gets warm enough. We were there before the tourist rush, which by definition was before it was warm enough for a proper beach vacation. We had a great time exploring Spain, but we spent less than an hour in the course of 9 days on the beach.

Another first for me was today when I went to the grocery store. I saw a product that I often buy, offered in a smaller container. Much to my own surprise, I was excited and bought one. I have never before been excited about a smaller container. I was always king of buying the largest container I could find to save a couple of cents in the long run.

The first sign of my assimilation was the last time I was in the US. I parked on the second floor of a parking garage and was shocked and dismayed when I walked down one flight of stairs and found myself on the ground floor. (In Europe, floors are generally numbered as the nth floor above the ground floor. In order words, what Americans call the second floor is the first floor here. What Americans call the first floor is the ground floor here.)

Ich glaub' schon, daß ich fast Deutscher bin...

Further evidence: I was walking past a beer garden last weekend, and the smell of the beer reminded that spring is finally here. When "nice weather" implies "beer," you know you're in Germany.

Fortunately, it's fixed in Grid Engine 6.0u3. However, since we can't just make large behavioral changes in an update release without warning, the fix is not enabled by default. Instead, we introduced two new execution daemon parameters to control inheritance behavior.

The first one is SET_LIB_PATH. By default, it is false. When false, Grid Engine does not set the library path (LD_LIBRARY_PATH, LIB_PATH, et al.) for executing jobs. If true, Grid Engine will add the Grid Engine shared library directory to all jobs' library paths. Since the shared library directory is usually NFS mounted, having it in the library path can be a performance problem.

The second one is INHERIT_ENV. By default, it is true. When true, all jobs will inherit the environment of the shell which started the execution daemon on which they are running. When false, they don't. This parameter is the answer to the question from the mailing list. (It's documented in the man pages and the 6.0u3 release notes, but I thought it wouldn't hurt to have it here too.) With 6.1, this parameter will very likely go away, and the default behavior will be to not inherit the shell's environment. In reality, this is a bug and should have been fixed directly, but that would have been too big of a change for an update release.

To set these parameters, use qconf -mconf, and edit the "execd_params" line. To set INHERIT_ENV to false, it would look like this:

eomer:/home/dant 15 % source /scratch4/dant/sge6u4/default/common/settings.csh
eomer:/home/dant 16 % qconf -mconf
[vi pops up]
...
qmaster_params                  none
execd_params                    INHERIT_ENV=false
reporting_params                accounting=true reporting=false \
...
[:wq]
"/var/tmp/28657-qvUOwP" 46 lines, 1723 characters
dant@eomer modified "global" in configuration list

eomer:/home/dant 17 %

I have been asked by a couple of people how to get the Java^TM language binding API without the Grid Engine SPI built in. Here's how:

1. Download the Grid Engine 6.0u4 source. Really, you only need the gridengine/source/classes directory. If you're using CVS, you can get just the classes directory like this:

   cvs -d :pserver:guest@cvs.sunsource.net:/cvs checkout gridengine/source/classes

2. Once you have the source, go to the classes directory and run:

   ant api

   Ant will build a file called drmaa-api.jar in the gridengine/source/CLASSES directory. That jar file will contain all of the API classes and none of the SPI classes.

   Alternatively, if you have the complete source tree, you can go to the gridengine/source directory and run:

   aimk -only-java api

   which will do the exact same thing.

At some point (probably after 6.0u4 releases), the drmaa-api.jar file will be made available from the DRMAA working group's web site. Until then, building it as described above is the only way to get it.

The only reasonable explanation I can see is the latent World War II propoganda to which we, as Americans, get exposed, from the black and white war time movies to the Bugs Bunny cartoons. There was a time when it was very important to make a clear distinction between "us" and "them," and the evil-doing "them" were called "Germans."

Am I the only one suffering from this disorder? Do Russians feel the same way about labeling someone "an American?"

This is the first official draft of the tutorial. I have until the 20th of May to get three independent reviews of it. Of course, I'd like to have as many reviews as possible.

If you've always wanted to learn how to use the DRMAA Java^TM language binding, but never got around to it, this is your chance. Please, go download the lab and give it a try. It's called "DRMAA Tutorial" in the file list. What I need from each reviewer, aside from a check for technical accuracy, is the following:

• Rate the quality of the lab (1-10; 1 is best)
• How challenging is the lab? (beginning, intermediate, or advanced)
• What is not clearly enough explained?
• How long did each section take you?
• What can I improve?
• Other comments

Thanks!