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.
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.
I recently built and OSx86 machine, but I had never actually tried doing any (native) development[0] on it as I had been using my MacBook for that purpose. Tonight I finally fired up Xcode on the new desktop, created an iPhone application, and found that my breakpoints, which were being correctly set and detected, were not ever actually being hit. It was as if they were being ignored completely.
After Googling around for some hints as to why this would happen, on a hunch I tried debugging a C application that targeted the OSx86 machine itself: same issue, no breakpoints were hit. My desktop and laptop have the exact same applications and tool chains, and the only real difference between the two machines from a software standpoint was the kernel. This led me to believe that the Voodoo kernel used on the desktop had some debugging issues. Doing a search on this confirmed my suspicion, as the Voodoo team has an open bug on this exact issue. Luckily, a few searches down, I also found a workaround that happens to fix the issue for Intel based machines.
When starting your system, enter the following as one of your boot flags:
std_dyld=1
From the voodoo kernel documention:
std_dyld= On-the-fly opcode patching requires an elaborate technique to patch dynamic libraries. Because of this, the kernel includes its own specialized copy of dyld, and chooses the best one depending on your CPU. Use this option to force the kernel to use standard dyld (pass value 1) or its specialized copy. (pass value 0), regardless of your CPU type. Note: AMD insta$s might fail to function if you specify this boot-flag!
While Googling, I saw numerous forum posts about this issue on OSx86 machines, with no one realizing there is a workaround. So hopefully this post matches enough keywords to save someone an hour or two of searching. :)
Edit/Note: If you are booting off a kernel on your EFI partition, make sure that it is named "mach_kernel" and that a copy of that exact kernel is available at /mach_kernel on your system partition. (I had issues with VMWare not working until I did this, and suspect it may cause issues with XCode too)
[0] I have been using it to do Android development, and have no issues debugging the Dalvik VM. But I am guessing the Dalvik VM on an emulator/device does not require the same low level kernel hooks on the host.
Quick update: I have made fixes to both Klaxon and Screenshot to support Android 1.5. However, I am still hearing reports from users that Klaxon does not work on Haykuro builds; the device goes into a reboot loop. Haykuro does not have a build based off the T-Mobile OTA update, so I can not provide support for his build- I believe he is using older/pre-release cupcake pieces in his current builds. Once he updates, I may look into the issue further.
I am currently running JF 1.5, and have no issues with either application. Unfortunately, I can not spend my time supporting every fork/tweaked version of Android (Haykuro, DudeOfLife, etc, etc). The only supported builds will be Retail and JF.
