So I happened to come across a broken HTC Incredible 2. My sister had replaced
it with an iPhone when the Incredible stopped charging. She had taken it back
to the Verizon shop where they tried replacing the battery but it still
wouldn't charge. It seems like such a waste to throw away such a fine piece of
hardware which clearly works but can't recharge the battery.

Long story short, a lot of people have had a similar problem and had success
by simply replacing the USB chargin port of the phone. As it turns out the
repair is not even that difficult. The phones design is incredibly modular,
with everything connected to the mainboard by ribbon cables. In this post I
document the process of disassembling the HTC Incredible 2 and replacing the
USB charging port.

In addition to these tools, I also used a pair of tweezers, an exacto knife,
and a very small phillips screw driver. Start by removing the outer cover.
This can be done with the plastic pry tool or a coin, or a credit card with
one corner shaved down a bit. There is a little tab at the bottom of the phone
to get you started.

Then remove the battery and the simcard. These are pretty easy, just take them
out.

Now there are seven (7) star screws to remove in order to get the inner
housing cover off. One of them is covered with a green "void" sticker
(removing this screw will void the warranty, which I assume is already
voided). If you dont have a star screwdriver (though one came with my
replacement part) a small flathead should work. you can look at the next
picture to see where the screws are located.

I used a piece of paper and take to diagram where all the parts came from as I
took them off. This is a handy way to keep track of where stuff goes when you
put it back together. Anyway, now that the screws are removed we may remove
the inner back of the case.

For me, the case took some work. Note that the volume rocker switch is a part
of the piece we are removing so it is safe to pry under it, however the little
piece of plastic over the headphone jack is not part of the piece we are
removing, so don't try to pry it out too. During this process, the USB
protective housing and the little rubber cover to what looks like an antenna
port came out. I just added them to my diagram so I knew how to put them back.

Now we can see the (presumable) culprit of the charging problem. The USB
charging port has some corrosion on it. I've read that many people have had
problems charging and that replacing this part will fix those problems. I'm
making an $9 bet that this is my problem too.

Now we have to disconnect two ribbon cables on the right side of the main
board. They are covered with some ESD tape. I saved the tape and put it back
on when I reassembled the phone. I'm not sure if they're useful but I figured
perhaps they'd relieve some stress on the attach points.

To remove the ribbon cables pop the tab on the back of the attach point. With
the tab up, the ribbon cable should slide right out.

Now remove the two small philips screws. One is holding a piece of plastic
over the headphone jack. The other is holding the main board onto the case.

Next we need to pop out the vibrator motor. Once the motor is removed from
it's holder, you may leave it connected to the mainboard. It's not held in
with any tabs so just pull it on out with your pry tool.

Now it's time to separate the mainboard from the housing. The mainboard is
still connected by a ribbon cable on the left side, so lift up from the right
side. The board is held down by two attach points. It fits under the headphone
jack at the top, and it is clipped in place at the vibrator motor housing. I
used the pry tool to separate the board from the clip at the vibrator motor
housing, and then pulled slightly downward to remove it from under the
headphone jack.

Now we can remove the ribbon cable that is attaching the board to the screen.
In hindsight this is not really necessary since our part is already exposed,
but I guess it make things a bit easier later. Start by removing the plastic
tape covering the ribbon cable attach point. Then pop the lever, and slide out
the ribbon cable.

Now that the mainboard is separated from the housing we can remove the USB
port. It's just another ribbon cable so remove the tape, flip the tab, and
slide out the part.

The we simply swap in the new part. Insert the ribbon cable, make sure it's
snug inside the attach point, then close the tab.

Now we reattach the mainboard to the housing by the big ribbon cable on the
left (screen?). This was a bit tricky since the ribbon cable is kind of short.
I had to pull a five finger maneuver to get the thing in a position where I
could insert the cable without it sliding back out. Once the cable is in,
close the tab.

Now simply flip the mainboard back over so that it is lying on the housing.
Check the camera to make sure it didn't slide out. Mine had slid out and was
sitting at a funny angle so I had to shift it back into place. Also make sure
that the two small ribbon cables on the right side are pulled out and aren't
buried under the mainboard.

Now we can snap the mainboard back into place, and return the vibrator motor
back to it's home.

Now screw back in the two phillips screws. One holds the plastic cover over
the headphone jack, and the other holds the mainboard onto the housing.

Now we reattach the small ribbon cables on the right side. Slide them into the
attach point, close the lever, and then replace the tape (if you like).

Now we can snap the cover back on. Start by replacing the USB port cover. This
fits into the housing by two tabs that are under the port. Replace the rubber
cap on the left side if it fell off. Also return the volume rocker to it's
place inside the back of the housing (the part that you took off) if it fell
out.

Then simply snap the back of the housing into place, and screw all the screws
back in.

Now you can replace the battery, simcard, and outer cover.

Plug in the phone, and if nothing starts sparking/smoking perhaps you have
indeed fixed your problem. Not that this is proof, but the phone now at least
tells me it's charging the battery. We'll see if it ever gets to 100%.

Note that I did not restrict partitions or specify an MBR file. This is
because I want windows to actually put its loader in the MBR of the /dev/sdb
disk.

I created a virtualmachine, attaching this disk as a SATA drive, and putting
the windows 7 install iso as the cd drive. After installation, I did not enter
a serial number, but just "continued". After windows loaded I ran "Windows
Loader" installation to handle the serial number issues.

Anyway, after this all happened Ubuntu had trouble reading from /dev/sdb. It
could not enumerate the partitions. In order to solve this I rebooted, changed
boot disk order, and booted into windows natively. It worked without requiring
the repair disk, but note that in some tutorials they say that you'll need to
repair the installation.

After rebooting again, and changing the boot disk order, ubuntu started and
could see the partitions on /dev/sdb. I probably didn't need to change boot
disk order, but probably just needed to restart so that the drive was re-
enumerated.

Anyway, after this, I ran

sudo update-grub

and windows 7 was found. The grub entry that was created would boot windows 7
natively without any problems.

This is blatent copy-paste job from here
put here for my own posterity.

This all works very well if the computer sending the Magic Packet is on the
same LAN as the sleeping computer, but requires some additional effort to get
working over the Internet. Especially if the very common Linksys WRT54G is
your wireless router. The WRT54G setup page employs javascript to prevent the
user from entering a broadcast address, so there is a work around. Here’s what
to do to set this up:

Enable WOL on your computer. This is usually a setting in the BIOS. (This may not be possible if you are using a wireless card. Only the very latest cards support Wireless Wake On Lan.)

Use DOM inspector to find the “WOL” entry and change IP Address from 200 to 255. (Firefox will red highlight the areas you have selected in DOM Inspector, this makes it easier to narrow down to the correct element.)

Click “Save Changes” on the Applications and Gaming page.

Download and install a Magic Packet program that can send a packet over the Internet. I like this one: http://magicpacket.free.fr/

You should now be able to wake your computer up from where ever you are.
(Also, I should say that my router has firmware version 8.00.5. I don’t know
if this matters, since I don’t have any other router to test it on.)

Lately I've been trying to learn how to use (and I mean really use) the
open source font stack. Since I tend to greatly prefer c++ over c, as part of
the process of learning these libraries I figured I'd workout API wrappers.
Since the font stack libraries are generally object oriented, I figured a C++
wrapper around these would be easy to accomplish.

Here's a short but handy C++ Snippet. I was looking for a way to quickly
generate runtime exceptions with useful information about the current program
state. My process was:

Create a string stream

Build the message

Throw the exception using the string from the stream

I felt like this was particularly cumbersome and quite annoying, especially
for doing things like string parsing or SQL because there are a lot of places
in the code where error checking is required.

In any case, I came up with this simple little class tempate which sits in a
single header file and is included in the cpp file where it is to be used.

#ifndef _UTILITY_EXCEPTIONSTREAM_H_#define _UTILITY_EXCEPTIONSTREAM_H_#include#include namespaceutility{/// used to simplify the process of generating an exception message/** * Derives from stringstream so provides an ostream interface, but throws * an exception with the contents of the string when the object is destroyed * * \tparam Exception_t must be an exception type which accepts a * const char* in it's constructor * */templateclassExceptionStream:publicstd::stringstream{public:~ExceptionStream(){throwException_t(str().c_str());}std::ostream&operator()(){return*this;}};typedefExceptionStreamex;}/* namespace utility */#endif /* EXCEPTIONSTREAM_H_ */

Here I'm using GiNaC to parse a string into a mathematical expression. If the
process fails I want to throw a runtime exception (typedef'ed as utility::ex).

The class derives from string stream so it works just like a string stream…
building a string by catting together the RHS of all the string operators. The
magic is that the destructor for the class throws an exception. The message
for the exception is the string that was built.

It's a very handy time saver… though I'm not sure if it's actually safe to
use. If the destructor throws an exception, is the object memory still freed?

As part of writing inkbook, I decided to use sqlite3 for data storage. The
C/C++ API is actually a C API, and while it is object oriented and rather
intuitive, it's just not C++. Considering that the API is very simple and, in
particular, the subset of the API I wanted to use was very simple, I went
ahead and wrote a quick wrapper.

Sqlitemm provides a C++ style interface to creation of database connections
and statements (as in Connection and Statement are classes). Objects are
reference counted using Glib::RefPtr so memory management is a bit easier.

You can find the project in my tracker
, but heres an example
of it's usage:

#includeintmain(intargc,char**argv){//openaconnectiontoasqlitedatabaseGlib::RefPtrsqlite=sqlite::Connection::create("/path/to/db.sqlite");//we'llreusethisvariablefordifferentstatementsGlib::RefPtrstmt;//prepareareadstatementstmt=sqlite->prepare("SELECT*FROMtable_aWHEREfield_a=?");//bindavaluetooneoftheparametersstmt->bind(1,10);//executetheselectstatementstmt->step();//readouttheresultsetwhile(stmt->hasAnotherRow()){//retrievethefirstcolumnoftheresultsetasanintegerintfield_a=stmt->get(0);//retrievethesecondcolumnoftheresultsetasastringstd::stringfield_b=stmt->get(1);//retrievethethirdcolumnoftheresultsetasadoubledoublefield_c=stmt->get(2);//dosomething}//ifwewanttoreusethestatementweneedtocallthisstmt->reset();//prepareasecondstatement,notethatallmemoryallocatedforthe//firststatementisreleasedhere,becausethesmartpointeris//reassignedandtheobjectitpointstoonlyhasoneoutstandingreferencestmt=m_sqlite->prepare("UPDATE table SET field_a=? WHERE field_b=?");stmt->bind(1,20);stmt->bind(2,"something");//nowactuallyexecutethestatementstmt->step();//notethatwedonothavetoexplicitlyclosetheconnection,when//thesqlitevariablegoesoutofscope,thesmartpointerwilldropit's//referencetotheunderlyingConnectionobject,andtheconnection//objectwillbedestroyed.Thedatabseisclosedduringthedestructor//oftheConnectionobject.return0;}

texmake is a makefile generator, much like cmake. In fact, it originally
started with me looking for ways to make cmake work with latex documents.
After a bit of work, I decided the system was too much designed around the
c/c++ build process, so I started working on some tools to simplify my life.

Keeping it simple

texmake tries to eliminate as much work as possible from the document writer.
It will try to figure out and resolve dependencies, including graphics files
which require conversion from their source format. It also allows for out-of-
source builds, so that the source directory doesn't get all cluttered with the
intermediate files that latex generates.

Example

Consider this scenario: We have a very long complicated report to write (i.e.
software manual, end-of-project report, thesis, how-to-book). We want to
generate both a full version, and a simplified quick-start kind of version.
The quick start version will contain a subset of the chapters of the full
version. The quick start will be published in PDF and HTML (i.e. web-
friendly). The long version will probably be a large document and we don't
really want it to be browsed on-line, but it is likely to be printed, so we'll
put it in pdf and dvi format, as well as epub for people who have e-readers.

In the process of making this document, we've generated many image files. Some
of them are hand drawn SVGs. Some of them are generated tikz images. Some of
them are diagrams drawn in DIA or plots in GNU Plot. Some of these figures are
shown in multiple different chapters (because the author does not want to just
refer the user back to a previous page, which is unnecessary in an electronic
format, but may be more meaningful in a print format).

Furthermore, we have some things that need to only be included in each
version. For instance each version should include some kind of header which
tells the reader where he can find the other versions online, or where he can
order them from.

Now, we can go maintain a makefile structure that manages all of this quite
easily, but we will have to build it by hand. Every time we add a new chapter
or image or output format, we have to go add a line to a makefile somewhere.
Wouldn't it be nice if all of that work would just happen?

Features

here are a list of features that I have implemented or am working on

don't rebuild the document unless it needs it

multiple documents in the same project, potentially sharing various pieces of content

monitor documents dependency on package, style, and class files so that document is rebuilt if these are updated

monitor dependencies on all included files, so that if any included file is updated, the document is rebuilt

out of source builds so that sources can be in version control without complicated ignore rules

caches values of environment variables and binary locations so that initial environment does not have to be manually set-up each time the document is built

colorize output to make it clear where and when things get messed up

Usage

texmake relies on the presence of a texmakefile in the directory of the
document you want to build. The texmakefile simply lists source files (.tex
documents) and the output files that should be built from them. Multiple
output files can be built from the same input file, so that the same latex
source can be used to generate pdf, dvi, and xhtml versions (so-called single
source builds).

texmake init is called from the build directory, accepting a single parameter
being the directory that contains the root texmakefile. texmake resolves the
absolute path to all the tools it needs (latex, pdflatex, bibtex, latexml,
kpsewhich, …), and caches those locations. (TODO: also cache environment
variables for latex and search paths for kpsewhich). It generates a makefile
in that directory which contains rules for all of the output files registered,
and creates directories, if they're missing, in which the output files will be
located.

texmake relies on GNU make to determine when documents need to be rebuilt.
This makefile includes several other makefiles (if they exist) containing
detailed dependency lists for each of the output files. If the output files
have never been built, these included files do not exist, but that's OK
because it is already clear to make that it needs to build the output files.

The output files are built with texmake build. The texmake builder runs
(pdf)latex(ml) with all the necessary switches to make sure that the source
directory and output directory are searched for required files. The builder
also scans the output of latex to build a list of all the files that latex
loads (for the dependency graph) as well as all the files that are missing. If
the missing files are graphics files, then it generates make rules for how to
build those graphics files from similarly graphics files in the source
directory (it is assumed the source file has the same name, but a different
extension). This way, an svg source file can be used to generate pdf,eps,or
png images depending on if the document being built is dvi,pdf, or xhtml
(respectively). If the file in the source directory is already compatible with
the latex that is being used, then no conversion is necessary. If the missing
file is a bibliography file, then bibtex is run to generate the bibliography
file. The builder also scans the output of bibtex to add bibliography database
files (.bib files) to the dependency graph. Bibtex is also run if there are
missing citations reported by latex (this is because bibtex will not include
bibliography entries that are not cited in the latex source, so if a new
citation is added, bibtex will need to be rerun). The texmake builder also
scans the output of latex for rerun suggestions. It will rerun latex if it had
to run bibtex, or if latex itself suggested that it be rerun (to get cross
references straight, for example).

Major TODO items

cache environment variables in init

use diff to determine if TOC's get updated (they will get touched by latex so make will always think they're new) to determine of a rerun is necessary for TOCs

add image generation rules for tikz

consider a more modular design for making intermediates (i.e. run a program, like matlab, to generate intermediates)

Code

As I was working on texmake I decided that I didn't want to figure out what
all the possible auxilary output files would be for a latex document. Also,
I'm suspecting that it will depend on what packages are included and things.
Anyway, I wanted a way to just monitor the build directory and see all the
files that were created while running latex. It turns out this is very easy on
linux. This is a very simple program which watches a directory, and will print
out any files that are created, modified, opened, closed, moved, or deleted.
It prints out the file name, followed by a comma, followed by the notification
event.

I've been working on a new makefile for my latex projects. The goal is to have
single-source builds of dvi, pdf, and xhtml documents. I ran into a problem of
generating figures. latex expects eps graphics, pdflatex expects pdf figures,
and latexml expects png figures (or will try to generate them). In order to
generate documents with make, I need a way to generate eps and pdf figures
from svg sources (I usually use inkscape to make my figures). Inkscape can be
run from the command line, but I dont want to install inkscape on my server
because that will require installing a ton of libraries that don't make sense
to have on a server with no graphical interface.

As it turns out, writing such a command line tool is very easy with librsvg
and cairo. Carl Worth of redhat has produced a nice demo of svg2pdf which can
be found at freedesktop.org. I
cloned his project, create a cmake project out of it, and made a trivial
modification to turn it into svg2eps as well.

One feature that I've really been wanting from compiz is to give windows a bit
of momentum when I'm moving them around. In other words, if I flick a window
with the pointer and then let go, I want it to continue moving, so that it can
be "thrown" across the screen. Thankfully, someone involved in compiz wrote
such a plugin, found on his blog
here.
Unfortunately, the strategy that he uses doesn't work well for me.
There are essentially three problems with it:

In order to calculate the velocity of the window after it is released, he compares the window position at the time it is released to the window position at the time it was grabbed, and calculates the delta. This leads to weird behavior when the users is indecisive and moving the window around sporadically before releasing it.

The velocity of the window has an unnatural association to the actual "velocity" that the user was moving it with.

The velocity appears to be zero when using a pen-tablet (wacom) input because my hand generally stops before the pen moves out of range of the tablet.

While the compiz API documentation is in a very sad state, Sam's plugin showed
me all the parts of the API that I needed. I rewrote the plugin to essentially
low-pass the velocity of the window, sampled at the compiz frame rate. At each
"movement" event, I update the delta in the x direction and the y direction.
At each "frame" of compiz, I bake the accumulated deltas, along with the time
(in ms) since the last sample. The accumulated deltas and the number of
milliseconds are stored in a ring buffer. When the window is released, the
buffer is averaged to get a window velocity in pixels-per-millisecond.

I also augmented the window structure to store a floating point representation
of the window location. Together with the low-pass on the velocity, the
outcome seems to be a lot smoother.

The window velocity exactly matches what I "feel" like the velocity of the
window is when I let go of it. Also, the filter only has enough history for a
couple of frames so weird movement of the window prior to release is
"forgotten", and only the "most recent velocity" is used.