Saturday, October 13, 2012

CWM Recovery Loop

I've recently been playing with some android tablets and phones, and was looking for the best OS for my TF201, Transformer Prime (IMO, it's Virtuous Prime). In the process, I installed a number of Cyanogen Mod versions, but each one had some weird quirks: auto-rotate never worked, GPS didn't work, WiFi was flakey... all in all, a terrible tablet experience.

On my way back to Virtuous Prime, I asked Cyanogen Mod to reboot into recovery mode. This was a huge mistake.

I don't know if it's a bug in Cyanogen Mod, or a bug in Clockwork Recovery, but from that point on, any reboot, cold boot, hard boot, you name it, would bring me into the CWM recovery prompt. I tried installing numerous other images, but I was still stuck with this very basic issue.

A couple websites suggested holding the power + volume down buttons to do a cold boot, and boot the OS from there. On my setup, CWM seems to have bypassed this extremely useful functionality, and instead would always take me to CWM Recovery.

I found the correct workaround on this blog: http://hmastuff.com/blog/?p=65, however I couldn't do that first cold boot step.

To workaround, I plugged in my TF201 to my computer via USB, booted into CWM Recover (like I had any choice...), and started up adb. I had this lying around from my initial rooting efforts. If you don't know how to get it, try installing the Android SDK, and looking for it in platform-tools. Anyways, I confirmed that my devices was connected with 'adb devices' and used 'adb shell' to implement the workaround I had found, and unstick my boot loop.

To summarize here's the steps:

adb shell
echo boot | dd of=/dev/block/mmcblk0p3 bs=1 seek=0
reboot

Hope that helps someone!

Wednesday, July 1, 2009

MySQL on OS X via PHP

I don't know why, but I always have trouble when I'm setting up PHP and MySQL on OS X. Actually, I do know why, and it's for two reasons:
  1. I usually forget that you have to uncomment the line 'Load module php5..." in /etc/apache2/httpd.conf
  2. Whenever I try to connect to mysql in php using localhost from a website I'm sandboxing on my machine, I get an error.
The error will read something like "Could not connect to socket via /var/mysql/mysl.sock..." I poked around and, indeed, there is no such path on my machine. Instead my mysql.sock goes to /temp/mysql.sock. If instead I try to change the host from 'localhost' to '/tmp/mysql.sock' then I get the same message, but after the server does a lot of thinking. I suspect that it may be something related to the file permissions on my system, but the only thing that works for me is to symlink to /tmp/mysql.sock in /var/mysql/mysql.sock. Bingo, problem solved. I'd be curious to know if there is a better workaround...

Tuesday, June 30, 2009

Recovering From Apple Coma

I recently had the pleasure of reviving my macbook's broken hard drive from the dead. A quick word of advise for anyone with Apple products: get Applecare! You'll wish you did when things start breaking after the year-long factory warranty has expired (aint it always the way...). Warnings aside, I did some funny gymnastics to get up and running again:

My problem was a bum hard drive. I'm not sure what caused it, but at some point my system stopped responding and after a cold restart, I could not progress past the gray apple logo and nice wheel loading screen. I could hear my hard drive sputtering as if it were trying to get fired up and failing. I never received an error, I just hung at this screen indefinitely (8+ hours while I was sleeping didn't make any progress).

I had backups of most things, save for some music I was working on earlier in the day. Luckily my sister's iMac was close by, and my Macbook is old enough to have a firewire port. I happened to have a firewire cable, so I booted up in Target mode (hold 't' after the apple sound during startup), and was actually able to mount my drive on sis's computer. It took me a long time to navigate my folder structure, but everything was visible after enough time. I took this to mean that my hard drive was merely crippled, and not gone.

I got the few files I needed and ran to Fry's to get a new hard drive. Replacing the HD on my macbook was nice and easy -- it sits kiddy corner to the ram -- however, finding the screw driver to mount the new hard drive in the easily removable case that my old one was in was not. It turns out that you need a Torx T8 screwdriver if you ever want to get the drive out again. Luckily Ace Hardware had it, and all I had to do from there was reinstall with the system discs.

Of course, to make things interesting, my CD drive has been broken for almost two years now, so I had to go back into target mode and do it from sis's computer. Luckily it all worked out and I'm back in the blogosphere, the twitterverse, and every other electronic habitat.

Thursday, February 5, 2009

Binutils and objdump on Mac OS 10.4

For some reason OS X (10.4) does not contain objdump.  Seems like quite a useful tool to leave out.  Some searching revealed that objdump is part of binutils.  After much failure trying to install binutils 2.19 for OS X (10.4), I finally came across the supported version on the Apple website (binutils 2.16).  This version of binutils successfully compiled, but much to my chagrin, did not produce any binaries (weird).

To make a long story short, otools, does come with at least the developer tools for OS 10.4, and provides the same functionality as objdump.  Sample usage:

otools -tv a.out

The above will print out the disassembled assembly code of a.out.  You can do other nifty things like print out the shared libraries used.  I hope this saves someone some trouble.

Wednesday, March 5, 2008

Cross-Browser AJAX

I am celebrating right now because I found a work-around for a very strange problem I've been having regarding AJAX and Internet Explorer's general noncompliance with the world. This has literally been on the critical path in my senior design project for months, and seemed to have cropped up out of nowhere. Let me explain...

The Problem

I have a call to a function which initializes an XMLHttp request object based on the browser, of course, grabs some form inputs, and sends those values in the request header of a call to my nifty php function, which manipulates these inputs and gives me some XML in return. Pretty standard stuff. After using this for a while, I noted that it seemed to fail in IE, but not in Firefox (surprise). After some debugging I had determined that IE was indeed making the request, and was indeed getting back data, but the data was all invalid. I tried calling my php file directly from IE, with the same parameters that my javascript pulls, and got legitimate results. What was going on!?

Clearly, the php file seemed to not be getting the right parameters, even though the javascript was computing them correctly. Here is the code:


function customTime() {

// Get form element values
param1 = document.getElementById('param1').value;
...

// Initialize the XMLHttpRequest object
var xmlHttp = ajaxInit();

if (xmlHttp) {

// Define what to do when data is ready
xmlHttp.onreadystatechange=function() {
if(xmlHttp.readyState == 4) {

// Note that even though I get bogus data,
// I still get data... confusing!
var xmlDoc = xmlHttp.responseXML.documentElement;
var nmarkers = xmlDoc.getElementsByTagName("marker");

alert('Number of results: ' + nmarkers.length +
'\nSome data: ' + nmarkers[0].getAttribute("number"));

}
};

// Send the request...
try {
xmlHttp.open("POST", 'custom_data.php', true);
xmlHttp.setRequestHeader('Content-Type', "text/xml");
xmlHttp.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded; charset=UTF-8");

xmlHttp.send('param1=' + param1 + ...);

} catch (e) {
alert("Unable to make request, please try later... Error:"
+ e.message);
}
}
}


The 'Solution'

The problem, in fact, was that, for some reason, using the parameter of XMLHttp.send() to add my form inputs to the request header of my http request failed in IE. The reason for this still has me scratching my head, but the fix was simple enough:


// Send the request...
try {
xmlHttp.open("POST", 'custom_data.php?param1='
+param1+ ..., true);
xmlHttp.setRequestHeader('Content-Type', "text/xml");
xmlHttp.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded; charset=UTF-8");

xmlHttp.send(null);

} catch (e) {
alert("Unable to make request, please try later... Error:"
+ e.message);
}


All I did was move the parameters as part of the URL for the XMLHttp.open() function. Tada! I'll try to do some research into the open and send functions and post the method behind the madness when I get a chance.

Sunday, February 17, 2008

Wosaic

So, the hectic pace of school and life has left this blog seriously lacking.  That's ok though, because this shameless plug comes with a reminder that (for me) that this blog exists, and some ideas for new posts.  The plug: Wosaic.


Yea, I think I've plugged this already, but today (Sunday) marks the first official "beta" release for our project.  It's pretty exciting, as it represents a couple months of hard work and problem solving, not only in the domain of programming problems, but also project management and software design.  Maybe in the course of this plug, we can get some insight from the project's ups and downs, and how to manage a project.


Lesson 1: Version Control

This is a must.  Anyone who's done any kind of serious coding within a group, knows this as common sense.  Luckily for me, this has become my intuition as well as the intuition of my project partner, Scott.  However, living in the world of undergraduates, it's easy to come across people who have not been exposed to such situations.  So, for anyone not aware: verison control is crucial.  It allows you to organize your code such that it is available to all your project members, is up to date and synchronized with your latest changes, and serves as an archive of your code, should something go terribly wrong.  Typically the flow is something like, check out some source code, make your changes, and commit them.  For instance, if you wanted to toy with Wosaic (say, add a new source plugin, which is nice and easy to do), you could check it out with the following svn command:


svn checkout http://wosaic.googlecode.com/svn/trunk/ wosaic


Subversion (SVN), for example, keeps track of the files that you change and will recognize this when you are ready to commit your changes.  Committing simply adds your changes to the 'trunk,' or the rest of the source code.  Now when other people checkout, or update their code, they will get your changes.  Neat, huh?  Not only is it neat, but it is an excellent way to stay synchronized with your project members.  


Lesson Two: Bug Tracking

No project is perfect, but good projects can track their imperfections and schedule fixes.  This is where having a database of bugs is useful.  The idea is that someone can file an issue, or bug, document it, and assign it to someone.  This gives the developers a clear list of the things they have to fix and how to reproduce issues.  Not only is it good documentation, but having a glaring list of bugs helps remind project members about what needs to be done, and ends up making people more productive.  I mean, let's face it, nobody wants to admit that their project has bugs.  One resource people rave about, though I haven't used it myself, is Bugzilla.  This has the advantage of being free, fully featured, and developed by the open source demi-gods of Mozilla.  On Wosaic, we used a simple Issue Tracker that came with our Google Code site.


Lesson Three: Project Website

Another useful thing to have is a website for the project.  It's useful to aggregate releases, documentation, and discussion in one spot.  For this, we used Google Code.  This was an invaluable resource, as it sets up a nice SVN repository.  Additionally, it provides a wiki, and issue tracking.  The wiki is perfect for documenting features and project design.  Having the ability to get feedback from users is also a valuable tool... assuming, of course, that you have users.


Lesson Four: Distribution

This was probably the most interesting part of developing the Wosaic project.  Being an open source project, Scott and I wanted to make it accessible to all platforms.  Naturally, we chose to implement our idea in Java, since Java prides itself on striving for platform independence.  This is all well and good, but you still need to sort through the small nightmare of different JRE versions, IDEs, building jars, automating the build process, and producing 'native' applications for multiple platforms.  One tip for Java developers: decide what JRE to use right up front.  Say, "Hey, let's be compatible with Java 1.5 and up" and stick to it.  This is important, regardless of the language, as there are and will continue to be revisions to languages and their compilers.  Java is interesting because it requires a virtual machine to run, which gives it the platform independence, but lacks the feel of, say a native OS X (or Windos, or *nix) application.  The ability to create executable jars makes the experience close, but not quite there.  We resorted to some other tools to help us out, such as Launch4j for windows, and Apple's Jar Bundler for OS X.


Such tools are nice for releases, but for day to day development, there's nothing that beats a good Ant script.  This is very similar to a Makefile, for those lucky enough to be acquainted with Makefiles.  For others less (or more?) fortunate, this means that with a simple command, 'ant' you can build the source of your project, run it, generate documentation, and brew a cup of coffee.  Well, maybe you can't get coffee out of the deal, but just about anything else you might want to automate with regard to the build process can be automated with Apache's Ant.  It's pretty sweet, because an ant script just boils down to an XML file that specifies various targets and tasks.  One cool thing about this is, if you are a documentation freak like me, you can whip up a little XSL stylesheet and transform this xml into a website that details your build targets for anyone to view at their leisure.  You can even use ant to perform the transform ().  Sweet.


... And Back to the Plug

Phew.  Well, that turned out to be more substantial than I anticipated.  There are plenty more lessons to be learned, but I think we've hit on some important point here.  Remember to check out Wosaic's project site, and grab yourself a copy of our source (or one of our sweet binaries... Mac users note the handy disk image).  Until next time, peace!

Saturday, December 1, 2007

Java Profilers

Why is it so hard to find a good Java Profiler?  My friend and I have a pretty neat Java project at the moment, but it seems that finding a good solution for profiling is difficult.  All I want is something that can tell me what percentage of time is spent in which pieces of my code, maybe create a nice little call graph, and maybe even provide some insight into the memory usage of my app.  Preferably this solution is open source and available for my OS X system.

My first and most promising result was an open source profiler for Eclipse known as TPTP.  Setup was a breeze, but when it comes time to perform, I consistently get the following error: "Agent Controller is unavailable under port 10002.  Make sure that the service is started and the port number is correct under preferences. "  A fix for this problem is supposedly to download an Agent Controller and configure it to use a different port, other than 1002.  This is of absolutely no use to me, as the controller is a windows executable.  As an aside, I haven't found a good way to see what ports are in use on my OS X system.  This is disappointing because from what I can tell, TPTP integrates very nicely with Eclipse, and provides all sorts of great profiling information.  Oh well, the search continues...

Another quick search resulted in Extensible Java Profiler.  This seemed promising at first, but a lack of a binary for my Intel Mac, and an apparent lack in development for the past two years leaves me wary.  I downloaded the source, but had some problems building it.  The documentation is kind of lacking, and despite setting the appropriate environmental variables and following the README, I had no luck building it.

A slightly less open source solution exists in the form of YourKit Java Profiler.  This has a nice interface that is easy to interpret, if not a little bit daunting at first.  I like this solution because it worked right out of the box with Eclipse, and actually contains some nifty monitor and thread monitoring tools.  It also will show you the various performance metrics during run time, which turns out to be an invaluable debugging tool.  Licenses are pretty pricey, but they do offer a free license for open source projects if you contact their sales department.

One solution that is simple, free, and works as advertised is JRat.  Invoking it is simply a matter of adding an extra option to the java command.  This will save its profiling data to a file once your program finishes execution.  From this you can launch their included GUI to see a basic call graph, complete with various performance metrics.  I like this solution because it works and is simple, however it doesn't provide for dynamic analysis (that is, you can't see profiling information while running your app).  It also lacks information regarding memory usage, but, again, I'm partial to solutions that work.

Ultimately, I'm going to stick with YourKit for my open source project, as it has a nice, professional feel to it.  I would have loved to have used TPTP, but its cryptic error with no work-around for my system leaves YourKit a clear winner, in my opinion.  JRat is a great utility if all you are looking for is your typical call graph, complete with execution times.  I hope that the state of open source profilers improves in the near future, but until then, I'll sell out to commercial software.