Older blog entries for johnnyb (starting at number 146)

If anyone has the new Sakar KidzCam digital camera (or is it "Kidz Cam" -- I've seen it both ways) and is trying to get it to work on Mac OS X, this is the post for you!

To start with, iPhoto will not load from this camera by default. macam claims to support it but they are wrong. It doesn't detect it.

It turns out the chipset for this thing is the SQ905C (it's not the SQ905).

I tried downloading gphoto (or is it officially gphoto2 or libgphoto2) -- that didn't work (I had to use DarwinPorts libgphoto2 and then compile gphoto2 myself). I eventually got gphoto to download and install, but it wouldn't detect the camera. I tried using this SQ905 Mac Driver Software -- still no luck. It looks like none of these work for the SQ905C.

However, but looking up the USB id (0x2770:0x905c), and googling that, I was able to find another driver that worked. It turns out, there is a Strawberry Shortcake camera (I'm not kidding!) that uses this chipset. They have iPhoto and even Mac OS 9 drivers at their website. Here is the direct download link to the OS X drivers.

These drivers work great. Hope you enjoy your cheap camera. What's really amusing is that the Strawberry Shortcake camera costs 2 times what this camera costs.

Grrr... now that I look at the macam site again, it turns out they have this info already. Maybe they just posted it. Hopefully I didn't waste all that time because I was too stupid to keep looking....

I was trying to get a JPEG from an outside source to load into Flash. Some worked, some did not. In fact, I even modified and saved them using Adobe Photoshop. Still, the same ones worked, and the same ones did not. It turns out, Flash doesn't like progressive JPEG files/images. Photoshop, if you load and save a JPEG using "Save As" will decide whether or not to use progressive encoding based on whether or not the original was progressively encoded. You CAN modify it if you do "Save For Web".

In order to determine if this was the problem, I tried to figure out how to tell whether or not an image was saved as a progressive jpeg. Finally, a nice IRC user helped me out. ImageMagick has a nice tool called "identify" that can be used to tell if an image is progressive. Do

identify -verbose FILENAME|grep -i interlace

If the result is anything but "none", then it is a progressive JPEG. It turns out "identify" can tell you all sorts of things about an image's encoding. It is very cool!

Anyway, I leave you with a list of keywords so that others googling for this same problem can find it easily:

problems loading image into flash
flash progressive jpeg
problems loading jpeg into flash
can't load an image into flash

In the America's Army game (which is FREE as in beer, and runs on Linux, Mac, and Windows, and is the best game I've EVER played), in order to get special forces qualified you have to do a training mission called "E and E" (evasion and extraction, maybe? can't remember). Anyway, there is one move on it which is difficult to find, so I thought I'd post it here if anyone else has trouble getting to it.

I hit objective alpha easily after 3-4 tries. I hit objective charlie on my first. But objective Bravo was near impossible. Here's how to do it.

After reaching objective alpha, crawl down to the creek bed by going to the _right_ of the bridge. As soon as you are in the creek bed, turn left. Follow the creek bed around. As soon as you see a bridge-looking structure, start looking for a path to the right. It is nearly impossible to see, but it is there (it may even be covered up by brush). DO NOT GO UNDER THE BRIDGE. The path is somewhere between where you first see the bridge and the bridge itself, and it is to your RIGHT.

Once you find the path, the rest is pretty easy.

OK. I have to say that I am thoroughly unimpressed with YourPay and LinkPoint. It took me all day just to figure out how to CONNECT to their test server. Here is the email I sent them. Hopefully google will pick this up and help any poor, weary traveller who is searching to find the answer to these issues if they don't revise their help pages.

----

There are several issues with connecting to your server using Java which were not mentioned in any manual, and which I spent most of the day tracking down. Perhaps if I mention this to you, you can get an FAQ or something written to help out anyone else who has to deal with this.

1) The certificate files that you download from the interface are in the wrong format for Java. Java seems to require keys to be in the PKCS12 format. Instead of having a helpful error message, Java gives something akin to the following error message:

java.io.IOException: toDerInputStream rejects tag type 45

In order to solve the problem, you must use openssl to convert the certificate into one that is usable. So, for the file 12345.pem, you would do:

openssl pkcs12 -export -out 12345.pkcs -in 12345.pem

Then you would use 12345.pkcs as your client certificate file.

2) Now, this works great for connecting to your production server. However, your test server is a different problem. Connecting to your test server gives the following error:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found

This is because you have self-signed your testing certificate. Java doesn't like that. Now, you can import your own certificate into Java, provided you actually have the certificate. I didn't find your certificate on your website, but I found a way to grab it from the SSL connection. If you do:

openssl s_client -connect staging.linkpt.net:1129

It will spit out the certificate file during connection. You can then copy that into a file to use to import into your Java KeyStore (I'm using staging_certificate.txt for this example).

They way you import it into the Java keystore is as follows:

keytool -import -keystore /PATH/TO/YOUR/KEYSTORE/cacerts -file staging_certificate.txt -alias linkptstaging

The /PATH/TO/YOUR/KEYSTORE/cacerts varies by platform. Of course, this entire step would be avoided if you simply bothered to spend the $300 to sign the certificate for your staging server.

I love garbage-collected languages. Here's a nice algorithm in Scheme to calculate the multiple at which a given vector from the origin comes closest to a point in n-dimensional space:

(define (vector:closest-to-point vec point)
  (/
   (vector:sum (vector:map * vec point))
   (vector:sum (vector:map * vec vec))))

If you don't have my handy-dandy vector library, you can do it with lists just as easily:

(define (closest-to-point vec point)
  (/
    (apply + (map * vec point))
    (apply + (map * vec vec))))

Compared to what you have to do in C or other lower-level languages, this is a dream. I didn't even have to define any variables.

For those of you who do barcoding applications, I just found out that someone has made traces of an OCRB raster, and given us this nice Type 1 file for free:

http://thinking-forth.sourceforge.net/OCRB.pfb

I found some OpenGL oddities that weren't very clear from the documentation that I had read so far. The two things I found were oddities with gluPickMatrix and glRasterPos*.

With gluPickMatrix I was under the impression that this only modified the projection matrix. However, it actually modifies both the Projection matrix and the ModelView matrix. That took a long time to figure out. Also, the hit records are laid out really wierd. They even record hits if there are no names in the name stack.

The other thing I figured out is with glRasterPos. First of all, I was under the impression that glutBitmapCharacter and glutBitmapString just render from the origin of the current modelview. I was wrong. It appears that it actually renders from the current RasterPosition, and advances forward along the raster position, and I think it is independent of the ModelView Matrix from that point on, moving the current raster position. FreeGLUT may be different, but I need to test it. It will also use the color from the time of the call to glRasterPos*, not from the call to glutBitmapCharacter. That's a little counterintuitive, except that the documentation mentions that glRasterPos* works just like glVertex*. Therefore, it is transformed and colored just as if it were a vertex. So when a bitmap is drawn at the raster position, it uses the OpenGL state that was present when the raster position was set up, not how the render state currently is.

Hopefully, my ANOPA viewer (which is what I'm working on for this project) will be ready to show sometime soon. Working through these two problems helped a lot, especially the gluPickMatrix stuff, as well as figuring out the details of what is returned in the selection buffer.

Also, I'm hopefully going to generate some nice utility functions for opengl.egg for Chicken Scheme.

If anyone is having problems with IE support for PNG images (displaying them darker than your background color, for example), then I've found your solution. Apparently Photoshop always saves gamma information to your PNG. You need to strip it out. You can do this with pngcrush (which you should be using anyway).

pngcrush -rem gAMA infile outfile

I made a simple webpage for this for internal use, and it works quite handily.

I believe GIMP works if you choose to leave off the Gamma information.

Just posted a new article to IBM's Developerworks. This one is on recursive programming and program proving, and touches on C, Scheme, and even assembly language. You can see it here:

Mastering Recursive Programming

Anyway, if you're interested, please email your comments on it to me! johnnyb@eskimo.com

I have an application that integrates with DHL's online shipping rate calculator HTTP interface. This calculator has always been dumb from one perspective -- it doesn't allow floating-point values for the weight. However, I can kind of overlook that. In fact, generally I like their calculator because the API for it is described in just a few pages, as opposed to, say, UPS, that has hundreds of pages of documentation just to get a stupid rate quote.

What's really stupid, though, is that they changed the output format of their web requests, and I don't think they even realize it. It looks like it was a dumb formatting bug, and they don't even know it happened.

Let's look at the old format of the data:

  GND, NAS, SDS, EXP

   $6.25, $28.5, $13.3, $32.25

Now, let's look at the new format of the data:

                                                                               
                                                                               
  GND, NAS, SDS, EXP
  <br>
  $6.25, $28.5, $13.3, $32.25
                                                                                                                                                                                                                                             

(note that the indentation is actually the same on both of them, I think, but I couldn't replicate it due to some HTML or Advogato wierdness).

First, they added two blank lines to the beginning of the document. Second, they added a stupid <br> tag in the middle of the data. This would throw off many reasonable parsers of this data.

Why did this happen? My guess is that someone added some sort of stupid output filter to their web application, and forgot to set it not to filter the web apps that are used by programs as API's rather than by humans.

Well, DHL lost a customer for that one. UPS may have a large API for those of us who just want rate requests, but at least I have a reasonable expectation that they're output formats might be consistent.