My Brain Hurts

One of the most tedious things I seem to do on a regular basis, for both blogging and developing, is downloading an image off of Google Image Search and shrinking it. Having to do a scale a lot of images to a similar size can become really annoying. I ended up writing a command line tool to shrink an image given a percent or a maximum dimension. Probably won’t be useful for many, but who knows!

Grab shrinkimage off of GitHub.

Warning: Weak browsers (aka Internet Explorer) may not be able to render this blog entry in its glory. Use a real browser!

If you browse on over to the Code and Applications section of this site, you will notice that it takes a little time to load. That’s because that entire page is being dynamically generated by your browser via the GitHub (JSON) APIs. What you see on that page is a live, up to the minute, list of every public project in my GitHub repository.

And here’s the JavaScript code that does it:

But that’s not really the magical part. Here’s the code that inserted the code above into this page:

<pre class="githubfile" file="githubprojects.js" repository="GithubProjects" user="koush"></pre>

The first bit of JavaScript code you see above is a live view of the file that is checked into my GitHub repository… and your browser is using the GitHub API to view it, highlight it (using SyntaxHighlighter), and then render it to your screen. Kudos to Github for a fantastic API!

I wrote GithubProjects up today as an exercise in learning jquery, AJAX, and some other Web 2.0 acronyms. Of course, all of this code is available in my GithubProjects repository.

This will be a running blog entry that I’ll update periodically when I have new ideas.

Enum.ToUserString();

string.IsNullOrEmpty:

public static bool IsNullOrEmpty(this string str)
{
    return string.IsNullOrEmpty(str);
}

release-1.0 branch:

static int open_library(const char *name)
{
    int fd;
    char buf[512];
    const char **path;

    TRACE("[ %5d opening %s ]\n", pid, name);

    if(strlen(name) > 256) return -1;
    if(name == 0) return -1;

    fd = open(name, O_RDONLY);
    if(fd != -1) return fd;

    for(path = sopaths; *path; path++){
        sprintf(buf,"%s/%s", *path, name);
        fd = open(buf, O_RDONLY);
        if(fd != -1) return fd;
    }

    return -1;
}

cupcake branch:

/* TODO: Need to add support for initializing the so search path with
 * LD_LIBRARY_PATH env variable for non-setuid programs. */
static int open_library(const char *name)
{
    int fd;
    char buf[512];
    const char **path;

    TRACE("[ %5d opening %s ]\n", pid, name);

    if(name == 0) return -1;
    if(strlen(name) > 256) return -1;

    if ((name[0] == '/') && ((fd = _open_lib(name)) >= 0))
        return fd;

    for (path = sopaths; *path; path++) {
        snprintf(buf, sizeof(buf), "%s/%s", *path, name);
        if ((fd = _open_lib(buf)) >= 0)
            return fd;
    }

    return -1;
}

Summary: Android’s linker used to look in the current working directory to resolve library references. Now it doesn’t. (And it never used LD_LIBRARY_PATH at all) This is really only annoying for 3rd party command line applications which have references to libraries that aren’t part of the standard Android build (and contained in /system/lib). I need to figure out how to make gcc, et al, create binaries that store the full path to the libraries they reference, rather than just the base file name...

Edit: I tried patching it to use LD_LIBRARY_PATH, but calling getenv from within the linker would always return NULL. Not sure why. So I did the next best thing and added “.” to the list of search paths. I think that is default behavior anyways on other Linux based systems (will verify later). Submitted the change, hope it gets accepted.