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
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
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
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
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
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
+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
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
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
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
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? =
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
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
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
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
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
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
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
-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
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
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,
21 matches
Mail list logo
