API Reference and Tutorials please check/update your libraries
I've been collecting pointers to (and generating) documentation for the various components in the system into what I'm intending to become central locations for developer documentation on the project. If you see some resource that developers need or would find useful that I've missed, please add it. There are two pages, the first is for tutorial-style documentation pointers: http://wiki.laptop.org/go/Tutorials if you have or know about a developer's tutorial that isn't there, please add it. Eventually I'd like to get a lot more sample code and tutorials in there. The second is a collection of pointers to reference documentation for developers: http://wiki.laptop.org/go/API_Reference At present a lot of this documentation is actually auto-generated pydoc stuff, particularly for the in-house stuff. For much of the GTK-related stuff this is of little value due to the lack of method signatures or useful docstrings. If you are the owner of any of these packages (e.g. abiword, hippo, hulahop) and have documentation available online, please update your package's entry to point to the documentation. Note: the various Sugar services and the Sugar GUI Shell are not documented because they are not importable and are using top-level executable code. We should probably fix that structuring at some point. Scripts to auto-generate the documentation from within an image are available via: bzr branch http://www.vrplumber.com/bzr/autodoc cd autodoc ./builddocs.py for those who want to make the pydoc-generated documentation their primary documentation format. It's not pretty, but at least it's automatic :) . Have fun all, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unable to update my machine
On 02/09/2007, at 3:33 PM, Hal Murray wrote: It might help if the wiki section had an example of something known to work - that is take a USB flash drive in unknown state, erase everything, and set it to a good state. Good idea. Perhaps something that wiped the partition table and other stuff at the start of the drive. If I knew exactly how the problem was caused, I'd recommend something, but I've missed the reproducer. I admit, a full erase did fix a problem like this for me earlier last month. -- James Cameron ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote: Note: ohci_pci_resume does msleep 20. Hm. It's just waiting for the hardware to settle, right? Do the resume functions for the devices themselves actually have to wait until this is complete, before they can do anything? It really sounds like we need to decouple suspend/resume of individual hardware devices from the full system suspend. It should be almost completely asynchronous. Why can't I start running userspace after resume, before I've reinitialised the USB thermometer which is plugged in? Why don't we just block access to that particular device until it's complete (and take that device off-line to save power even when the full system isn't suspended). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
trac still dead
FYI, in case everything is fine at OLPC headquarters, the bug mailing list archives show nothing for this month and I can't file a bug report. Well here: wiki fixed-style text shows up proportional, breaking plenty of things. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Sun, Sep 02, 2007 at 12:50:03PM +0100, David Woodhouse wrote: On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote: Note: ohci_pci_resume does msleep 20. Hm. It's just waiting for the hardware to settle, right? Do the resume functions for the devices themselves actually have to wait until this is complete, before they can do anything? It really sounds like we need to decouple suspend/resume of individual hardware devices from the full system suspend. It should be almost completely asynchronous. Why can't I start running userspace after resume, before I've reinitialised the USB thermometer which is plugged in? Why don't we just block access to that particular device until it's complete (and take that device off-line to save power even when the full system isn't suspended). You're entirely right, but I'm talking about something else: [0.040909] cpu_idle+0x2e/0x7c - check_pgt_cache+0xb/0x31 [0.00] check_pgt_cache+0x2f/0x31 - quicklist_trim+0xe/0xe5 [0.040912] cpu_idle+0x4e/0x7c - default_idle+0x8/0x43 [0.233593] do_IRQ+0x45/0xdb - irq_enter+0xb/0x2d [0.233594] irq_enter+0x22/0x2d - idle_cpu+0x8/0x1b This interrupt scheduled for 233-40ms is what sounds wrong. It should just continue to blaze off the EHCI resume path. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
