Getting started programming

From OLPC
Revision as of 17:46, 13 December 2007 by Mcfletch (talk | contribs) (→‎Option 1 - Emulated XO: Clarify when recommended)
Jump to navigation Jump to search
  english | 日本語 | 한국어 HowTo [ID# 84438]  +/-  

Thank you for considering working on the One Laptop Per Child project. This page tries to provide you with the answers you need to get started either by contributing to existing projects or starting your own. Getting started is not yet as easy as we would like it to be (OLPC growing pains) - helping with that is one of many ways you might contribute.

Where to find code

On our trac install, mostly - http://dev.laptop.org.

Check out Development terminology for a description of some of the labels we use there.

Current release schedule

2006-11-18   Factory.1 (Build 185; Firmware Q2B11)
2007-04-31   Factory.2 (Build 386; Firmware Q2C09)
2007-05-08   Factory.3 (Build 406; Firmware Q2C11)
2007-08-04   Factory.4 (Build 542; Firmware Q2C22)
2007-10-26   Factory.5 (Build 622; Firmware Q2D02)
2007-10-30   Ship.1 (Build 623; Firmware Q2D03)
2007-11-02   Feature freeze for Update.1
2007-12-01   Update.1 (==Ship.2)

We expect to be doing updates monthly through the first quarter of 2008. After that, we will likely adopt a three-month update cycle. Eventually we will adopt a six-month update cycle.

It should also be noted that we will be—when time permits—moving to a build environment that enables individual activity developers to maintain their own build cycles.

Setting up a Development Environment

The OLPC's software environment is a heavily modified Fedora 7 Linux system running a custom GUI shell (Sugar). To develop for the platform you will eventually need access to a platform which runs in a manner substantially similar to the OLPC environment. Luckily there are many available options.

Option 1 - Emulated XO

An emulated XO laptop is the recommended platform for "checking out" the Sugar environment, testing activities and for initial development of new activities. By installing an emulation package on your (reasonably powerful) host desktop, you can run an emulated version of the Sugar environment which is essentially the same code as runs on the real laptops.

An emulated XO does not provide tools such as SVG editors or Integrated Development Environments. You will normally run such software on your host machine and push the results onto the emulated machine.

The emulated XO has certain limitations with regard to the specialized hardware in the XO. See the Developer's FAQ below for some pointers on how to simulate the special hardware.

Option 2 - sugar-jhbuild

This is what the core development team uses and is one of the most pleasant ways to work. Compared with using an Emulated XO, installing sugar takes more time and space to set up, and can be difficult to maintain, but results in a more flexible better environment. If you are intending to work on the core system/activities you will likely need to use sugar-jhbuild to set up your environment. See Sugar with sugar-jhbuild to get going. The 'native' environment for sugar-jhbuild is Fedora 7 and Ubuntu (feisty or gutsy).

This approach also works nicely under emulation (Qemu, Parallels, VirtualBox or VMWare) on Linux, Windows or Mac OS host operating systems. This allows you to work without rebooting even when using sugar-jhbuild, and without risk of corrupting your host operating system.

On 32-bit Linux

To get a working Sugar using jhbuild you will need to be running an OS that provides compatible versions of the various libraries that Sugar requires (basically a very up-to-date Linux platform).

As of 2007-12-13 the distributions known to be able to support sugar-jhbuild are:

At the moment, a Fedora 7 install with sugar-jhbuild is probably the most "sure" approach to getting a working full-speed (non-emulated) working environment for developing on Sugar with the latest libraries and solid upgrade path. As most of the core developers are working on Fedora boxes with sugar-jhbuild it is the most likely environment to be supported and continue to receive support.

On 64-bit Linux

As of 2007-12-13 it is possible to build Sugar on 64-bit Linux with trivial workarounds/fixes. This has been confirmed on Gentoo amd64 and Debian Lenny (with the caveats below).

Sugar seems to be working on Debian Lenny (2007-11-05), though Python 2.5, even when installed, is not detected. Comment out the line jhbuild.commands.run('sanitycheck', config, []), line 95, to get it to install.

Option 3 - Native Sugar Packages on Linux

As Sugar stabilizes and is ported to more distributions, it should be possible to use your Linux distribution's package management system to install Sugar. Distributions with ports so far:

  • Ubuntu Gutsy -- Note that we need more testing of this package-set, please let us know your experiences

If you don't see your distribution here, ask your distribution maintainers, or if you have the skills, create the packages yourself and submit them.

Option 4 - A real XO laptop

Hardware Developer's Program - while there are only a small number of test units being produced, developers can submit proposals to receive one of those units for testing and development.

You can also, if you live in the US or Canada, and have sufficient funds, until Dec 31, 2007 use the Give 1 Get 1 program to acquire a production-run machine (and donate one to a child).

Operating Environment

Official description of the Software components on the laptop (XXX maybe merge this into that page, we want links to further information about each library, though?)

Development Languages:

  • Python is strongly encouraged, to have a single language "under the hood" when the curious child looks inside
    • C/C++ should be used where Python performance is unacceptable, but try to keep it to a minimum, preferably as standard well-encapsulated and documented components
  • Smalltalk-speaking developers may wish to work within the eToys environment
  • Javascript can be used in web-based applications (Gecko or Opera engine Javascript implementation)

GUI Environments:

  • PyGTK or the PyGTK-derived Sugar system should be used for most "Window, Icon, Mouse, Pointer" type GUIs. Note, however, as of 2007-04-21 that the Sugar "graphics" package is in Flux.
  • Pygame SDL-based 2D game environment can be used for "Canvas" graphics using "Sprites".
  • (Mozilla) XULRunner can be used to develop Gecko-based activities
  • EToys

Operating Stack:

Libraries/modules/services of note:

  • D-BUS -- efficient Desktop-level RPC engine, most specialized laptop hardware and operations are exposed over DBus
  • Telepathy (Glib, Salut, Gabble) -- collaboration/communications engine with "Tubes" (cross-machine RPC over DBus) and various network traversal and discovery logic, activities are encouraged to use Tubes where ever practical
  • CSound -- acoustically modelled sound-synthesis engine (seen in the TamTam activity)
  • Abiword -- collaborative text editor/word processor usable as a GTK widget that can be embedded in other activities
  • SQLite -- lightweight relational database
  • XULRunner (with Python DOM-capable bindings) -- Gecko 1.9 (Firefox 3.x) engine
  • GStreamer -- general purpose media streaming platform, used for accessing the video camera and playing media
  • Avahi -- discovery and advertising mechanism for mesh-hosted services

Common libraries not available:

  • OpenGL
  • Server-based relational databases (MySQL, PostgreSQL)
  • If you are unsure whether something is supported, ask, or load up an emulated machine and check for the presence of the library

Testing/working:

  • Announce your project on the OLPC devel list so that people know what you are working on and duplication of effort is reduced
  • Add your project to the Software projects page
  • Test your application in an official image (or a physical laptop) before publishing broadly
  • To conserve memory or improve performance, consider replacing problematic areas in your Python code with C. For example, a rewrite of the hardware manager service in C saved 1.8 megabytes of private dirty memory. On a machine with only 256 megabytes of RAM and no swap space, efficient use of memory can make the difference between a usable system and a system made unreliable by out-of-memory failures.
  • Distribute your source code under the GPL, LGPL or MIT license.
  • When ready to test with real users add your activity to the Activities page to allow for easy download and installation

Joining or Starting a Project

Most developers will probably be working on an Activity for use on the OLPC. This kind of development can normally be done with little interaction with other development groups, save for the core Sugar developers (whose work directly affects activity developers).

Communications Channels

Most of the core developers use IRC for instant-messaging-style communications: 

 irc.freenode.net #sugar #olpc #olpc-content

the Sugar mailing list is also used for broader comment and collaboration: 

 List Information

If you have a large number of developers in a given area and would like to set up a local discussion list, post to the Sugar mailing list with a request for a new discussion list.

Current Active Local Discussion Lists:

Unofficial news and interesting tidbits often show up in the blog aggregator for the project.

Requests and Ideas for Projects

Software ideas describes activity and tool types that are currently needed. If you have an idea for an activity, add it to the list in the appropriate category (create a new category if necessary). You can create a new wiki page to describe your idea in more detail.

Existing Projects

Software projects describes the currently active projects that may need help. Once you have decided on a project, add yourself to the list along with your contact information, homepage (which may be a wiki page on the OLPC wiki), etceteras. In particular, the various Activities available on the XO may need help as build time draws near; if you're looking for an existing project to get your feet wet with, check there.

Available Resources

The Developers Program provides general project management facilities for OLPC projects.

Documentation

As with most software projects, we have difficulties with documentation. We are very interested in finding people interested in documenting the system. If you are to shy about your coding skills to write code, helping us document the code-base would be an amazing and valuable contribution and might help you learn.

Tutorials

See the Tutorials page for introductory and quick-start tutorials. Game developers will likely want to focus on:

References

See the API Reference for pointers to the various libraries' reference documentation.

Resources

Code worth reading:

Frequently Asked Questions

How do I do networking in Sugar?

Recommended pattern for networking applications on the OLPC laptops is to use the Tubes/Telepathy system. This is basically DBUS remote procedure calls over telepathy networking. The Telepathy framework allows for session establishment and routing across strange network topologies. See Activity Sharing

  • Can I wrap Tubes with a socket compatibility layer to get the NAT traversal features and the like, but use old socket-based code? (yes with caveats)

The laptops will have IPv6 and IPv4 connectivity, they can use "normal" internet networking primitives as available in Python, Scheme and C.

  • Standard Python supports synchronous and asynchronous networking including basic web-servers and the like.
  • Twisted will not be available by default on the laptops but partial installs of the framework could be included in your activities if you want to do lots of multi-protocol networking operations
  • PyRO (Python remote objects) is another common Python networking RPC approach.
  • XMLRPC/SOAP can be used to produce web services

How do I create a persistent server/service?

  • How do I register for start-time loading?
  • Is there any dbus event service for loading only on response to messages? That is, not loading until there is an event of a given type, such as a presence event?
    • Yes, of a sort, services are defined in .service files, these match a named service to an executable which is to provide that service. Thus one can register to handle requests for a given named service, but you still need to arrange to have that service called by something.

How do I access the special hardware?

While Sugar will run on many machines, the OLPC-XO has some special hardware which can be exploited by software.

Camera / Camera-as-video-camera (v4l2)

See GStreamer for general instructions and OLPCGames for Pygame-specific instructions.

Directional pad/buttons
  • Have their own X key names
  • Currently 4-button set mapped to arrow (cursor) keys
  • Two separate buttons mapped to ??? (pageup/pagedown)
  • See OLPCGames for Pygame-specific instructions, key layouts and discussion of using the directional pad for gaming situations
Touchpad / Glide Sensor
  • Shows up as a normal mouse under X.
  • This is not a multi-touch capable glide sensor.
Drawing pad (stylus pad)
  • How to switch in/out of stylus mode?
  • How to set interpretation parameters?
Audio-port probe

Best sample code currently available is in the Measure Activity.

  • How to get access?
    • You configure the ALSA mixer (using os.system in the example code) and then use gstreamer events to process a the incoming audio-buffer "handoff" using a fake data sink. You unpack the data from the string values and get integer values. (Or just use the utility class (AudioGrab) in the Measure Activity).
  • What's going to come out when I get access (keeping in mind I (the developer) likely won't have the actual hardware available)?
    • You are processing a stream of audio data. In the sample code you are configuring gstreamer to produce a stream of integers at 48000 Hz. You should be able to produce the same effect using gstreamer on any linux box using your normal microphone port.
Mode-switching code for the screen

Much of this is controlled via the HardwareManager service on DBUS. There is sample code for getting a reference to the hardware manager in the Read Activity, from there, simply call the dbus-exposed methods to set the values you want. HardwareManager controlled operations:

  • Display Controller (DCON) data-source (CPU or DCON)
  • DCON freeze/unfreeze
  • backlight brightness
  • keyboard light brightness
  • color/black and white mode

How do we:

  • set all 8 (4 distinct) settings for MODE_MONO_LUMA, MODE_CSWIZZLE, MODE_COL_AA (as distinct from just colour/black and white)
  • query, change, and restrict screen orientation
  • drop to a lower resolution for performance or ease of porting, such as 600x450 or 400x300

See also Display.

How do I create my activity GUI?

  • Can I just use Cairo, Pygame or GTK directly?
    • PyGTK, Pango and PyCairo are the recommended GUI toolkit for coding new window/button/text/vector-graphics activities
    • Pygame is recommended for arcade-style raster-graphics games which need performance
    • EToys can be used to produce sophisticated object-scripting GUIs, with support for rich media
  • How can a non-GTK (or Qt) app fully interact with Sugar?
    • At the moment the Low-level Activity API is quite involved
    • Can be "fixed" by creating a wrapper in Python (e.g. the ClassicGnome activity with a performance and memory penalty)
    • Can write various DBUS services using a GTK event loop to provide the required introspection services (implies that GTK must be loaded by every process, regardless of whether it is needed)
    • Can alter your core event loop to cooperate with an embedded GObject event loop (PyGame allows this, for instance), with the small concern that this requires loading GObject into your process' memory space
  • How flexible does the GUI need to be?
    • Should be able to handle a resize-and-rotate event from the X server
    • Should be able to handle internationalisation/localisation, including to right-to-left-written scripts
  • What's the best development approach:
    • Write outside Sugar, finish and debug, then port?
      • For older PowerPC-based Macs, this is likely the best approach
    • Write to Sugar, test and debug within the system?
      • Usable if you can set up a reasonably-performing emulated system or upgrade your system to support Sugar directly
    • Write directly on the XO
      • Usable if you are comfortable with command-line Linux editing tools, or want to use EToys. As Develop becomes available this should become more approachable.

How do I package my activity?

  • How do I work from an in-process activity (develop registration)?
    • setup.py develop
    • You can use sugar-activity to start the activity, but you have to manually close it (note that by default there is no way to easily kill a mis-behaving activity in Sugar)
  • How do I produce a binary extension?
    • On a workstation with Qemu, you can create a compilation workspace. (Using a Qemu qcow overlay lets you do this without corrupting your base OS image). Within that work-space, compile the packages you want using gcc, yum, and all the traditional tools. Package and upload the results.
  • How do I share code between activities?
    • How do I use (large, common) Python packages?
      • The system will "unify" common files across packages, so if you have a large package and another activity also uses that package then the system will only store one copy of the package (using a file-by-file comparison).
      • Numpy
      • Matplotlib
      • MySQL or PostgreSQL client code
      • Twisted
      • Zope Interfaces
      • Pygsear, PGU or other PyGame extensions
    • How do I provide my own base packages on top of which I have written dozens of applications?
      • As with the common activities, the current plan is to have the system unify the packages on the laptop. There is a cost in that the packages must contain complete copies of their supporting framework for each activity.

How do I publish for others to download?

  • The Activities page is where most users will go to find new Activities
  • Any http (web) server can be used to distribute packages
    • Users can download a .xo package, when the package completes downloading, they use the Journal activity to "resume" the downloaded package
  • How do I tell users about updates to the packages?

How do I share files between applications?

Plan at the moment is to have file-sharing handled by the underlying system. That is, the system will simply notice that you have duplicate files with the same properties and hash and will share them between the two activities.

How do I test a Sugar activity?

  • Use the standard logging module in Python where possible
  • Start your activity normally, its logs will be sent to the ~/.sugar/default/logs/ directory named after your Activity's DBUS service
  • You can use the built-in Log Viewer activity on production XO versions (build 649 and up), alternately you can just view the logs in a developer's console using less or vi
  • If you like you can also use:
sugar-jhbuild shell
sugar-activity YourActivityName

to run your activity from a shell and be able to drop into pdb or similar command-line debuggers.

How do I debug a Sugar activity?

If you start your Sugar activity from the command line (see above), you can insert a standard Python: 

 import pdb
 pdb.set_trace()

command into your activity and then use the Python debugger to step through your activity's behaviour. Note that this will "freeze" your application while you are working, so you may have display issues.

How do I edit with emacs on the laptop?

How do I mount a USB drive?

Normally this is done automatically by the HAL when you plug the USB key into the laptop. It will show up as a directory in the /media folder. If, however, you had the USB key in when you started the machine, or the HAL doesn't recognize the key, you may not get the mount completed. In that case you can try manually mounting the key:

  • Enter the linux shell mode
  • First become root: $ su
  • Then make a place to mount it: $ mkdir /mnt/usb
  • Then mount the drive: $ mount /dev/sda1 /mnt/usb
  • Don't forget to unmount it before removal: $ umount /mnt/usb
  • If anything fails you should edit your /etc/fstab file to include the mount point, device, and filesystem for the device to mount.

See also

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Getting_started_programming&oldid=84438"