sugarbot's aim is to provide testing and automation facilities for the OLPC Project's Sugar GUI. The project must first identify and evaluate possible implementation options, and then implement the best choice. Although it has a Sugar focus, sugarbot should be easily extensible to other Python-based GUI's.
Sunday, June 29, 2008
Committed several new files to SVN, lots of tests for most of the other functionality.
Friday, June 27, 2008
Thursday, June 26, 2008
First, I tried to use the old sugar-jhbuild from before the drive corruption, because I had the actual files stored on the Mac filesystem (accessed in Ubuntu via the Shared Folders featured in VMWare). For whatever reason, that didn't work. Okay, I can accept that.
Next, I tried to simply './sugar-jhbuild update' and './sugar-jhbuild build' on the existing installation. I let that run overnight. No dice.
So I started out with a fresh copy, via git. After 'update' passed, 'build' decided that it would freeze the VM, resulting in me having to hard-reboot (because the VMWare process would not quit via Force Quit or sudo kill).
Now I am rebuilding sugar-jhbuild *again*, and it's deciding that it's going to take its dandy time. Literally. I've given the VM 512MB of RAM and access to both processors, and it's sitting at about 20% utilization. In addition to that, the VM is completely unresponsive -- which is intereseting, because it is supposedly (according to Activity Monitor in OSX) -- not really doing anything.
This whole incident is becoming very frustrating. I can't test any of the 'nose' code that I've written, because none of the Sugar libraries are available/working under Leopard, which means that anything that's Sugar-dependent (read: everything) refuses to run on Python under OSX.
In order to see if I could expedite things, I went the 'apt' route with precreated Sugar packages and emulator. I figured I'd just run the sugar-jhbuild process in the background, and work around it until it was done building. As I mentioend before, the VM is completely unresponsive... to the point that I'm considering just creating a new VM (yet again...). Of course, I know that won't really solve anything, because Ubuntu runs just fine until it gets a few minutes into the sugar-jhbuild process.
I should very shortly have access to a shiny new Dell workstation (as part of my UH project) that will have Ubuntu on it. Hopefully that will yield better results.
Monday, June 23, 2008
Sunday, June 22, 2008
After my Time Machine backup finishes restoring (looks like about 45 minutes left on that), I have to re-install my Ubuntu VM, as my VM's are the only thing I didn't have Time Machine back up (because they would chew up disk space). I'm hoping to be back up and running before the night is over.
Saturday, June 21, 2008
I think/hope I have FINALLY gotten things sorted out. Maybe.
Friday, June 20, 2008
Thursday, June 19, 2008
I can make a work-around for this (for example, by making the class name a member, and then passing that to another function that re-instantiates the object) but it seems like a giant kludge.
Wednesday, June 18, 2008
Tuesday, June 17, 2008
After an hour of struggling with it, only to finally notice that I have to restart the server script (in addition to the Sugar Activity) if I actually want my changes to propagate, I have to say... that was pretty freaking easy.
Sunday, June 15, 2008
A separate XML-RPC server can feed it the commands. Bingo!
Saturday, June 14, 2008
Turns out that I might need to create a separate thread in order to launch the commands, as the method that I am currently using is only good until things are done initializing. After that, no new gdk.Event's are issued, which means that the place that I use as a callback to launch sbCommand objects never gets called.
For an example of what I mean, check out r41 (just committed it) and run the sugarbot activity. No modification should be necessary, and it should launch the Terminal activity (which you need to have installed for this to work properly, obviously). After/during the "sleep '2'" statement, everything finishes initializing, which means there are no more Events flying around. That means that all of the 'type' commands will not execute until some event is created. To see this, launch the activity, and do not touch your mouse or keyboard for a few seconds. Then move the mouse, and the 'type' commands should execute shortly thereafter.
- Multithreading. Just have a thread that sits and does what the hooked code would otherwise do. This would allow me to separate the sbgui functionality from the execution of commands, which is a Good ThingTM.
- Find a way to generate some kind of empty gdk.Event after executing a sbCommand, if there are no other gdk.Event's waiting for processing.
Friday, June 13, 2008
- A script file that actually contains multiple scripts. With each subsequent execution, the next 'script' is run. sugarbot keeps track of where it needs to read from next with some other file, and resets that data once it reaches the end.
- Use the network to connect to some separate 'server' application that tells sugarbot what to do. This other application would have unlimited flexibility, since it is not bounded by the Sugar environment.
Wednesday, June 11, 2008
Sunday, June 8, 2008
A commenter (Michael Stone) asked for a bit more information on the multiple-initialization issues that I ran into. The issue first appeared when I first started the project, and I resolved the issue with a runtime inheritance hack. The general idea is:The sugarbot object makes itself inherit from the other class, then calls __init__(self, self.handle) so that the Activity gets initialized the way that it normally would. This was not how it was originally set up (because it did not work the way it was originally set up). At first, I just assumed that I could do the following:
self.parentClass = someOtherActivityClass…and have everything work. Unfortunately, certain calls (calling activity.Activity.__init__ explicitly, to initialize the activity being one of those) only like to be called by the Activity instance that it expects the call to come from. Otherwise, the excrement comes into contact with the rotary cooling device.
sugarbot.bases = (self.parentClass,)
launchedActivity = someOtherActivity(self,handle)An issue that I’m facing is that, with the current way of instantiating Activities, it is not possible (to my knowledge) to terminate the spawned activity without causing the whole process to terminate. I think the way to resolve this is going to (ultimately) be to automate the Sugar GUI itself, so that I can re-launch the sugarbot Activity after it terminates. It will somehow know (or perhaps have this information provided to it) to run the next automation script or the like.
from sugar.activity import activity
import sys, os
def init(self, handle):
# With or without the following call, everything freaks out.
# Add the path to the activity
# Import and instantiate the activity
from calculate import Calculate
launchedActivity = Calculate(self,handle)
Saturday, June 7, 2008
Thursday, June 5, 2008
Wednesday, June 4, 2008
Tuesday, June 3, 2008
Monday, June 2, 2008
- Issues Testing XML Server
- So wait...
- Not cooperating...
- Documentation Effort
- Ubuntu is running
- Drive Genius
- New Wiki Pages
- Not going well today...
- Now Launching
- Parsing Server-side
- Bug Hunting
- That's it, really?
- Timout problem
- Temporary Diversion
- Brick Wall
- Reorganizing, issues with a few Widgets
- In Maryland
- Re-factoring mood?
- Widget Identifier Refactor
- Getting pretty sugar-specific
- Damnit, Python
- Evaluating Entries, basic parsing
- ▼ June (30)