Re: [sugar] Log Viewer - View Log? (Was: [PATCH] Log Viewer overhaul)
On Tue, May 13, 2008 at 9:31 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 5:46 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: Forking the thread here, but I wonder if this activity could be renamed to something more closely following the verb standard, like View log(s)? Nitpick perhaps, but goes along my opinion that our dictionaries don't have enough verbs to exactly identify all activities that will appear, so adding a noun when necessary would improve things. How about Inspect or Diagnose? We have Analyze already, which is a separate activity. View Logs sounds good to me. Eben? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Log Viewer overhaul.
On Tue, May 13, 2008 at 4:04 AM, Wade Brainerd [EMAIL PROTECTED] wrote: I'm happy to co-maintain. Eduardo, were you planning to integrate more stuff from Memphis into Log Viewer? I don't want to interfere with that work of course. I don't think so. Most of the memphis stuff should be in Analyze rather than in the log viewer. Off topic- 'Log Viewer Activity' does not fit in the activity toolbar's title entry. I have seen this problem with other activities as well. Can we consider expanding the default size of this entry, or else dropping the word 'Activity' from the default titles? Eben, can/should we drop Activity from the toolbar? Double word activity will be pretty common I think, since a verb is often not enough to describe it properly. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity Proposal: Chat
Following the procedure at http://wiki.sugarlabs.org/go/Release, here's the proposal for Chat: * Short description of the features: The Chat activity will provide a simple interface for collaborative discussion, be it between two individuals or among a group as large as an entire classroom. * Screenshots or screencasts: Mockups on http://wiki.laptop.org/go/Chat * Are you willing to follow the Schedule? Yes * System components the activity depends on: sugar, hippo canvas, presence service * Members of the developer team: Maintainer: Morgan Collett Assistance from Collabora developers * Status of internationalization: In pootle * Code repository: git://dev.laptop.org/chat-activity * Bug tracking system: chat-activity in dev.laptop.org Trac Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity Proposal: Chat
http://wiki.sugarlabs.org/go/Modules#chat-activity Feel free to edit if I got anything wrong. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity Proposal: Chat
+1 by me. Relevant, unique, well maintained. Marco On Tue, May 13, 2008 at 11:12 AM, Morgan Collett [EMAIL PROTECTED] wrote: Following the procedure at http://wiki.sugarlabs.org/go/Release, here's the proposal for Chat: * Short description of the features: The Chat activity will provide a simple interface for collaborative discussion, be it between two individuals or among a group as large as an entire classroom. * Screenshots or screencasts: Mockups on http://wiki.laptop.org/go/Chat * Are you willing to follow the Schedule? Yes * System components the activity depends on: sugar, hippo canvas, presence service * Members of the developer team: Maintainer: Morgan Collett Assistance from Collabora developers * Status of internationalization: In pootle * Code repository: git://dev.laptop.org/chat-activity * Bug tracking system: chat-activity in dev.laptop.org Trac Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
Benjamin M. Schwartz wrote: I think shared Terminal would be very cool. A lot of other people seem to think so too. It would be a fun way to learn command-line stuff, by sharing a prompt with a remote friend. That would be very cool. I wrote some note on using screen for this, which details some of the permissions bits you have to set up: http://www.pixelbeat.org/docs/screen/ cheers, Pádraig. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
Le lundi 12 mai 2008 à 13:25 -0400, Benjamin M. Schwartz a écrit : I think shared Terminal would be very cool. A lot of other people seem to think so too. It would be a fun way to learn command-line stuff, by sharing a prompt with a remote friend. Definitely. Shared terminal could be a killer feature. I'd like to see something similar in GNOME using gnome-terminal and Empathy. Most of the work could probably be reused. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Revised schedule
http://wiki.sugarlabs.org/go/Roadmap#Schedule Changes: * Push off everything one week to make room to complete the features proposal before the first development release. * Make sure we don't have release and tarballs due in the weekend. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
In general, it'd be great to be able to share like this for most activities. Another way of thinking about sharing would be to share resources of multiple laptops to get a bigger workspace, e.g., some times it is useful to have multiple xterms open. This would seemingly be simple to do in the context of the X Window System if we wrap the appropriate Sugar/Collaboration model around it. I can think of lots of activities that are someone space constrained at times--having the option of a larger or multiple screens--putting the debugging output on a separate laptop, for example. Future feature wish list. -walter On Tue, May 13, 2008 at 7:57 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le lundi 12 mai 2008 à 13:25 -0400, Benjamin M. Schwartz a écrit : I think shared Terminal would be very cool. A lot of other people seem to think so too. It would be a fun way to learn command-line stuff, by sharing a prompt with a remote friend. Definitely. Shared terminal could be a killer feature. I'd like to see something similar in GNOME using gnome-terminal and Empathy. Most of the work could probably be reused. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Log Viewer - View Log? (Was: [PATCH] Log Viewer overhaul)
marco pesenti gritti wrote: On Tue, May 13, 2008 at 9:31 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 5:46 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: Forking the thread here, but I wonder if this activity could be renamed to something more closely following the verb standard, like View log(s)? Nitpick perhaps, but goes along my opinion that our dictionaries don't have enough verbs to exactly identify all activities that will appear, so adding a noun when necessary would improve things. How about Inspect or Diagnose? We have Analyze already, which is a separate activity. View Logs sounds good to me. Eben? since you bring it up, in my opinion Analyze suffers from incomplete naming as well. analyze what? though i know i've learned it twice before, to be honest i can't at the moment remember what it does -- all i can think of is that it's going to let me do some kind of science experiment. but it's something to do with system statistics or resources right? seems to me that names either have to be quite unrelated to preconceptions of their meaning (TamTam, Pippy), or fairly descriptive (Read, Browse, Calculate). and as eduardo points out, there aren't enough verbs to use verbs alone for descriptive names. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 52.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Log Viewer - View Log? (Was: [PATCH] Log Viewer overhaul)
Hi Guys, I've missed this thread... , if some contributor wants to improve VIEW LOG(S) please feel free to do it, there's so many missed features that can be done... ATM I'm re-coding memphis in order to use new metrics found in the latest kernels, if you want I can retake Analize Activity and improve it a little bit... cheers. Eduardo. On Tue, May 13, 2008 at 8:42 AM, Paul Fox [EMAIL PROTECTED] wrote: marco pesenti gritti wrote: On Tue, May 13, 2008 at 9:31 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 5:46 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: Forking the thread here, but I wonder if this activity could be renamed to something more closely following the verb standard, like View log(s)? Nitpick perhaps, but goes along my opinion that our dictionaries don't have enough verbs to exactly identify all activities that will appear, so adding a noun when necessary would improve things. How about Inspect or Diagnose? We have Analyze already, which is a separate activity. View Logs sounds good to me. Eben? since you bring it up, in my opinion Analyze suffers from incomplete naming as well. analyze what? though i know i've learned it twice before, to be honest i can't at the moment remember what it does -- all i can think of is that it's going to let me do some kind of science experiment. but it's something to do with system statistics or resources right? seems to me that names either have to be quite unrelated to preconceptions of their meaning (TamTam, Pippy), or fairly descriptive (Read, Browse, Calculate). and as eduardo points out, there aren't enough verbs to use verbs alone for descriptive names. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 52.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity Proposal: Browse
Following the procedure at http://wiki.sugarlabs.org/go/Release, here's the proposal for Browse: * Short description of the features: Xulrunner: Update to xulrunner beta5 Bookmarks: We have only session bookmarks at the moment. We want to extend this, to provide the ability for global bookmarks and caching of the sites for offile viewing (http://dev.laptop.org/ticket/3889) Search: http://dev.laptop.org/ticket/7002 Stabilization: #6825 (email webfrontend), #6826 (uploading images on blogger.com)... I left 'UI to handle exceptions to invalid certificates in the browser.' out for the moment, since we need to discuss the necessity for update.2 first. * Screenshots or screencasts: No mockups of the features yet. * Are you willing to follow the Schedule? Yes I am. * System components the activity depends on: sugar, hulahop, xulrunner * Members of the developer team: Maintainer: Simon Schampijer Peer: Marco, Tomeu * Status of internationalization: In pootle * Code repository: git://dev.laptop.org/web-activity * Bug tracking system: browse-activity in dev.laptop.org Trac Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Log Viewer - View Log? (Was: [PATCH] Log Viewer overhaul)
On Tue, May 13, 2008 at 3:05 PM, Eduardo Silva [EMAIL PROTECTED] wrote: Hi Guys, I've missed this thread... , if some contributor wants to improve VIEW LOG(S) please feel free to do it, there's so many missed features that can be done... ATM I'm re-coding memphis in order to use new metrics found in the latest kernels, if you want I can retake Analize Activity and improve it a little bit... Thanks Eduardo. Wade, so I think it's OK to go ahead and get your patch in. Also if you want to propose log-activity for 0.82 that would be great. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
On May 12, 2008, at 3:31 PM, Ricardo Carrano wrote: How does the collision model/scheme change between AP mode and ad-hoc/mesh modes? As far as I can tell, it doesn't. 802.11s is interoperable with 802.11abg, which means that the same media access algorithms are used. At least part of our problem might be in the synchronized transmits occurring in our present 802.11s implementation of broadcast, which are probably killing whatever CA scheme 802.11abg dictate. See: http://wiki.laptop.org/go/ Path_Discovery_Mechanism:Sanity#Question_.232_- _Does_PDM_traffic_self-interfere.3F which is trying to deal with low-level path discovery requests, which also use the broadcast mechanism. --scott Yes, it is the same 802.11 DCF for both scenarios (infra and mesh). I would like to add to this discussion that sparse and dense mesh are too completely different animals. Most of the problems that we are trying to address now, are associated to the latter. Certainly an interesting question. But is your answer really true ? I'd argue that very little, if any, testing has been done of the large, yet sparse mesh. Certainly none by OLPC. Our problems certainly come from large meshes (more than 10-15 laptops in the mesh). What is your definition of sparse ? The more we dig into this, the more clear it gets that we need to adapt. Everything we do to increase coverage in a sparse mesh hurt us in a dense cloud. One example: broadcasting or multicasting at 1 or 2Mbps. Likewise, what we do to increase reliability, might actually decrease it. One example: the verbosity or redundancy of some of our protocols. And that's one of the strengths of Cerebro (less is more). So, as a side note: Treating the two animals as different will avoid some bites and scratches. ;-) One interesting note is that the suggested routing algorithm for 802.11s is a combination of reactive and proactive routing (unlike our current one, which is solely reactive). Perhaps that provides the adaptation necessary for the mesh to work ? wad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Push get_buddy from Connect into sugar.presence (#6473)
This subclasses TubeConnection to make a version (SugarTubeConnection)
that can resolve a handle to a Buddy.
Patches are for sugar(.presence) and Connect.
Morgan
From fe68fb70cff7753b4f158b7127a0bc5712235fc3 Mon Sep 17 00:00:00 2001
From: Morgan Collett [EMAIL PROTECTED]
Date: Tue, 13 May 2008 16:59:34 +0200
Subject: [PATCH] #6473: Better method for resolving handles to buddies
---
src/sugar/presence/Makefile.am |1 +
src/sugar/presence/sugartubeconn.py | 60 +++
2 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 src/sugar/presence/sugartubeconn.py
diff --git a/src/sugar/presence/Makefile.am b/src/sugar/presence/Makefile.am
index cb52a41..0c4368b 100644
--- a/src/sugar/presence/Makefile.am
+++ b/src/sugar/presence/Makefile.am
@@ -3,6 +3,7 @@ sugar_PYTHON = \
__init__.py \
activity.py \
buddy.py \
+ sugartubeconn.py \
tubeconn.py \
presenceservice.py
diff --git a/src/sugar/presence/sugartubeconn.py b/src/sugar/presence/sugartubeconn.py
new file mode 100644
index 000..ce4d559
--- /dev/null
+++ b/src/sugar/presence/sugartubeconn.py
@@ -0,0 +1,60 @@
+Subclass of TubeConnection that converts handles to Sugar Buddies
+# Copyright (C) 2008 One Laptop Per Child
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as published
+# by the Free Software Foundation; either version 2.1 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+
+from telepathy.constants import (
+CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES)
+
+from tubeconn import TubeConnection
+import presenceservice
+
+
+class SugarTubeConnection(TubeConnection):
+Subclass of TubeConnection that converts handles to Sugar Buddies
+
+def __new__(cls, conn, tubes_iface, tube_id, address=None,
+group_iface=None, mainloop=None):
+self = super(SugarTubeConnection, cls).__new__(
+cls, conn, tubes_iface, tube_id, address=address,
+group_iface=group_iface, mainloop=mainloop)
+self._conn = conn
+self._group_iface = group_iface
+return self
+
+def get_buddy(self, cs_handle):
+Retrieve a Buddy object given a telepathy handle.
+
+cs_handle: A channel-specific CONTACT type handle.
+returns: sugar.presence Buddy object or None
+
+pservice = presenceservice.get_instance()
+if self.self_handle == cs_handle:
+# It's me, just get my global handle
+handle = self._conn.GetSelfHandle()
+elif self._group_iface.GetGroupFlags() \
+CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES:
+# The group (channel) has channel specific handles
+handle = self._group_iface.GetHandleOwners([cs_handle])[0]
+else:
+# The group does not have channel specific handles
+handle = cs_handle
+
+# deal with failure to get the handle owner
+if handle == 0:
+return None
+return pservice.get_buddy_by_telepathy_handle(
+self._conn.service_name, self._conn.object_path, handle)
--
1.5.4.3
From abeae363528ce25c946a747e9c6b79ce1a108382 Mon Sep 17 00:00:00 2001
From: Morgan Collett [EMAIL PROTECTED]
Date: Tue, 13 May 2008 17:00:35 +0200
Subject: [PATCH] #6473: Better method for resolving handles to buddies
---
activity.py | 43 +++
game.py | 18 ++
2 files changed, 21 insertions(+), 40 deletions(-)
diff --git a/activity.py b/activity.py
index f4b7054..7663d68 100644
--- a/activity.py
+++ b/activity.py
@@ -25,7 +25,7 @@ import telepathy.client
from sugar.activity.activity import Activity, ActivityToolbox
from sugar.presence import presenceservice
-from sugar.presence.tubeconn import TubeConnection
+from sugar.presence.sugartubeconn import SugarTubeConnection
import sugar.logger
import gridwidget
@@ -88,8 +88,10 @@ class ConnectActivity(Activity):
# we are joining the activity
self.buddies_panel.add_watcher(owner)
self.connect('joined', self._joined_cb)
-self._shared_activity.connect('buddy-joined', self._buddy_joined_cb)
-self._shared_activity.connect('buddy-left', self._buddy_left_cb)
+self._shared_activity.connect('buddy-joined',
+ self._buddy_joined_cb)
+
[sugar] Activity proposal: Read
* Short description of the features: No new features currently scheduled for Update.2. * Screenshots or screencasts: Mockup: http://wiki.laptop.org/go/Image:Activity_read.jpg * Are you willing to follow the Schedule? Yup. * System components the activity depends on: sugar, evince-olpc, evince-python * Members of the developer team: Tomeu Reinier? Marco * Status of internationalization: In pootle * Code repository: git://dev.laptop.org/read-activity * Bug tracking system: read-activity in dev.laptop.org Trac Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
John Watlington wrote: One interesting note is that the suggested routing algorithm for 802.11s is a combination of reactive and proactive routing (unlike our current one, which is solely reactive). Perhaps that provides the adaptation necessary for the mesh to work ? If you refer to the hybrid routing protocol, it constructs a spanning tree of the whole mesh network rooted at some node. This is meant to be used in non-homogenous meshes (eg having an MPP or access point that acts as the root). So it may help in a school environment, but not in a simple mesh environment where all nodes are equal (if you attempt to build a different tree rooted at every node, you will probably face the wrath of a proactive protocol running on a mobile network - god save us from such a day ;-) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Mon, May 12, 2008 at 7:03 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 7:01 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 5:37 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: As any new module/activity will add some overhead to the release team, perhaps we should ask that any module included in the release process has to provide functionality that the community believes is important to the project goals? So maybe we should ask such a new point: * Provide functionality that the community judges as important for reaching the goals of the project. Yeah, I think we will need to define some relevance criteria. I wanted to let those emerge from the concrete activities discussions rather than defining them upfront... but your generic definition sounds pretty good, please add it to the wiki so that we keep this in mind. Btw I think a good way to start defining some of those criteria concretely might be a discussion on its.an.education.project list. Also Walter wrote some criteria to determine the core activities which we could reuse in this context. Will initiate such a thread. One thing I don't have completely clear is the meaning of an activity being part of the Sugar release. Which implications has? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
I think we need to decouple the release cycles between activities and Sugar to whatever degree possible. Activities should be able to change at whatever pace is dictated by the activity developers. Since activities depend upon Sugar, the Sugar schedule needs to be more predictable. The only time it seems there would be a conflict is when an incompatible change in a Sugar module is made, which, with the emerging process, is hopefully rare and well known in advance. Note that the above says nothing about what constitutes a core activity. But we do want to make sure we are not leaving activity developers in the dust as we make changes. Sugar without activities is not very interesting. -walter On Tue, May 13, 2008 at 12:05 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 7:03 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 7:01 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 5:37 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: As any new module/activity will add some overhead to the release team, perhaps we should ask that any module included in the release process has to provide functionality that the community believes is important to the project goals? So maybe we should ask such a new point: * Provide functionality that the community judges as important for reaching the goals of the project. Yeah, I think we will need to define some relevance criteria. I wanted to let those emerge from the concrete activities discussions rather than defining them upfront... but your generic definition sounds pretty good, please add it to the wiki so that we keep this in mind. Btw I think a good way to start defining some of those criteria concretely might be a discussion on its.an.education.project list. Also Walter wrote some criteria to determine the core activities which we could reuse in this context. Will initiate such a thread. One thing I don't have completely clear is the meaning of an activity being part of the Sugar release. Which implications has? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 6:24 PM, Walter Bender [EMAIL PROTECTED] wrote: I think we need to decouple the release cycles between activities and Sugar to whatever degree possible. Activities should be able to change at whatever pace is dictated by the activity developers. Since activities depend upon Sugar, the Sugar schedule needs to be more predictable. The only time it seems there would be a conflict is when an incompatible change in a Sugar module is made, which, with the emerging process, is hopefully rare and well known in advance. Note that the above says nothing about what constitutes a core activity. But we do want to make sure we are not leaving activity developers in the dust as we make changes. Sugar without activities is not very interesting. I agree that limiting the number of components released as a whole brings important benefits. I think that the idea of releasing some activities as part of Sugar is because they provide services that are considered a basic part of the user experience inside Sugar. I think this is the reason why GNOME releases applications along with desktop components? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
On Tue, May 13, 2008 at 11:59 AM, John Watlington [EMAIL PROTECTED] wrote: On May 12, 2008, at 3:31 PM, Ricardo Carrano wrote: How does the collision model/scheme change between AP mode and ad-hoc/mesh modes? As far as I can tell, it doesn't. 802.11s is interoperable with 802.11abg, which means that the same media access algorithms are used. At least part of our problem might be in the synchronized transmits occurring in our present 802.11s implementation of broadcast, which are probably killing whatever CA scheme 802.11abg dictate. See: http://wiki.laptop.org/go/ Path_Discovery_Mechanism:Sanity#Question_.232_-_Does_PDM_traffic_self-interfere.3F which is trying to deal with low-level path discovery requests, which also use the broadcast mechanism. --scott Yes, it is the same 802.11 DCF for both scenarios (infra and mesh). I would like to add to this discussion that sparse and dense mesh are too completely different animals. Most of the problems that we are trying to address now, are associated to the latter. Certainly an interesting question. But is your answer really true ? I'd argue that very little, if any, testing has been done of the large, yet sparse mesh. Certainly none by OLPC. Our problems certainly come from large meshes (more than 10-15 laptops in the mesh). What is your definition of sparse ? My definition, since I never found o good one in the literature. In a sparse mesh the number of active neighbors is smaller than your retry limit. So, in a sparse mesh your frame will never be discarded without being transmitted at least one time. In a dense mesh, there is a chance that a frame will reach the retry limit without being ever transmitted. So, 10 XOs in a room is a dense mesh (in that definition). I've done some tests in sparse topologies early in 2007. but I doubt they have any lasting values, after so many changes and fixes. Back there we were particularly interested in the hidden node problem and checked to see if RTS/CTS would help us (by the way it does not seem to help in multihop scenarios http://www.midiacom.uff.br/~schara/publications/SBrT2007.pdf) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 6:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 6:24 PM, Walter Bender [EMAIL PROTECTED] wrote: I think we need to decouple the release cycles between activities and Sugar to whatever degree possible. Activities should be able to change at whatever pace is dictated by the activity developers. Since activities depend upon Sugar, the Sugar schedule needs to be more predictable. The only time it seems there would be a conflict is when an incompatible change in a Sugar module is made, which, with the emerging process, is hopefully rare and well known in advance. Note that the above says nothing about what constitutes a core activity. But we do want to make sure we are not leaving activity developers in the dust as we make changes. Sugar without activities is not very interesting. I agree that limiting the number of components released as a whole brings important benefits. I think that the idea of releasing some activities as part of Sugar is because they provide services that are considered a basic part of the user experience inside Sugar. I think this is the reason why GNOME releases applications along with desktop components? Distributions will need ship a set of activities, as you say sugar without activities is not interesting. Having them on a coordinated schedule will make their life easier. I think we should aim at releasing a product that makes some sense from the user experience point of view. And Sugar without activities doesn't. Also many features in the Sugar core will be developed for certain activities. And many features can only be tested using activities. Having a few of them on the same schedule makes this a lot easier. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Log Viewer overhaul.
On Tue, May 13, 2008 at 4:14 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 4:04 AM, Wade Brainerd [EMAIL PROTECTED] wrote: I'm happy to co-maintain. Eduardo, were you planning to integrate more stuff from Memphis into Log Viewer? I don't want to interfere with that work of course. I don't think so. Most of the memphis stuff should be in Analyze rather than in the log viewer. Off topic- 'Log Viewer Activity' does not fit in the activity toolbar's title entry. I have seen this problem with other activities as well. Can we consider expanding the default size of this entry, or else dropping the word 'Activity' from the default titles? Eben, can/should we drop Activity from the toolbar? Double word activity will be pretty common I think, since a verb is often not enough to describe it properly. Three points. =) 1. There is currently no reason for the arbitrarily short entry field. We can (should) definitely expand it. 2. We really should *not* be appending activity to the title at all. In fact, that seems to be the wrong message. If anything, we would want to append something like instance instead. But, that aside, what I really want is .info support for suggested (and translated) default titles! I've brought this up before, and again recently in the ML. Perhaps homunq can add support for this and activity tags when he plays with the bundle spec? 3. We need to revisit the possibility of abandoning the activity toolbar itself, in favor of a non-modal (or modal?) title request alert and a host of features (keep, share, name, tag, etc) within the palette for the activity in the Frame instead. We could probably do this along with the new design if we decide it's the right thing to do. I think we need the alert even if we don't drop the toolbar. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 6:41 PM, Walter Bender [EMAIL PROTECTED] wrote: Ah. I was missing a subtly: do we agree that activities can be released on their own timeframe, but that some activities are released with the Sugar releases? For example, Write could be updated whenever the Abiword team feels it is appropriate, perhaps in sync with other Abiword releases, but a Sugar release would always include a working Write? Is this the Gnome model? In GNOME applications tend to sync up with GNOME at least until the stable release. Then usually distributions start to ship them and each projects does his own releases in response to critical bugs reported etc. It also happens that some applications skip a cycle and GNOME ship with the latest stable release. I think we should just be flexible in this respect: * In the normal case maintainers of activities included in the Sugar release process should be willing to follow the schedule, i.e. provide development and stable releases more or less in sync with the Sugar process. * If there is a need to skip a development cycle (for example because the developers are working on large features or refactoring of the code) it's fine to do so. * Activities are encouraged to release stable updates outside the Sugar dev cycle when there is need to do so. In some cases, there is more than one choice for a core activity: there are at least three credible Draw programs at the moment. Which one is folded into the Sugar release is an interesting question--somewhat different from the question of what are core activities. The Sugar community would bless one of these. And that's fine I think. Distributors are obviously free to disregard the blessing. Michael and Scott's Customization process takes care of some aspects of both of these questions, I think the customization process will work in specific distribution context. It's not the right solution for Sugar/Fedora or Sugar/Ubuntu, for example. but it doesn't address the question of whether or not Sugar would issue a release that was incompatible with *any* Draw activity. That's another reason the Sugar release should include activities imo. It will give good criteria to decide when API changes are ready to be released (yeah we should aim for API stability, but at some you always need to break). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 6:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: I agree that limiting the number of components released as a whole brings important benefits. Can we explicitly enumerate the benefits? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | I agree that limiting the number of components released as a whole | brings important benefits. I think that the idea of releasing some | activities as part of Sugar is because they provide services that | are considered a basic part of the user experience inside Sugar. Could you name an example of such an Activity? It seems to me that the presence of any such Activity represents a design bug in Sugar. In the case of Chat and Journal, these are known design bugs. Chat will eventually be rendered mostly obsolete by pervasive overlay chat, and the Journal is planned to be merged into the Sugar interface itself. The question of whether activities are included by default refers either to prefabricated disk images or packages for distros like Fedora and Ubuntu. Regarding disk images, the answer is clear: do both. We should have minimal disk images, with just the Sugar base, and also demo images with all the activities we think someone might want. Determining what to do in the case of packages for other distros, the situation is much muddier. The plan for Activity packaging is designed around the idea of thousands of unknown authors writing code that installs and runs with minimal privileges. Users will be able to install multiple distinct activities with the same name, distinguished by cryptographic authorship and history, upgrade or downgrade them, and modify their source code, all without superuser access. It's already difficult to harmonize this with yum/rpm and apt/deb, and it's only going to get harder with the new Activity bundle system. I think our best option is to let Sugar retain control of Activity installation, even when running on a system with its own package management. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKdDXUJT6e6HFtqQRAjsdAJ9TbLwUGlzM+hyWNV47k5AH/oX79ACgj0MD HEQu4wpYffdtpYCfMANPh4I= =KxvY -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Help building and running sugar
Hi everyone, I made a fresh sugar install following the wiki recipe for Ubuntu Feisty with sugar-jhbuild. After a few stops I have did. But when I try './sugar-jhbuild run' only got a bare bones Xwindow and the console say: snip [EMAIL PROTECTED]:~/sugar-jhbuild$ ./sugar-jhbuild run INFO:sugar-emulator:Attempting to find free port for X11 (Xephyr) INFO:sugar-emulator: Found free port: #4 (6004) INFO:sugar-emulator:Starting the Xephyr nested X display on display 4 DEBUG:sugar-emulator:Xephyr command: Xephyr :4 -ac -screen 1200x900 -dpi 96 INFO:sugar-emulator:Attempting to launch sugar to replace this process: dbus-launch dbus-launch --exit-with-session sugar-shell Extended Input Devices not yet supported. Impelement it at line 625 in ../../../../hw/kdrive/src/kinput.c Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing from list! Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1, removing from list! Traceback (most recent call last): File /home/gob/sugar-jhbuild/install/bin/sugar-shell, line 30, in module from main import main File /home/gob/sugar-jhbuild/install/share/sugar/shell/main.py, line 23, in module import numpy ImportError: No module named numpy /snip May somebody help me in fixing this? Thanks in advance. -- Saludos, Gustavo Olaza ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity Proposal: Browse
Uncontroversially in, I think. Marco On Tue, May 13, 2008 at 4:23 PM, Simon Schampijer [EMAIL PROTECTED] wrote: Following the procedure at http://wiki.sugarlabs.org/go/Release, here's the proposal for Browse: * Short description of the features: Xulrunner: Update to xulrunner beta5 Bookmarks: We have only session bookmarks at the moment. We want to extend this, to provide the ability for global bookmarks and caching of the sites for offile viewing (http://dev.laptop.org/ticket/3889) Search: http://dev.laptop.org/ticket/7002 Stabilization: #6825 (email webfrontend), #6826 (uploading images on blogger.com)... I left 'UI to handle exceptions to invalid certificates in the browser.' out for the moment, since we need to discuss the necessity for update.2 first. * Screenshots or screencasts: No mockups of the features yet. * Are you willing to follow the Schedule? Yes I am. * System components the activity depends on: sugar, hulahop, xulrunner * Members of the developer team: Maintainer: Simon Schampijer Peer: Marco, Tomeu * Status of internationalization: In pootle * Code repository: git://dev.laptop.org/web-activity * Bug tracking system: browse-activity in dev.laptop.org Trac Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugarlabs
There seems to be some comprehensibility to sugar development now :-) Thank you for the effort ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 8:07 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Tue, May 13, 2008 at 7:33 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | We should | have minimal disk images, with just the Sugar base, and also demo images | with all the activities we think someone might want. | | What use cases do you envision for the minimal disk image? A minimal disk image would be used in the construction of a custom build for a deployment, using a Customization Stick or equivalent mechanism. Given that Activities are going to be added later, there is no need for any Activities to be included by default. Oh, I had misread you. Thanks for clarifying. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 7:33 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: The question of whether activities are included by default refers either to prefabricated disk images or packages for distros like Fedora and Ubuntu. Regarding disk images, the answer is clear: do both. We should have minimal disk images, with just the Sugar base, and also demo images with all the activities we think someone might want. Determining what to do in the case of packages for other distros, the situation is much muddier. The plan for Activity packaging is designed around the idea of thousands of unknown authors writing code that installs and runs with minimal privileges. Users will be able to install multiple distinct activities with the same name, distinguished by cryptographic authorship and history, upgrade or downgrade them, and modify their source code, all without superuser access. It's already difficult to harmonize this with yum/rpm and apt/deb, and it's only going to get harder with the new Activity bundle system. I think our best option is to let Sugar retain control of Activity installation, even when running on a system with its own package management. I think it's useful to separate distribution and development when discussing this. You are discussing several distribution models. Some of them goes through a no-activities state during the process, but all of them include activities in their final form (unless for the distro case you are thinking to start clean and let the user select the activities he wants). To me including activities in the coordinated development process has two main advantages: 1 It gives distributors a complete product they can customize and extend for their users. 2 It makes developers work on a concrete, complete product, rather than on a set of libraries and services. Activities are our strength. Putting a bunch of them at the core of our development processes is the best way to ensure they get the attention they need. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
I totally agree with this suggestion - implementing collaboration can be a lot of work and be error prone, so I think activity developers tend to not get around to it. Having a built in VNC or Remote X based 'default sharing solution', along the lines of what LogMeIn or GotoMyPC do but on a per-activity basis, would go a long way towards establishing the ubiquitous Sugar collaboration experience as designed. Then, activities with special sharing requirements, like games which become multiplayer competitions when shared, can override this default behavior. Best, Wade On Tue, May 13, 2008 at 5:31 AM, Walter Bender [EMAIL PROTECTED] wrote: In general, it'd be great to be able to share like this for most activities. Another way of thinking about sharing would be to share resources of multiple laptops to get a bigger workspace, e.g., some times it is useful to have multiple xterms open. This would seemingly be simple to do in the context of the X Window System if we wrap the appropriate Sugar/Collaboration model around it. I can think of lots of activities that are someone space constrained at times--having the option of a larger or multiple screens--putting the debugging output on a separate laptop, for example. Future feature wish list. -walter On Tue, May 13, 2008 at 7:57 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le lundi 12 mai 2008 à 13:25 -0400, Benjamin M. Schwartz a écrit : I think shared Terminal would be very cool. A lot of other people seem to think so too. It would be a fun way to learn command-line stuff, by sharing a prompt with a remote friend. Definitely. Shared terminal could be a killer feature. I'd like to see something similar in GNOME using gnome-terminal and Empathy. Most of the work could probably be reused. G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Log Viewer overhaul.
If we go with the 'Please enter a title for this activity' alert, would it be possible to add a simple one-click way to say 'Don't keep'? This might help with the Journal pollution issue. -Wade On Tue, May 13, 2008 at 9:29 AM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 4:14 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 4:04 AM, Wade Brainerd [EMAIL PROTECTED] wrote: I'm happy to co-maintain. Eduardo, were you planning to integrate more stuff from Memphis into Log Viewer? I don't want to interfere with that work of course. I don't think so. Most of the memphis stuff should be in Analyze rather than in the log viewer. Off topic- 'Log Viewer Activity' does not fit in the activity toolbar's title entry. I have seen this problem with other activities as well. Can we consider expanding the default size of this entry, or else dropping the word 'Activity' from the default titles? Eben, can/should we drop Activity from the toolbar? Double word activity will be pretty common I think, since a verb is often not enough to describe it properly. Three points. =) 1. There is currently no reason for the arbitrarily short entry field. We can (should) definitely expand it. 2. We really should *not* be appending activity to the title at all. In fact, that seems to be the wrong message. If anything, we would want to append something like instance instead. But, that aside, what I really want is .info support for suggested (and translated) default titles! I've brought this up before, and again recently in the ML. Perhaps homunq can add support for this and activity tags when he plays with the bundle spec? 3. We need to revisit the possibility of abandoning the activity toolbar itself, in favor of a non-modal (or modal?) title request alert and a host of features (keep, share, name, tag, etc) within the palette for the activity in the Frame instead. We could probably do this along with the new design if we decide it's the right thing to do. I think we need the alert even if we don't drop the toolbar. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | In general, it'd be great to be able to share like this for most | activities. Another way of thinking about sharing would be to share | resources of multiple laptops to get a bigger workspace, e.g., some | times it is useful to have multiple xterms open. This would seemingly | be simple to do in the context of the X Window System if we wrap the | appropriate Sugar/Collaboration model around it. I can think of lots | of activities that are someone space constrained at times--having the | option of a larger or multiple screens--putting the debugging output | on a separate laptop, for example. Future feature wish list. What you are describing is very similar to the Distributed Multihead X system (DMX, also called Xdmx). See, for example, the pictures in (http://www.ibm.com/developerworks/opensource/library/os-mltihed/index.html) There has been renewed interest in DMX among X developers, especially in the context of Multiple-Pointer X (MPX) and the new rendering plans. If you think this is of interest to Sugar, it might be worth talking to an X expert. For the record, I think that this is probably not a good idea for Sugar. DMX requires a potentially huge amount of network bandwidth, with little tolerance for latency or packet loss. It also seems inevitably, tremendously complicated for a user to manage. But don't listen to me; talk to someone who actually knows where the DMX work is headed. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKfICUJT6e6HFtqQRAvBfAJkBxjAd1TofcLBAaS3Os+aCNhamHQCgmEe6 Wum2SQFNByhhuXN6zHTNCRc= =/2lk -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity proposal: Calculate
* Short description of the features: - Mathematics for kids, both basic features and more advanced functionality. - No major new features expected for Update.2. * Screenshots or screencasts: http://wiki.laptop.org/go/Image:Calculate_screenshot.jpg http://wiki.laptop.org/go/Calculate for more images * Are you willing to follow the Schedule? Yep * System components the activity depends on: sugar * Members of the developer team: Reinier * Status of internationalization: In pootle * Code repository: http://dev.laptop.org/git?p=projects/calculate;a=summary * Bug tracking system: calculator-activity in dev.laptop.org Trac Cheers, -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Help building and running sugar
Gustavo, The first few lines look like normal messages. The real problem, I think, is pointed to by this last traceback: Traceback (most recent call last): File /home/gob/sugar-jhbuild/install/bin/sugar-shell, line 30, in module from main import main File /home/gob/sugar-jhbuild/install/share/sugar/shell/main.py, line 23, in module import numpy ImportError: No module named numpy numpy is the Numeric Python module. You may be able to install this with apt-get install numpy. Sugar-jhbuild in my own case identified numpy as a required module before it even ran the build step, but it may not be doing that anymore. In any case, it looks like Sugar can build itself without numpy but can't run without it. James Simmons Message: 6 Date: Tue, 13 May 2008 14:38:13 -0300 From: Gustavo Olaza [EMAIL PROTECTED] Subject: [sugar] Help building and running sugar To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, I made a fresh sugar install following the wiki recipe for Ubuntu Feisty with sugar-jhbuild. After a few stops I have did. But when I try './sugar-jhbuild run' only got a bare bones Xwindow and the console say: snip [EMAIL PROTECTED]:~/sugar-jhbuild$ ./sugar-jhbuild run INFO:sugar-emulator:Attempting to find free port for X11 (Xephyr) INFO:sugar-emulator: Found free port: #4 (6004) INFO:sugar-emulator:Starting the Xephyr nested X display on display 4 DEBUG:sugar-emulator:Xephyr command: Xephyr :4 -ac -screen 1200x900 -dpi 96 INFO:sugar-emulator:Attempting to launch sugar to replace this process: dbus-launch dbus-launch --exit-with-session sugar-shell Extended Input Devices not yet supported. Impelement it at line 625 in ../../../../hw/kdrive/src/kinput.c Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing from list! Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1, removing from list! Traceback (most recent call last): File /home/gob/sugar-jhbuild/install/bin/sugar-shell, line 30, in module from main import main File /home/gob/sugar-jhbuild/install/share/sugar/shell/main.py, line 23, in module import numpy ImportError: No module named numpy /snip May somebody help me in fixing this? Thanks in advance. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
Etoys has a DMX-like feature built in -- you can tile workspaces or share a single workspace -- but it is more than what I was thinking. The idea is not so much to make a large virtual space -- although there could be times when that could be useful -- but rather to simply break an activity out into multiple views across different machines, e.g., using a remote machine to serve as the debugging console for something you are building in Pippy, etc. I don't think these sorts of things need be bandwidth intensive at all. -walter On Tue, May 13, 2008 at 3:54 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | In general, it'd be great to be able to share like this for most | activities. Another way of thinking about sharing would be to share | resources of multiple laptops to get a bigger workspace, e.g., some | times it is useful to have multiple xterms open. This would seemingly | be simple to do in the context of the X Window System if we wrap the | appropriate Sugar/Collaboration model around it. I can think of lots | of activities that are someone space constrained at times--having the | option of a larger or multiple screens--putting the debugging output | on a separate laptop, for example. Future feature wish list. What you are describing is very similar to the Distributed Multihead X system (DMX, also called Xdmx). See, for example, the pictures in (http://www.ibm.com/developerworks/opensource/library/os-mltihed/index.html) There has been renewed interest in DMX among X developers, especially in the context of Multiple-Pointer X (MPX) and the new rendering plans. If you think this is of interest to Sugar, it might be worth talking to an X expert. For the record, I think that this is probably not a good idea for Sugar. DMX requires a potentially huge amount of network bandwidth, with little tolerance for latency or packet loss. It also seems inevitably, tremendously complicated for a user to manage. But don't listen to me; talk to someone who actually knows where the DMX work is headed. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKfICUJT6e6HFtqQRAvBfAJkBxjAd1TofcLBAaS3Os+aCNhamHQCgmEe6 Wum2SQFNByhhuXN6zHTNCRc= =/2lk -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Help building and running sugar
config/sysdeps/ubuntu-7.10.xml has python-numpy Is that the correct name of the package? Gustavo, do you have it installed? If you don't sugar-jhbuild build should tell you about the missing dep and exit. Marco On Tue, May 13, 2008 at 10:54 PM, James Simmons [EMAIL PROTECTED] wrote: Gustavo, The first few lines look like normal messages. The real problem, I think, is pointed to by this last traceback: Traceback (most recent call last): File /home/gob/sugar-jhbuild/install/bin/sugar-shell, line 30, in module from main import main File /home/gob/sugar-jhbuild/install/share/sugar/shell/main.py, line 23, in module import numpy ImportError: No module named numpy numpy is the Numeric Python module. You may be able to install this with apt-get install numpy. Sugar-jhbuild in my own case identified numpy as a required module before it even ran the build step, but it may not be doing that anymore. In any case, it looks like Sugar can build itself without numpy but can't run without it. James Simmons Message: 6 Date: Tue, 13 May 2008 14:38:13 -0300 From: Gustavo Olaza [EMAIL PROTECTED] Subject: [sugar] Help building and running sugar To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, I made a fresh sugar install following the wiki recipe for Ubuntu Feisty with sugar-jhbuild. After a few stops I have did. But when I try './sugar-jhbuild run' only got a bare bones Xwindow and the console say: snip [EMAIL PROTECTED]:~/sugar-jhbuild$ ./sugar-jhbuild run INFO:sugar-emulator:Attempting to find free port for X11 (Xephyr) INFO:sugar-emulator: Found free port: #4 (6004) INFO:sugar-emulator:Starting the Xephyr nested X display on display 4 DEBUG:sugar-emulator:Xephyr command: Xephyr :4 -ac -screen 1200x900 -dpi 96 INFO:sugar-emulator:Attempting to launch sugar to replace this process: dbus-launch dbus-launch --exit-with-session sugar-shell Extended Input Devices not yet supported. Impelement it at line 625 in ../../../../hw/kdrive/src/kinput.c Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing from list! Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1, removing from list! Traceback (most recent call last): File /home/gob/sugar-jhbuild/install/bin/sugar-shell, line 30, in module from main import main File /home/gob/sugar-jhbuild/install/share/sugar/shell/main.py, line 23, in module import numpy ImportError: No module named numpy /snip May somebody help me in fixing this? Thanks in advance. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
Walter wrote: I think we need to decouple the release cycles between activities and Sugar to whatever degree possible. Activities should be able to change at whatever pace is dictated by the activity developers. Since activities depend upon Sugar, the Sugar schedule needs to be more predictable. The only time it seems there would be a conflict is when an incompatible change in a Sugar module is made Yep. When the decision was made to not deliver built-in activities within the laptop.org builds, Activities development was decoupled from Sugar (except as noted above). Regarding the schedule for the 'release' of Activities: I believe there are three populations of Activity-users to be kept in mind: 1) Users who will not upgrade their Activities except under the direction of whoever they got their OLPCs from. [I presume this is what the automatic_upgrade (e.g., 'security/update-stream') was designed for. How Activities are submitted (including timeline determination) to this facility needs to be documented.] (2) Users who don't want to wait for an automatic_upgrade, but who would only accept __certified__ Activities. [I presume that when enough significant new/changed Activities have been tested by a responsible organization, that organization will create a newer version of an activity package, and make that package available on a server. This can be need-driven, instead of time-driven.] (3) Users who would like to independently install Activities, even when such Activities have not undergone official QA. [I presume that a master list of the latest and greatest Activities will be kept by a responsible organization. Activities ought to be listed as soon as the individual developer says so.] If doesn't run situations are to be avoided, something like a package manager will have to be provided AT EACH XO (to perform the *actual* Activity installation). It will check the system for pre-requisites as indicated by each Activity, and will alert the user when an install is attempted whose pre-requisites are not met. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 11:40 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 7:33 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: The question of whether activities are included by default refers either to prefabricated disk images or packages for distros like Fedora and Ubuntu. Regarding disk images, the answer is clear: do both. We should have minimal disk images, with just the Sugar base, and also demo images with all the activities we think someone might want. Determining what to do in the case of packages for other distros, the situation is much muddier. The plan for Activity packaging is designed around the idea of thousands of unknown authors writing code that installs and runs with minimal privileges. Users will be able to install multiple distinct activities with the same name, distinguished by cryptographic authorship and history, upgrade or downgrade them, and modify their source code, all without superuser access. It's already difficult to harmonize this with yum/rpm and apt/deb, and it's only going to get harder with the new Activity bundle system. I think our best option is to let Sugar retain control of Activity installation, even when running on a system with its own package management. I think it's useful to separate distribution and development when discussing this. You are discussing several distribution models. Some of them goes through a no-activities state during the process, but all of them include activities in their final form (unless for the distro case you are thinking to start clean and let the user select the activities he wants). There is another issue to consider. Those of us planning for a next-generation textbook want to know for sure what software they can count on. Otherwise, every active document will have to be packaged with dependencies. I am considering textbooks in drawing, music, any of the sciences that can make use of external measuring devices, photography, math, and other subjects. At the secondary and college levels, packaging a textbook with accompanying software is not a problem, but in elementary school classrooms we don't want to put the burden on both teachers and students to deal with extra installation steps. To me including activities in the coordinated development process has two main advantages: 1 It gives distributors a complete product they can customize and extend for their users. 2 It makes developers work on a concrete, complete product, rather than on a set of libraries and services. Activities are our strength. Putting a bunch of them at the core of our development processes is the best way to ensure they get the attention they need. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- 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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 5:09 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Edward Cherlin wrote: | Those of us planning for a | next-generation textbook want to know for sure | what software they can count on. Otherwise, every active document will | have to be packaged with dependencies. You cannot count on any software other than the shell itself. The Sugar design does not support inter-item dependencies, and explicitly allows the user to delete any Activity, independently of any other. You are welcome to propose a dependency mechanism, but we have had this discussion many times, and you are unlikely to discover the magic bullet that avoids the pitfalls of UI complexity, bundle identity, versioning, and location. Rather than attempt to solve this hard technical problem, you are much better off simply avoiding dependencies. In the particular case of software textbooks, this is really not an issue. If your textbook suggests exercises in a particular group of Activities, it should say so on the first page. Going out of the book into the Activities isn't the model. The MatLab or Mathematica Notebook is a starting point. Having every math expression in the book be executable by clicking and graphable via NumPy or Measure is good. Building in simulations rather than static graphs takes it further. Including a kit of Smalltalk objects that can be snapped together to build visual or computational models goes further yet. There are many other possibilities. You should not feel the need to limit your scope to some default set; rather, you should provide copies of all the ancillary Activities for download along with your textbook. You can even include copies of those Activities as .xo bundles inside the textbook, like the Library does. Free redistribution is one of the beautiful things about free software. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKi2sUJT6e6HFtqQRAlIoAKCTGRKPxFyGc7juBGBm8JjmklmbUACglJrm 8QKT9vc0Hi3bxk7fTSzY8CU= =+Mzb -END PGP SIGNATURE- -- 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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
