Changes

:'''Yes!!!''' See the [[Developers Program]] for details. Also read the [[Development Systems]] page for ideas of using other minimal systems to do your application testing.

:'''Yes!!!''' See the [[Developers Program]] for details. Also read the [[Development Systems]] page for ideas of using other minimal systems to do your application testing.

*What if I don't qualify for one of the development systems?

*What if I don't qualify for one of the development systems?

:Since [[Python]] is the primary development language for applications, you can still build something as long as you are careful to isolate the GUI portions of your code and not do anything overly complex. Or, if you use [[PyGTK]], then you come very close to the real development environment in [[Sugar|SUGAR]].

:Since [[Python]] is the primary development language for applications, you can still build something as long as you are careful to isolate the GUI portions of your code and not do anything overly complex. Or, if you use [[PyGTK]], then you come very close to the real development environment in [[Sugar|SUGAR]]. If you will be programming in C++ or assembly, make sure that the program does not use any instruction that the Geode GX does not support. Geode GX fully support the Athlon instruction set, plus some Geode-specific instructions (the instructions that the Geode GX support are listed in it's data book. See [[Hardware specification]] for a link to it). It does not support SSE, except for the subset that Athlon's 3DNow Enhanced supports.

* where can I find the sources?

* where can I find the sources?

If you are a skilled *IX user then the [[Sugar]] page should help. But most developers who will be working on OLPC will be using Python to develop educational applications.

If you are a skilled *IX user then the [[Sugar]] page should help. But most developers who will be working on OLPC will be using Python to develop educational applications.

:It must be as small as you can make it. These are memory-constrained devices. 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.

:It must be as small as you can make it. These are memory-constrained devices. 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

* memory leaks

: You need to measure the memory usage repeatedly while thoroughly exercising your program. 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.  

: You need to measure the memory usage repeatedly while thoroughly exercising your program. 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!

* required flash footprint of the application; if it is big, there may not be space.  However, [[JFFS2]] does data compression, so don't presume that the size of a file in a conventional file system corresponds to the actual amount of flash used.  As a *rule of thumb*, expect a factor of 2 compression for text and typical data, expect no compression on already compressed content, but take actual measurements to understand what your actual flash usage will be.

* required flash footprint of the application; if it is big, there may not be space.  However, [[JFFS2]] does data compression, so don't presume that the size of a file in a conventional file system corresponds to the actual amount of flash used.  As a *rule of thumb*, expect a factor of 2 compression for text and typical data, expect no compression on already compressed content, but take actual measurements to understand what your actual flash usage will be.

: If you test on a Unix system you can install [[JFFS2]] and test directly. Since [[JFFS2]] does block compression you can affect the amount of compression by reorganizing your code.

: If you test on a Unix system you can install [[JFFS2]] and test directly. Since [[JFFS2]] does block compression you can affect the amount of compression by reorganizing your code.

* 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

* 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.

: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.

* 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.

* 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. Run it with "python -v" to get a list of all modules imported.

: In the meantime, make sure you know your application's dependencies. 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

* 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. Your users may have to exert themselves physically to provide the electricity to run their OLPC. Respect them and their effort.

: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.

* 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, or routinely requires itself to be run (can't be suspended well), this isn't good

* 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

* 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 a compiled language since it compiles into an intermediate form. It should not suffer from this problem. However, rather than condemn all interpreters it would be better to test some of them and publish their idle power consumption.

:Python is a compiled language since it compiles into an intermediate form. It should not suffer from this problem. However, rather than condemn all interpreters it would be better to test some of them and publish their idle power consumption.

* your slow code has a direct impact on power consumption, and its usability.  Applications that run CPU bound will be very, very unpopular on battery powered machines that may be powered by children having to run a generator.

* 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.

* 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.

* looping waiting for events 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.

* 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 [[Python]] code that uses select instead of busy-waiting.

:Right now this is a nice summary page. But items like this deserve some more explanation along with some sample [[Python]] code that uses select 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.

* 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.