Re: Pagemap
Jordan Crouse wrote: They just talked about pagemap from Matt Mackall during an BoF at OLS. This seems like something useful we can use to measure our memory usage - in particular, it is screaming for tinderbox integration.. :) http://lkml.org/lkml/2007/4/3/405 (patches are in -mm - map2*). A related python tool, using the older smaps interface is: http://www.pixelbeat.org/scripts/ps_mem.py cheers, Pádraig. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why pilgrim does not support indic language
Hi John, Thank you very much. I checked the file which you have pointed for /etc/init.d/olpc-configure, and it worked for me. The actual case was, I modified the oplc-development.stream and added some scim as well as fonts-hindi things in that. Also I modified script, so that it should accept gnome as my default desktop, even though I installed gdm for that. As you said, I modified the file, instead of en_US.UTF-8 and I made it hi_IN.UTF-8. So it is giving desktop tools, I mean the the menus from applications and system as well as places, in the Hindi (Indian) language. Well, more over I want to make a proper olpc image with gnome desktop, which should give me the option of language selection through gdm screen. Still it is not giving me the option, how to access it from gdm- select language. Can you suggest some more things, about where olpc scripts, I mean from where pilgrim is deleting these .mo files or other locale kind of things. Thanks and regards, Sachin T On 6/26/07, John (J5) Palmieri [EMAIL PROTECTED] wrote: On Tue, 2007-06-26 at 10:08 +0530, sachin Tawniya wrote: Hi all, I have tried pilgrim with fedora and olpc development repo. Also I added gnome-session and scim things with some indic language support. I got ISO image with gnome and scim activated things. I can operate in common indic language like Hindi and can use it with terminal, text editor etc... Issue with me is, when I want my desktop should come in local language, it's not providing any indic language selection menu. Take a example of Indic-Hindi. I have installed m17n-dn-hindi, fonts-hindi etc.. While login if I select change language option, it doesn't provide option for hindi (Indic Language) Can any one give me some reference over it or any suggestions for supporting/enabling Indic Language in OLPC ISO. Any suggestions will be appreciated. First, Sugar and activities need to be translated. Please see http://wiki.laptop.org/go/Activity_Translations Second, since we work off dedicated hardware we can tell what language the device is laid out for. Please look at /etc/init.d/olpc-configure to see how we configure languages. Third, no one has put work in creating a language selection menu though I think we do need some sort of place to make it easy to override the default settings. Patches welcomed. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: Hi, My name is Alexander Larsson, and I just started working on the field upgrade system of the olpc laptops. I have some ideas I'd like to explain and get feedback on. The olpc uses a full-image system, as opposed to the per-package versioning scheme of deb or rpms. So, an upgrade consists of replacing your system files with a full copy of a later (or earlier) version of the system image. We want to support both upgrading from a central server or from another laptop, and we want to minimize the data we have to download for an upgrade. To support this we create a manifest that describes each image, and we save a copy of the current image manifest installed on the laptop. The manifest format is very similar to the git tree object, and describes each file by listing name, metadata and sha1 hash value of the contents. Here is a small example: - link 777 500:500 foo bar blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt blob 711 500:500 empty logfs.pdf dir 775 500:500 subdir1 blob 664 500:500 empty subdir1/file1.txt blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt --- Given a manifest for the current image and a manifest for the image to upgrade to it is very simple and cheap to calculate what changes you need to make to transform the image (on the client), and what sha1 blobs you need to download. You can then download the file blobs from whatever source you have (they are self-verifying, since they are named by the sha1 hash of the content) and do the upgrade. Two questions here: 1) what does the scheme do in the case where the file it's about to replace on the local machine isn't the same as what the manifest on the local machine says? ie, local changes have changed the sha1 hash of the local file. That's essentially a policy decision, do we replace when there are local changes or don't we. A %config-type thing could work here to mark files that you may/may not always want to replace. 2) After downloading a blob, I assume the tool sha1s the downloaded file to ensure that it's content matches the name, right? It is very simple to host the blobs. We just put them all in a directory named by sha1 and export that with a http server. One can also host multiple versions of an image in the same directory, while minimizing the space used for common data. (Possibly one might want to gzip the blobs too.) I've written some code (attached) to generate and manipulate manifests like these. There are three tools: * generate-manifest: This generates a manifest files given a path to a directory containing the image tree. You can also make it populate a directory of sha1-named blobs by giving it a blob directory with -b. * diff-manifest: Gives a simple visual diff between two manifests. If you pass it -b it will instead give a list of all blobs required to update between the two manifests. * upgrade-manifest: Updates an image from one manifest to another, given a path of a directory with the required blobs. Using these tools I upgraded from olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a directory on my development machine, so it seems to work so far. For finding and downloading updates I was thinking of using avahi to publish the image id + version, and then downloading the data and manifests using http. That way that clients can detect machines around them with later versions and auto-download (and apply automatically or later). The individual laptops can publish the version of the image they are using, and a school server can publish several versions. From the point of view of the individual laptop searching for upgrades they will look the same. Of course, we'd have to sign the manifests with some key to make sure you can't just auto-upgrade any machine to a rouge image. Now over to the questions I have: I'd like to put this code in a repository somewhere. Where should I put it? Does OLPC use selinux or xattrs? Because if so we have to extend the manifest format. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? Yeah, though the ironic thing just occurred to me that libcurl is (along with Mozilla) one of the more frequently updated pieces of a linux distro :) (We also need a very simple http sever that maps sha1 - file in system image for laptop-to-laptop upgrades, but I think we can do that without using a library.) simple means lighttpd in my mind, but apache has a longer track record. Is using avahi/mDNS on the mesh network ok? Certainly. There is no other way to do link-local
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 08:22 -0400, Dan Williams wrote: Two questions here: 1) what does the scheme do in the case where the file it's about to replace on the local machine isn't the same as what the manifest on the local machine says? ie, local changes have changed the sha1 hash of the local file. That's essentially a policy decision, do we replace when there are local changes or don't we. A %config-type thing could work here to mark files that you may/may not always want to replace. At the moment it only touches the files that are affected by the diff in the manifest. If a file wasn't changed in the manifests we don't even look at it. However, if the file we're replacing has changed locally, we currently throw that away. 2) After downloading a blob, I assume the tool sha1s the downloaded file to ensure that it's content matches the name, right? Yeah, or rather, while downloading. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? Yeah, though the ironic thing just occurred to me that libcurl is (along with Mozilla) one of the more frequently updated pieces of a linux distro :) I ended up using urllib2 in python. (We also need a very simple http sever that maps sha1 - file in system image for laptop-to-laptop upgrades, but I think we can do that without using a library.) simple means lighttpd in my mind, but apache has a longer track record. simple means 300 lines of C code in serve-manifest.c... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 14:21 +0200, Alexander Larsson wrote: On Fri, 2007-06-29 at 08:22 -0400, Dan Williams wrote: Two questions here: 1) what does the scheme do in the case where the file it's about to replace on the local machine isn't the same as what the manifest on the local machine says? ie, local changes have changed the sha1 hash of the local file. That's essentially a policy decision, do we replace when there are local changes or don't we. A %config-type thing could work here to mark files that you may/may not always want to replace. At the moment it only touches the files that are affected by the diff in the manifest. If a file wasn't changed in the manifests we don't even look at it. However, if the file we're replacing has changed locally, we currently throw that away. 2) After downloading a blob, I assume the tool sha1s the downloaded file to ensure that it's content matches the name, right? Yeah, or rather, while downloading. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? Yeah, though the ironic thing just occurred to me that libcurl is (along with Mozilla) one of the more frequently updated pieces of a linux distro :) I ended up using urllib2 in python. Right, python too :) If we get a factory python process (didn't we have one at one point?) we save some memory. (We also need a very simple http sever that maps sha1 - file in system image for laptop-to-laptop upgrades, but I think we can do that without using a library.) simple means lighttpd in my mind, but apache has a longer track record. simple means 300 lines of C code in serve-manifest.c... That may work even better, 300 lines is certainly 1,000,000 times easier to audit for security problems than all of apache or lighttpd. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: Hi, My name is Alexander Larsson, and I just started working on the field upgrade system of the olpc laptops. I have some ideas I'd like to explain and get feedback on. The olpc uses a full-image system, as opposed to the per-package versioning scheme of deb or rpms. So, an upgrade consists of replacing your system files with a full copy of a later (or earlier) version of the system image. We want to support both upgrading from a central server or from another laptop, and we want to minimize the data we have to download for an upgrade. To support this we create a manifest that describes each image, and we save a copy of the current image manifest installed on the laptop. The manifest format is very similar to the git tree object, and describes each file by listing name, metadata and sha1 hash value of the contents. Here is a small example: - link 777 500:500 foo bar blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt blob 711 500:500 empty logfs.pdf dir 775 500:500 subdir1 blob 664 500:500 empty subdir1/file1.txt blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt --- Given a manifest for the current image and a manifest for the image to upgrade to it is very simple and cheap to calculate what changes you So the manifest you update to is an interesting piece, and it's easier because where you get it from is completely orthogonal to the update process. So, you could: 1) as others have suggested, XO periodically contacts the school server 2) XO sends it's current image, asks what to update to, if anything 3) school server makes policy decision about update 4) school server sends back new manifest 5) XO verifies manifests signature 6) XO downloads changesets This is cool, because it doesn't matter _where_ you get the changesets from, be it the school server (which should be seeding the changesets anyway), or from another XO. It optimizes for bandwidth, but not at the expense of any security. You already know what changesets are valid based on the signature-verified server-provided manifest, and on the self-verifying sha1 of the changesets that anyone can provide to you. All in all, simple, straightforward, and not very much code. Dan need to make to transform the image (on the client), and what sha1 blobs you need to download. You can then download the file blobs from whatever source you have (they are self-verifying, since they are named by the sha1 hash of the content) and do the upgrade. It is very simple to host the blobs. We just put them all in a directory named by sha1 and export that with a http server. One can also host multiple versions of an image in the same directory, while minimizing the space used for common data. (Possibly one might want to gzip the blobs too.) I've written some code (attached) to generate and manipulate manifests like these. There are three tools: * generate-manifest: This generates a manifest files given a path to a directory containing the image tree. You can also make it populate a directory of sha1-named blobs by giving it a blob directory with -b. * diff-manifest: Gives a simple visual diff between two manifests. If you pass it -b it will instead give a list of all blobs required to update between the two manifests. * upgrade-manifest: Updates an image from one manifest to another, given a path of a directory with the required blobs. Using these tools I upgraded from olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a directory on my development machine, so it seems to work so far. For finding and downloading updates I was thinking of using avahi to publish the image id + version, and then downloading the data and manifests using http. That way that clients can detect machines around them with later versions and auto-download (and apply automatically or later). The individual laptops can publish the version of the image they are using, and a school server can publish several versions. From the point of view of the individual laptop searching for upgrades they will look the same. Of course, we'd have to sign the manifests with some key to make sure you can't just auto-upgrade any machine to a rouge image. Now over to the questions I have: I'd like to put this code in a repository somewhere. Where should I put it? Does OLPC use selinux or xattrs? Because if so we have to extend the manifest format. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? (We also need a very simple http sever that maps sha1 - file in system image for
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: Hi, My name is Alexander Larsson, and I just started working on the field upgrade system of the olpc laptops. I have some ideas I'd like to explain and get feedback on. One more thing :) I'm sure you know, but something people haven't brought up in the whole updates discussion yet is the whole picture. It's not just about the mechanical process of getting updates from point A to point B, since that completely forgets the users who's XO we're trying to update. It's critical to give some user visibility into the update process. While the tool needs to be resilient against users moving around and downloads timing out, the user also needs the _ability_ to see what the tool is doing, even if the UI or the user don't always want to or care. Sugar may want to notify the user when an update starts so the user knows why their machine is now slower, and why their WLAN light is always on. We should have at least the ability to do the Sidekick thing and allow the user to postpone certain updates, but after a week it gets applied automatically. We may want to show the progress of the update, to give users visibility into the process and when to expect it to get done. We need to notify the user than an update is done, and we would suggest that they reboot (possibly based on a metadata flag in the manifest for suggest-reboot=yes). The update daemon must provide a fair amount read-only status information before and during the update process to allow the GUI bits the flexibility to present that information to the user in the way it sees fit. In the ideal world, that means a D-Bus service that sends signals at various stages and has methods Sugar can call to get more information about the update process. However, that links in more libraries and adds vulnerability window to a critical piece of the system. So in that sense, even though a D-Bus server model is a very good one from an API point of view, perhaps the most responsible method would be simple text files that Sugar can inotify and get the required information. Oh, and we should probably rate-limit or connection-limit the local HTTP server that's serving updates so we don't hammer one particular XO. This could mean putting an _advisory_ try-me=true/false flag in the mDNS advertisement that we switch depending on the current connection load. The server would obviously still boot users if there were too many connections, but at least using the 'try-me' gives other laptops more information about whether they should try to connect right away, or try a different XO that may advertise the same blob. Have you thought about what information the mDNS record would advertise? In the best case, it's as large of a UDP packet as we can push out. And since we can probably deal easily with packets up to the wireless MTU (which is something 2000 bytes), there's more room than the traditional 512 byte UDP packet. However, the space in the mDNS announcement is not unlimited, so I don't think we could put the entire blob list in there :) There's certainly enough room to put a build number, HTTP server port number, manifest hash, etc. Dan The olpc uses a full-image system, as opposed to the per-package versioning scheme of deb or rpms. So, an upgrade consists of replacing your system files with a full copy of a later (or earlier) version of the system image. We want to support both upgrading from a central server or from another laptop, and we want to minimize the data we have to download for an upgrade. To support this we create a manifest that describes each image, and we save a copy of the current image manifest installed on the laptop. The manifest format is very similar to the git tree object, and describes each file by listing name, metadata and sha1 hash value of the contents. Here is a small example: - link 777 500:500 foo bar blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt blob 711 500:500 empty logfs.pdf dir 775 500:500 subdir1 blob 664 500:500 empty subdir1/file1.txt blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt --- Given a manifest for the current image and a manifest for the image to upgrade to it is very simple and cheap to calculate what changes you need to make to transform the image (on the client), and what sha1 blobs you need to download. You can then download the file blobs from whatever source you have (they are self-verifying, since they are named by the sha1 hash of the content) and do the upgrade. It is very simple to host the blobs. We just put them all in a directory named by sha1 and export that with a http server. One can also host multiple versions of an image in the same directory, while minimizing the space used
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 10:21 -0400, Dan Williams wrote: On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: The update daemon must provide a fair amount read-only status information before and during the update process to allow the GUI bits the flexibility to present that information to the user in the way it sees fit. auto-updatinator (the mDNS background downloader) emits dbus signals when there is a new version availible, and when it downloaded a new blob. The actual applying of the update once its done downloading should be triggered by something listening to that signal. Oh, and we should probably rate-limit or connection-limit the local HTTP server that's serving updates so we don't hammer one particular XO. This could mean putting an _advisory_ try-me=true/false flag in the mDNS advertisement that we switch depending on the current connection load. The server would obviously still boot users if there were too many connections, but at least using the 'try-me' gives other laptops more information about whether they should try to connect right away, or try a different XO that may advertise the same blob. Yeah. We currently only handle one file at a time in the local http server. However, some rate limiting on that sounds fair. At the moment we pick a new server to download each blob for randomly from the set of availible servers that has the version we want. Have you thought about what information the mDNS record would advertise? In the best case, it's as large of a UDP packet as we can push out. And since we can probably deal easily with packets up to the wireless MTU (which is something 2000 bytes), there's more room than the traditional 512 byte UDP packet. However, the space in the mDNS announcement is not unlimited, so I don't think we could put the entire blob list in there :) There's certainly enough room to put a build number, HTTP server port number, manifest hash, etc. At the moment we have image id, a list of image version ranges availible, a base directory for the http uri, a hint that the server has diffs and a prio hint which is unused atm. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 15:49 +0200, Alexander Larsson wrote: I've got the code mostly working now, and I managed to update a qemu instance of build 406 to the devel build 406 using something like: ./updatinator.py -u http://10.x.y.z/updates --get-manifest olpc-ext3 406 ./updatinator.py -u http://10.x.y.z/updates -i -m manifests/olpc-ext3.406 --download olpc-devel-ext3 406 ./upgrade-manifest -b blobs/ -d / manifests/olpc-ext3.406 manifests/olpc-devel-ext3.406 Where http://10.x.y.z/updates is an apache server with manifests and blobs generated with generate-manifests from the -tree OLPC images. However, then things failed when I upgraded to olpc-devel-ext3.445, due to out of diskspace. I need to look into using gzip of blobs and removing blobs once they have been applied (this is harder than it sounds because blobs can be used multiple times in one manifest). I added --delete to upgrade-manifest that does delete-behind (handling multiple uses of the same hash in one upgrade). So now it should be possible to do the upgrade using less space. It worked when running on my local machine, but I haven't tried it in a qemu instance yet. However, I gotta leave now, and I won't be able to do any OLPC work at all next week. It would be cool if someone else could play a bit with this, test it a bit more, get the blobs on a public service, test on a real XO, etc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Build 472 - testing
Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) John, Can we get a changelog with each build now? Between the changelog and the release information that can be provided on the 'Test Group Release Notes', we will be providing some good info for those who want to use the latest build. Regards, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
csound and glade / pygtk
hi, i am still having some trouble building a pyGTK interface for a csound application - a simple one, basically just as a replacement for FLTK widgets, which are not supported on the laptop. i am aware that there are multiple approaches at the moment, including the csound server etc. the csound event and the pygtk interface currently run on seperate threads, but they interfere with each other - any activity in the interface causes csound to stop. i was wondering whether anyone has some examples of similar applications running on the laptop? best, dietmar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
Looking into it, most likely a NetworkManager issue. On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) John, Can we get a changelog with each build now? Between the changelog and the release information that can be provided on the 'Test Group Release Notes', we will be providing some good info for those who want to use the latest build. Regards, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
Please read Ivan's update proposal. He addresses many of the peripheral issues that have arisen, re user notification, etc. At this point, as far as I'm concerned, the only open question is how we get a filesystem image onto the laptop once we know which one to get. Ivan suggests rsync; I refined that somewhat with a directory-at-a-time rsync using manifests; someone else (Mike?) proposed bittorrent, and previously I proposed a bespoke solution using binary diffs and multicast. Alex's work is interesting, but we need to see benchmarks if we're not going to make a decision based on just fiat and personality. I've posted up/download bandwidth for upgrades between 464-465 and 465-466. Following up on Mike's suggestion, I've also patched bittorrent to allow using it for upgrades: the net bandwidth usage is something like 30MB, because it does not use block compression. I can post more detailed comparisons if people are interested. Please perform the equivalent benchmarks on the updatinator, before we continue this discussion. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Upgrade Plans
Michail needs to run mesh tests on 50+ laptops. He needs an automated way to get slightly customized versions of the OLPC software quickly to all of these. In the next few days I'll be working on hacking together a quick prototype of: a) the part of the antitheft server which tells a laptop which software it should have b) the part of the XO which periodically checks this c) code which pushes bits onto the machine d) code which switches to the new image after reboot. I will coordinate with Ivan to try to get real security and antitheft stuff into parts (a) and (b), but my priority will be to get Something Working for Michail's tests, so there will likely be stubs. Similarly, it would be nice if (c) and (d) were vserver-containerized and whatnot, but I'll probably just stub out the vserver bits and use hard links --- as per the previous discussion, the vserver COW is used just to protect the system from a rogue updater, it's not fundamental to the process and hard links will work fine in the prototype. Between parts (c) and (d) there would ideally be Sugar UI code which looked at update priority and deferred reboot or whatnot, but again that will be stubbed out. Finally, there's some controversy about how (c) actually gets the bits onto the machine. I'll use rsync for this initially, because this testbed will also help settle concerns about its scalability (or lack thereof), but I'll make sure that this interface is clean and we could easily swap out some other distribution mechanism (bittorrent, updatinator, or diff-multicast) if benchmarks and testing show it is worthwhile. Basically, I hope to be writing a robust skeleton that lots of different groups can plug their stuff into. If you've already got pieces of this skeleton written, send me the bits. I'll send followup mail with the git repository info once the basic stuff is there. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: csound and glade / pygtk
From: James Bergstra [EMAIL PROTECTED] Subject: Re: Fwd: csound and glade / pygtk To: [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 12:24:07 -0400 User-Agent: Mutt/1.4.2.1i Message-ID: [EMAIL PROTECTED] You're right that there are many good ways to make a GUI app around csound. In TamTam, we are using csound as a sound rendering library, within a pthread that writes directly to ALSA. These things are controlled by a C++ python module that we import into TamTam. Without a clear idea of the approach you've taken, or the problems you are facing, I venture that the following tip: If you are using multiple threads of python code, you should be aware of the global interpeter lock (often called GIL). To prevent gtk from hogging the GIL while there are no events to handle, you might want to explore the functions threads_init(), threads_enter(), and threads_leave() in gdk James From: dietmar offenhuber [EMAIL PROTECTED] Date: June 29, 2007 11:44:02 AM EDT (CA) To: ! [EMAIL PROTECTED] Subject: csound and glade / pygtk hi, i am still having some trouble building a pyGTK interface for a csound application - a simple one, basically just as a replacement for FLTK widgets, which are not supported on the laptop. i am aware that there are multiple approaches at the moment, including the csound server etc. the csound event and the pygtk interface currently run on seperate threads, but they interfere with each other - any activity in the interface causes csou! nd to sto r anyone has some examples of similar applications running on the laptop? best, dietmar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: csound and glade / pygtk
On Fri, 2007-06-29 at 11:44 -0400, dietmar offenhuber wrote: hi, i am still having some trouble building a pyGTK interface for a csound application - a simple one, basically just as a replacement for FLTK widgets, which are not supported on the laptop. i am aware that there are multiple approaches at the moment, including the csound server etc. the csound event and the pygtk interface currently run on seperate threads, but they interfere with each other - any activity in the interface causes csound to stop. i was wondering whether anyone has some examples of similar applications running on the laptop? best, dietmar This behavior sounds like problems I've had when I forget to call gtk.gdk.threads_init(). I don't think you have to worry about threads_enter and threads_leave unless you plan to make calls to GTK from a thread separate from the main GTK thread. But you do always need to initialize threads in a multithreaded program. owen ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On 6/28/07, Wayne Davison [EMAIL PROTECTED] wrote: I wouldn't recommend deploying rsync 3 widely just yet. I'm going to be working on finalizing the release in the near future, but there is still a chance that protocol 30 (which is new for this release) may still need to be changed a bit before it is released. The program is stable enough that I use it for all my own rsync copying, but I also ensure that my installed versions get updated for new releases. As I've written before, I think that splitting up the rsync per-directory will solve our immediate resource worries, although we'll shortly validate that with some testing. We certainly remain interested in your work on version 3.0. One rsync feature I would like to see is a ''--hints directory option that would tell the remote rsync that the local machine is highly likely to have the files in the specified remote directory. When blocks mismatch, the local machine can send the hash of the block it has, and if that block is in the remote hints directory the remote machine can send a binary diff instead of the complete contents of the block. That could greatly reduce the bandwidth used. (With --fuzzy I suppose each block in the hints directory could be hashed and checked for possible matches to remote blocks, but without --fuzzy the --hints directory would be required to match the directory structure of the rsync'ed directory to allow using one hints file at a time for less required memory. The --fuzzy would be useful when rsyncing (say) linux-2.6.21/ when both sides have linux-2.6.20/ available, while the non-fuzzy would be faster when I'm updating local:linux/ to remote:linux-2.6.21/ while giving the remote a hint that I previously had remote:linux-2.6.20/ in there.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: csound and glade / pygtk
On 6/29/07, Owen Williams [EMAIL PROTECTED] wrote: the csound event and the pygtk interface currently run on seperate threads, but they interfere with each other - any activity in the interface causes csound to stop. i was wondering whether anyone has some examples of similar applications running on the laptop? You should tell GTK your gonna use threads. When using threads I just put the following piece of code just after importing gtk. import gobject gobject.threads_init() That's all. Stas -- A collection of educational activities for schools http://www.schoolsplay.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) John, Can we get a changelog with each build now? Between the changelog and the release information that can be provided on the 'Test Group Release Notes', we will be providing some good info for those who want to use the latest build. Regards, Kim Ok, starting to do ChangeLogs with each build. I think I found the networking issue which I will fix in the next build. For now if you want you can log into root at a terminal and type chmod +x /etc/NetworkManager/callouts/* That should fix things. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
