Re: Animation/Python/PyGames vs battery charge
Hi I suspect that the best thing you can do to reduce power is to make sure that your game doesn't do anything when it isn't the frontmost thing on the screen. I.e. if the window that you're drawing in is totally obscured, then don't run ANYTHING -- no game animations, but also no background world-simulating stuff, and little or no network activity. Resume activity once the user brings your game to the front again. Don't wake up periodically and do anything; be sure to do NOTHING. Ensuring this background-idle behavior will not only allow the activity that's frontmost to get 100% of the CPU cycles. It will also allow the XO to suspend and power down if that frontmost activity goes idle. (If you're chewing up CPU in the background, the system won't auto-suspend.) Maybe sugar could suspend those activities which are in the background so the activities don't have to worry about it. Also it would be fool proof. -- Rózsás Gödény ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: splitting djvulibre
On Jan 30, 2008 1:38 AM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Tomeu Vizoso wrote: On Tue, 2008-01-29 at 09:15 +0100, Reinier Heeres wrote: What's dragging in djvulibre, desktop-file-utils and xdg-utils? djvulibre is dragged in by Read, which in the current joyride also supports reading djvu files. Don't know about the other two... xdg-utils is dragged in by djvulibre, I think. This one dependency seems useless to us. It's only used to do the register-djvu-mime and register-djvu-menu in the post-install scriptlet, which we don't need. I guess we could split this package into djvulibre-libs and djvulibre (containing just the apps). Matthias, could you please do that? Or, if you have no time, would you mind if we go on and do it? At the moment we are building our own djvulibre so I can just disable these dependencies. It would be nice to have these packages properly splitted up for when we upgrade to F9 though... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: flash usb drives not on journal
Hi Ricardo, issues I have seen lately are http://dev.laptop.org/ticket/6029 (which should be fixed since 1590). I just filed a bug about problems with devices indexed in certain images (so far tested with 670). 653 to 690 and the other way around works why I am not so worried about that for the moment. Best, Simon Ricardo Carrano wrote: I apologize if this is intended and I missed the news, but usb sticks are not displaying in the journal anymore (joyride 1608). ___ 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: flash usb drives not on journal
Sorry forgot to mention the bug: http://dev.laptop.org/ticket/6269 Simon Schampijer wrote: Hi Ricardo, issues I have seen lately are http://dev.laptop.org/ticket/6029 (which should be fixed since 1590). I just filed a bug about problems with devices indexed in certain images (so far tested with 670). 653 to 690 and the other way around works why I am not so worried about that for the moment. Best, Simon Ricardo Carrano wrote: I apologize if this is intended and I missed the news, but usb sticks are not displaying in the journal anymore (joyride 1608). ___ 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1611
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1611 Changes in build 1611 from build: 1610 Size delta: 0.00M -bootfw q2d10-1.olpc2.unsigned +bootfw q2d11-1.olpc2.unsigned --- Changes for bootfw q2d11-1.olpc2.unsigned from q2d10-1.olpc2.unsigned --- + update to q2d11 this is an unsigned image + OFW is rev 791 + EC is pq2d11 + none + Fix abnormal code 9 from occurring (Fixes blinking red LED) + Revert 500ms battery state machine processing back to 1s. (Fixes + Turn ec cmd 0x23 into no-op since its unusable. -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: flash usb drives not on journal
On Tue, 2008-01-29 at 22:50 -0200, Ricardo Carrano wrote: I apologize if this is intended and I missed the news, but usb sticks are not displaying in the journal anymore (joyride 1608). In order for usb sticks to appear in the journal, several components need to cooperate: at least the kernel, HAL, datastore and journal. Also, failure can happen due to many environment variables. Thus, without logs for each of these components the developers can't do much. Please attach /var/log/messages, the output of lshal -l, and sugar debugging logs as explained in http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets . But, if your problem looks similar to the one described in the links below, then just do as Jani said and delete the .olpc.store dir in the usb stick: http://lists.laptop.org/pipermail/devel/2008-January/009800.html http://dev.laptop.org/ticket/6269 I'm sorry for the confusion that this has caused, hopefully people will stop using the offending builds and we won't see this again. In the future I'll be watching more closely the xapian releases we put in the builds. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
On Wed, Jan 30, 2008 at 01:21:29AM -0500, Giannis Galanis wrote: The results were: 1. The xmas tree effect is still here. i.e. XOs occasionally vanish/reappear in differenent positions. This is because of the following: When the avahi cache includes several inactive/departed/(reported as failed) peers, and a new pear arrives, then all the inactive peers vanish from the screen instantly. (#5501) If their inactivity was temporary, then they will reappear shortly in a different location If for e.g. 3-4 XOs are (by user internention) moved simultaneously from ch6 to ch11, and then back to ch6, the icons wont have the time to disappear. BUT, the first to return to ch6 will cause the effect/bug to the others, which will instantly vanish. Shortly after they will naturally all return 1by1 to ch6 and will reappear in different locations. There was a patch for this issue(5501), which was included in 678+, but it has no effect. Please. Report your findings in the actual bug report so we can track it. And also, don't expect things to be fixed in reasonable timeframes if we have to wait more one month before our changes are actually tested. 2. It takes up to 10min for avahi even to detect the inactivity of a peer. i.e. If an XOs switches channels, for up to 10min avahi wont even know(it used to be 1-2min). Is this with or without the patch from bug #6162 ? If without, then the time it takes avahi to discover it should still be 2 mintues. I'd like to how you test this. Oh and please file a bug, so we can actually track these issues. 3. It will take a total of about 30min for the XO to vanish from the mesh view(this is tooo long!) Again, file a bug. Needed info here is if there is a time difference between when avahi marks something as removed, when salut sends out the removed signal and when it actually disappears from the mesh view. 4. Avahi/mesh view respond independently. The situation used to be that when an entry dissappeared in avahi, it disappeared in mesh view, and the same when new peers arrive. This relation was very consistent. However, now we have the following cases: a) an XO will vanish from the mesh view, but remain indefinitely in the avahi cache as failed to resolve b) sometimes avahi shows alot less peers than the mesh view. The extra peers in the mesh view are definitely active since they properly respond to activity joining/sharing. c)sometimes avahi included more active peers than the mesh view. does anyone know why this is happening? Is it a bug? I have logs, if needed, that compare avahi-browse with timestamped dbus-monitor logs, that indicate the inconsistencies. Well you all list them as undesired behaviour, so i would say they're bugs. 5. An important improvement is that peers will not generally fail alot on their own. So, if many XOs join a mesh channel, and noone goes away, the will not start failing. This used to be a common effect after 4-5 XOs. However, i noticed once in 1cc, 61 active XOs in the mesh view! When you say salut, you actually mean avahi. It would help if you could be clear on what you mean :) This improvement is probably caused by the fix in #5501. This shows that salut is more capable then we expected. Well both avahi and salut are quite capable. I'm not sure why it has such a bad reputation with you. Probably because your only seeing it in a very very exterme network and because there seems to be a lot of FUD about mdns going around. MDNS definately isn't an optimal protocol for a mesh, but most of the issues in big rollouts are actually caused by the wireless firmware not being good enough to do actual multicast routing. Anyway for all the bugs you should have filed instead of sending this mail, i will need tcpdump logs, avahi logs, salut logs and if possible meshview logs indicating when contacts are removed from the mesh from a machine where you say the behaviour. Preferably with timestamps Sjoerd -- I am what you will be; I was what you are. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Sjoerd, Could you please develop this? What do you mean by wireless firmware not being good enough to do actual multicast routing.? Thanks, Ricardo Carrano Well both avahi and salut are quite capable. I'm not sure why it has such a bad reputation with you. Probably because your only seeing it in a very very exterme network and because there seems to be a lot of FUD about mdns going around. MDNS definately isn't an optimal protocol for a mesh, but most of the issues in big rollouts are actually caused by the wireless firmware not being good enough to do actual multicast routing. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: flash usb drives not on journal
Yes. Removing .olpc-store restored normal behavior. Thank you all! On Jan 30, 2008 9:29 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, 2008-01-29 at 22:50 -0200, Ricardo Carrano wrote: I apologize if this is intended and I missed the news, but usb sticks are not displaying in the journal anymore (joyride 1608). In order for usb sticks to appear in the journal, several components need to cooperate: at least the kernel, HAL, datastore and journal. Also, failure can happen due to many environment variables. Thus, without logs for each of these components the developers can't do much. Please attach /var/log/messages, the output of lshal -l, and sugar debugging logs as explained in http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets . But, if your problem looks similar to the one described in the links below, then just do as Jani said and delete the .olpc.store dir in the usb stick: http://lists.laptop.org/pipermail/devel/2008-January/009800.html http://dev.laptop.org/ticket/6269 I'm sorry for the confusion that this has caused, hopefully people will stop using the offending builds and we won't see this again. In the future I'll be watching more closely the xapian releases we put in the builds. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1612
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1612 Changes in build 1612 from build: 1611 Size delta: -0.13M -djvulibre 3.5.18-2.olpc2 +djvulibre 3.5.18-3.olpc2 -desktop-file-utils 0.12-4.fc7 -xdg-utils 1.0.2-4.fc7 --- Changes for djvulibre 3.5.18-3.olpc2 from 3.5.18-2.olpc2 --- + Remove dependency on xdg-utils -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Sjoerd Simons [EMAIL PROTECTED] wrote on 01/30/2008 06:45:48 AM: Well both avahi and salut are quite capable. I'm not sure why it hassuch a bad reputation with you. Probably because your only seeing it in a very very exterme network and because there seems to be a lot of FUD about mdns going around. MDNS definately isn't an optimal protocol for a mesh, but most of the issues in big rollouts are actually caused by the wireless firmware not being good enough to do actual multicast routing. Have you given any thought to the overhead (just in traffic - let's leave memory out of the question right now) required to do what you call actual multicast routing in the firmware? We all understand how difficult is what we are trying to achieve. The firmware hasn't changed much since you started working on this project. So, let's drop the finger pointing and try to come up with realistic and implementable solutions. Yianni does testing, he doesn't care where specifically the problem is, all that he wants is to see something that works. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
On Wed, Jan 30, 2008 at 09:27:06AM -0500, Michail Bletsas wrote: Sjoerd Simons [EMAIL PROTECTED] wrote on 01/30/2008 06:45:48 AM: Well both avahi and salut are quite capable. I'm not sure why it hassuch a bad reputation with you. Probably because your only seeing it in a very very exterme network and because there seems to be a lot of FUD about mdns going around. MDNS definately isn't an optimal protocol for a mesh, but most of the issues in big rollouts are actually caused by the wireless firmware not being good enough to do actual multicast routing. Have you given any thought to the overhead (just in traffic - let's leave memory out of the question right now) required to do what you call actual multicast routing in the firmware? I did some research into mesh routing protocols before starting the salut muc work. From the research papers i've seen, proper multicast routing seems entirely viable. Traffic and memory overhead depend on the exact tradeoffs you make and the protocols used. So i see no reason why this can't be done on olpc's mesh network. We all understand how difficult is what we are trying to achieve. The firmware hasn't changed much since you started working on this project. So, let's drop the finger pointing and try to come up with realistic and implementable solutions. As said, from my point of view, proper multicast routing is an entirely realistic thing. Note that nobody is claiming MDNS is particularely suited for mesh networks. Because it's not. The reason why we used it, is that it was already used on the olpc mesh even before salut came along and we just didn't have the resources to do both a new presence protocol and a MUC protoocl. Also note that our muc protocol uses multicast, the rationale for that was outlined when we originally proposed telepathy. Now the exact rationale doesn't matter much. The point is that we've always been quite clear about the fact that we're heavily using multicast. And nobody ever claimed that this was a bad/unrelistic thing (at some points there were even interns at OLPC experimenting with reliable multicast on the mesh, so it seems that even inside olpc multicast was regarded as a good thing). So we always (maybe naievely) assume the mesh did/could do proper multicasting. When we discovered the mesh did not do proper multicasting, we did tell various people that this was going to be a bad thing. But apparently nobody ever seemed to think this was a big deal untill recently. So if you now want to say that multicast is not a viable solution and will never be, because for some reason it's unrealistic with the current mesh hardware. Please make this very very clear. Then at least we can throw more then a year of development effort out of the window and redo things from scratch. Yianni does testing, he doesn't care where specifically the problem is, all that he wants is to see something that works. Well for good testing he should have least have an idea where the problems are and what the issues involved are :) The scalability problem lies in the current combination of the mesh implemenation and the mdns traffic, how exactly we're going to solve that is still up for discussion. Sjoerd -- Each of us bears his own Hell. -- Publius Vergilius Maro (Virgil) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
On Jan 30, 2008, at 5:12 PM, Michail Bletsas wrote: For completely serverless environments, what we have is invaluable. The fact that it doesn't scale to large numbers of nodes doesn't make it useless. I'm similarly confused about people's insistence on a rigid dichotomy between the approaches. I never regarded our mesh work to be aimed at replacing proper infrastructure -- its goal was to provide a viable (if degraded) transport when proper infrastructure was prohibitively expensive or otherwise not an option. We always knew that this approach carried scaling limits, and that's _fine_. As Michail says, this by no means makes the system useless. We have serious problems making Avahi and even the Jabber server do their thing with small numbers of nodes These two are very different. Avahi is hitting design and network limits. With Jabber, the problem is our ugly shared roster hack which makes the system do something it's not designed to; this is not an issue intrinsic to Jabber. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Sjoerd Simons [EMAIL PROTECTED] wrote on 01/30/2008 10:46:33 AM: I did some research into mesh routing protocols before starting the salut muc work. From the research papers i've seen, proper multicast routing seems entirely viable. Traffic and memory overhead depend on the exact tradeoffs you make and the protocols used. So i see no reason why this can't be done on olpc's mesh network. Given ample time, resources, many good programmers and a Turing machine, everything is possible. We have something more than a Turing machine, but we are having serious shortages on the other fronts. The distance from research papers to actual implementation is a great one. We all understand how difficult is what we are trying to achieve. The firmware hasn't changed much since you started working on this project. So, let's drop the finger pointing and try to come up with realistic and implementable solutions. As said, from my point of view, proper multicast routing is an entirely realistic thing. No it is not, given the constraints at hand. Note that nobody is claiming MDNS is particularely suited for mesh networks. Because it's not. The reason why we used it, is that it was already used on the olpc mesh even before salut came along and we just didn't have the resources to do both a new presence protocol and a MUC protoocl. Also note that our muc protocol uses multicast, the rationale for that was outlined when weoriginally proposed telepathy. Now the exact rationale doesn't matter much. The point is that we've always been quite clear about the fact that we're heavily using multicast. And nobody ever claimed that this was a bad/unrelistic thing (at some points there were even interns at OLPC experimenting with reliable multicast on the mesh, so it seems that even inside olpc multicast was regarded as a good thing). So we always (maybe naievely) assume the mesh did/could do proper multicasting. When we discovered the mesh did not do proper multicasting, we did tell various people that this was going to be a bad thing. But apparently nobody ever seemed to think this was a big deal untill recently. We have found that out way before you did, hence the need to be able to transition from a p2p mDNS approach to the unicast server based one. (What we still miss is the intermediate step, i.e. having XOs become presence servers -aka supernodes on demand) The fact that some people were shocked when they realized that you can not cram 500 XOs under one roof and still expect to be passing traffic around when you rely heavily on basic rate multicast over mesh is not a reason to radically rethink everything from scratch. We had discussed how important being able to control the flood would be very early on and hence the requirement for per application mesh TTL settings (so that we can even disable multicast flooding by setting the TTL to 1 for scenarios like the one in Mongolia) We can alway decrease the contention window if we increase the multicast rate. For completely serverless environments, what we have is invaluable. The fact that it doesn't scale to large numbers of nodes doesn't make it useless. Yianni does testing, he doesn't care where specifically the problem is, all that he wants is to see something that works. Well for good testing he should have least have an idea where the problems are and what the issues involved are :) The scalability problem lies in the current combination of the mesh implemenation and the mdns traffic, how exactly we're going to solve that is still up for discussion. I don't think that the issues that Yanni pointed out are directly related to the transport's multicast scalability issues. We have serious problems making Avahi and even the Jabber server do their thing with small numbers of nodes, so let's not blame the transport for everything. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Animation/Python/PyGames vs battery charge
The stuff I am writing is interactive animation. That is to say the activity responses are animated. There may be intentional delays while the child is given time to consider a response. If the delay is long the activity may give additional information or encouragement to facilitate the child's response. I was looking for a way to minimize energy consumption while waiting for the child to respond. On Wednesday 30 January 2008 00:04:27 Rózsás Gödény wrote: Hi I suspect that the best thing you can do to reduce power is to make sure that your game doesn't do anything when it isn't the frontmost thing on the screen. I.e. if the window that you're drawing in is totally obscured, then don't run ANYTHING -- no game animations, but also no background world-simulating stuff, and little or no network activity. Resume activity once the user brings your game to the front again. Don't wake up periodically and do anything; be sure to do NOTHING. Ensuring this background-idle behavior will not only allow the activity that's frontmost to get 100% of the CPU cycles. It will also allow the XO to suspend and power down if that frontmost activity goes idle. (If you're chewing up CPU in the background, the system won't auto-suspend.) Maybe sugar could suspend those activities which are in the background so the activities don't have to worry about it. Also it would be fool proof. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Allow me to offer a perspective. Last year I went to a trial school in Porto Alegre (South part of Brazil). We grabbed five XOs and went to the housing project where the children live. There, five kids could use the chat activity from their homes. Everyone was very excited. The possibilities of the mesh are huge (ok, within limits, like anything). Let's not forget that no infrastructure is the default condition around the world (at least in many years to come). This is not a waste of our time. On Jan 30, 2008 2:25 PM, Ivan Krstić [EMAIL PROTECTED] wrote: On Jan 30, 2008, at 5:12 PM, Michail Bletsas wrote: For completely serverless environments, what we have is invaluable. The fact that it doesn't scale to large numbers of nodes doesn't make it useless. I'm similarly confused about people's insistence on a rigid dichotomy between the approaches. I never regarded our mesh work to be aimed at replacing proper infrastructure -- its goal was to provide a viable (if degraded) transport when proper infrastructure was prohibitively expensive or otherwise not an option. We always knew that this approach carried scaling limits, and that's _fine_. As Michail says, this by no means makes the system useless. We have serious problems making Avahi and even the Jabber server do their thing with small numbers of nodes These two are very different. Avahi is hitting design and network limits. With Jabber, the problem is our ugly shared roster hack which makes the system do something it's not designed to; this is not an issue intrinsic to Jabber. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
On Jan 30, 2008, at 6:34 PM, Ricardo Carrano wrote: This is not a waste of our time. Your reply is addressed to me, so I'm not sure whether you understood me to be implying that the mesh is a waste of our time. I was trying to say exactly the opposite. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
I got your point. I apologize if my message was unclear on that. 2008/1/30 Ivan Krstić [EMAIL PROTECTED]: On Jan 30, 2008, at 6:34 PM, Ricardo Carrano wrote: This is not a waste of our time. Your reply is addressed to me, so I'm not sure whether you understood me to be implying that the mesh is a waste of our time. I was trying to say exactly the opposite. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
On Wed, Jan 30, 2008 at 10:37:24AM -0200, Ricardo Carrano wrote: Sjoerd, Could you please develop this? What do you mean by wireless firmware not being good enough to do actual multicast routing.? Not good enough might be a bit harsh. What i mean is that as far as i know it doesn't implement any mesh multicast routing protocols. MAODV is a well-known example of a mesh multicast routing protocols and there are a whole bunch more. Wikipedia has a whole list[0] and if you look a bit into the research on MANET's a bit you'll probably find those and a whole lot more. If it would implement one of those, the point at which the network starts melting because of MDNS traffic should be a lot higher then it is now. Especially if you have a reasonably dense network, like say inside one school. Sjoerd 0: http://en.wikipedia.org/wiki/List_of_ad-hoc_routing_protocols#Multicast_Routing -- Each of us bears his own Hell. -- Publius Vergilius Maro (Virgil) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC library] MATLAB for OLPC?
Speaking of the free alternatives (of which I only know a bit -- I don't actually do any of this kind of work), I haven't noticed anyone mention RPy (http://rpy.sourceforge.net/) which provides some integration between R and Python. It would probably be very helpful for porting R to the XO, as you could write Activity wrapper in Python, and/or hook into things like the Journal using the bindings. I don't really know what the difference is between RPy and R/SPlus, it's not immediately obvious. Matplotlib (http://matplotlib.sourceforge.net/) implements a lot of 2D graphing for Python. The graphs is creates can be quite nice, and the API is pretty simple. I'm not really sure what the end-user experience is that people are looking for. An interactive prompt to explore data? A full GUI for managing the data? A tool that can be used by other Activities that actually have the data? Mel Chua wrote: On the subject of transcribing MATLAB to numpy, aside from the aforementioned smattering of dependencies on MATLAB environmental features, I would say the answer to your question is: very hard. Not only are the numpy types not a one-to-one mapping with MATLAB types; MATLAB syntax is optimized around certain assumptions about matrix iteration at a deep level. I don't fully understand the inner workings, but my impression is it would require tweaks in the Python interpreter and stack to get it running MATLAB computations at a reasonable efficiency. I'm not sure his summary here is true. You can do efficient operations over sets of data in Python (actually due to some small tweaks to the language requested by NumPy/Numeric users back around the time of Python 2.1). So if you do something like array * 6, it actually does the multiplication of items in the array in C. They bend Python's magic methods quite a bit in NumPy, so things like array access, slicing, and multiplication all avoid actually iterating over the arrays or matrixes in Python. While I imagine Matlab has a greater number of routines and algorithms written in C or other efficient languages, from Python you can access similarly efficient algorithms (once they get written). Actually interpreting another language in Python, or translating a language to Python, is probably infeasible. I've never been a fan of attempts to do this that I've seen in the past. If you actually want the Matlab language then you probably need to start with that as a goal, as Octave seems to do. I'm not sure of what the goal of having a translation from Matlab would be. Lots of XO users already know Matlab? That seems unlikely. There are libraries implemented for Matlab that would be really hard to port/reimplement? Maybe. You want XO users to collaborate with scientists who are using Matlab? I suppose; except it's easy to transfer exact code, but hard to transfer familiarity, so while Octave builds on people's Matlab familiarity I'm not sure you can confidently transfer actual code from Matlab to Octave. Given a very specific goal, I am guessing that NumPy plus Matplotlib would probably be a good base for building an Activity. For generic goals -- analyzing data in novel ways -- straight Python may be too undirected, and writing a directed Activity would probably be a significant undertaking. Ian ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Sjoerd, I know the wikipedia list. Most papers (never implemented). And to my best knowledge none implemented at layer 2. On Jan 30, 2008 4:12 PM, Sjoerd Simons [EMAIL PROTECTED] wrote: On Wed, Jan 30, 2008 at 10:37:24AM -0200, Ricardo Carrano wrote: Sjoerd, Could you please develop this? What do you mean by wireless firmware not being good enough to do actual multicast routing.? Not good enough might be a bit harsh. What i mean is that as far as i know it doesn't implement any mesh multicast routing protocols. MAODV is a well-known example of a mesh multicast routing protocols and there are a whole bunch more. Wikipedia has a whole list[0] and if you look a bit into the research on MANET's a bit you'll probably find those and a whole lot more. If it would implement one of those, the point at which the network starts melting because of MDNS traffic should be a lot higher then it is now. Especially if you have a reasonably dense network, like say inside one school. Sjoerd 0: http://en.wikipedia.org/wiki/List_of_ad-hoc_routing_protocols#Multicast_Routing -- Each of us bears his own Hell. -- Publius Vergilius Maro (Virgil) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1614
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1614 Changes in build 1614 from build: 1612 Size delta: 0.00M -fontconfig 2.4.2-3.fc7 +fontconfig 2.4.2-4.olpc2 -sugar-presence-service 0.65-0.31.20080103git76984f3f28 +sugar-presence-service 0.75.0-1 --- Changes for fontconfig 2.4.2-4.olpc2 from 2.4.2-3.fc7 --- + Fix %post so that older cache files are deleted + Make fc-cache verbose to aid in debugging + Add mtime_fix.patch to store directory mtime information in cache + (backport from version 2.4.92) + Resolves: olpc ticket #1525 --- Changes for sugar-presence-service 0.75.0-1 from 0.65-0.31.20080103git76984f3f28 --- + dev.laptop.org #6142: Don't update buddy properties without a key -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
kernels in repository
The announcement New joyride build 1610 says: -kernel 2.6.22-20080129.2.olpc.1b84a9e4bedcd66 +kernel 2.6.22-20080129.3.olpc.13dc6cf365d32ae Presumably the use of olpc in naming this kernel indicates that olpc-specific tweaks have been applied. To avoid needing to re-customize if I were to install anew, I often use 'yum update'. What that offers is a 2.6.23 kernel (without the olpc in its name). If this 2.6.23 kernel is missing some of those olpc-specific tweaks, should it even __be__ in the package repository accessed by 'yum' ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 3 activities with system-name maze
I think that the JigSaw bundle linked to from the activity page is altogether wrong. It should be Jigsaw, not Maze. I'll try to find the proper link. -walter On 1/29/08, Chris Hager [EMAIL PROTECTED] wrote: Hey all, I just wanted to inform you, that we have 3 Activities with the system name maze (specified in activity.info). They are: 1. Maze 2. Jigsaw Puzzle 3. GCompris-Maze I'm not sure what impact it may have on Journal, Sugar or removing the bundles, there are some issues with xo-get, as it removes activities by their system names. Maybe it's possible to give them more distinct names than just maze (except for 'maze' of course :)... Regards from Vienna, Chris http://xo-get.olpc.at/repository/ http://xo-get.olpc.at/repository/xoget.xml ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1614
-sugar-presence-service 0.65-0.31.20080103git76984f3f28 +sugar-presence-service 0.75.0-1 The version number does not seem to have been bumped to 0.75.0 in git master. Where does it come from? I noticed the same with journal and web-activity a few weeks ago, the versions in configure.ac lag behind what the joyride logs show. Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO Connectivity: Some Ideas
Hello, I found out that XO uses SoC Wireless Adapter for providing networking locally. In the present system 56k modem with fixed telephone line connection or WiFi connection is provided for network connectivity. One laptop connected via USB to a GSM/GPRS Modem could serve as a mesh portal point. The XOs present in the mesh could access the internet from this XO. Otherwise, External Mobile Phone (GPRS enabled) can be connected to the XO via infrared (IrDA), Bluetooth (Not a feasible option! It may cause disturbance with WiFi) or via a USB cable. Some Advantages that I thought of: In todays fast paced world where everyone is running short of time, parents generally do not have time to keep check over their wards activities which may lead to falling in the bad company or indulge in undesirable activities. Parents can get location information from their child laptop after sending a request to it. Sol: Parents can directly SMS (as in rural areas internet is not available) through even a cheap mobile (which is available) to the School server where a running application would find the location of the laptop in the mesh and reply the parent back with a SMS. Students in the schools can write their queries on laptop and then send them via SMS to teachers at distant places even after school hours which would result in a better and cheap way of communication. Sol: On mesh network Student can send SMS to teachers mobile regarding any query one has. Many of the students remain uninformed of important notices and circulars etc. issued by the institution authorities and thus face problems, leading to waste of time and energy. Teacher can send real-time messages to students providing them information regarding all happenings (e.g. results notification, attendance record, assessment deadlines, feedback from tutors and other urgent administrative details) on their laptops. Sol. Teachers when away from their students can send urgent messages to mesh portal point via their mobiles. Wireless Internet can be achieved without any distance constraint by incorporating GSM/GPRS Modem. This enables the student to attend online classes and tutorials without any distance limitation. GSM/GPRS Modem can also serve the purpose of internet in areas where no internet facility is available, but GSM coverage is there. (E.g. Remote Rural areas, which are the targets where we want to, deploy XO). Design and Development: For interfacing external GSM/GPRS Modem, we need to communicate to it via Serial Port programming. A Driver is already available in Fedora 4 for PL2303, a chip used to convert USB to Serial. We just need to put SIM card into GPRS Phone, then plug it. If / dev/ttyUSB0 is there, that means Fedora recognized this Modem. Then using minicom, we can test the connection using Hayes AT commands. The GPRS Modem setup finished! And then Internet could be shared among the mesh nodes. Further, for Sending and Receiving SMS, an application needs to be built, starting from low level details by using AT Commands for communicating with the GSM modem. Apart from this, GSM Modem could also be interfaced with the school server giving it all the networking capabilities and then via wireless all the laptops could get internet connectivity. Please give me your views and suggestions regarding it. I would be very interested in contributing to it. Earlier, I had worked for OLPC as Summer of Content Intern. I had put what I explained above on this page along with some more elaboration. Ankur Verma Junior, Undergraduate Student Electronics and Communication Engineering, NSIT, New Delhi Website: http://ankur.nsit.googlepages.com/ - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1614
On Wed, 2008-01-30 at 23:22 +0200, Jani Monoses wrote: -sugar-presence-service 0.65-0.31.20080103git76984f3f28 +sugar-presence-service 0.75.0-1 The version number does not seem to have been bumped to 0.75.0 in git master. Where does it come from? I noticed the same with journal and web-activity a few weeks ago, the versions in configure.ac lag behind what the joyride logs show. Not sure about s-p-s, but the journal and most of sugar packages are being released from the update.1 branch. The idea is that we are not releasing anything from master until update.1 is released. I think/hope all this will change after update.1, when we review our processes. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Like Michail and Ricardo said, going from a paper publication to an actual implementation and also _testing_ of that implementation is a very long way. The following factors need to be taken into account when comparing various approaches to routing and presence in MANETs: 1) scalability: I would consider broadcasting a special case of multicasting and as such I assume this is a O(n^2) approach (this means that, on average, there are n packets in the network for each of n nodes) 2) mobility: Requiring our protocol to be able to handle mobile nodes eliminates a good portion of the literature for routing in ad-hoc networks. AODV is the most widely adopted algorithm for routing in MANETs. 3) simplicity: This is more important than it sounds. This is the factor that allows theory to turn into implementation. Multicasting in the mesh network does not scale, but it is relatively simple. My approach to provides presence information for a 100 nodes with a total overhead of 120Kbps at the worst case (everybody in range with each other, like in the school scenario). For 200 nodes, it would have an overhead of up to 240Kbps in the worse case and so on. Time resolution is at 10 seconds/hop, so for 5 hops it will take 50 seconds for a change to propagate from one side to the other. By doubling the time resolution to 20 secs/hop, the overhead gets halved to 60Kbps for 100 nodes, etc. The whole implementation is about 700 lines of python code, so this should provide a hint about its simplicity. I have implemented both the protocol and a simulator that runs multiple instances of the actual implementation, just to showcase its actual scalability. The problem is that running more than 50 nodes on my Centrino 1.8MHz uses up all available processing power and packets start getting dropped. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Announcement: LiveBackup XO-LiveCD (build 689)
A new release of the Livebackup XO-LiveCD is available at: http://dev.laptop.org/pub/livebackupcd and mirrored at ftp://rohrmoser-engineering.de/pub/XO-LiveCD/ http://skolelinux.de/XO-LiveCD/ Main features and changes since the initial version: * the CD is based on OLPC development build 689 * during startup you can choose between English, Spanish, French or German language/keyboard settings. * the Live-CD has an automated installation of additional (beta) activities. Depending on available RAM size you will get some or all of: BlockParty-7.xo, CartoonBuilder-RC-1.7.xo, FlipSticks-RC-1.4.xo Implode-2.xo, JigsawPuzzle-1_20071030.xo, Jump-1.xo, Maze-3.xo, Simcity-4.xo, SliderPuzzle-3_20071030.xo, Speak-3.xo StopWatchActivity-1.xo, StoryBuilder-11.xo, branches-stable-ImageQuiz.activity-ImageQuiz.xo, gcompris.activity.xo * the documentation has a new chapter about system installation on harddisk and configuration of a multiboot setup. This Live-CD project targets the main goals: * give children, students, teachers and parents the opportunity to participate and use the educational software on a common PC * support demonstration of OLPC software to non-developers * for developers the CD provides an easy maintainable Live-System, which could be used to develop and test activities on the sugar desktop Further information is available in the PDF documents: ftp://rohrmoser-engineering.de/pub/XO-LiveCD/XO-LiveCD_080130.pdf http://skolelinux.de/XO-LiveCD/XO-LiveCD_080130.pdf For discussion we invite you to join the mailing list: http://lists.laptop.org/listinfo/livebackup-xo-cd Regards Wolfgang Rohrmoser, Kurt Gramlich ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: [PyCON-Organizers] OLPC Booth]
2008/1/29 Noah Kantrowitz [EMAIL PROTECTED]: Anyone know the status on this? Hello, We are holding open an OLPC booth, as someone had mentioned that they wanted one. Can anyone confirm this? A number of OLPC volunteers will be at PyCon, myself included. Does that work? Thanks, Van ___ Pycon-organizers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pycon-organizers ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 3 activities with system-name maze
It looks like this has been fixed now. http://wiki.laptop.org/index.php? title=Activitiesdiff=103441oldid=103206 I went to look to see how this happened, for fear that I had somehow done this by mistake. It looks like someone named Golfscout checked in a new version of the JigsawPuzzle-1_20071030.xo file on December 23rd with the Maze.activity bundle in it. http://wiki.laptop.org/go/Media:JigsawPuzzle-1_20071030.xo#filehistory The wiki says that person has no contributions: http:// wiki.laptop.org/go/Special:Contributions/Golfscout so I'm not sure what happened or why. As for the name conflict between Maze and GCompris-Maze... I picked the name Maze naively. Since GCompris pre-dates Maze I'm happy to rename Maze to Labyrinth or something like that, but I'd like to understand the details of the name conflict before I do. I thought that only bundle_id needed to be unique. -josh On Jan 30, 2008, at 12:22 PM, Walter Bender wrote: I think that the JigSaw bundle linked to from the activity page is altogether wrong. It should be Jigsaw, not Maze. I'll try to find the proper link. -walter On 1/29/08, Chris Hager [EMAIL PROTECTED] wrote: Hey all, I just wanted to inform you, that we have 3 Activities with the system name maze (specified in activity.info). They are: 1. Maze 2. Jigsaw Puzzle 3. GCompris-Maze I'm not sure what impact it may have on Journal, Sugar or removing the bundles, there are some issues with xo-get, as it removes activities by their system names. Maybe it's possible to give them more distinct names than just maze (except for 'maze' of course :)... Regards from Vienna, Chris http://xo-get.olpc.at/repository/ http://xo-get.olpc.at/repository/xoget.xml ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ 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: XO Speech Server : speech-dispatcher
I'm glad that is getting off the ground; I'm sure the speech-dispatcher people would love the extra attention. The core API is usable as it is; I dont see any reason to change the design of the software. - Duane On Sunday 27 January 2008 08:40:21 am Hemant Goyal wrote: Hi, We have been analyzing the speech-dispatcher as a viable option for the XO. Our initial analysis has thrown up great results and it seems to support the present requirements from a speech synthesis server. With the inclusion of speech-dispatcher on the XO we will be able to have a truly client-server based model for speech synthesis. It uses sockets for communication (is that okay ?) Speech-dispatcher has provided a Python Client API [ http://cvs.freebsoft.org/repository/speechd/src/python/speechd/client.py?vi ew=markup ]. Questions: 1. We are wondering whether this API would be directly usable/suitable for use on the XO or it should be modified to make it simpler to use? 2. How can we request for inclusion of the speech-dispatcher daemon services and libraries on the XO? Thanks! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1616
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1616 Changes in build 1616 from build: 1614 Size delta: 0.00M -libertas-usb8388-firmware 2:5.110.20.p49-1.fc7 +libertas-usb8388-firmware 2:5.110.22.p1-1.fc7 -telepathy-salut 0.2.0-2.olpc2 +telepathy-salut 0.2.2-1.olpc2 --- Changes for telepathy-salut 0.2.2-1.olpc2 from 0.2.0-2.olpc2 --- + dev.laptop.org #6067: crash when you create and leave a muc fast + dev.laptop.org #6200: assertion failed: (priv-gt;state == STATE_JOINING) + dev.laptop.org #6199: crash when disposing connection -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
