405 Error on Google App Engine

I was happily programming away on a new project on Google App Engine when I started getting 405 errors from all of my handlers. I would get the following in the dev app server log:

dev_appserver.py:3317] "GET / HTTP/1.1" 405 -

In the Firebug:

URL                   Status                
> GET localhost:8084  405 Method Not Allowed

In the browser when I tried to directly access pages they would render normally but if you looked at the headers I was still getting the 405 error and anything Ajax would fail. From looking around Google and StackOverflow there seemed to be a various reasons for this to fail, none of which seemed to be my issue.

What eventually turned out to be the issue was that I was trying to be a good OOP programmer and was calling up the inheritance tree for each of my methods. So HomeHandler.get() was calling BaseHandler.get() was calling webapp.RequestHandler.get(). Unfortunately, it seems that webapp.RequestHandler.get() does not exist or is at least not callable which resulted in the 405 status code. I changed my BaseHandler.get to not call webapp.RequestHandler.get and we were back in business.

Hopefull this blog post saves you some time.

Modeling collections in Google App Engine

When I first began working with Google App Engine I assumed I would need to model a one-to-many relationship manually with a db.ReferenceProperty in each of the manies and db.ListProperty(db.ReferenceProperty) on the one. The actual solution is much simpler and elegant:

class StackUserData(db.Model):
    name = db.StringProperty()
    last_access = db.IntegerProperty()

class Activity(db.Model):
    user = db.ReferenceProperty(StackUserData,
                                collection_name='activities')
    title = db.StringProperty()
    body = db.StringProperty(default='')
    link = db.LinkProperty()
    creation_date = db.IntegerProperty()
    last_activity_date = db.IntegerProperty()

This adds an activities attribute to StackUserData behind the scenes. So StackUserData.activities will give you a list of all activities owned by that StackUserData instance. This relationship is set when creating the Activity:

Activity(user = activity_owner_user).put()

This code will create a new Activity and attach it to the activity_owner_user.

Find out more at Datastore series: Modeling Entity Relationships

Aero Snap Keyboard Shortcuts in Ubuntu

I wanted the "Aero Snap" functionality in Windows 7 to work on my fresh Ubuntu 10.10 install. In case you are not familiar, this allows a window to snap to a certain position. I have a widescreen monitor that is wide enough to comfortably have two windows side by side. Arranging this by hand is a pain. The snap feature will automatically resize a window to maximum vertical and half the width of the screen on either side. In Windows 7 you can either drag the window to the sides of the desktop or you can use the Windows key + arrows shortcuts. I was mostly interested in the shortcuts.

I found the basic solution at Get Aero Snap in Ubuntu

The instructions as given did not quite work for me so I just hardcoded in the width of my screen:

WIDTH=1920 && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,0,0,$HALF,-1
WIDTH=1920 && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,$HALF,0,$HALF,-1
wmctrl -r :ACTIVE: -b toggle,maximized_vert,maximized_horz

Note that I did not need to change the last entry for going full screen. Then under the General Options of the Compiz Settings Manager I just mapped Key Bindings rather than Edge Bindings.

Command 0 to Windows Key + Left Arrow
Command 1 to Windows Key + Right Arrow
Command 2 to Windows Key + Up Arrow

Problems compiling Chromium with distcc

So everything appeared to be working, however, I am getting compile errors when using distcc that I am not getting when I only compile locally. Will investigate more...stay tuned.

Using distcc to build Chromium with mix of 32 and 64 bit machines

I have been wanting to hack on Chromium for a while and have finally found the time to download the source and try building it. The first build on my main desktop took quite a while so I thought I would also take the opportunity to try out distcc, incorporating an older laptop that I had lying around as well as my new netbook. The desktop and netbook are both 64 bit and the older laptop is an i686.

All the machines are running Ubuntu 10.10, netbook and desktop running the 64 bit build. On the i686 I installed the multilibs package (see previous post).

I was initiating the build from the 64bit desktop. Since this system was already a 64 bit system it would compile 64 bit by default. However, the 32 machine would compile only 32 bit by default. To fix this problem, I needed to explicitly set the flags for generating the 64 bit executables. So on the 64 bit system I set CFLAGS and CXXFLAGS to -m64.

I wish it had actually been as easy as this post may lead you to believe it was but I spent a couple of days on this and asked one question on Stack Overflow.

Cross compiling 64 bit program on 32 bit machine (Ubuntu 10.10)

In preparation for creating a small build cluster for helping with compiling Chromium I was trying to get my old college laptop up and running under Ubuntu 10.10. I installed the g++-multilib package as multiple sources on the internet had instructed but when I tried compiling 64 bit hello world I got the following error:

In file included from main.cpp:1:
/usr/include/c++/4.4/iostream:39: fatal error: bits/c++config.h: No such file or directory
compilation terminated.

Searching through /usr/include yielded a couple instances of bits/c++config.h but they were all located under different architectures (i486-linux-gnu, i686-linux-gnu).

Googling around did not result in much so I decided to ask the fine folks over at Stackoverflow (link to question is at bottom of page - if you read it now, this post will be significantly less interesting). One answer told me to explicitly include the path for the c++config.h file from the other architectures - this worked but it seemed a bit hacky to have to explicitly set include paths for system includes.

I had not used the verbose parameter for g++ before so I thought I would give it a try to see if that could explain a little more what the system was trying to do:

jesse@shalored:~/projects/test$ g++ -v -m64 main.cpp
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-m64' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/i686-linux-gnu/4.4.5/cc1plus -quiet -v -imultilib 64 -D_GNU_SOURCE main.cpp -D_FORTIFY_SOURCE=2 -quiet -dumpbase main.cpp -m64 -mtune=generic -auxbase main -version -fstack-protector -o /tmp/ccMvIfFH.s
ignoring nonexistent directory "/usr/include/c++/4.4/i686-linux-gnu/64"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/i686-linux-gnu/4.4.5/include
/usr/lib/gcc/i686-linux-gnu/4.4.5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++ (Ubuntu/Linaro 4.4.4-14ubuntu5) version 4.4.5 (i686-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128197
Compiler executable checksum: 1fe36891f4a5f71e4a498e712867261c
In file included from main.cpp:1:
/usr/include/c++/4.4/iostream:39: fatal error: bits/c++config.h: No such file or directory
compilation terminated.

The ignoring nonexistent directory error messages was what gave me the clue. Since it was looking for /usr/include/c++/4.4/i686-linux-gnu/64, I checked my 64 machine hoping to see a similiar structure but with an x86_64 architecture and corresponding 32bit directory. Sure enough it was there: /usr/include/c++/4.4/x86_64-linux-gnu/32/bits. To fix my problem I just copied the /usr/include/c++/4.4/x86_64-linux-gnu/bits directory from my 64 bit machine to /usr/include/c++/4.4/i686-linux-gnu/64/bits on my 32 machine.

Now I know this is not a proper solution since the next update to the system could break something but I think it was enough to get going. Now on to getting this system to help out with building!

Stackoverflow Question: Missing include “bits/c++config.h” when cross compiling 64 bit program on 32 bit in Ubuntu