[SOLVED] Sublime Text 2: Git binary could not be found in PATH

Got this annoying dialog popping up on Sublime Text 2?
Screen Shot 2014-07-22 at 4.31.03 PM

Go to Preferences > Browse Packages …

Screen Shot 2014-07-22 at 4.33.02 PM

a Finder window will open, go to the “Git” folder, open the file called “Git.sublime-settings”

Look for “git_command” and set it’s value to the path of your git executable

Screen Shot 2014-07-22 at 4.31.47 PM

(you can find the path of your git executable on the Terminal by typing “which git”)

Screen Shot 2014-07-22 at 4.35.24 PM

Setting up Eclipse as your IDE for Bitcoin C++ development on MacOSX.

If you are a Java developer used to the productivity levels achieved by working with eclipse’s code navigation, code completion and refactoring tools, it’s worth your time staying in eclipse for any sort of C++ development.

Screen Shot 2014-02-09 at 1.03.21 PM

This post refers specifically to getting your eclipse environment to work with a particular C++ Open Source project, The Bitcoin Project.

Before you start setting up eclipse, please make sure you can build Bitcoin from the command line, this way you know that you have everything necessary to build Bitcoin, even if you’re still getting a few errors showing in Eclipse, in the end Eclipse will be using the Makefiles provided by the project whenever we need to compile (and it can do so incrementally when possible saving you a lot of compilation time)

I’m assuming you have installed:
– eclipse
eclipse CDT tools, up to date for the version of eclipse you’re working with (I’m still working with Juno)
– Qt/Eclipse plugin (optionally)
– All the dependencies (autoconf automake berkeley-db4 boost miniupnpc openssl pkg-config protobuf qt gdb) necessary to build Bitcoin which are easily installable via HomeBrew.

1. Let’s import the bitcoin/ project to our workspace.

File > Import > Existing Code as Makefile Project

Screen Shot 2014-02-09 at 12.41.45 PM

 

Look for the bitcoin/ git checkout folder, and make sure you use the GNU Autotools Toolchain

Screen Shot 2014-02-09 at 12.43.05 PM

 

Click Finish.

2. Fixing the C++ compiler Path and Symbols.

Right click on the project containing folder in the Project Explorer > Properties.
Go to C/C++ General > Paths and Symbols > Languages: GNU C++ >  “Includes” Tab and make sure it looks something like the screenshot below (I got those paths by looking at  the  ones used by the Makefiles in the Bitcoin. Hit Apply , OK, then wait for the reindexing, you might still have a few weird errors because of how the compiler checking settings are.

Screen Shot 2014-02-09 at 12.55.38 PM

3. Remove a few more issues like “Error: Invalid arguments candidates are: void resize(?, int)."

We open again the project Properties, this time we go to C/C++ General > Preproessor Include Paths, Macros, etc.
Click on the Providers tab and make sure “CDT GCC Built-in Compiler Settings [Shared]” is checked. Hit Apply, OK, wait for reindexing.
If there are still errors, you might want to just delete them and refresh the project (F5 on the project folder in the Project explorer), all errors should be gone by now.

Screen Shot 2014-02-09 at 1.01.25 PM

Now start working just as fast as you’re used to with Java on Eclipse.

 

Code completion…

Screen Shot 2014-02-09 at 1.09.39 PM

 

Project wide renaming refactors in seconds…

Screen Shot 2014-02-09 at 1.10.07 PM

 

 

Find references of variables, methods, classes (Cmd+Shift+G)

Screen Shot 2014-02-09 at 1.23.37 PM

 

Find all the implementations of an interface (Cmd+T)

Screen Shot 2014-02-09 at 3.34.39 PM

and best of all

Interactive debugging with gdb*

Screen Shot 2014-02-11 at 1.21.07 PM

and all the tools you know and love from Eclipse.

*Setting up GDB debugging

To do step by step debugging you can use gdb, if you don’t have it installed just go to your Terminal and type brew install gdb.

On your command line, execute your Makefile to create an executable, once it appears on your Project Explorer you can Right click on it Debug As > Debug Configuration…

Screen Shot 2014-02-11 at 1.31.43 PM

then make sure you have set gdb as the executable debugger in the “Debugger” configuration tab, then just set your breakpoints and debug away!

Screen Shot 2014-02-11 at 1.32.00 PM

Not so fast… 🙁

As of Mac OSX 10.9, Apple decided that you cannot use gdb unless the gdb executable is signed with a certificate, they want you to use their super duper lldb debugger, but it’s still not compatible with Eclipse, you know, so you use their XCode IDE instead of what you want to use…

Anyways, signing the gdb at /usr/local/bin/gdb is not that hard.

To sign it you can create a certificate, or use an existing developer certificate. In my case, I already had a Mac Developer certificate so it was a very simple process, just issuing a single command in the Terminal and I finally got rid of the "Unable to find Mach task port for process-id 93213: (os/kern) failure (0x5).\n (please check gdb is codesigned - see taskgated(8))" error.

codesign -s “Name of my certificate here” /usr/local/bin/gdb

Then I tried debugging, I got a password dialog to verify I was the owner of the certificate, and then gdb could take over and then I could do my step by step debugging, with the ocassional crash.

Happy Hacking.

WordPress: Cannot create directory error, got everything chmoded to 777?

So you went as far as chmod’ing your entire folder structure to 777 (very unsafe), you’ve hacked wp/wp-admin/includes/file.php

return new WP_Error( 'mkdir_failed_ziparchive', __( get_current_user() . ' Could not create directory. ('.$_dir.')' )...

to print out exactly what directory it cannot create and what user is trying to create the folder, everything is correct, yet it won’t create the fucking folder?

the issue might be your vsftpd configuration!

Go to /etc/vsftpd.con and make sure that you have this setting uncommented:

write_enable=YES

restart your vsftpd (sudo service vsftpd restart) and try upgrading again, you’ll want to hit that ‘Donate Bitcoin’ button if I saved your ass today.

Cheers

AWS troubleshooting: how to fix a broken EBS volume (bad superblock on xfs)

As great as EBS volumes are on Amazon Web Services, they can break and not ever mount again, even though your data could still be there intact, a simple corruption on the filesystem structure can cause a lot of damage. On this post I teach you how to move all that data onto a new EBS drive, so keep calm and read slowly.

So, you try to mount your drive after some updates and you get an error like this on dmesg | tail:

[56439860.329754] XFS (xvdf): Corruption detected. Unmount and run xfs_repair

so you unmount your drive, invoke xfs_repair and you get this…

$ sudo xfs_repair -n /dev/xvdf
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
..........................................

and no good secondary superblock is found.

Don’t panic, this is what you have to do next to solve this issue:

  1. Go to your AWS dashboard, EC2 section.
  2. Click on “Volumes”
  3. Find the broken volume.
  4. Create a snapshot of the broken volume (this takes a while)
  5. Create a new volume the same size (or larger than) your old drive out of the snapshot you just created (this takes a while)
  6. Attach your new volume to the same EC2 instance (no need to reboot or anything), if the old drive was mapped to /dev/xvdf, the new one will be mapped to /dev/xvdg (see how the last letter increases alphabetically)

Now here’s a gotcha, Amazon will not create your new drive using the same file system type (xfs), for some reason it will create it using the ext2 filesystem.

$ sudo file -s /dev/xvdg
/dev/xvdg: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=2e35874f-1d21-4d2d-b42b-ae27966e0aab (large files)

Here you have two options:
1. Live with the new ext2 file system, make sure your /etc/fstab is updated to look something like this:
/dev/xvdg /path/to/mount/to auto defaults,nobootwait,noatime 0 0

or 2. copy the contents of your drive to a temporary location, usually inside /mnt which has plenty of space from that ephemeral drive the ec2 instances come to, and then mkfs.xfs the new volume, and then copy the contents back… (which what I did, as I chose to create a larger drive and the ext2 format that came on the new volume only recognized the size of the snapshot)

Hope this saved your ass, leave a note if I did.

Remember to never do any irreversible action until you have a disk snapshot, try your best to never lose data.