Quick script to decompile all the class files.
find . -name "*.class" -not -name "*\$*" | while read class do dir=`dirname $class` file=`basename $class .class` pushd $dir >/dev/null jad -p ${file}.class > ${file}.java popd >/dev/null done
Quick script to decompile all the class files.
find . -name "*.class" -not -name "*\$*" | while read class do dir=`dirname $class` file=`basename $class .class` pushd $dir >/dev/null jad -p ${file}.class > ${file}.java popd >/dev/null done
WOW! scary but pretty.
I think new version of ruby is meant to be installed with the following prefix, using 1.8.7 as an example.
/System/Library/Frameworks/Ruby.framework/Versions/1.8.7/usr
That way you can just /System/Library/Frameworks/Ruby.framework/Versions/Current to the version you want.
As I mentioned before, I upgraded to ruby 1.8.7 and decided to use —prefix=/usr, i.e. overwriting existing ruby 1.8.6. Big mistake. After some issues I decided to roll back completely.
This is what I did (luckily I can copy the required files from my wife’s Macbook).
The framework is /System/Library/Frameworks/Ruby.framework
Rename the following directories then copy the same directories from another OS X
Make sure the following files are links to os x ruby framework’s /usr/bin
Remove these backup directories afterwards (once everything is ok)
Now
That’s one expensive apartment!!
Oh Oh I want one!!
I was in a update mood so I updated my system to use GWT 1.5.0 and ruby 1.8.7.
After updated ruby I tried to figure out how to keep the old gems. My solution was to set the following env variables (similar result could be achieved with .gemrc).
But in the end I decided to revert back to ruby 1.8.6…. because I realised a problem that I worked around earlier is bigger than I thought. The problem was that hpricot 0.6 didn’t load properly under 1.8.7. I was too focused on understanding how OS X setup ruby framework and replicating it in 1.8.7.
All was not lost, someone has found the problem and fixed it. So once a new hpricot released then I should be able to re-apply what I learnt.
I use iPhoto Library Manager to manage the size of my iPhoto libraries.
When I need to split libraries there isn’t a easy way to delete photos that match your criteria (I use date) from the library.
If there are less than 50% of the photos that I want to keep in a library then I can just create a smart album that contain those photos and simply drag and drop the album to a new library. But when there are more than 50% then it is faster to delete the unwanted photo from the existing library.
That is the problem, there isn’t an easy way to delete a bunch of photos from library that belongs to a certain album (i.e. match certain criteria).
My solution is this, iPhoto has a Bulk Update (cmd+shift+B) function. So I select all the photos in the album that I want to delete and use Bulk Update to set the description to be ‘deleteme’ then I go to the photos and do a find (cmd+F) with the same string. Voila now I can select the photos and delete them out of the library. Just remember to empty the iPhoto Trash so you recover the disk space from the library.