Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Thu, Jul 31, 2008 at 4:14 AM, Bastien [EMAIL PROTECTED] wrote: John Gilmore [EMAIL PROTECTED] writes: you can't just share a file, you have to share an activity, ... Right. Idea for a new activity: Candy Bag. You open a bag (i.e. you launch the CandyBag activity), then you put journal entries in it, then sharing this activity means that your friends can grab a candy in your bag. I thought Benjamin Schwartz had already done something similar? Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
Any follow-up on the idea of having a precise list of maintainers for all Sugar activities? Even just the email address from the git repo would be nice. Thanks! Simon Schampijer [EMAIL PROTECTED] writes: What I find interesting is that as well areas where contributions are quite easy to do (Activities) have really stagnated. At the moment we lack maintainers for most of them. Browse, Pippy, Chat, Terminal and Etoys are well covered because they are maintained by core people. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
Any follow-up on the idea of having a precise list of maintainers for all Sugar activities? Even just the email address from the git repo would be nice. Thanks! Simon Schampijer [EMAIL PROTECTED] writes: What I find interesting is that as well areas where contributions are quite easy to do (Activities) have really stagnated. At the moment we lack maintainers for most of them. Browse, Pippy, Chat, Terminal and Etoys are well covered because they are maintained by core people. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
Great idea... Robson had a similar one. SJ On Wed, Jul 30, 2008 at 11:14 PM, Bastien [EMAIL PROTECTED]wrote: John Gilmore [EMAIL PROTECTED] writes: you can't just share a file, you have to share an activity, ... Right. Idea for a new activity: Candy Bag. You open a bag (i.e. you launch the CandyBag activity), then you put journal entries in it, then sharing this activity means that your friends can grab a candy in your bag. 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. Let's not lose the focus of making the *teachers* love the machines. And let's don't see children as small hackus homunculus! :) -- Bastien ___ 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: [sugar] Remarks on the Work of Sugar
Any follow-up on the idea of having a precise list of maintainers for all Sugar activities? Even just the email address from the git repo would be nice. Thanks! Simon Schampijer [EMAIL PROTECTED] writes: What I find interesting is that as well areas where contributions are quite easy to do (Activities) have really stagnated. At the moment we lack maintainers for most of them. Browse, Pippy, Chat, Terminal and Etoys are well covered because they are maintained by core people. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
John Gilmore [EMAIL PROTECTED] writes: you can't just share a file, you have to share an activity, ... Right. Idea for a new activity: Candy Bag. You open a bag (i.e. you launch the CandyBag activity), then you put journal entries in it, then sharing this activity means that your friends can grab a candy in your bag. 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. Let's not lose the focus of making the *teachers* love the machines. And let's don't see children as small hackus homunculus! :) -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
+1 There are some activities clustered together here from the list of git projects: http://dev.laptop.org/~sj/git-list.txt SJ On Wed, Jul 30, 2008 at 10:42 PM, Bastien [EMAIL PROTECTED]wrote: Any follow-up on the idea of having a precise list of maintainers for all Sugar activities? Even just the email address from the git repo would be nice. Thanks! Simon Schampijer [EMAIL PROTECTED] writes: What I find interesting is that as well areas where contributions are quite easy to do (Activities) have really stagnated. At the moment we lack maintainers for most of them. Browse, Pippy, Chat, Terminal and Etoys are well covered because they are maintained by core people. -- Bastien ___ 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: [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: [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)
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)
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
Michael Stone wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. Evidence: Trac and xmonad both have thriving communities of contributors based around their plugin architectures and community sites like trac-hacks.org. Evidence: Sugar has already attracted new contributors by creating three different extension points: Activities themselves Device entries on the Frame Control Panel Entries Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. What I find interesting is that as well areas where contributions are quite easy to do (Activities) have really stagnated. At the moment we lack maintainers for most of them. Browse, Pippy, Chat, Terminal and Etoys are well covered because they are maintained by core people. Write, Read, TamTam, Paint, Record, Memorize to name a few have been really struggling lately. There are probably various reasons for that - one might be I that the activities have been taken out from the base system another one that the overall development has been really fast and no entry points/good documentation could be found. And well, the windows news were not helpful either. Would be interesting to know what the activity maintainers struggled most to make it easier in the future. For sugar core - I don't think that 'small fixes' need more than python skills. And we would be more than happy to have them. We will try in the next sugar dev meeting s to give out a few bugs that we think are easy to work on where people could help - stay tuned. Best, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 9:36 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Michael Stone wrote: After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. One hint from Robert about how the project is seen by FOSS people: Jul 19 15:43:38 tomeu Robot101: thanks for remembering the gnome mobile people that we are still alive Jul 19 15:43:57 tomeu would have been great to be at guadec :/ Jul 19 15:44:47 Robot101 yeah they were somehow talking about OLPC as dead and failed, I had to give them some re-schooling Would you spend much time on a dead and failed project? Note that the GNOME Mobile people are not supposed to be the kind of people that know about OLPC only from NBC News. About the rest, Michael's post makes me think he believes that we are very proud of our work. Just for the record, I think my work at OLPC is crap and I would have refused to deliver so poor quality in any commercial project (in case any future employer is reading this.) I have kept going on with this craziness because I expected that at some point the promises of more resources would be fulfilled. If our only plan is to blame the Sugar developers for not being able to attract more developers for free... It may not be worth the effort. Best regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 6:56 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: On the other hand, circumventing the layers altogether has not been an option either as it would brake backwards compatibility with existing activities (Sugar is a two-year old experimental project and already has legacy?). The fact that this prototype is already heavily deployed puts us in a very difficult situation in this respect. We will have to figure out ways to break compatibility but it's going to hurt :/ Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: Michael Stone wrote: [...] Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. [...] For sugar core - I don't think that 'small fixes' need more than python skills. I agree. Of course people also need the knowledge about where to put those python skills to work. That's non-trivial in Sugar, but - apart from m_stone's layering comment - I don't think the UI-code makes this more of a problem than it just is, inherently. Best, Simon Martin pgpXwARkLzrfC.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
Martin Dengler wrote: On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: Michael Stone wrote: [...] Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. [...] For sugar core - I don't think that 'small fixes' need more than python skills. I agree. Of course people also need the knowledge about where to put those python skills to work. That's non-trivial in Sugar, but - apart from m_stone's layering comment - I don't think the UI-code makes this more of a problem than it just is, inherently. Best, Simon Martin Sure, some guidance is needed. I hope we have done a decent job to guide you to the places to provide your great fixes :) for example: http://dev.laptop.org/git?p=sugar;a=commit;h=40306308325448fe85c2a78ad243aa179fd1b37f http://dev.laptop.org/git?p=sugar;a=commit;h=8127e2680e101b36218b4576733a4d69537e5915 Thanks! Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
On Wed, 2008-07-23 at 09:36 +0200, Simon Schampijer wrote: Write, Read, TamTam, Paint, Record, Memorize to name a few have been really struggling lately. There are probably various reasons for that - one might be I that the activities have been taken out from the base system another one that the overall development has been really fast and no entry points/good documentation could be found. And well, the windows news were not helpful either. You are missing 'funding': Most of Write's development was funded by OLPC, which gave us what we have today. Expecting volunteers to hack on Write is unrealistic at this point. Let me clarify: Write is written in Python and uses the pyabiword bindings around AbiWord's GTK canvas widget extensively. The GTK widget and pyabiword bindings were extended as I went along, to expose the functionality Write needed. Currently almost 100% of pyabiword's functionality is used by Write. What this means is that if Write needs new feature X, it will almost always require new functionality to be exposed through pyabiword *and* AbiWord's GTK canvas widget. This will generally be too hard for volunteers who just want to spend a few hours hacking on something fun. Cheers, Marc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: External contributions (Re: [sugar] Remarks on the Work of Sugar)
On Wed, Jul 23, 2008 at 12:03:42PM +0200, Marco Pesenti Gritti wrote: On Wed, Jul 23, 2008 at 11:33 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Sure, some guidance is needed. [...] Tomeu, Simon and Eben has been much more proactive and, what matters most, more *succesfull* than anyone else in helping out the community to participate. They deserve credit and instead they are getting blame. Absolutely - I have lurked on IRC a lot and they are doing a great job when people come in. They do indeed deserve credit. Guys, keep it up. Getting flames *and* praise is almost a guarantee that what you are doing is worth something. This is an true and often overlooked point. Marco Martin pgpPOFVZP90pL.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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | 5) Sugar is built on technologies that incentivize its developers to | recompute prior results which could be cached across boots. Sugar was intended to write to disk absolutely as little as possible, and also to reboot as infrequently as possible. I will attempt to find references to these intentions from years ago. Regarding the majority of your points, I would say: Sugar has been, and continues to be, in a constant rush just to implement the desired functionality, regardless of efficiency. The question has long been how can we code this as fast as possible, not what is the ideal way to implement this. I think that is a good thing. I think we will need retain this mindset through 9.1, in order to finally deliver a Sugar that has the features required for usability. I hope that Sugar developers can spend 2009 focusing on efficiency, laziness/memoization/eagerness, and delayering. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiGe9wACgkQUJT6e6HFtqRQlgCcD5u0UXpqr+tR5Yf7aeSFd6yy QHQAoJ72ZXy7+PCVF66av7BsMahd+VNz =IsWm -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 12:19 PM, Michael Stone [EMAIL PROTECTED] wrote: I regard fully pythonic python data as a subgraph of a reference-counted object graph. So far as I know, Python has lots of interesting ways to parse bytestreams into object graphs, but no great way to read an object graph directly into memory without the overhead of parsing or to save an subgraph of its object graph directly to a bytestream. This makes it hard to use pythonic data via shared-memory or to pull it quickly off of a filesystem. None of the dynamic languages I am used to can do this - Perl, Python, PHP, Ruby - even with locks or read-only shmem arrangements. Whenever I've used a shmem arrangement in any of them, it involved marshalling/unmarshalling, which of course is a huge perf drag. Which makes me suspect that there's something else that is tricky there -- things in that shmem space do have references to the private mem of the originating process (pointers to the class code perhaps). I understand the PHP and Perl (circa P5.0005) internal memory handling. YMMV. In other words, it's in the way-too-hard-and-brittle basket, barring an execution-engine redesign, that might incorporate some changes. OTOH, ISTR reading that Erlang's odd all-variables-are-constants scheme makes this easier. 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: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 2:46 AM, Michael Stone [EMAIL PROTECTED] wrote: I disagree because I think that the approach we have taken has made it much harder for others to help us. For a project like Sugar, this ultimately results is less software of less quality in the same timeframe. At least, that's what I take away from the Trac and xmonad examples. (When you examine your own notoriously easy-to-contribute-to projects, do your conclusions match mine?) That's a tradeoff and a very difficult one. In retrospect I tend to think we invested too little on enabling contributions. But you should consider a few of things: * Sugar is very much of an experimental project at the UI level. It's making big progresses on that front but even now it's far from solid. To be able to iterate on UI design you need quick prototyping. And to be fair, in so many respects, Sugar is still a prototype and will be for a long time. * Deployments are putting a huge pressure on us. We can't just delay features to do them right, often we are just forced to hack them up at the best we can. * The disproportion between the project expectations and the bootstrap investment is simply ridiculous. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
