Developers/Issues

  For Developers

Previous Next

Localization

The OLPC project is deploying in a large number of countries, each of which has unique cultures and languages. To be accessible to the children in these countries we have to internationalize and localize our software for each country. Regardless of which Activity stack you are working on, your project will need to be localized.

The quick summary of how to make your project internationalizable is to:

• always remember that you will need to internationalize (so avoid building assumptions of culture into the activity)
• use gettext for all user-facing strings, text, icons and the like

If you do that the job of internationalizing won't be finished, but it will be reasonably straightforward and won't require a lot of retrofitting.

See: Localization for extensive documentation on how to Localize your Activity

Hardware Constraints

While Sugar can run on almost any computer, the target of the OLPC project is to run on extremely inexpensive machines, and particularly the OLPC-XO. As such, you need to target your projects to the constraints of the hardware.

Modularity is Good

Breaking out the functionality of your application into separately-loadable plugins or modules can allow for substantial memory and/or storage savings.

For example, GAIM supports just about every IM protocol in existence, but we can only anticipate 3 being common. Leaving off the unneeded plugins saves both memory and flash-storage footprint.

For Python development, don't import modules at the top. Instead, import them just where they are needed in the code and then unload the module. This will require some work with ihooks and imp to support unload() but for now, just use a dummy function in your code.

If possible, implement optional components as a separate Python module and delete the .pyc file when a user chooses not to use that option. Remove objects when they are no longer needed using del.

Memory leaks

Normally when programming in high-level garbage-collected languages such as Python, Javascript or Smalltalk you normally do not need to worry about garbage collection. In lower-level language development, including extensions for high-level languages you need to be more on your guard.

It is a good idea to check for memory leaks at least a few times during the development process. Sample the memory size every minute and graph it. If there is a slowly increasing size, then you have a leak. A normal program will increase rapidly at the beginning and then remain perfectly flat or shrink and grow repeatedly.

Remember that every leak, however small, counts!

Storage

An OLPC-XO has 1GB of storage using a JFFS2 compressing, wear-leveling file-system. JFFS2 compression tends to provide about 2:1 compression for text and typical data, with no extra compression on already compressed data.

It is possible to install JFFS2 on a Linux machine should you feel you need particularly precise measurements of your storage usage. This likely isn't practically necessary, try to keep the size down and use the zip-compressed size as an approximate estimate of the JFFS2 storage requirement.

Power Usage

• Ability to operate applications when running in black/white mode

Judicious use of contrasting colors will mean that your program automatically works in B&W mode.

• The effective resolution in color mode is somewhat lower in color than grayscale: some applications will find this hard, even though the frame buffer will always be in high resolution. If your application does not honor the font resolution change-on-the-fly mechanisms, or hardwires fonts by pixel size, your application won't be able to switch modes gracefully and may require manual intervention to be usable. Please fix.
• The hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well
• No 3D hardware: we don't have shaded triangles or a geometry pipe; so any OpenGL used will be based on Mesa, and without hardware, will be very slow

Ideally, don't use OpenGL at all except for specialty applications which absolutely must and which can accept the slow rendering. For instance a design program could use OpenGL to provide a rendered view because most of the time the user will not be using OpenGL.

Remember that the Geode supports MMX and Enhanced 3DNow!, which can speed up some applications, such as 3D rendering, and should be appropriately used.

• Choice of libraries and required applications: you may not have the dependencies you might need, or those dependencies might come at too high a memory cost. We will inventory what you can "count on" in the basic system as it becomes clear.

In the meantime, make sure you know your application's dependencies. For compiled code, run it with "ldd" to get a list of all the libraries being loaded. For Python code, run it with "python -v" to get a list of all modules imported.

• Graphical activity that does not turn itself off quickly; we want to save power

This means avoid cute animated GIFs that do not add value to the educational experience. (That is one example of not letting the CPU be idle) Your users may have to exert themselves physically to provide the electricity to run their OLPC. Respect them and their effort.

• CPU performance: the system is slow relative to current desktops, though fast relative to desktops at the turn of the millenium.
• Power consumption: if your application is CPU bound for long periods (not letting the CPU be idle), or routinely requires itself to be run (can't be suspended well), this isn't good
• While we are a great fan of interpreted languages, key CPU bound kernels had better be in compiled code, or your performance and power consumption will be poor.

Python is an interpreted language, similar in operation to perl. It lacks a JIT, though it does use an intermediate code form rather than strictly interpreting the raw text as a shell script or makefile would. It is thus inherently slower than C# or Java, but not as bad as it could be. A more serious problem for Python is often memory consumption.

• Remember that your slow code has a direct impact on power consumption (far more than on a desktop), and its usability. Applications that run slowly or don't let the processor idle will be very, very unpopular on battery powered machines that may be powered by children having to run a generator.
• The file system is a flash file system, so its write performance is slow, while random access is actually very good. The performance is glacial if the file system is low on space and has to continually erase freed blocks before writing (JFFS2 attempts to do this in the background, but if it can't....). Programs that continually write to the file system without need are anti-social; wear leveling helps flash longevity, but it certainly doesn't help, and burns power. Writable file mappings (via the mmap system call) may not be supported.
• Looping waiting for events (or other busy-waiting) eats power; don't do it. Poll and select with timeouts are your friends. Don't gratuitously wake up at frequent intervals just to test if something has happened; design your hardware and software to be completely idle between events they have to respond to.

Right now this is a nice summary page. But items like this deserve some more explanation along with some sample code that uses select/poll/inotify/signals instead of busy-waiting.

• Keep in mind that the OLPC wireless network is peer-to-peer. Design applications accordingly. We can presume at least some technology like mDNS (e.g. Avahi) is available for discovery.
• Applications should be localizable.

If you will be using Python, start by reading these 31 slides about how to use Unicode in Python: http://downloads.egenix.com/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf

Next, read the page on gettext and it's documentation. Become familiar with GTK+ and Pango features for I18N and L10N.

You can create a fake translation with lengthy text containing non-ASCII characters. It is common to do this with Cyrillic (Russian) and Greek characters that are shaped similar to English characters. Does the text get rendered? Are any graphical elements too small? East-Asian characters may need extra height, along with some of the double-accented characters used in Eastern Europe. Right-to-left scripts like Arabic should also be considered.

• Read and comprehend Dave Jones' paper on "Why Userspace Sucks"; a summary and pointers to the paper can be found at LWN. Note that most of those problems are now being worked on; please do not make similar mistakes!
• What kind of applications are needed?

have a look at Sample Applications for some ideas. Or, release an early prototype of your own app as a sample application to help others learn the ropes of developping for this innovative, i.e. non-standard laptop.

Previous Next