I recently had issues checking out an SVN repo. The problem went something like this:
adam@nynaeve:~$ svn co https://server/path
Password for ‘default’ GNOME keyring:
svn: OPTIONS of ‘https://server/path’: authorization failed: Could not authenticate to server: rejected Basic challenge (https://server)
This was a little puzzling, not least of which because I don’t use GNOME. The problem seems to be a bug, which the SVN guys say is a GNOME issue, and the GNOME guys say is an SVN issue. To make a long story short, the answer was to delete ~/.gnome2/keyrings/default.keyring. The GNOME keyring left me alone, SVN prompted for my credentials, and the day was saved.
On Linux, a file may be deleted (removed/unlinked) while a process has it open. When this happens, the file is essentially invisible to other processes, but it still takes on physical space on the drive. To find out how much space is taken up by these files, run:
sudo lsof | awk '/deleted/ {sum+=$7} END {print sum}'
lsof will list all open files. awk then searches for the deleted ones and sums up the file sizes (in bytes).
It turns out that you can use lsof and the /proc filesystem to recover deleted files, as long as some process has them open.
I recently worked on a project that involved heavy use of custom graphics. Specifically, lots of lines. The code was sufficiently important and complex that it needed to be unit tested. However, I had never unit tested drawing code before.
A simple strategy would be to paint to an image, then compare the result with a target image. However, this has a few disadvantages:
It’s impossible to tell if unnecessary graphics calls were made (outside the clipping region, for example).
Graphics may render slightly differently on different platforms.
This can tell you where the output image is wrong, but it does not automatically tell you which part of the test failed.
I decided to mock a Graphics object and check that various calls were correct. To avoid writing a lot of boilerplate code to keep track of color, line style, clipping, etc., I created a GraphicsProxy class, added a base field, and used Eclipse to generate methods that pass the call on to the delegate. (This would have been perfect for the Proxy class, but Graphics is an abstract class, not an interface. Poor foresight on the part of the original writers, but I digress.)
This proxy class is then subclassed to count calls to drawLine and drawPolyline, and to keep track of the line segments drawn. I also wrote a LineChecker class to compare the expected line segments with the actual line segments. This is slightly trickier than it might sound, because the segments may be drawn in a different order, and the endpoints of individual segments may be switched. All in all, a test method looks like this:
public void testPaint() {
BufferedImage image = new BufferedImage(200, 200, BufferedImage.TYPE_3BYTE_BGR);
Graphics2D imageG = image.createGraphics();
CountingGraphics g = new CountingGraphics(imageG);
// draw here
LineChecker c = new LineChecker();
c.require(19, 180, 19, 160);
c.require(19, 160, 39, 160);
c.require(159, 40, 159, 20);
c.require(159, 20, 179, 20);
c.check(g.lines);
}
I recently worked on a project that involved rendering images with the POV-Ray raytracer. In the particular scene I was rendering, every pixel was expected to be mostly black with a very small, very bright white spot. I needed very high supersampling for the output pixel to be the correct shade of gray.
POV-Ray has built-in support for anti-aliasing only via adaptive supersampling. Unfortunately, that doesn’t work with my scene, because most initial rays will come back the same color (black), and the adaptive algorithm decides that further sampling is not necessary.
Another way to approach the problem is to render at a larger resolution and reduce the final image. However, that does not work either because of clamping. As I said, most values would be black, but a few would be very bright. Let’s say we have 8 rays that return black and one ray that returns a value of 1000. When that gets saved to the image, the white value gets clamped to 255. The reduced image would then have a value of 255/9 or 28 for that pixel. Using the correct value of 1000 would give 1000/9 or 111. I tried getting around the clamping issue by saving to a high dynamic range format such as EXR. Either POV-Ray or ImageMagick (which I used to reduce the images) was still clamping values, though.
In the end, I used a new feature in the POV-Ray beta called a mesh camera. The basic idea is to create a mesh in the scene with each polygon mapping to a pixel in the output image. To supersample, I used multiple meshes, each offset by a small amount. The values from the corresponding polygons in each mesh can then be averaged before being output. Without further ado, here is the code I used:
// Our camera is orthographic
#declare ca_mesh =
mesh {
#local px_inc = 1; // Distance between vertices in the mesh
#local py_inc = 1;
#local row_count = 0;
#while (row_count < image_height)
#local col_count = 0;
#local d_y = row_count * py_inc;
#while (col_count < image_width)
#local d_x = col_count * px_inc;
triangle {
<d_x, d_y, -1>
<d_x + px_inc, d_y + py_inc, -1>
<d_x + px_inc, d_y, -1>
}
#local col_count = col_count + 1;
#end
#local row_count = row_count + 1;
#end
}
// Our sample grid per pixel is sampleCount by sampleCount.
// In other words, sampleCount is the square root of the number of samples per pixel.
camera {
mesh_camera {
sampleCount * sampleCount
0 // distribution #0 averages values from multiple meshes as described
#local i = 0;
#while(i < sampleCount)
#local j = 0;
#while(j < sampleCount)
mesh {
ca_mesh
translate <i / sampleCount - .5, j / sampleCount - .5, 0>
}
#local j = j + 1;
#end
#local i = i + 1;
#end
}
}
I’ve been working on a class project that involves a cluster of worker machines. Just to throw something quick together, I thought I’d use RMI. Since I could ensure that every machine was running byte-for-byte identical programs, I didn’t think I’d run into class loading issues. However, I’ve never had good luck with RMI, and it failed again.
Even with my class Worker existing on the client and on the server, and being identical, I’d still get ClassNotFoundExceptions for it. I also had to manually set the java.rmi.server.hostname and java.rmi.server.codebase properties to get RMI to work at all, since it can’t seem to autodetect these settings.
After a few hours of failure, I gave up and decided to give up and use simple TCP connections to send serialized objects. Worked like a charm. Screw you, RMI.
I fell in love with Haskell almost the day I started using it. It’s not perfect, though, and one of its weaker areas is error/exception handling. I’m not going to cover all ways to return errors. For more details, see 8 ways to report errors in Haskell.
Haskell has an Exception class in the Control.Exception module, but this can only be caught within the IO monad, which is an onerous restriction. In my (un)experience, a more flexible approach is to have your function return Either String a, where a is whatever type it would return normally. In this case, the function would evaluate to Left "error text" on an error, or Right 2 (if it was going to return 2, for example). There are two issues:
A lot of boilerplate is necessary to propagate the exception. This is actually easy to solve with the Error monad.
Haskell has no support whatsoever for stack traces. These can be hacked in, but it requires manual effort.
To propagate the exceptions, use the Error monad. You can use pretty much any error type with the Error monad as long as you set up up first. Either String a is set up already, so it’s easy to use. Let’s say you have functions f1 and f2 which accept a non-negative integer and return Either String Int. To sum them, define mysum as follows:
-- This uses the Error monad even though we don't say so anywhere. Type inference is awesome!
mysum :: Int -> Either String Int
mysum x =
do
when (x < 0) (throwError "x is negative")
x1 <- f1 x
x2 <- f2 x
return (x1 + x2)
This is essentially equivalent to:
-- Ugly boilerplate, even for only two function invocations.
mysum :: Int -> Either String Int
mysum x =
if x < 0
then Left "x is negative"
else case f1 x of
Left e -> Left e
Right x1 -> case f2 x of
Left e -> Left e
Right x2 -> Right (x1 + x2)
As I said, the problem of stack traces is more difficult. I’m not aware of a standard or convention, but one way to handle it is to manually add prefixes to a list of some sort, like String (which is a list of Char), which means we can still use Either String a. A helper function I wrote makes this a little easier:
nestError :: (MonadError [p] m) => [p] -> m a -> m a
nestError prefix a = catchError a (\e -> throwError (prefix ++ e))
This would be used like so:
mysum :: Int -> Either String Int
mysum x =
nestError "Error in mysum: " (do
when (x < 0) (throwError "x is negative")
x1 <- f1 x
x2 <- f2 x
return (x1 + x2)
)
If the second argument returns normally, nestError just returns the value. If there’s an error, it adds the prefix. For example, if x was negative, the final result would be Left "Error in mysum: x is negative". If f1 had the error “foo”, the final result would be Left "Error in mysum: foo".
Clearly, this pales compared to Java’s exceptions, which are the best of any language I’ve used. However, tricks like this make Haskell’s error handling a bit easier to use.
(Disclaimer: I am not a Haskell expert. There may be (and probably are) better ways to do this.)
I got to go on a tour of the facilities at the Vertical Motion Simulator (flight simulator) at the NASA Ames Research Center. While we were there, a pilot was training in a simulation of a tiltrotor, one that resembles a 737 but can takeoff vertically.
We also had a view into the control room for the simulator.
Here’s the cab used for space shuttle training. If I heard our guide right, every astronaut that has flown the space shuttle trained in this exact cab.
The cab for the lunar lander was right next to the one for the space shuttle. We couldn’t go inside it because it wasn’t hooked up, so the lights weren’t on.
Here are all the hookups for the shuttle cab.
Here’s the one for the lunar lander so you can see what some of the cables are for.
This website contains my own opinions and does not reflect the opinions of anyone else.
I do not guarantee that any information on this site is accurate.
Use at your own risk.
Content is subject to change or removal without notice.
All rights reserved.
Slippery when wet.
May contain peanuts.