This holds problems we've seen in the course of our work that have non-obvious answers.

Log in with the prod-read account. Select the module and version you're interested in. If you can't see what you're looking for, it might be collapsed.

What's up with jsonify + camel_cased=True?

this question's been asked a bunch of times, and komalo wonderfully commented in review #K106871:

But here is the background with camelCasing JSON items as they are returned from the server: 

1. the objects, on the server, have underscored variable names 
2. our JS style guide uses camelCase (as is consistent with almost every other 3rd party JS library we use) 
3. likewise, we use Backbone, whose models sync directly with attributes as returned from JSON from the server 

Combine these 3 points, and you have a world of pain. Since if you don't translate the JSON objects to camel case, then your Backbone views will have underscored properties if returned from the server, and camelCased properties otherwise. 

My ideal world would be this: 
- *always* return camelCased JSON from the server, and *always* translate from camelCase to underscore when accepting JSON to the server 

Unfortunately, we had a lot of legacy code when we started to use Backbone/JSON based API's in our main app, so I made jsonify accept a parameter. So now we have a world where some endpoints return underscores and some return camelCase. 

There is no good solution now. The way I see it, there are two options to deal with what we have: 

Option A: 
- continue trying to eliminate all legacy code that uses underscore JSON objects, and translate using camel_cased=True in all future places 

Option B: 
- give up on camel_cased=True, and make explicit all JSON sources from the server by using under_score. Unfortunately, in order to do this, we would also have to make all Backbone Model and View properties use underscores, because it would be a disaster if they were mixed. Likewise, it would propagate out to handlebars files. 

I still believe Option A is the cleanest, but I could be convinced otherwise. I didn't do a good job communicating this to the team, though, and am happy to work with anyone who wants to help me fix this situation. :)

I'm getting a seemingly random layer_cache CacheMissError:

Visit /devadmin/content?refresh_caches=1&version=default to refresh the PublishedContentCache with the latest and greatest. The exact stack trace will depend on what page you're trying to load, of course. See https://sites.google.com/a/khanacademy.org/forge/for-developers/cachemisserror-and-the-publishedcontentcache!

layer_cache unexpected miss: TCE:default_version:__VERSION_GLOBAL__@684_9

layer_cache.py:340:in `get_cached_result_raw' topics/cache.py:175:in `get' topic_models.py:182:in `get_default_version' topic_models.py:1002:in `get_by_id' homepage.py:169:in `new_and_noteworthy_link_sets' layer_cache.py:465:in `layer_cache_check_set_return' layer_cache.py:219:in `wrapper' homepage.py:443:in `render_full' homepage.py:421:in `get' user_util.py:144:in `wrapper' ssl_util.py:84:in `wrapper'
I'm getting this error on startup: 
dev_appserver_main.py:640] <class 'google.appengine.runtime.apiproxy_errors.ApplicationError'>: ApplicationError: 3 Could not read data from /Users/tom/source/KA/datastore/data. Try running with the --clear_datastore flag. Cause: ValueError('insecure string pickle',)

It means you didn't start the appserver with --use_sqlite.

I can't install numpy with pip install -r requirements.txt on Mac

OS X 10.9 and 10.10

As of June 2015, these instructions are inspired by the gist at https://gist.github.com/goldsmith/7262122. Tested by Andy.

# Install the Xcode command-line tools
xcode-select --install

# Wait until the GUI completes, then:
# Install an older version of GCC via homebrew.
brew tap homebrew/dupes
brew install apple-gcc42

# Use flags from the gist to install Numpy 1.6.1 successfully.
CFLAGS="-arch i386 -arch x86_64" FFLAGS="-m32 -m64" LDFLAGS="-Wall -undefined dynamic_lookup -bundle -arch i386 -arch x86_64" CC=gcc-4.2 CXX="g++ -arch i386 -arch x86_64" pip install numpy==1.6.1

OS X 10.8

As of April 2013 on 10.8.3, while numpy installation works following the OS X 10.7 instructions below, SciPy needs extra work. It can be installed via homebrew. Tested by Chris.

# This is what I wanted to run...
$ brew install samueljohn/python/scipy

# ...but some dependencies were needed first:
$ sudo easy_install nose
$ brew tap homebrew/science
$ brew tap samueljohn/python
$ brew install samueljohn/python/scipy

# By the time you read this the formula may be homebrew/science/scipy instead.

# At this point scipy is installed into homebrew, but your system python
# or virtualenv python may not be able to see it. I had to link it into my
# virtualenv like this:
$ ln -s /PATH/TO/homebrew/lib/python2.7/site-packages/scipy* ~/.virtualenv/khan/lib/python2.7/site-packages/

OS X 10.7 and below

See this thread: http://stackoverflow.com/questions/13106919/numpy-installation-on-mac-10-8-2/14131249#14131249

This is how I fixed this problem:

export CC=gcc
export CXX=g++
export FFLAGS=ff2c

Based on the information I found under the 10.7 installation instructions here: http://www.scipy.org/Installing_SciPy/Mac_OS_X

Running 'make deps' fails with "unused-command-line-argument-hard-error-in-future" error

This error occurs when you have a relatively recent version of XCode installed, since XCode 5.1+ no longer accepts this parameter. This can be circumvented by running 'ARCHFLAGS=-Wno-error make deps' instead, which will suppress the relevant gcc errors. This may also suppress other errors as well, so use with caution!

Google AppEngine dev server crashes with "IOError: [Errno 13] file not accessible"

This worked for me:

"Simply remove (or rename) the file(...)lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg"


mv /Users/stchangg/.virtualenv/khan27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg /Users/stchangg/.virtualenv/khan27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7-moved.egg

pyobjc-framework-FSEvents fails to install with "AttributeError: 'module' object has no attribute ‘_install_lib’"

We're still working through this one, but in the meantime, Dylan notes: "Your dev server will still work fine, but it won't be as fast as it could be. When the FSEvents wrapper isn't available it will fall back to polling the files' mtimes to detect changes and reload the code."

Test runs fail with OSError: [Errno 24] Too many open files

You can override this limit by running ulimit -S -n 2560