Re: Definition of "Stable Enough To Release" for 8.2.0
On Wed, Jul 23, 2008 at 8:59 PM, Martin Langhoff <[EMAIL PROTECTED]> wrote: >> 9 - Always boots up, especially when there is no space on NAND > > "Always" is a tricky one :-) - might be useful to focus on specific issues > > - boots even with no space on NAND to a mode that allows > user-controlled file deletion > - warns when running out of space FWIW, joyride-2208 will start X even with no NAND space, and the sugar patches in #7587 allow us to start a usable Sugar. Unfortunately, the Journal doesn't start (#7631) -- working on this! Trac #7125 contains a complete taxonomy of "things we'd like to do when NAND is full". --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tuxpaint activity is bloated
On Wed, Jul 23, 2008 at 10:11 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > The "sugar-is-lame" string comes from a value that activities are > required to provide, even when the value is of no use. Activity > authors are being forced to provide a random string that is of no > use to the activity, so of course I provided one. The fact that I > was **forced** to provide this string is of course evidence of the > fact that sugar is in fact lame. Every Java program is required to have a unique class name. Most have unique package names. Is that lame? Among other things, this value is used to identify programs which purport to be the 'same' for upgrade purposes. See the 'activity management' portions of http://wiki.laptop.org/go/Presentations/April_2008_Technical_Mini-conference for more information. The Software Update control panel definitely uses the bundle_id, whether you think it is lame or not. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
On Thu, Jul 24, 2008 at 8:18 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > really surprisingly short. Each item on the list has been debated to a > stationary point over the last two years, so all that is left is to make a > final decision for the engineers to execute. Each task could be completed > or hugely improved by a single developer in a few months, provided that we > do not allow changes to the requirements, and the developers are not asked > to split their time and focus. I do not believe that either of these statements is correct. We are not lacking in decisions: we have substantially complete designs; we are lacking implementation. Each of your items is not the work of "a single developer in a few months": solving these problems is realistically a year's work at least, if we have a single developer working full time on each. And honestly, OLPC does not actually have the resources to devote a even single unique developer to each. If they did, we would not have any releases made, languages added, deployment issues addressed, emails sent to devel@, additional engineers interviewed and hired, or any of the myriad other tasks which the overstretched OLPC engineers currently do. We need realistic management and expectations, and I'm afraid that, "so let's just do these things" isn't going to help us much. But in one fundamental way you are entirely correct: these are (some of) our goals for our platform, and we should ensure that we are making progress in each release toward these ends. We should ensure that *some* progress is made in each of these areas in 9.1, and *some more* progress in 9.2, and so on until the features are complete. If we allow the work to be arbitrarily deferred, we will never get any closer to where we want to be. --scott ps. and, of course, you've neglected "software for kids that does things kids want to do", "powerful and pervasive collaboration" and "mesh networking" in your list of items. -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2208
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2208 Changes in build 2208 from build: 2207 Size delta: 0.00M -ohm 0.1.1-6.14.20080707git.olpc3 +ohm 0.1.1-6.15.20080707git.olpc3 -rainbow 0.7.16-1.fc9 +rainbow 0.7.17-1.fc9 --- Changes for ohm 0.1.1-6.15.20080707git.olpc3 from 0.1.1-6.14.20080707git.olpc3 --- + Move xauthority from /home/olpc to /var/tmp/olpc-auth. -- 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: Congratulations! but Sugar sucks
On Fri, Jul 25, 2008 at 12:18 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > The list of missing features needed to make Sugar a first-rate system is > really surprisingly short. Fantastic news! As Kim points out, we knew most (all?) those things already, and we are just extremely short on *people* so if you want to make a difference, trade the provocative letter-writing for some testing & patching help. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Calling all small keyboards
On Thu, Jul 24, 2008 at 3:29 PM, John Watlington <[EMAIL PROTECTED]> wrote: > > We are looking for examples of keyboards for small children > present before 1993. > > Specifically, we are looking for keyboards whose key-key spacing > is between 10.8 and 16.4 mm horizontally, and 10.8 to 18.0 mm > vertically, and with a stroke distance of 0.9 to 6mm. > > Thanks for your memories, > wad > > http://www.google.com/patents?vid=USPAT7354209 > http://www.google.com/patents?vid=USPAT7101101 > http://www.google.com/patents?vid=USPAT5531529 Reminds me of the Seiko UC-2200 I picked-up at a computer show in '85 or so. Wristwatch with a 40x24 display screen.(pixels, not characters) magneto-coupled non-contact interface to a keyboard base with plug-in application ROM pack, BASIC language programmable, integrated dot-matrix printer. Anybody got a BR2325 button cell battery? I'm not sure how you're measuring keyspace, but this looks close. horizontal edge-to-edge looks like 18.0 mm vertical at 10.0 mm can't estimate vertical stroke, but motion is involved. Label calls it a SEIKO UC-2200 CONTROLLER MODEL NO. UM01-0020 Hattori seiko co. ltd No 457624 made in Japan. FCC ID C4Z7NSUM0120 Pictures on the Wiki.. .http://wiki.laptop.org/go/Seiko_uc2200 -- Steve Holton [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
Am 24.07.2008 um 21:44 schrieb Daniel Drake: > The software GL is very slow but word on the street is that some > activities use it anyway. Until very recently we did not even ship libGL so no activity relying on it would even load. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
joyride keyboard problems & GL/glx
Just a quick FYI: the keyboard bugs in recent joyrides (various buttons not working or misbehaving) is fixed by the X server update in joyride 2207. The problem was that a Fedora 9 update included an updated evdev driver, which had been compiled against a newer X server (we have forked xserver, so we don't automatically get updates there). I have resynced our xserver with Fedora's so we support the new ABI which evdev uses. Resyncing the X server was not quite as simple as you might expect. Previously, X was compiled along with the mesa sources to offer software-based GL. The software GL is very slow but word on the street is that some activities use it anyway. In the newer X server, the software GL implementation (dri_swrast) has been moved to mesa, which we don't include in our builds. The newer X server also includes a bug which caused it to crash when no swrast was present, I wrote a patch included in our build which I will be committing to freedesktop git upstream shortly... Anyway, at the moment, we have no swrast in our build, which means no GL support at all. Does anyone care? I am going to work with Fedora to get the swrast module separated from the overweight mesa-dri-drivers - this could return in future if we need it. Sorry for any inconvenience, this was the most straightforward way of getting a working X and a working keyboard again. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2207
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2207 Changes in build 2207 from build: 2206 Size delta: -1.31M -gdb 6.8-11.fc9 +gdb 6.8-12.fc9 -kernel 2.6.25-20080722.2.olpc.d86980aeb8d0adb +kernel 2.6.25-20080724.1.olpc.284cecf34b83fb0 -ntp-ntpdate 4.2.4p4-1.olpc3 +ntp-ntpdate 4.2.4p4-7.olpc3 -olpc-utils 0.80-1.olpc3 +olpc-utils 0.81-1.olpc3 -rainbow 0.7.14-1.fc9 +rainbow 0.7.16-1.fc9 -cyrus-sasl-lib 2.1.22-13.fc9 +cyrus-sasl-lib 2.1.22-15.fc9 -glib2 2.16.4-1.fc9 +glib2 2.16.5-1.fc9 -gstreamer-plugins-good 0.10.8-7.fc9 +gstreamer-plugins-good 0.10.8-8.fc9 -xorg-x11-server-Xorg 1.4.99.902-3.20080612.olpc3.1 +xorg-x11-server-Xorg 1.4.99.906-1.olpc3 -xorg-x11-server-common 1.4.99.902-3.20080612.olpc3.1 +xorg-x11-server-common 1.4.99.906-1.olpc3 --- Changes for gdb 6.8-12.fc9 from 6.8-11.fc9 --- + Temporarily disable attaching to a stopped process (BZ 453688) + To be reintroduced after a fix of the kernel BZ 454404. --- Changes for glib2 2.16.5-1.fc9 from 2.16.4-1.fc9 --- + Update to 2.16.5 --- Changes for gstreamer-plugins-good 0.10.8-8.fc9 from 0.10.8-7.fc9 --- + gst-plugins-good-0.10.8-v4l2-progressive-fix.patch: Backport v4l2 -- 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: Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kimberley Quirk wrote: | I think many people will agree with much of what you have identified | in your rant; and we have been working on making the most progress we | can given the constraints of the 'real' world: Kim: Though I was obviously trying to be a bit provocative with my letter, I did not mean to imply a criticism of the work that has been done so far. ~ I have been very impressed with what you and the Sugar team have been able to accomplish, given the many constraints under which you have been operating. The point of my letter, ideally, is positive. Stated more formally, my thesis is: The list of missing features needed to make Sugar a first-rate system is really surprisingly short. Each item on the list has been debated to a stationary point over the last two years, so all that is left is to make a final decision for the engineers to execute. Each task could be completed or hugely improved by a single developer in a few months, provided that we do not allow changes to the requirements, and the developers are not asked to split their time and focus. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJG8oACgkQUJT6e6HFtqQ3rACeIcRBMnaaCaLuFWjoDogq8PDx AGYAniKBirOfFkA7CycAmHg0ObPcX5OL =peKD -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
From way out in right field Re: [sugar] Congratulations! but Sugar sucks
On 平成 20/07/25, at 6:53, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bert Freudenberg wrote: > | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: > | > |> 1. The datastore > |> 2. OS Updates > |> 3. File Sharing > |> 4. Activity Modification > |> 5. Bitfrost > |> 6. Power management > | > | Note that half of these items have nothing to do with Sugar, oo the > | subject line is a bit misleading. > > Every one of them requires work on the Linux-based software stack that > runs on the XO. The name of that stack is Sugar, as far as I'm aware. > Perhaps a breakdown would be helpful: > > 1. The datastore: Glucose > 2. OS Updates: Ribose. (Ribose is all the low-level software that > keeps > Sugar running on the XO) > 3. File Sharing: Glucose > 4. Activity Modification: Glucose and Fructose. > 5. Bitfrost: Glucose and Ribose. > 6. Power management: Glucose, Ribose, and EC. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkiI+dwACgkQUJT6e6HFtqROZgCeLfWTvjKraknjHT9MkrkK2Dhe > LcEAn2mHnSx0+2uvpEQpkCVOUCii/Zlx > =rbFq > -END PGP SIGNATURE- > ___ > Sugar mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/sugar > I'm not an active participant anywhere, just someone who wanted to but has never had the time. And I hate to be the party pooper. But, ... The keyword here is bloat. The source of the problem is the Sell. The Sell is Bill Gates's patented (with lots of prior art) checkmate move. When I ran out of time to monitor the list, you guys were still warding off the Sell, but somewhere in the last half-year, you succumbed. The only defense was to let those people that are deceived by Microsoft's sell tactics alone, let them wake up and smell the coffee when they do. That defense was set aside somewhere around the time somebody said, give the user su. Features take storage space, and some features are deceptively simply to spec and impossible to implement. There is no defense now. The only way forward is to go un-sell. Strip out the bloat and send someone around to apologize. Joel Rees ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
Ben, I think many people will agree with much of what you have identified in your rant; and we have been working on making the most progress we can given the constraints of the 'real' world: 1 - 350,000 laptops in the hands of kids today. This alone takes most of the resources away from your identified big issues and forces us to focus on the serious bugs that are currently shipping. This is not an excuse... just reality. We identified all the items you have written down as being 'not good enough' pretty much from the day we shipped. But the problems of real world take precedent over the next features. At the same time, we have been hiring so we can try to tackle both: support what we've shipped AND make progress on the next features. Hiring and coming up to speed take many months. 2 - OLPC never had enough resources to deliver all 6 of these new technologies with 'developed world' quality from day 1. This has been identified well before we even shipped the first laptop... and we decided it was still better to have something in the hands of kids rather than nothing. We've heard it from others who have visited schools in Mongolia, Rwanda, Haiti, Uruguay, etc. and I will add my voice to that group as I just got back from visiting a school in Peru. The students and teachers are all learning so quickly with the laptops, and they are all excited and appreciative to have this opportunity in their school. It really is better to continuing shipping these laptops where they can help children, then to stop and 'get it right' for the developed world market. Yes, sometimes progress is slow; and I (for one) appreciate the time and thought you put into this list as it DOES represent the areas where we want to make progress and can most use help. Now, maybe we can turn this list into a real request for how people can help! Kim On Jul 24, 2008, at 2:25 PM, Benjamin M. Schwartz wrote: > (Foreword: I originally intended to send this e-mail after the > release of > 8.2.0, > but I have been convinced to send it earlier in order to prompt > discussion) > > Dear OLPC developers, > > Congratulations on your work so far towards 8.2.0, with its new UI, > new > underpinnings, and thousands of individual improvements. It took > years of > effort to get this far, and a tremendous amount has been done to > reinvent > the entire notion of a software stack to better serve the educational > needs of children. This release will be a triumph. > > Unfortunately, it is also an abysmal failure. There is hardly a worse > operating > environment available than Sugar as it currently stands. In > addition to an > amazing variety of terrible bugs, this failure is due to a handful of > major missing > features. I list here six major missing features, and what can be > done about > them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding. > > 1. The datastore > Sugar's design calls for a centralized rich data storage system, the > datastore. The datastore provides secure, limited file access to > Activities, manages file metadata, maintains a differentially > compressed > history of all work, ensures reliable backups to a trusted server, and > mediates the connection to removable media. Every one of these > features > is crucial to Sugar's functioning, and almost none are really > working at > this time. We cannot afford another release based on the present > datastore, as it fails to implement the features we require, and is > unreliable even in the features it supposedly implements. > > Solution: > There have, at this point, been at least five distinct proposals for a > next-generation datastore design, all differing in underlying > implementation and user-facing functionality. We need to have a > Once And > For All datastore summit, draw up a compromise datastore design, and > implement it. We can do this by 9.1.0, if we are willing to make it a > priority. > > 2. OS Updates > We now have hundreds of thousands of laptops deployed in the field, > running a variety of OS versions. OLPC cannot afford to support a > multitude of decrepit versions, and children cannot afford to suffer > defects that have long since been fixed. We need a reliable, fast, > update system that does not rely on the network, so that children > everywhere can move to the > latest version of Sugar without losing their data. The update > system must > support tremendously invasive upgrades, like repartitioning the NAND > and > replacing JFFS2, because we expect to do this in short order. > > Solution: > A secure usb autoreinstallation stick is required. It is not > technically > challenging to implement, but it must be made a priority, and then > be made > widely available and idiot-proof. > > 3. File Sharing > Students and teachers have no good way to distribute files directly > from > one person's Journal to another. If all Activities that open a file > do
[RFC] Four solutions to NAND fillup
OLPC Developers, Greg asked me to write a report of the solutions to the NAND fillup problem. We need to present a set of solutions to LATU as soon as possible so that they can establish what solution(s) are tenable for their deployment. Several provisional solutions are in the works. I describe and evaluate them here. I seek comments, suggestions, and clarifications. Description: -= 1. Boot on a read-only filesystem =- For the 8.2.0 release our developers are working on getting the system to boot and run without any writes to the underlying filesystem. This allows us to reach a state in which the user has access to the journal and can start deleting items. -= 2. Automatically delete files from the datastore =- Chris Ball has produced a patch which will delete items from the datastore when we encounter a NAND-full situation at boot. It builds a list of files in the datastore, sorts them in order of size, and deletes them from largest to smallest until the system's free space falls below some threshold. -= 3. Boot on a union-mounted writeable filesystem =- A union mount (http://en.wikipedia.org/wiki/Union_mount) can be used to unify a read/write filesystem (typically a ram-backed tmpfs) and a read-only filesystem (such as a CD-R or a full jffs2 partition) into a single writeable filesystem. This arrangement allows us to boot Sugar and run applications without any code-level modifications. -= 4. Store a large file on jffs2 and delete when space is low =- This solution is roughly equivalent to the aufs solution except that boot is guaranteed when NAND is full by removing a large buffer file stored in the jffs2 root partition. Discussion: 1. Booting Sugar even on a read-only filesystem is a development goal for 8.2.0 (and as I understand has been mostly achieved for that purpose), but for Uruguay it may not be possible to push such a complex set of changes from our development branch into the builds which they have deployed. 2. This solution is by far the simplest and most sure to immediately resolve the problem. However, automatically deleting files seems to me to be at least a user-confusing solution to the NAND fillup problem. We are teaching children what to expect from computers. Absolute breakage due to storage media exhaustion is intelligible, but apparently random patterns of file deletion may confuse users. More problematically, the only metric which we can establish for automatic deletion is size, and this may bias deletions toward specific activities, perhaps ones needed or specifically desired by users. Despite these concerns, we must acknowledge that such a change is certainly within the realm of feasibility for Uruguay's deployment and will at least resolve a mounting support problem caused by NAND fillup. In my opinion, this should be considered a viable failsafe solution. 3. This solution has been tested, and verified to boot Sugar and launch activities on an otherwise unmodified 656 system with a full NAND. To boot on a union-mount, all that is required is the addition of the aufs module (Another UnionFS) to the initramfs and a patch to the initscripts to check if the system has passed the NAND fill threshold. A small amount of work is still required to update the Journal to delete items from the jffs2 partition when the system is running on a union mount. Further work could be completed to force the user to delete items, but it may be sufficient to simply alert the user to the fact that the system will not save any data between reboots until they delete enough items from their journal. We will also have to convey some information to the user about how close they are to the fillup threshold. 4. This solution has not yet been tested, but it seems likely to work, to similar effect as #3. It presents us with a slighly different set of issues; namely, we must manage the episodic creation and deletion of a large file. We also must forbid the user from creating more data while the buffer file is not in existence, lest we decrease the amount of buffer available or end up with an unbootable system. This requires a much more stringent recovery console than #3, such as an X session only running an instance of the journal activity. Furthermore, depending on the size of the file, some percentage of deployed systems may fall into NAND-full territory during upgrade. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpcgames SVGSprite bug + fix
+ [EMAIL PROTECTED] 2008/7/22 Alex Levenson <[EMAIL PROTECTED]>: > Hello, > > I've been using olpcgames for some physics + puzzle games I'm writing. I > just started using the SVGSprite class but I kept on getting an error when > using it. I realized that in the SVGSprite class a module named 'svg' is > imported, AND a local variable is named svg. So when you call svg.render() > it tries it on the local variable (which is a string) and then that causess > a crash. > The fix is easy, change the line at the top of svgsprite.py from: > from olpcgames import svg > to: > from olpcgames import svg as svgModule > and then later in the code there is one reference to svg that needs to be > changed to svgModule. > Basically just a python scope issue, but I don't know who maintains > olpcgames so I decided to just send this to devel. > > Thanks, > Alex Levenson > > ___ > 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: Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bert Freudenberg wrote: | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: | |> 1. The datastore |> 2. OS Updates |> 3. File Sharing |> 4. Activity Modification |> 5. Bitfrost |> 6. Power management | | Note that half of these items have nothing to do with Sugar, oo the | subject line is a bit misleading. Every one of them requires work on the Linux-based software stack that runs on the XO. The name of that stack is Sugar, as far as I'm aware. Perhaps a breakdown would be helpful: 1. The datastore: Glucose 2. OS Updates: Ribose. (Ribose is all the low-level software that keeps Sugar running on the XO) 3. File Sharing: Glucose 4. Activity Modification: Glucose and Fructose. 5. Bitfrost: Glucose and Ribose. 6. Power management: Glucose, Ribose, and EC. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI+dwACgkQUJT6e6HFtqROZgCeLfWTvjKraknjHT9MkrkK2Dhe LcEAn2mHnSx0+2uvpEQpkCVOUCii/Zlx =rbFq -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2206
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2206 Changes in build 2206 from build: 2204 Size delta: 0.13M -initscripts 8.76.2-1.olpc3.6 +initscripts 8.76.2-1.olpc3.7 -- 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: Congratulations! but Sugar sucks
Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: > 1. The datastore > 2. OS Updates > 3. File Sharing > 4. Activity Modification > 5. Bitfrost > 6. Power management Note that half of these items have nothing to do with Sugar, oo the subject line is a bit misleading. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mikus Grinbergs wrote: | I'm not familiar with the details of the Rainbow implementation, but | I question this claim: | |> Sugar, as it currently stands, is among the least secure operating systems |> ever, far less secure than any modern Linux or Windows OS. I can easily |> write an Activity that, when run by the user, escalates to root privileges |> and does anything I like with the system. | | My understanding was that something called an 'Activity' would be | assigned its own userid-groupid. The standard Linux permissions | would prevent such an 'Activity' from messing up the system. The problem is the "loophole'd" activities: Journal and Terminal. These two activities run with the full privileges of the user. The identity of an activity is simply its D-Bus name. Therefore, if I write an Activity and set its D-Bus name to be org.laptop.TerminalActivity, it will run as user "olpc", not as an isolated user. It will therefore have root access via passwordless su. This loophole was meant as a temporary workaround, to be replaced once Sugar acquired a secure mechanism for providing specific Activity bundles with elevated privileges. I'm merely suggesting that it is time to implement that mechanism. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI3QEACgkQUJT6e6HFtqSOKQCcCwW0dNZ9nnrHgF/bzEuU0YPj wdUAn2Vnfx+RVw95W/fUXqtcQVF2aGSI =bs5K -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
I'm not familiar with the details of the Rainbow implementation, but I question this claim: > Sugar, as it currently stands, is among the least secure operating systems > ever, far less secure than any modern Linux or Windows OS. I can easily > write an Activity that, when run by the user, escalates to root privileges > and does anything I like with the system. My understanding was that something called an 'Activity' would be assigned its own userid-groupid. The standard Linux permissions would prevent such an 'Activity' from messing up the system. I agree that "as of this date", the 'su' (or its equivalent) provision sucks -- a decision has been made that the kid does not have to enter a password, even if one has been defined for root. But that can be improved to not remain the 'least secure ever'. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
Deepak Saxena wrote: > On Jul 24 2008, at 14:06, Ton van Overbeek was caught saying: > >> Tried your updated ramdisk, still no boot. >> No more missing modules, but the mount still fails in the same way. >> USB Mass Storage support is now properly loaded. Here is an excerpt from >> the boot screen: >> - >> [5.540762] usbcore: registered new ineterface driver usbfs >> [5.553912] usbcore: registered new interface driver hub >> [5.564065] usbcore: registered new device driver usb >> [5.585768] usbcore: registered new interface driver libusual >> [5.601305] Initializing USB Mass Storage driver... >> [5.613938] usbcore: registered new interface driver usb-storage >> [5.619927] USB Mass Storage support registered. >> [5.630239] modprobe used greatest stack depth: 2888 bytes left >> mount: mounting /dev/sda1 on /sysroot failed: No such device or address >> [ 10.904898] mount used greatest stack depth: 2772 bytes left >> Traceback (most recent call last:) >> >> [ 11.239467] init used greatest stack depth: 2708 bytes left >> >> --- >> Note that it takes about 5 seconds for mount to fail. >> Something wrong with /dev or /sysroot in the ram disk >> > > Can you try with the updated olpcrd at the same URL? We're also missing > sg.ko. I've added it to the ramdisk along with the changes to load it. > If this works for you, we'll push into another build. > > The 5 seconds is b/c we sleep to give disks time to spin up. > > Thanks, > ~Deepak > Tried with your version of 14:57 (2720066 bytes). Same result. Same messages, still failure to mount /dev/sda1. Apologies for the disappointing result. Do we need more/other scsi modules? Can we get more debug info from mount? Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Calling all small keyboards
We are looking for examples of keyboards for small children present before 1993. Specifically, we are looking for keyboards whose key-key spacing is between 10.8 and 16.4 mm horizontally, and 10.8 to 18.0 mm vertically, and with a stroke distance of 0.9 to 6mm. Thanks for your memories, wad http://www.google.com/patents?vid=USPAT7354209 http://www.google.com/patents?vid=USPAT7101101 http://www.google.com/patents?vid=USPAT5531529 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Congratulations! but Sugar sucks
(Foreword: I originally intended to send this e-mail after the release of 8.2.0, but I have been convinced to send it earlier in order to prompt discussion) Dear OLPC developers, Congratulations on your work so far towards 8.2.0, with its new UI, new underpinnings, and thousands of individual improvements. It took years of effort to get this far, and a tremendous amount has been done to reinvent the entire notion of a software stack to better serve the educational needs of children. This release will be a triumph. Unfortunately, it is also an abysmal failure. There is hardly a worse operating environment available than Sugar as it currently stands. In addition to an amazing variety of terrible bugs, this failure is due to a handful of major missing features. I list here six major missing features, and what can be done about them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding. 1. The datastore Sugar's design calls for a centralized rich data storage system, the datastore. The datastore provides secure, limited file access to Activities, manages file metadata, maintains a differentially compressed history of all work, ensures reliable backups to a trusted server, and mediates the connection to removable media. Every one of these features is crucial to Sugar's functioning, and almost none are really working at this time. We cannot afford another release based on the present datastore, as it fails to implement the features we require, and is unreliable even in the features it supposedly implements. Solution: There have, at this point, been at least five distinct proposals for a next-generation datastore design, all differing in underlying implementation and user-facing functionality. We need to have a Once And For All datastore summit, draw up a compromise datastore design, and implement it. We can do this by 9.1.0, if we are willing to make it a priority. 2. OS Updates We now have hundreds of thousands of laptops deployed in the field, running a variety of OS versions. OLPC cannot afford to support a multitude of decrepit versions, and children cannot afford to suffer defects that have long since been fixed. We need a reliable, fast, update system that does not rely on the network, so that children everywhere can move to the latest version of Sugar without losing their data. The update system must support tremendously invasive upgrades, like repartitioning the NAND and replacing JFFS2, because we expect to do this in short order. Solution: A secure usb autoreinstallation stick is required. It is not technically challenging to implement, but it must be made a priority, and then be made widely available and idiot-proof. 3. File Sharing Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer that file over the network. This is the most basic possible network functionality --- FTP was standardized in 1971 --- but it is completely missing from our system. Solution: A number of technical proof-of-concept programs have been written for distributing files, using methods like HTTP over stream tubes and Cerebro's Teleport. There is an excellent set of UI mockups for this functionality. All that is left is to Get It Done. 4. Activity Modification A keystone of the Sugar design has always been the user's ability to edit any Activity, and to cement this a "View Source" key was designed right into the hardware. This functionality is simply missing, and that prevents us from making our principal claim regarding an emphasis on user modification. Solution: "Develop" must be polished, finished, and included by default. This will require modifications to the core system, in order to support an endless variety of slightly modified Activities. It will also require work on the Develop program itself. If volunteer efforts are not moving fast enough, OLPC must ensure that someone is working on the problem as a professional. 5. Bitfrost Sugar, as it currently stands, is among the least secure operating systems ever, far less secure than any modern Linux or Windows OS. I can easily write an Activity that, when run by the user, escalates to root privileges and does anything I like with the system. Given Sugar's competitive status against Windows XO, this failing threatens the very existence of the project. The Sugar designs have long stated that safely running untrusted code from a classmate is a key goal for learning, but the current software accomplishes precisely the opposite. Solution: NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on Sugar security (after activation) has either left OLPC or moved into another role. Someone must be assigned to continue the security work, or it will certainly never make progress. Anyone who _does_ take on this challenge will start from a much better position th
Re: Cannot boot joyride-2200 from USB stick
Deepak Saxena wrote:
> On Jul 24 2008, at 08:07, Deepak Saxena was caught saying:
>
>> On Jul 24 2008, at 09:37, Ton van Overbeek was caught saying:
>>
>>> I did *not* copy it to /versions/boot/current/boot, since it never
>>> completed the
>>> boot from the USB stick.
>>>
>>> I copied your modified ramdisk to /boot on the USB disk, renamed it to
>>> olpcrd-2.6.25-deepak-fix.img and changed the olpcrd.img sym link to
>>> point to it.
>>>
>>> The USB boot still does not succed, but we are a bit further.
>>> Now it is complaining about a missing libusual.ko:
>>> WARNING: Could not open
>>> '/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/libusual.ko':
>>>
>>> No such file or directory
>>> I get fewer warnings about missing symbols in usb-storage (now only four):
>>> storage_usb_ids, usb_usual_clear_presetn, usb_usual_check_type and
>>> usb_usual_set_present.
>>> But the end result is still the same: cannot mount /dev/sda1 on /sysroot.
>>>
>>> Could you make (yet) an other fixed ram disk which I can try?
>>>
>> Yep.
>>
>
> OK, I've uploaded a new olpcrd with libusual to the same URL.
>
>
>>> Other question, should this be entered in trac, and is it blocking for
>>> 8.2.0 ?
>>>
>> I've opened #7620 to track this. Definetely a blocker.
>>
>
> Scott has added the missing modules and we should see it fixed in the next
> joyride.
>
> ~Deepak
>
Tried your updated ramdisk, still no boot.
No more missing modules, but the mount still fails in the same way.
USB Mass Storage support is now properly loaded. Here is an excerpt from
the boot screen:
-
[5.540762] usbcore: registered new ineterface driver usbfs
[5.553912] usbcore: registered new interface driver hub
[5.564065] usbcore: registered new device driver usb
[5.585768] usbcore: registered new interface driver libusual
[5.601305] Initializing USB Mass Storage driver...
[5.613938] usbcore: registered new interface driver usb-storage
[5.619927] USB Mass Storage support registered.
[5.630239] modprobe used greatest stack depth: 2888 bytes left
mount: mounting /dev/sda1 on /sysroot failed: No such device or address
[ 10.904898] mount used greatest stack depth: 2772 bytes left
Traceback (most recent call last:)
[ 11.239467] init used greatest stack depth: 2708 bytes left
---
Note that it takes about 5 seconds for mount to fail.
Something wrong with /dev or /sysroot in the ram disk
I'll try the next joyride (2205 ?) too.
My firmware is now Q2E11 (got updated during one of these tests when my
xo-1 was on net power)
Ton van Overbeek
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Jul 24 2008, at 08:07, Deepak Saxena was caught saying: > On Jul 24 2008, at 09:37, Ton van Overbeek was caught saying: > > I did *not* copy it to /versions/boot/current/boot, since it never > > completed the > > boot from the USB stick. > > > > I copied your modified ramdisk to /boot on the USB disk, renamed it to > > olpcrd-2.6.25-deepak-fix.img and changed the olpcrd.img sym link to > > point to it. > > > > The USB boot still does not succed, but we are a bit further. > > Now it is complaining about a missing libusual.ko: > > WARNING: Could not open > > '/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/libusual.ko': > > > > No such file or directory > > I get fewer warnings about missing symbols in usb-storage (now only four): > > storage_usb_ids, usb_usual_clear_presetn, usb_usual_check_type and > > usb_usual_set_present. > > But the end result is still the same: cannot mount /dev/sda1 on /sysroot. > > > > Could you make (yet) an other fixed ram disk which I can try? > > Yep. OK, I've uploaded a new olpcrd with libusual to the same URL. > > Other question, should this be entered in trac, and is it blocking for > > 8.2.0 ? > > I've opened #7620 to track this. Definetely a blocker. Scott has added the missing modules and we should see it fixed in the next joyride. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Jul 24 2008, at 09:37, Ton van Overbeek was caught saying: > I did *not* copy it to /versions/boot/current/boot, since it never > completed the > boot from the USB stick. > > I copied your modified ramdisk to /boot on the USB disk, renamed it to > olpcrd-2.6.25-deepak-fix.img and changed the olpcrd.img sym link to > point to it. > > The USB boot still does not succed, but we are a bit further. > Now it is complaining about a missing libusual.ko: > WARNING: Could not open > '/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/libusual.ko': > > No such file or directory > I get fewer warnings about missing symbols in usb-storage (now only four): > storage_usb_ids, usb_usual_clear_presetn, usb_usual_check_type and > usb_usual_set_present. > But the end result is still the same: cannot mount /dev/sda1 on /sysroot. > > Could you make (yet) an other fixed ram disk which I can try? Yep. > Other question, should this be entered in trac, and is it blocking for > 8.2.0 ? I've opened #7620 to track this. Definetely a blocker. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2204
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2204 Changes in build 2204 from build: 2203 Size delta: 0.00M -hulahop 0.4.1-3.olpc3 +hulahop 0.4.2-1.olpc3 -- 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
Feedback from deployment lead
Hi All, I got some good feedback this week on priorities from Carla who has led several of our early installations. Its posted at: http://wiki.laptop.org/go/9.1.0#Unadorned_and_unedited_user_feedback I probed for more detail on: "Guarantee that everything they work on is saved –and/or backed up– and never lost." I think we will ensure no data is lost on shutdown (see recent autosave in 8.2.0 thread). However, their experience was a little different. See the details below. We have lost touch with them so this is all the info we are likely to get. Does this look familiar to anyone and if so do we know if its fixed in 8.2.0 (e.g. bug ID)? Please don't e-mail Carla directly on this. Give me a chance to gather the consensus of the list and get back to her. That way we won't bury her inbox and discourage further input. Thanks, Greg S Running 703 w/ Q2D14 they saw this: Write: In one group, many teachers lost all their work in Write. It didn't save automatically, and even if they saved manually, they suddenly lost all their data. It doesn't even appear on the Journal. It happened in at least 7 machines out of a group of 23 teachers and we couldn't find any pattern. I couldn't replicate the problem on mine. Also, instead of re-saving within the same file, it saves many new files every time it auto-saves, however sometimes it doesn't auto-save. This is for the 7 teachers that lost their work: They were using lots of tables, images, lots of formatting to the text (color, size,...) and the files were long... Since the journal didn't show it. They couldn't back it up to USB key One teacher was saving his work, then copied to a USB and tried looking at it on a PC (he tried all the 4 formats) and he always got a blank file with 0 Kb. (no significance to the caps - GS) RIGHT NOW TEACHERS ARE ALSO TELLING ME THAT IMAGES SAVED IN A FILE ARE NOT ALWAYS KEPT IN THE FILE , SPECIALLY IF SAVING UNDER HTML.. OR THEY SAVE IN ONE MACHINE SHARE IT WITH OTHERS AND OTHERS DON'T SEE THE IMAGES. THEY ARE SAVING 'WRITE' IN USB KEYS AND TRY TO SHARE IT AND THEN IT DISPLAYS NO-CONTENT IN OTHER XOs ...AND IN MY IBM LAPTOP I CAN'T SEE THE FILE. IT HAD HAPPENED TWICE. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
Deepak Saxena wrote: > On Jul 23 2008, at 22:30, Ton van Overbeek was caught saying: > >> Booting starts, but mounting /dev/sda1 on /sysroot fails because the >> usbcore.ko module >> needed by usb-storage.ko cannot be found. >> > > Our initramfs is missing usbcore and hcd-ehci. I've uploaded a manually > fixed version @: > > http:/dev.laptop.org/~dsaxena/olpcrd.img > > Just copy this over /versions/boot/current/boot olpcrd.img and it should work > (note that I haven't actually tested this). > > I'm not sure how to permanently fix this as I'm not sure where in the build > the modules get pulled in... > > ~Deepak > I did *not* copy it to /versions/boot/current/boot, since it never completed the boot from the USB stick. I copied your modified ramdisk to /boot on the USB disk, renamed it to olpcrd-2.6.25-deepak-fix.img and changed the olpcrd.img sym link to point to it. The USB boot still does not succed, but we are a bit further. Now it is complaining about a missing libusual.ko: WARNING: Could not open '/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/libusual.ko': No such file or directory I get fewer warnings about missing symbols in usb-storage (now only four): storage_usb_ids, usb_usual_clear_presetn, usb_usual_check_type and usb_usual_set_present. But the end result is still the same: cannot mount /dev/sda1 on /sysroot. Could you make (yet) an other fixed ram disk which I can try? Other question, should this be entered in trac, and is it blocking for 8.2.0 ? Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: > [some interesting points] Sorry my meta-comments snuck in - they aren't relevant, and I didn't follow my own advice...I retract them (I'm sure you can tell what parts they were). > => Do any frequent contributors have ONLY an XO? <= As I've been fiddling around with a patch or two, my jhbuild has been broken due to x86_64 Xephyr F9 brokenness that's been recently fixed (thanks dodji, if you're listening, and cjb/marco for pushing), so please count me among those contributors who only have an XO (temporarily). > But the tools needed to be a contributing part of the Sugar community > don't run on the XO. [...] > Merely installing the change without trashing his XO's entire GUI > with a typo or missing Python file is tricky. After restarting X/Sugar so often to test patches for #6995, I've developed an itch for a Sugar-shell-REPL in Pippy, or something similar. Perhaps that's one way for people in the field to tinker. Of course there are diff/code browsing issues still. > John Martin pgp6DOwu7OZVK.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
> instead of just turtle programs and gooey smalltalk... Cannot let this one slip by uncommented on. Etoys is one place where kids are doing real programming, as a means of achieving fluency about many powerful ideas, not just syntax. But I unaware that children have made contributions to Squeak yet. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
I don't think anyone would argue that we need better tools for software development on the XO. There has been a latent Develop activity in the works that occasionally gets a boost from the community (want to jump in?). I would argue that a bigger stumbling block than problems with Sugar and "interpreted languages" is a lack of good affordances. In particular, the screen is small, so you have to keep a lot around in your head. (As Alan pointed out in a recent post, this may not be as great a liability as I believe--Knuth's "desk checking" didn't hold him back, but he is somewhat special in the world of programming). One idea that has also been kicking around for a while is to take advantage of the fact that most deployments involve multiple laptops, so once could spread the debugging task out across multiple windows on multiple machines. (Perhaps the Sugar collaboration model (and X-Windows) will come to the rescue of the Sugar development problem.) The good news is that there has been a great deal of innovation with the XOs already. The children at Galadima made their won spelling dictionary for Igbo; the children in Thailand came up with some innovative uses of TamTam for orchestral performances that also incorporate indigenous instruments; there have been many innovative uses of the sharing feature in write to encourage peer editing of documents. None of these innovations involve hacking code -- yet -- but they are all part of a cultural shift in school that is synergistic with the ideals of appropriation of not just software, but of ideas. Not a bad start. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: > > > 2) Sugar would run more smoothly on-XO if jhbuild were retired. > > I think this is a good point in the abstract. Do any frequent contributors > > *not* have an XO? > > I approve of retiring jhbuild, and handing out XO's to Sugar > contributors, but you've really got the question backwards: > > => Do any frequent contributors have ONLY an XO? <= Yes, I've taken it on a tangent, as I promised in my boilerplate. Thanks for getting back to the topic. Is the question really best phrased as you did? Are you really asking "should the contributor community only use XOs"? It seems you're asking "how can we turn our XO deployment kids into contributors", which is a great question. I think the way forward is to raise some awareness (as you're doing) and constructively move the discussion forward. > I've seen lots of high flying rhetoric about Sugar being maintainable > and extensible by kids with their XO's, because it's in an easy > interpreted language shipped in source, etc. You have almost 500,000 > units in the field (admittedly in younger kids). Seen any Python > prodigies contributing yet? The sound-bite rhetorical question distracts from your later good points. Especially given the point is educating kids, I'm not so concerned that kids learning english and maths haven't sent sugar patches in yet :). > But the tools needed to be a contributing part of the Sugar community > don't run on the XO. [...] > Merely installing the change without trashing his XO's entire GUI > with a typo or missing Python file is tricky. Indeed! How can we as the community improve the extensibility while letting the core people get on with developing the core (and yes, I know the core has to be extensible, and I think it's good to keep raising the point; but we also need to *do* something about it - any ideas? I would be very interested in working on some, and coming up with some when I'm finished my one or two patches I'm working on now). > If we want the kids who *love* their machines to come to *know* and > *evolve* their machines, there's a lot more work to be done. Indeed. I quote this not for the mindless "me too gnu++ kthx" but to highlight it more - I think it gets lost a bit in your detailed points. > In many ways the unique XO UI and collab setup make the learning > curve steeper, not easier. I don't know this to be true, and I suspect it to be a distracting falsehood. But let's try to address the more fundamental issues (like no diff / diff-like utility / tools) you raised earlier. > John > Sugar is hung up in its own maintenance > machinery. I don't think you (only) mean Sugar here. Very interesting comments, btw. Thanks. Martin pgpjJBMMDtQIN.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: QUERY REGARDING INTERFACING OF TOOLBAR
Thanks for the quick response..The xocom is at
http://github.com/lukec/xocom/tree/master
I will definitely go through the codes you have sent. After studying that, I
will try to get back to SocialCalc again..
Regards
Preeti
On 7/24/08, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> where is the xocom source repository?
>
> I know nothing about xocom, but I recommend you to code a simple
> python-only activity first to familiarize with that part of the
> problem, and only then coming back to the SocialCalc Activity. Take a
> look to this activity:
>
> http://dev.laptop.org/~marco/Edit-1.xo
>
> http://dev.laptop.org/git?p=users/marco/edit-activity;a=blob;f=editactivity.py;h=bb2e98e27f236e716fb47faad952ac35fb827ab9;hb=HEAD
>
> Good luck,
>
> Tomeu
>
> 2008/7/24 Preeti KS <[EMAIL PROTECTED]>:
> > Dear all,
> >
> > I have been working on the toolbar of the SocialCalc Activity. In
> this
> > activity, a Spreadsheet was being made. The main programme has been
> written
> > in Javascript. whereas the function call has been made from Python.
> Hence, a
> > package called xocom was made to felicitate communication between JS and
> > Python.
> >I made the toolbar in Python, and used xocom to create the
> webview,etc. I
> > also managed to interface the toolbar.py file with the socialcalc.py
> file,
> > however, as I am not very adept with JS, I am facing problems interfacing
> > the toolbar.py file with the Javascript file. I have attached the
> relevent
> > files with this email and also at
> > http://wiki.laptop.org/go/Image:SocialCalc-toolbar.zip .
> > My toolbar.py file is as follows, these are some code snippets:
> >
> > This is the main spreadsheet activity toolbar, It has used xocom to
> create
> > the webview..
> >
> > class SpreadSheetActivityToolbar:
> >
> > def __init__(self, activity, toolbox, self_canvas):
> >
> > self._activity = activity
> > self.set_canvas( xocom.create_webview() )
> > self._activity_toolbar = toolbox.get_activity_toolbar()
> > self._keep_palette = self._activity_toolbar.keep.get_palette()
> >
> > .
> >
> > Then, I have created another class, for the edit toolbar. Its definition
> is
> > as follows:
> >
> > class SpreadsheetEditToolbar(EditToolbar):
> >
> > def __init__(self, toolbox, self_canvas):
> >
> > EditToolbar.__init__(self)
> > self.set_canvas( xocom.create_webview() )
> > .
> >
> > This is followed by the general definition of edit toolbar,
> > copy,paste,undo,redo, etc. There is also a viewtoolbar class, for viewing
> it
> > on hulahoop.
> >
> > Here are the details of the SocialCalc.py file:
> > To interface it with toolbar.py, I have imported the classes from this
> file
> > as:
> >
> > import toolbar
> > from toolbar import SpreadSheetActivityToolbar, SpreadsheetEditToolbar,
> > ViewToolbar
> >
> > Then, while creating the toolbar, I have called these functions as:
> >
> > toolbox = activity.ActivityToolbox(self)
> > self.set_toolbox(toolbox)
> > toolbox.show()
> >
> > Separately calling edit toolbar:
> >
> > self._edit_toolbar = SpreadsheetEditToolbar(self,
> self._edit_toolbar,
> > set_canvas)
> > toolbox.add_toolbar(_('Edit'),self._edit_toolbar)
> > self._edit_toolbar.show()
> >
> > And similarly calling the Viewtoolbar class:
> >
> > view_toolbar = ViewToolbar (self.set_canvas)
> > self.set_canvas.show()
> >
> > Now, my problem is that, the xocom class connects the socialcalc.py file
> > with the Javascript file, socialcalc.js and xocom.js. I am unable to make
> > out, whether I have to make changes in the JS file, and what changes to
> > make.
> >
> > I would be obliged if someone who has been designing toolbars, can help
> me
> > out with this interfacing problem.
> >
> > Thanks and regards
> > KS Preeti,
> > Team Member,
> > SocialCalc Team
> >
> >
> >
> >
> > ___
> > 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: SMS messaging
Le jeudi 24 juillet 2008 à 03:36 -0400, Ankur Verma a écrit : > > As per our earlier discussion, the method at present is to use > roster.py, which you are planning to remove in the next versions. Humm not really. Using the roster is and will always be a sane way to find contacts. But, as you can guess, it assumes that the contact is in your roster. Currently this is a sane assumption because of the shared roster hack. But when we'll drop it, that won't be true anymore. > As roster.py also uses Telepathy to get the nicks of XO who have > subscribed or are friends, are there any alternative functions which I > can use to fetch the list of XOs? I am ready to look more into > telepathy specs, but I am curious to know the answer. The plan with Gadget is to allow user to request random buddies (and activities) or perform search based on different criteria. As you can see on [1], currently only search based on buddy properties is implemented but we plan to add alias search soon (maybe next week if you really need it). So for now, I suggest you to use a server with the shared roster hack or manually subscribe your SMS user with a test buddy for your tests. So you could test most of the part of your app and just change it to use alias search later. G. [1] http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: QUERY REGARDING INTERFACING OF TOOLBAR
Hi,
where is the xocom source repository?
I know nothing about xocom, but I recommend you to code a simple
python-only activity first to familiarize with that part of the
problem, and only then coming back to the SocialCalc Activity. Take a
look to this activity:
http://dev.laptop.org/~marco/Edit-1.xo
http://dev.laptop.org/git?p=users/marco/edit-activity;a=blob;f=editactivity.py;h=bb2e98e27f236e716fb47faad952ac35fb827ab9;hb=HEAD
Good luck,
Tomeu
2008/7/24 Preeti KS <[EMAIL PROTECTED]>:
> Dear all,
>
> I have been working on the toolbar of the SocialCalc Activity. In this
> activity, a Spreadsheet was being made. The main programme has been written
> in Javascript. whereas the function call has been made from Python. Hence, a
> package called xocom was made to felicitate communication between JS and
> Python.
>I made the toolbar in Python, and used xocom to create the webview,etc. I
> also managed to interface the toolbar.py file with the socialcalc.py file,
> however, as I am not very adept with JS, I am facing problems interfacing
> the toolbar.py file with the Javascript file. I have attached the relevent
> files with this email and also at
> http://wiki.laptop.org/go/Image:SocialCalc-toolbar.zip .
> My toolbar.py file is as follows, these are some code snippets:
>
> This is the main spreadsheet activity toolbar, It has used xocom to create
> the webview..
>
> class SpreadSheetActivityToolbar:
>
> def __init__(self, activity, toolbox, self_canvas):
>
> self._activity = activity
> self.set_canvas( xocom.create_webview() )
> self._activity_toolbar = toolbox.get_activity_toolbar()
> self._keep_palette = self._activity_toolbar.keep.get_palette()
>
> .
>
> Then, I have created another class, for the edit toolbar. Its definition is
> as follows:
>
> class SpreadsheetEditToolbar(EditToolbar):
>
> def __init__(self, toolbox, self_canvas):
>
> EditToolbar.__init__(self)
> self.set_canvas( xocom.create_webview() )
> .
>
> This is followed by the general definition of edit toolbar,
> copy,paste,undo,redo, etc. There is also a viewtoolbar class, for viewing it
> on hulahoop.
>
> Here are the details of the SocialCalc.py file:
> To interface it with toolbar.py, I have imported the classes from this file
> as:
>
> import toolbar
> from toolbar import SpreadSheetActivityToolbar, SpreadsheetEditToolbar,
> ViewToolbar
>
> Then, while creating the toolbar, I have called these functions as:
>
> toolbox = activity.ActivityToolbox(self)
> self.set_toolbox(toolbox)
> toolbox.show()
>
> Separately calling edit toolbar:
>
> self._edit_toolbar = SpreadsheetEditToolbar(self, self._edit_toolbar,
> set_canvas)
> toolbox.add_toolbar(_('Edit'),self._edit_toolbar)
> self._edit_toolbar.show()
>
> And similarly calling the Viewtoolbar class:
>
> view_toolbar = ViewToolbar (self.set_canvas)
> self.set_canvas.show()
>
> Now, my problem is that, the xocom class connects the socialcalc.py file
> with the Javascript file, socialcalc.js and xocom.js. I am unable to make
> out, whether I have to make changes in the JS file, and what changes to
> make.
>
> I would be obliged if someone who has been designing toolbars, can help me
> out with this interfacing problem.
>
> Thanks and regards
> KS Preeti,
> Team Member,
> SocialCalc Team
>
>
>
>
> ___
> 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: SMS messaging
As per our earlier discussion, the method at present is to use roster.py, which you are planning to remove in the next versions. As roster.py also uses Telepathy to get the nicks of XO who have subscribed or are friends, are there any alternative functions which I can use to fetch the list of XOs? I am ready to look more into telepathy specs, but I am curious to know the answer. Thank you. Best, Ankur Verma On Thu, Jul 24, 2008 at 2:51 AM, Guillaume Desmottes < [EMAIL PROTECTED]> wrote: > Le mercredi 23 juillet 2008 à 12:38 -0400, Ankur Verma a écrit : > > > > I can run a bash/python script upon the reception of the message with > > the message parameters. This makes it flexible enough to call any > > application. > > > > Then I think you should write a Python application which connect to the > jabber server, find the buddy and send him the message. > > As a start I suggest you to take a look on the Telepathy spec [1] and > telepathy-python examples. > > >G. > > > [1] http://telepathy.freedesktop.org/spec.html > > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
