Home › Posts tagged development › Page 2

development

Android NDK Standalone GCC 4.6

Posted on by — No Comments ↓

Not entirely sure when Google started to include the GCC 4.6 sources.  I have first noticed it at the current NDK r8 when running the download-toolchain-sources.sh

You have to compile it yourself.  There are instructions out there but now that google is including it things have gotten easier.  These instructions only apply to Linux.  Specifically tested in Ubuntu 12.04.

  • sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl
  • Download NDK
  • Untar NDK to [SOME_LOCATION], using /opt/ndk/
  • Set NDK_ROOT=/opt/ndk/
  •  ./build/tools/download-toolchain-sources.sh src/
  • Download MPC 0.9
  • Move mpc tar to ./src/mpc/
  • ./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) arm-linux-androideabi-4.6
  • ./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) x86-4.6
  • ./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) mipsel-linux-android-4.6
  • (Patience)

Now you can generate a standalone toolchain for distribution:

  • ./build/tools/make-standalone-toolchain.sh --toolchain=arm-linux-androideabi-4.6 --platform=android-9 --install-dir=/opt/android-9_arm/
  • ./build/tools/make-standalone-toolchain.sh --toolchain=x86-4.6 --platform=android-9 --install-dir=/opt/android-9_x86/
  • ./build/tools/make-standalone-toolchain.sh --toolchain=mipsel-linux-android-4.6 --platform=android-9 --install-dir=/opt/android-9_mips/

Done.

Similar steps can be applied to MAC OS X however setting up the development environment is far more annoying.  I have a feeling this might be near impossible to pull off in Windows without jumping through major hoops.

Swap with no Temp Variable

Posted on by — No Comments ↓

When I used to TA for the University of Saskatchewan in our intro C/C++ first year classes I used to try and challenge the students sometimes.  When the assignment rolled out on sorting the students were instructed to swap two variables.  As brand new programmers sometimes something as simple as swapping two variables doesn’t leap out at you.  Of course we just teach them that you need a temp variable and mission accomplished.  Well I always offered bonus marks for anyone who could derive the variable swap with no temp variable.   Years pass, no student ever got back to me with the answer ( they obviously didn’t have Google Fu ).  I find myself writing a routine today that required a swap.  I still remembered the trick:

int main()
{

int x = 42;
int y = 51236;

printf(“X before swap = %d\n”, x);

x ^= y;
y ^= x;
x ^= y;

printf(“X after swap = %d\n”, x);

return 0;

}

XOR god mode and fairly easy to remember. X xor Y, Y xor X, X xor Y.  Useful for any POD that is expressed as bytes consistently across architectures.

Needless to say this is a fun trick to blow the minds of long time programmers.

GIT Work Flow

Posted on by — No Comments ↓

I get asked a lot about SVN, GIT, Mercurial.  It is clear to me that SVN has been superseded by GIT and I think many others agree.  Go ahead and read a great comparison here (GitSVNComparison).  My favorite addition (other than the dramatic decrease in size of repositories) is the branching mechanism that GIT adds.  This also becomes the learning curve to long time SVN users.  SVN users famously create the classic trunk,branch,tag structure for every repository they use but almost never utilized anything but trunk.

So the biggest learning curve with jumping into GIT is the intended workflow.  Lets take a quick look at how one should use GIT when working on a group project.  This workflow maximizes modularity of your code additions and minimizes the downtime created by conflicts.  To get you thinking while you are reading.  Typical branching usage is to have each developer work in their own branch.

First some terminology:

  • master branch –  This is essentially your trunk in SVN.  This is the main working branch in SVN.
  • local commit – In GIT everything you commit is local until you push.
  • remote push – Since all your commits are local, they need to be pushed to the remote server.
  • checkout – In GIT this refers to checking out a branch, the entire repository is morphed into a branch when you perform a checkout.
Now the intended workflow:
  1. Clone the repository, URL is often provided.
    git clone git@github.com:halsafar/TerraMater.git
  2. Create a branch for you to work in.
    git checkout -b experimentalBranch
  3. Do some work!
  4. Commit your work.
    git commit -a
  5. Push your branch to the remote server (optional!), required if you want to get your branch from another machine.
    git push origin experimentalBranch
  6.  You have completed your bug fix lets say, time to merge your changes into the master branch.  First we have to checkout the master branch.
    git checkout master
  7. Make sure we have an updated master branch.
    git pull
  8. Time to merge your branch into master, this is the conflict resolution step.
    git merge experimentalBranch
  9. If all went well, push the updated master branch to the remote repo
    git push
 Now what if we are working on our experimental branch and some very important bugs are fixed and pushed into master.  These changes will directly impact your work.  It might be easier at this point to merge master into your branch so you can get the updates and keep working.
  1. Make sure you are on your branch.
    git checkout experimentalBranch
  2. Merge master into your branch
    git merge master

 

Android SurfNet Workshop

Posted on by — No Comments ↓

Over the past year I was on the intern team for a Canadian research network called SurfNet.  SurfNet primarily concerns itself with interactive surfaces and things you can touch like a touch table or SMART boards.  The intern team gets projects submitted to them by professors that are part of the research network.  It was fun to work on the intern team but unfortunately it was not a lot of team work.  The majority of the projects came from my local university and I worked alone.  Even after finishing with them September 1, 2011 they are still keeping me on the payroll to work unofficially for them.  They wish to put the entire team on a project I have been working on over the past few months.

Every year they hold a conference and gather all the people involved in SurfNet.  This year it was held in Calgary, Alberta at the University of Calgary.  Excellent establishment, great people and an all around fun time.  This year they offered students to submit ideas for workshops.  I decided to submit a workshop on Android development.  Albeit not to related to SurfNet it is still an interactive surface and almost everyone is beginning to pick up on Android as the best way to developer quick research projects targeting mobile devices.  So I gave a 1.5hr talk on Android and it generated some pretty good interest. Here are the slides purely for interests sake.

Presentation Download

Halsafar