A process proposal for 3.10

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
132 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Joshua Gargus-2
This goes back to one of the opinions that Marcus expressed earlier  
in the thread:

"The SqueakLand people don't use 3.9, and I am quite sure they never  
will"

This rings true to me (although it would be nice to hear directly  
from a squeaklander).  In my understanding, it was the  
internationalization code in 3.8 that made it worthwhile for  
squeakland to undergo the difficult synchronization.  I don't think  
that there is anything compelling enough in 3.9 (or that has been  
discussed for 3.10) to justify the effort again, especially with a  
Tweak version of EToys not too far over the horizon.

Josh


On Oct 18, 2006, at 8:37 AM, Bert Freudenberg wrote:

> As Juan wrote, removing Etoys from Morphic while keeping it both  
> loadable and functioning properly is futile.
>
> So either you leave it in, or you consciously give up compatibility  
> with anyone using Etoys now, like the squeakland distribution, OLPC  
> distribution, Smalland, the Spanish LinEx version, the Japanese  
> Nihongo version etc. Already synchronizing Squeakland and 3.8 was  
> hard, nobody has tried yet for 3.9, but this would make it outright  
> impossible.
>
> I'm *not* saying you should not do this, but please be aware of the  
> possible consequences.
>
> - Bert -
>
> Am 18.10.2006 um 14:11 schrieb [hidden email]:
>
>> Hi Giovanni,
>>
>> I don't think what you say is doable. We don't have the means to  
>> break all
>> dependencies on eToys, and at the same time keep eToys working. It  
>> would
>> need the same kind of work as to make it unloadable and loadable  
>> back.
>>
>> When I realized how much refactoring is needed to do that, I  
>> stopped the
>> MorphicSplitters effort and quited as the Morphic Steward.
>>
>> What I propose can be done. I did it for 3.7. You can download it  
>> from
>> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ 
>> EtoysFreeMorphic.html . I
>> believe Pavel did something similar (although I haven't looked at it.
>>
>> Anyway, I'd like to be proven wrong. Are you volunteering?
>>
>> Cheers,
>> Juan Vuletich
>>
>>> When resource is scare, the smarter come out ;)
>>>
>>> How is big etoys?
>>> And How is deeply integrated in Squeak?
>>>
>>> If Etoy is not so big (as I remembered), we can simply start to  
>>> "cut its
>>> wires" from Morphic and let it aging around.
>>> We can start creating a mechanism to deprecate some methods.
>>> By the way the deprecation engine seems to me very important to do.
>>>
>>> We can do this thing with less then 8 hours of work in my own  
>>> opinion,
>>> I suggest to rethink our apprach and to adopt a "Panta  
>>> Rei" (verything
>>> changes - the philosophy of Heraclitus).
>>> We should start to plan the new Squeak version WITHOUT throwing  
>>> away the
>>> bad
>>> things.
>>>
>>> We can start taking bad thing alone in a room, putting heavy  
>>> doors in it,
>>> and then
>>> prohibing them to exit :)
>>>
>>> The other developers will start stopping using EToy in a smooth way.
>>>
>>> After a while we can think how to dismiss them... or not.
>>>
>>> In my own opinion frequently Squeak home change, so the problem  
>>> will solve
>>> smootly without so much pain.
>>> Let's discuss on this approach.
>>>
>>>
>>> On 10/18/06, Juan Vuletich <[hidden email]> wrote:
>>>>
>>>> So, this seems a good time to remove eToys from the official  
>>>> release. I
>>>> can team with Pavel and Stef (and any other volunteer) to do this.
>>>>
>>>> However, it will take some 20 or 30 hours of work, and I think  
>>>> we need
>>>> to know if this will be adopted, otherwise I won't spend time on  
>>>> it.
>>>>
>>>> I guess the Board could lead, and make a decision, or enlight me  
>>>> about
>>>> the decision process for issues like this one.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>> Marcus Denker wrote:
>>>>> The SqueakLand people don't use 3.9, and I am quite sure they  
>>>>> never
>>>> will.
>>>>>
>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool  
>>>>> Etoys
>>>>> image for eToys1.
>>>>>
>>>>> For the future, there needs to be a new eToys2 that is  
>>>>> maintainable.
>>>>> There is a very cool demo of a next-gen eToys based on Tweak.
>>>>> That seems, to me, much more the thing to take a look at for the
>>>> future
>>>>> eToy system.
>>>>>
>>>>>        Marcus
>>>>
>>>>
>>>
>>>
>>> --
>>> "Just Design It" -- GG
>>> Software Architect
>>> http://www.objectsroot.com/
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Milan Zimmermann-2
In reply to this post by Juan Vuletich (dc)
Juan,

Once eToys are removed (and as you suggested perhaps 20-30 hours work), do you
think it is reasonbly possible to have them loadable again? I am not asking
you to do the "reload" piece of work, rather asking about your feeling about
whether reloadability is possible, and what number of hours would you
estimate to make eToys loadable (if such question even makes sense :) - in
very rough number, 10, 100, 1000 hours sort of thing). The reason I am
asking, and perhaps there are others in this camp, is that for my personal
playing with squeak I mostly play with eToys, and would have to either help
the reloading effort (which I will, but my abilities cannot guarantee
much :) ) or switch to squeakland image. In any case, work towards a small
well-defined "squeak core" (with hopefully loadable packages)  makes sense.

Thanks Milan

On 2006 October 18 06:10, Juan Vuletich wrote:

> So, this seems a good time to remove eToys from the official release. I
> can team with Pavel and Stef (and any other volunteer) to do this.
>
> However, it will take some 20 or 30 hours of work, and I think we need
> to know if this will be adopted, otherwise I won't spend time on it.
>
> I guess the Board could lead, and make a decision, or enlight me about
> the decision process for issues like this one.
>
> Cheers,
> Juan Vuletich
>
> Marcus Denker wrote:
> > The SqueakLand people don't use 3.9, and I am quite sure they never will.
> >
> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
> > image for eToys1.
> >
> > For the future, there needs to be a new eToys2 that is maintainable.
> > There is a very cool demo of a next-gen eToys based on Tweak.
> > That seems, to me, much more the thing to take a look at for the future
> > eToy system.
> >
> >        Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Juan Vuletich (dc)
In reply to this post by Joshua Gargus-2
The ones I can think of right now are:

1) Squeak should not include applications. And eToys, (for a Smalltalk
programmer) is an application.

2) eToys code is everywhere in the system, not only in eToys classes.

3) the impact of eToys in Morphic is terrible. Just download my image from
http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html and
browse a bit Morph or any core Morphic classes. Then compare with 3.9.

4) Cleaning (or refactoring or redesigning) Morphic is almost impossible
with eToys around.

5) eToys is not being maintained. People who use it, actually use other
Squeak distributions, like Squeakland and SmallLand.

I'm sure there are others.
Cheers,
Juan Vuletich

> This ignores the reasons that Juan wants to remove EToys in the first
> place.
>
> Juan, I'm sure I've read these reasons elsewhere, but could you
> please repeat them for the benefit of this thread?
>
> Thanks,
> Josh
>
>
>
> On Oct 18, 2006, at 9:03 AM, Giovanni Giorgi wrote:
>
>> As I have understood, there is a new eToy implementation in
>> progress inside Tweak.
>> We can wait until this implementation is a bit stable.
>> When this will be true, the other part depending from eToy1 will be
>> able to migrate to eToy2.
>> After that we can start to deliver an official squeak distribution
>> with eToy2 and eToy1 side by side.
>> Then after w ahile we can start to evict eToy1.
>>
>> This will save some efforts, at cost of a bit larger image (but
>> avoiding some hours of work can be a good exchange ;)
>>
>>
>> On 10/18/06, [hidden email] <[hidden email]> wrote: Of
>> course.
>>
>> That's why I'm asking the Board to decide, or advice.
>>
>> Cheers,
>> Juan Vuletich
>>
>> > As Juan wrote, removing Etoys from Morphic while keeping it both
>> > loadable and functioning properly is futile.
>> >
>> > So either you leave it in, or you consciously give up compatibility
>> > with anyone using Etoys now, like the squeakland distribution, OLPC
>> > distribution, Smalland, the Spanish LinEx version, the Japanese
>> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was
>> > hard, nobody has tried yet for 3.9, but this would make it outright
>> > impossible.
>> >
>> > I'm *not* saying you should not do this, but please be aware of the
>> > possible consequences.
>> >
>>
>>
>>
>>
>>
>>
>> --
>> "Just Design It" -- GG
>> Software Architect
>> http://www.objectsroot.com/
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Juan Vuletich (dc)
In reply to this post by Milan Zimmermann-2
Hi Milan,

It is hard to say, but it is a huge effort. May be in the 1000 hours
range. May be much more than that. I don't think it's worth doing.

For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the
new Tweak based, when available.

Cheers,
Juan Vuletich

> Juan,
>
> Once eToys are removed (and as you suggested perhaps 20-30 hours work), do
> you
> think it is reasonbly possible to have them loadable again? I am not
> asking
> you to do the "reload" piece of work, rather asking about your feeling
> about
> whether reloadability is possible, and what number of hours would you
> estimate to make eToys loadable (if such question even makes sense :) - in
> very rough number, 10, 100, 1000 hours sort of thing). The reason I am
> asking, and perhaps there are others in this camp, is that for my personal
> playing with squeak I mostly play with eToys, and would have to either
> help
> the reloading effort (which I will, but my abilities cannot guarantee
> much :) ) or switch to squeakland image. In any case, work towards a small
> well-defined "squeak core" (with hopefully loadable packages)  makes
> sense.
>
> Thanks Milan
>
> On 2006 October 18 06:10, Juan Vuletich wrote:
>> So, this seems a good time to remove eToys from the official release. I
>> can team with Pavel and Stef (and any other volunteer) to do this.
>>
>> However, it will take some 20 or 30 hours of work, and I think we need
>> to know if this will be adopted, otherwise I won't spend time on it.
>>
>> I guess the Board could lead, and make a decision, or enlight me about
>> the decision process for issues like this one.
>>
>> Cheers,
>> Juan Vuletich
>>
>> Marcus Denker wrote:
>> > The SqueakLand people don't use 3.9, and I am quite sure they never
>> will.
>> >
>> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
>> > image for eToys1.
>> >
>> > For the future, there needs to be a new eToys2 that is maintainable.
>> > There is a very cool demo of a next-gen eToys based on Tweak.
>> > That seems, to me, much more the thing to take a look at for the
>> future
>> > eToy system.
>> >
>> >        Marcus
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Giovanni Giorgi-3
As said, we must give up to a frontal attack.
There is a plan to use Tweak instead of Morphic in the next few years (1-3)?
If Morphic will be obsolete in three years,  it'd not be so bad to have "eToy1" around for a while.

We can think of fixing only eToy critical bugs and left the others alone.


On 10/18/06, [hidden email] <[hidden email]> wrote:
Hi Milan,

It is hard to say, but it is a huge effort. May be in the 1000 hours
range. May be much more than that. I don't think it's worth doing.

For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the
new Tweak based, when available.

Cheers,
Juan Vuletich

> Juan,
>
> Once eToys are removed (and as you suggested perhaps 20-30 hours work), do
> you
> think it is reasonbly possible to have them loadable again? I am not
> asking
> you to do the "reload" piece of work, rather asking about your feeling
> about
> whether reloadability is possible, and what number of hours would you
> estimate to make eToys loadable (if such question even makes sense :) - in
> very rough number, 10, 100, 1000 hours sort of thing). The reason I am
> asking, and perhaps there are others in this camp, is that for my personal
> playing with squeak I mostly play with eToys, and would have to either
> help
> the reloading effort (which I will, but my abilities cannot guarantee
> much :) ) or switch to squeakland image. In any case, work towards a small
> well-defined "squeak core" (with hopefully loadable packages)  makes
> sense.
>
> Thanks Milan
>
> On 2006 October 18 06:10, Juan Vuletich wrote:
>> So, this seems a good time to remove eToys from the official release. I
>> can team with Pavel and Stef (and any other volunteer) to do this.
>>
>> However, it will take some 20 or 30 hours of work, and I think we need
>> to know if this will be adopted, otherwise I won't spend time on it.
>>
>> I guess the Board could lead, and make a decision, or enlight me about
>> the decision process for issues like this one.
>>
>> Cheers,
>> Juan Vuletich
>>
>> Marcus Denker wrote:
>> > The SqueakLand people don't use 3.9, and I am quite sure they never
>> will.
>> >
>> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
>> > image for eToys1.
>> >
>> > For the future, there needs to be a new eToys2 that is maintainable.
>> > There is a very cool demo of a next-gen eToys based on Tweak.
>> > That seems, to me, much more the thing to take a look at for the
>> future
>> > eToy system.
>> >
>> >        Marcus
>
>






--
"Just Design It" -- GG
Software Architect
http://www.objectsroot.com/

Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Bert Freudenberg
In reply to this post by Joshua Gargus-2
Just for clarification - the m17n code *came* from Squeakland (and  
originally from the Japanese version) and was put into 3.8. Not the  
other way around.

About the Tweak Etoys version, as far as I know, nobody is currently  
working on it. It is usable, several people are building stuff on top  
of it, but nobody works on what you could call its core. It could be  
developed further by the community (same as Tweak, for that matter),  
but "waiting for it to happen" is not a fruitful strategy. Software  
does not write itself magically just yet.

- Bert -

Am 18.10.2006 um 15:27 schrieb Josh Gargus:

> This goes back to one of the opinions that Marcus expressed earlier  
> in the thread:
>
> "The SqueakLand people don't use 3.9, and I am quite sure they  
> never will"
>
> This rings true to me (although it would be nice to hear directly  
> from a squeaklander).  In my understanding, it was the  
> internationalization code in 3.8 that made it worthwhile for  
> squeakland to undergo the difficult synchronization.  I don't think  
> that there is anything compelling enough in 3.9 (or that has been  
> discussed for 3.10) to justify the effort again, especially with a  
> Tweak version of EToys not too far over the horizon.
>
> Josh
>
>
> On Oct 18, 2006, at 8:37 AM, Bert Freudenberg wrote:
>
>> As Juan wrote, removing Etoys from Morphic while keeping it both  
>> loadable and functioning properly is futile.
>>
>> So either you leave it in, or you consciously give up  
>> compatibility with anyone using Etoys now, like the squeakland  
>> distribution, OLPC distribution, Smalland, the Spanish LinEx  
>> version, the Japanese Nihongo version etc. Already synchronizing  
>> Squeakland and 3.8 was hard, nobody has tried yet for 3.9, but  
>> this would make it outright impossible.
>>
>> I'm *not* saying you should not do this, but please be aware of  
>> the possible consequences.
>>
>> - Bert -
>>
>> Am 18.10.2006 um 14:11 schrieb [hidden email]:
>>
>>> Hi Giovanni,
>>>
>>> I don't think what you say is doable. We don't have the means to  
>>> break all
>>> dependencies on eToys, and at the same time keep eToys working.  
>>> It would
>>> need the same kind of work as to make it unloadable and loadable  
>>> back.
>>>
>>> When I realized how much refactoring is needed to do that, I  
>>> stopped the
>>> MorphicSplitters effort and quited as the Morphic Steward.
>>>
>>> What I propose can be done. I did it for 3.7. You can download it  
>>> from
>>> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ 
>>> EtoysFreeMorphic.html . I
>>> believe Pavel did something similar (although I haven't looked at  
>>> it.
>>>
>>> Anyway, I'd like to be proven wrong. Are you volunteering?
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>> When resource is scare, the smarter come out ;)
>>>>
>>>> How is big etoys?
>>>> And How is deeply integrated in Squeak?
>>>>
>>>> If Etoy is not so big (as I remembered), we can simply start to  
>>>> "cut its
>>>> wires" from Morphic and let it aging around.
>>>> We can start creating a mechanism to deprecate some methods.
>>>> By the way the deprecation engine seems to me very important to do.
>>>>
>>>> We can do this thing with less then 8 hours of work in my own  
>>>> opinion,
>>>> I suggest to rethink our apprach and to adopt a "Panta  
>>>> Rei" (verything
>>>> changes - the philosophy of Heraclitus).
>>>> We should start to plan the new Squeak version WITHOUT throwing  
>>>> away the
>>>> bad
>>>> things.
>>>>
>>>> We can start taking bad thing alone in a room, putting heavy  
>>>> doors in it,
>>>> and then
>>>> prohibing them to exit :)
>>>>
>>>> The other developers will start stopping using EToy in a smooth  
>>>> way.
>>>>
>>>> After a while we can think how to dismiss them... or not.
>>>>
>>>> In my own opinion frequently Squeak home change, so the problem  
>>>> will solve
>>>> smootly without so much pain.
>>>> Let's discuss on this approach.
>>>>
>>>>
>>>> On 10/18/06, Juan Vuletich <[hidden email]> wrote:
>>>>>
>>>>> So, this seems a good time to remove eToys from the official  
>>>>> release. I
>>>>> can team with Pavel and Stef (and any other volunteer) to do this.
>>>>>
>>>>> However, it will take some 20 or 30 hours of work, and I think  
>>>>> we need
>>>>> to know if this will be adopted, otherwise I won't spend time  
>>>>> on it.
>>>>>
>>>>> I guess the Board could lead, and make a decision, or enlight  
>>>>> me about
>>>>> the decision process for issues like this one.
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>> Marcus Denker wrote:
>>>>>> The SqueakLand people don't use 3.9, and I am quite sure they  
>>>>>> never
>>>>> will.
>>>>>>
>>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool  
>>>>>> Etoys
>>>>>> image for eToys1.
>>>>>>
>>>>>> For the future, there needs to be a new eToys2 that is  
>>>>>> maintainable.
>>>>>> There is a very cool demo of a next-gen eToys based on Tweak.
>>>>>> That seems, to me, much more the thing to take a look at for the
>>>>> future
>>>>>> eToy system.
>>>>>>
>>>>>>        Marcus
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> "Just Design It" -- GG
>>>> Software Architect
>>>> http://www.objectsroot.com/
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Milan Zimmermann-2
In reply to this post by Juan Vuletich (dc)
On 2006 October 18 09:59, [hidden email] wrote:
> Hi Milan,
>
> It is hard to say, but it is a huge effort. May be in the 1000 hours
> range. May be much more than that. I don't think it's worth doing.

Thanks Juan, that's what I suspected.  And I agree that 3.9 will be here for
eToys guys like I, and Tweak-based eToys probably better and more fun.

Milan

>
> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the
> new Tweak based, when available.
>
> Cheers,
> Juan Vuletich
>
> > Juan,
> >
> > Once eToys are removed (and as you suggested perhaps 20-30 hours work),
> > do you
> > think it is reasonbly possible to have them loadable again? I am not
> > asking
> > you to do the "reload" piece of work, rather asking about your feeling
> > about
> > whether reloadability is possible, and what number of hours would you
> > estimate to make eToys loadable (if such question even makes sense :) -
> > in very rough number, 10, 100, 1000 hours sort of thing). The reason I am
> > asking, and perhaps there are others in this camp, is that for my
> > personal playing with squeak I mostly play with eToys, and would have to
> > either help
> > the reloading effort (which I will, but my abilities cannot guarantee
> > much :) ) or switch to squeakland image. In any case, work towards a
> > small well-defined "squeak core" (with hopefully loadable packages)
> > makes sense.
> >
> > Thanks Milan
> >
> > On 2006 October 18 06:10, Juan Vuletich wrote:
> >> So, this seems a good time to remove eToys from the official release. I
> >> can team with Pavel and Stef (and any other volunteer) to do this.
> >>
> >> However, it will take some 20 or 30 hours of work, and I think we need
> >> to know if this will be adopted, otherwise I won't spend time on it.
> >>
> >> I guess the Board could lead, and make a decision, or enlight me about
> >> the decision process for issues like this one.
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> >> Marcus Denker wrote:
> >> > The SqueakLand people don't use 3.9, and I am quite sure they never
> >>
> >> will.
> >>
> >> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
> >> > image for eToys1.
> >> >
> >> > For the future, there needs to be a new eToys2 that is maintainable.
> >> > There is a very cool demo of a next-gen eToys based on Tweak.
> >> > That seems, to me, much more the thing to take a look at for the
> >>
> >> future
> >>
> >> > eToy system.
> >> >
> >> >        Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Giovanni Giorgi-3
In reply to this post by Bert Freudenberg


On 10/18/06, Bert Freudenberg <[hidden email]> wrote:
[...]
About the Tweak Etoys version, as far as I know, nobody is currently
working on it. It is usable, several people are building stuff on top
of it, but nobody works on what you could call its core. It could be
developed further by the community (same as Tweak, for that matter),
but "waiting for it to happen" is not a fruitful strategy. Software
does not write itself magically just yet.

By the way after ten years of works on software field I *know* this very very *well*

I am only trying to keep the best things and to maximize our time.

Do you ever asked yourself because we have so little active developer on squeak?
Do you think we are  right?
I start having some doubts.


--
"Just Design It" -- GG
Software Architect
http://www.objectsroot.com/

Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Joshua Gargus-2
In reply to this post by Bert Freudenberg

On Oct 18, 2006, at 10:21 AM, Bert Freudenberg wrote:

> Just for clarification - the m17n code *came* from Squeakland (and  
> originally from the Japanese version) and was put into 3.8. Not the  
> other way around.
>

Thanks for the correction.

> About the Tweak Etoys version, as far as I know, nobody is  
> currently working on it. It is usable, several people are building  
> stuff on top of it, but nobody works on what you could call its  
> core. It could be developed further by the community (same as  
> Tweak, for that matter), but "waiting for it to happen" is not a  
> fruitful strategy. Software does not write itself magically just yet.

I'm not advocating waiting around for Tweak Etoys.  I'm speculating  
that removing Etoys from 3.10 will not have a large impact on the  
Squeakland community (leaving aside the other distros that you  
mentioned).  Of course Tweak Etoys won't magically appear, but  
neither will Squeakland magically port itself to 3.10.  I'm simply  
saying that, given my understanding of the risks and rewards, it is  
more likely that someone will put their energy into Tweak Etoys than  
into maintaining Etoys Classic in new Squeak versions.

Juan has volunteered to remove Etoys from 3.10.  My speculations  
above are intended solely to evaluate one of the potential costs of  
Juan's proposal, namely the cost of "consciously giving up  
compatability" with Squeakland.

Josh


>
> - Bert -
>
> Am 18.10.2006 um 15:27 schrieb Josh Gargus:
>
>> This goes back to one of the opinions that Marcus expressed  
>> earlier in the thread:
>>
>> "The SqueakLand people don't use 3.9, and I am quite sure they  
>> never will"
>>
>> This rings true to me (although it would be nice to hear directly  
>> from a squeaklander).  In my understanding, it was the  
>> internationalization code in 3.8 that made it worthwhile for  
>> squeakland to undergo the difficult synchronization.  I don't  
>> think that there is anything compelling enough in 3.9 (or that has  
>> been discussed for 3.10) to justify the effort again, especially  
>> with a Tweak version of EToys not too far over the horizon.
>>
>> Josh
>>
>>
>> On Oct 18, 2006, at 8:37 AM, Bert Freudenberg wrote:
>>
>>> As Juan wrote, removing Etoys from Morphic while keeping it both  
>>> loadable and functioning properly is futile.
>>>
>>> So either you leave it in, or you consciously give up  
>>> compatibility with anyone using Etoys now, like the squeakland  
>>> distribution, OLPC distribution, Smalland, the Spanish LinEx  
>>> version, the Japanese Nihongo version etc. Already synchronizing  
>>> Squeakland and 3.8 was hard, nobody has tried yet for 3.9, but  
>>> this would make it outright impossible.
>>>
>>> I'm *not* saying you should not do this, but please be aware of  
>>> the possible consequences.
>>>
>>> - Bert -
>>>
>>> Am 18.10.2006 um 14:11 schrieb [hidden email]:
>>>
>>>> Hi Giovanni,
>>>>
>>>> I don't think what you say is doable. We don't have the means to  
>>>> break all
>>>> dependencies on eToys, and at the same time keep eToys working.  
>>>> It would
>>>> need the same kind of work as to make it unloadable and loadable  
>>>> back.
>>>>
>>>> When I realized how much refactoring is needed to do that, I  
>>>> stopped the
>>>> MorphicSplitters effort and quited as the Morphic Steward.
>>>>
>>>> What I propose can be done. I did it for 3.7. You can download  
>>>> it from
>>>> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ 
>>>> EtoysFreeMorphic.html . I
>>>> believe Pavel did something similar (although I haven't looked  
>>>> at it.
>>>>
>>>> Anyway, I'd like to be proven wrong. Are you volunteering?
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>> When resource is scare, the smarter come out ;)
>>>>>
>>>>> How is big etoys?
>>>>> And How is deeply integrated in Squeak?
>>>>>
>>>>> If Etoy is not so big (as I remembered), we can simply start to  
>>>>> "cut its
>>>>> wires" from Morphic and let it aging around.
>>>>> We can start creating a mechanism to deprecate some methods.
>>>>> By the way the deprecation engine seems to me very important to  
>>>>> do.
>>>>>
>>>>> We can do this thing with less then 8 hours of work in my own  
>>>>> opinion,
>>>>> I suggest to rethink our apprach and to adopt a "Panta  
>>>>> Rei" (verything
>>>>> changes - the philosophy of Heraclitus).
>>>>> We should start to plan the new Squeak version WITHOUT throwing  
>>>>> away the
>>>>> bad
>>>>> things.
>>>>>
>>>>> We can start taking bad thing alone in a room, putting heavy  
>>>>> doors in it,
>>>>> and then
>>>>> prohibing them to exit :)
>>>>>
>>>>> The other developers will start stopping using EToy in a smooth  
>>>>> way.
>>>>>
>>>>> After a while we can think how to dismiss them... or not.
>>>>>
>>>>> In my own opinion frequently Squeak home change, so the problem  
>>>>> will solve
>>>>> smootly without so much pain.
>>>>> Let's discuss on this approach.
>>>>>
>>>>>
>>>>> On 10/18/06, Juan Vuletich <[hidden email]> wrote:
>>>>>>
>>>>>> So, this seems a good time to remove eToys from the official  
>>>>>> release. I
>>>>>> can team with Pavel and Stef (and any other volunteer) to do  
>>>>>> this.
>>>>>>
>>>>>> However, it will take some 20 or 30 hours of work, and I think  
>>>>>> we need
>>>>>> to know if this will be adopted, otherwise I won't spend time  
>>>>>> on it.
>>>>>>
>>>>>> I guess the Board could lead, and make a decision, or enlight  
>>>>>> me about
>>>>>> the decision process for issues like this one.
>>>>>>
>>>>>> Cheers,
>>>>>> Juan Vuletich
>>>>>>
>>>>>> Marcus Denker wrote:
>>>>>>> The SqueakLand people don't use 3.9, and I am quite sure they  
>>>>>>> never
>>>>>> will.
>>>>>>>
>>>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool  
>>>>>>> Etoys
>>>>>>> image for eToys1.
>>>>>>>
>>>>>>> For the future, there needs to be a new eToys2 that is  
>>>>>>> maintainable.
>>>>>>> There is a very cool demo of a next-gen eToys based on Tweak.
>>>>>>> That seems, to me, much more the thing to take a look at for the
>>>>>> future
>>>>>>> eToy system.
>>>>>>>
>>>>>>>        Marcus
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> "Just Design It" -- GG
>>>>> Software Architect
>>>>> http://www.objectsroot.com/
>>>
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: Removing Etoys (was Re: A process proposal for 3.10)

Ron Teitelbaum
In reply to this post by Juan Vuletich (dc)
Any chance we could instead make EToys removable, but leave it in the base
image so that if, in the future, Squeakland or Tweak would like to resync
with squeak that will still be possible?  I don't like the idea of hard
coding community fragmentation.

Ron Teitelbaum

> From: [hidden email]
> Sent: Wednesday, October 18, 2006 9:59 AM
>
> Hi Milan,
>
> It is hard to say, but it is a huge effort. May be in the 1000 hours
> range. May be much more than that. I don't think it's worth doing.
>
> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the
> new Tweak based, when available.
>
> Cheers,
> Juan Vuletich
>
> > Juan,
> >
> > Once eToys are removed (and as you suggested perhaps 20-30 hours work),
> do
> > you
> > think it is reasonbly possible to have them loadable again? I am not
> > asking
> > you to do the "reload" piece of work, rather asking about your feeling
> > about
> > whether reloadability is possible, and what number of hours would you
> > estimate to make eToys loadable (if such question even makes sense :) -
> in
> > very rough number, 10, 100, 1000 hours sort of thing). The reason I am
> > asking, and perhaps there are others in this camp, is that for my
> personal
> > playing with squeak I mostly play with eToys, and would have to either
> > help
> > the reloading effort (which I will, but my abilities cannot guarantee
> > much :) ) or switch to squeakland image. In any case, work towards a
> small
> > well-defined "squeak core" (with hopefully loadable packages)  makes
> > sense.
> >
> > Thanks Milan
> >
> > On 2006 October 18 06:10, Juan Vuletich wrote:
> >> So, this seems a good time to remove eToys from the official release. I
> >> can team with Pavel and Stef (and any other volunteer) to do this.
> >>
> >> However, it will take some 20 or 30 hours of work, and I think we need
> >> to know if this will be adopted, otherwise I won't spend time on it.
> >>
> >> I guess the Board could lead, and make a decision, or enlight me about
> >> the decision process for issues like this one.
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> >> Marcus Denker wrote:
> >> > The SqueakLand people don't use 3.9, and I am quite sure they never
> >> will.
> >> >
> >> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys
> >> > image for eToys1.
> >> >
> >> > For the future, there needs to be a new eToys2 that is maintainable.
> >> > There is a very cool demo of a next-gen eToys based on Tweak.
> >> > That seems, to me, much more the thing to take a look at for the
> >> future
> >> > eToy system.
> >> >
> >> >        Marcus
> >
> >
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Markus Gälli-3

On Oct 18, 2006, at 7:29 PM, Ron Teitelbaum wrote:

> Any chance we could instead make EToys removable, but leave it in  
> the base
> image so that if, in the future, Squeakland or Tweak would like to  
> resync
> with squeak that will still be possible?  I don't like the idea of  
> hard
> coding community fragmentation.
>
> Ron Teitelbaum

+1

Markus

>
>> From: [hidden email]
>> Sent: Wednesday, October 18, 2006 9:59 AM
>>
>> Hi Milan,
>>
>> It is hard to say, but it is a huge effort. May be in the 1000 hours
>> range. May be much more than that. I don't think it's worth doing.
>>
>> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9.  
>> Or the
>> new Tweak based, when available.
>>
>> Cheers,
>> Juan Vuletich
>>
>>> Juan,
>>>
>>> Once eToys are removed (and as you suggested perhaps 20-30 hours  
>>> work),
>> do
>>> you
>>> think it is reasonbly possible to have them loadable again? I am not
>>> asking
>>> you to do the "reload" piece of work, rather asking about your  
>>> feeling
>>> about
>>> whether reloadability is possible, and what number of hours would  
>>> you
>>> estimate to make eToys loadable (if such question even makes  
>>> sense :) -
>> in
>>> very rough number, 10, 100, 1000 hours sort of thing). The reason  
>>> I am
>>> asking, and perhaps there are others in this camp, is that for my
>> personal
>>> playing with squeak I mostly play with eToys, and would have to  
>>> either
>>> help
>>> the reloading effort (which I will, but my abilities cannot  
>>> guarantee
>>> much :) ) or switch to squeakland image. In any case, work towards a
>> small
>>> well-defined "squeak core" (with hopefully loadable packages)  makes
>>> sense.
>>>
>>> Thanks Milan
>>>
>>> On 2006 October 18 06:10, Juan Vuletich wrote:
>>>> So, this seems a good time to remove eToys from the official  
>>>> release. I
>>>> can team with Pavel and Stef (and any other volunteer) to do this.
>>>>
>>>> However, it will take some 20 or 30 hours of work, and I think  
>>>> we need
>>>> to know if this will be adopted, otherwise I won't spend time on  
>>>> it.
>>>>
>>>> I guess the Board could lead, and make a decision, or enlight me  
>>>> about
>>>> the decision process for issues like this one.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>> Marcus Denker wrote:
>>>>> The SqueakLand people don't use 3.9, and I am quite sure they  
>>>>> never
>>>> will.
>>>>>
>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool  
>>>>> Etoys
>>>>> image for eToys1.
>>>>>
>>>>> For the future, there needs to be a new eToys2 that is  
>>>>> maintainable.
>>>>> There is a very cool demo of a next-gen eToys based on Tweak.
>>>>> That seems, to me, much more the thing to take a look at for the
>>>> future
>>>>> eToy system.
>>>>>
>>>>>        Marcus
>>>
>>>
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Removing Etoys (was Re: A process proposal for 3.10)

Juan Vuletich (dc)
Ron, Marcus,

I guess you're volunteering for this to happen?

Cheers,
Juan Vuletich

>
> On Oct 18, 2006, at 7:29 PM, Ron Teitelbaum wrote:
>
>> Any chance we could instead make EToys removable, but leave it in
>> the base
>> image so that if, in the future, Squeakland or Tweak would like to
>> resync
>> with squeak that will still be possible?  I don't like the idea of
>> hard
>> coding community fragmentation.
>>
>> Ron Teitelbaum
>
> +1
>
> Markus
>
>>
>>> From: [hidden email]
>>> Sent: Wednesday, October 18, 2006 9:59 AM
>>>
>>> Hi Milan,
>>>
>>> It is hard to say, but it is a huge effort. May be in the 1000 hours
>>> range. May be much more than that. I don't think it's worth doing.
>>>
>>> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9.
>>> Or the
>>> new Tweak based, when available.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>> Juan,
>>>>
>>>> Once eToys are removed (and as you suggested perhaps 20-30 hours
>>>> work),
>>> do
>>>> you
>>>> think it is reasonbly possible to have them loadable again? I am not
>>>> asking
>>>> you to do the "reload" piece of work, rather asking about your
>>>> feeling
>>>> about
>>>> whether reloadability is possible, and what number of hours would
>>>> you
>>>> estimate to make eToys loadable (if such question even makes
>>>> sense :) -
>>> in
>>>> very rough number, 10, 100, 1000 hours sort of thing). The reason
>>>> I am
>>>> asking, and perhaps there are others in this camp, is that for my
>>> personal
>>>> playing with squeak I mostly play with eToys, and would have to
>>>> either
>>>> help
>>>> the reloading effort (which I will, but my abilities cannot
>>>> guarantee
>>>> much :) ) or switch to squeakland image. In any case, work towards a
>>> small
>>>> well-defined "squeak core" (with hopefully loadable packages)  makes
>>>> sense.
>>>>
>>>> Thanks Milan
>>>>
>>>> On 2006 October 18 06:10, Juan Vuletich wrote:
>>>>> So, this seems a good time to remove eToys from the official
>>>>> release. I
>>>>> can team with Pavel and Stef (and any other volunteer) to do this.
>>>>>
>>>>> However, it will take some 20 or 30 hours of work, and I think
>>>>> we need
>>>>> to know if this will be adopted, otherwise I won't spend time on
>>>>> it.
>>>>>
>>>>> I guess the Board could lead, and make a decision, or enlight me
>>>>> about
>>>>> the decision process for issues like this one.
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>> Marcus Denker wrote:
>>>>>> The SqueakLand people don't use 3.9, and I am quite sure they
>>>>>> never
>>>>> will.
>>>>>>
>>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool
>>>>>> Etoys
>>>>>> image for eToys1.
>>>>>>
>>>>>> For the future, there needs to be a new eToys2 that is
>>>>>> maintainable.
>>>>>> There is a very cool demo of a next-gen eToys based on Tweak.
>>>>>> That seems, to me, much more the thing to take a look at for the
>>>>> future
>>>>>> eToy system.
>>>>>>
>>>>>>        Marcus
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

RE: Removing Etoys (was Re: A process proposal for 3.10)

Ron Teitelbaum
Juan,

No, specifically I am not volunteering, I am voicing my opinion against
removing EToys at all if the result is further fragmentation of our
communities.  

My opinion concerns the politics that is currently Squeak and not a
technical assessment.  If a good case can be made for removing Etoys besides
let the SqueakLand image move along the road by itself since they will never
upgrade, then I would be interested in hearing that argument.  Otherwise I
would prefer to leave it in.  

I see a benefit in leaving a bridge, however tenuous, between the
communities.  I see a benefit in having Etoys even if it is an older version
in squeak to help facilitate learning and experimentation.  I would love to
see a Squeak that can run Croquet, Tweak, Etoys, Sophie, and Seaside and I
will do anything I can right now to keep these communities together.  

Ron Teitelbaum




> -----Original Message-----
> From: [hidden email]
> Sent: Wednesday, October 18, 2006 2:46 PM
>
> Ron, Marcus,
>
> I guess you're volunteering for this to happen?
>
> Cheers,
> Juan Vuletich
> >
> > On Oct 18, 2006, at 7:29 PM, Ron Teitelbaum wrote:
> >
> >> Any chance we could instead make EToys removable, but leave it in
> >> the base
> >> image so that if, in the future, Squeakland or Tweak would like to
> >> resync
> >> with squeak that will still be possible?  I don't like the idea of
> >> hard
> >> coding community fragmentation.
> >>
> >> Ron Teitelbaum
> >
> > +1
> >
> > Markus
> >
> >>
> >>> From: [hidden email]
> >>> Sent: Wednesday, October 18, 2006 9:59 AM
> >>>
> >>> Hi Milan,
> >>>
> >>> It is hard to say, but it is a huge effort. May be in the 1000 hours
> >>> range. May be much more than that. I don't think it's worth doing.
> >>>
> >>> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9.
> >>> Or the
> >>> new Tweak based, when available.
> >>>
> >>> Cheers,
> >>> Juan Vuletich
> >>>
> >>>> Juan,
> >>>>
> >>>> Once eToys are removed (and as you suggested perhaps 20-30 hours
> >>>> work),
> >>> do
> >>>> you
> >>>> think it is reasonbly possible to have them loadable again? I am not
> >>>> asking
> >>>> you to do the "reload" piece of work, rather asking about your
> >>>> feeling
> >>>> about
> >>>> whether reloadability is possible, and what number of hours would
> >>>> you
> >>>> estimate to make eToys loadable (if such question even makes
> >>>> sense :) -
> >>> in
> >>>> very rough number, 10, 100, 1000 hours sort of thing). The reason
> >>>> I am
> >>>> asking, and perhaps there are others in this camp, is that for my
> >>> personal
> >>>> playing with squeak I mostly play with eToys, and would have to
> >>>> either
> >>>> help
> >>>> the reloading effort (which I will, but my abilities cannot
> >>>> guarantee
> >>>> much :) ) or switch to squeakland image. In any case, work towards a
> >>> small
> >>>> well-defined "squeak core" (with hopefully loadable packages)  makes
> >>>> sense.
> >>>>
> >>>> Thanks Milan
> >>>>
> >>>> On 2006 October 18 06:10, Juan Vuletich wrote:
> >>>>> So, this seems a good time to remove eToys from the official
> >>>>> release. I
> >>>>> can team with Pavel and Stef (and any other volunteer) to do this.
> >>>>>
> >>>>> However, it will take some 20 or 30 hours of work, and I think
> >>>>> we need
> >>>>> to know if this will be adopted, otherwise I won't spend time on
> >>>>> it.
> >>>>>
> >>>>> I guess the Board could lead, and make a decision, or enlight me
> >>>>> about
> >>>>> the decision process for issues like this one.
> >>>>>
> >>>>> Cheers,
> >>>>> Juan Vuletich
> >>>>>
> >>>>> Marcus Denker wrote:
> >>>>>> The SqueakLand people don't use 3.9, and I am quite sure they
> >>>>>> never
> >>>>> will.
> >>>>>>
> >>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool
> >>>>>> Etoys
> >>>>>> image for eToys1.
> >>>>>>
> >>>>>> For the future, there needs to be a new eToys2 that is
> >>>>>> maintainable.
> >>>>>> There is a very cool demo of a next-gen eToys based on Tweak.
> >>>>>> That seems, to me, much more the thing to take a look at for the
> >>>>> future
> >>>>>> eToy system.
> >>>>>>
> >>>>>>        Marcus
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>



Reply | Threaded
Open this post in threaded view
|

Removing Morphic (was: Removing Etoys (was Re: A process proposal for 3.10))

Ron Teitelbaum
In reply to this post by Juan Vuletich (dc)
These are good reasons to remove eToys, if the removal of the application
lends to nominal improvements in Morphic.  If the goal is to clean up and
re-factor without a goal to improve Morphic, I would still vote against it.


I disagree with Squeak should not include applications, but I won't argue
the point.

What is the community's feeling about removing Morphic and replacing it with
Tweak so that squeak can run both Tweak, Croquet, and can be a platform for
new versions hopefully better packaged eToys?  We need to be thinking about
folding in and adopting both the private and research functionality that is
currently being developed.  How difficult would it be to modify current
toolBuilder tools to use Tweak instead?  Would Andreas even agree that this
is a good idea and agree to maintain Tweak in Squeak?  What is the
possibility that if we adopt Tweak that current Croquet development could
also be folded in?

(Putting on my flame proof suit)

Ron Teitelbaum


> From: [hidden email]
> Sent: Wednesday, October 18, 2006 9:56 AM
>
> The ones I can think of right now are:
>
> 1) Squeak should not include applications. And eToys, (for a Smalltalk
> programmer) is an application.
>
> 2) eToys code is everywhere in the system, not only in eToys classes.
>
> 3) the impact of eToys in Morphic is terrible. Just download my image from
> http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html and
> browse a bit Morph or any core Morphic classes. Then compare with 3.9.
>
> 4) Cleaning (or refactoring or redesigning) Morphic is almost impossible
> with eToys around.
>
> 5) eToys is not being maintained. People who use it, actually use other
> Squeak distributions, like Squeakland and SmallLand.
>
> I'm sure there are others.
> Cheers,
> Juan Vuletich
>
> > This ignores the reasons that Juan wants to remove EToys in the first
> > place.
> >
> > Juan, I'm sure I've read these reasons elsewhere, but could you
> > please repeat them for the benefit of this thread?
> >
> > Thanks,
> > Josh
> >
> >
> >
> > On Oct 18, 2006, at 9:03 AM, Giovanni Giorgi wrote:
> >
> >> As I have understood, there is a new eToy implementation in
> >> progress inside Tweak.
> >> We can wait until this implementation is a bit stable.
> >> When this will be true, the other part depending from eToy1 will be
> >> able to migrate to eToy2.
> >> After that we can start to deliver an official squeak distribution
> >> with eToy2 and eToy1 side by side.
> >> Then after w ahile we can start to evict eToy1.
> >>
> >> This will save some efforts, at cost of a bit larger image (but
> >> avoiding some hours of work can be a good exchange ;)
> >>
> >>
> >> On 10/18/06, [hidden email] <[hidden email]> wrote: Of
> >> course.
> >>
> >> That's why I'm asking the Board to decide, or advice.
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
> >> > As Juan wrote, removing Etoys from Morphic while keeping it both
> >> > loadable and functioning properly is futile.
> >> >
> >> > So either you leave it in, or you consciously give up compatibility
> >> > with anyone using Etoys now, like the squeakland distribution, OLPC
> >> > distribution, Smalland, the Spanish LinEx version, the Japanese
> >> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was
> >> > hard, nobody has tried yet for 3.9, but this would make it outright
> >> > impossible.
> >> >
> >> > I'm *not* saying you should not do this, but please be aware of the
> >> > possible consequences.
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> "Just Design It" -- GG
> >> Software Architect
> >> http://www.objectsroot.com/
> >>
> >
> >
> >
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Removing Morphic

keith1y
I would go for adopting tweak.

Personally I have never got on with morphic and would much rather see
something elegant in its place like Model-View-Presenter as used
superlatively in Dolphin.

When I last asked for an update on how tweak was progressing this was
the reply.

 > * we are 3.8-based by now
 > * we use Monticello packages in an MCConfiguration for most updates,
still have >  an update stream for complex changes
 >  * Islands are used now for projects, we might switch soon to the
Croquet island model
 >  * the new graphics interface is still in development
 >  * etoys work pretty well
 >  * not much has happened regarding a scripting syntax AFAIK
 > - Bert -

This sounds pretty good, and etoys lives.

Surely a UI framework could benefit significantly from traits and so it
would be in their interest to move to 3.9?

Keith


Send instant messages to your online friends http://uk.messenger.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)

Andreas.Raab
Keith Hodges wrote:
> Personally I have never got on with morphic and would much rather see
> something elegant in its place like Model-View-Presenter as used
> superlatively in Dolphin.

[... snip ...]

> Surely a UI framework could benefit significantly from traits and so it
> would be in their interest to move to 3.9?

It's kinda funny to see the two statements in the same message and I
just can't withstand a little rant. Hope you don't mind ;-)

To me, Morphic is to MVC as traits are to classes. What I mean by this
is that in MVC you have factored the roles into individual entities with
well-defined individual responsibilities. They can be plugged together
to enable a variety of interesting dynamic behavior. In Morphic, you
have many roles in the same object which means overlapping
responsibilities, less clarity and pluggability.

With traits, you use a similar approach to Morphic only on the
meta-level, e.g., instead of composing concrete ui behavior in a single
entity (Morph) you compose abstract trait behavior into a single entity
(Class). From what I've seen so far, the results seem shockingly
similar. Less clarity than when you have individually factored entities
(classes), more unforeseen interaction inside the entity where you
combine the different roles into, conflicting meanings which require
renames and introduce more complexity (and confusion and conflicted
meaning).

Another way to look at it is this: If you like MVC then think about what
it would mean if you would create Morphic by combining models and views
using traits. Would you think that the result is superior to MVC?
Personally, I don't think so which is why there is a clear separation
between the two in Tweak (in MVC terms only between model and view but
this seems to be the more relevant distinction).

There are of course some situations where due to technical limitations
it is not feasible to use individual entities (objects) to model a
problem. In these situations a formal mechanism like traits is of course
vastly advantageous to an ad-hoc mechanism like copying all the code
manually between two places. But that doesn't mean it's the superior
solution in general.

Here is another example: Most of the graphical attributes in Tweak are
grouped into so-called "costume aspects". Those are individual objects
that simply interact with a Tweak costume to model a certain role (like
the costume's fill, its border, its text etc). These could have been
modeled as traits by simply flattening the classes into the costume's
namespace but making them individual entities makes it a lot simpler to
deal with the interactions (besides, it saves space, allows controlled
exposure of properties etc).

For example, I can send the message #bounds to the costume and get the
composite bounds for the entire costume or I can send the message
#bounds to the text aspect and get only the text bounds. It is always
clear what I mean since I have to specify either "costume bounds" or
"costume text bounds" and it never changes, neither in the aspect nor
the costume. Compare this to a traits solution where I'd have to rename
one of the two. Which one is clearer? The one where I say "bounds" when
I implement a trait and "textBounds" when I use it? Where "show me the
senders of #textBounds" finds the senders in the composition but not in
the trait? Or where "senders of bounds" also lists all the senders of
#textBounds since they were once called #bounds? I think the answer is
clear.

[BTW, I just deleted a whole paragraph with another rant about things I
think we'll see as a result of applying traits on scale but since nobody
has used traits yet for anything real that rant just seemed a little bit
too presumptuous. I think I'll just wait with this rant up until someone
does something real so that I can point to the issues in context. And
I'd *love* to see someone built a UI framework based on traits to
illustrate some of these -in my opinion unavoidable- issues]

Bottom line: There are reasons to use traits in lack of alternatives,
but if I can avoid it by using self-contained entities (objects) I'd
rather not.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)

keith1y
So you dont like traits much?

I agree there is no reason to apply a paradigm where it doesnt fit.

But then I dont know enough about tweak to know whether it would fit or
not. (see below)

a small question though...

How come I get a longer and quicker reply in a rant as a result of one
sentence in an email to squeak-dev, than I got from two specific
requests on Tweak mailing list which was dead for months. The first
dated (26 May) asking for a current update and strategic direction
progress information, and the second asking what I could do that would
be of assistance in porting morphic tools to tweak which received no
replies.

best regards

Keith

>
>
>
> Bottom line: There are reasons to use traits in lack of alternatives,
> but if I can avoid it by using self-contained entities (objects) I'd
> rather not.
>
> Cheers,
>   - Andreas
>
>


       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

Reply | Threaded
Open this post in threaded view
|

Re: Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)

Andreas.Raab
Keith Hodges wrote:
> So you dont like traits much?

Well, I don't know really. I had much hopes for it but the results do
not seem to match my expectations. BTW, just in case you didn't know:
this project started as a discussion between Nathanael and myself, and
to me, although Nathanael solved the harder problem he also solved the
less interesting problem. I'm still looking for more real world examples
but to me it seems as if the biggest problem with traits is that they're
the logical equivalent of C's #include statement. This may sound harsh
but when you think about it, it is very, very similar. And of course
that has some uses for sure, but it often creates more problems than it
solves. In *particular* when it is applied just because it seems like a
good idea in general without having specific reasons for using it.
That's mostly why I reacted to your email, because my instant reaction
was hell, no, you wouldn't want to use traits instead of delegation in
such a situation unless you have to (same goes for subclassing btw).

> a small question though...
>
> How come I get a longer and quicker reply in a rant as a result of one
> sentence in an email to squeak-dev, than I got from two specific
> requests on Tweak mailing list which was dead for months. The first
> dated (26 May) asking for a current update and strategic direction
> progress information, and the second asking what I could do that would
> be of assistance in porting morphic tools to tweak which received no
> replies.

There was a period earlier this year (and I think it was the period you
are describing) where I didn't get email from the Tweak list. Not sure
why this happened but when I sent a test email (let me check ... yeah
that was on June 26th) everything seemed to work (again?). Before the
last message I have is from february. So there were probably some emails
inbetween that I didn't see.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)

keith1y
Thank you for the explanation.

I am afraid that this led to my losing interest in tweak for the time
being, because the list did indeed seem pretty dead.

Keith
>  from february. So there were probably some emails inbetween that I
> didn't see.
>
> Cheers,
>   - Andreas
>
>

Send instant messages to your online friends http://uk.messenger.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Re: A process proposal for 3.10

keith1y
In reply to this post by Andreas.Raab
I would like to know how the test server idea would work in practice?
What would it do. Would it be possible to have a one paragraph spec of
such a server.

This is my own idea as to how to informally collect fixes and image
enhancements in a decentralized manner, while the release team take on
bigger things in parallel.

The aim is to attempt to obtain potentially the same end result as the
'update stream' but with the possibility of full community
participation. One would also hope that we can lighten the burden of the
release team so as to free them up to do more radical improvements.
Rather than a test server, this idea gives everyone the ability to test
a known configuration against their hardware and their own favourite
packages.

1. Begin with a known starting image, be it a Kernal image or an RC2.

2. Present a wiki page consisting of an install script

This wiki needs the following features
- full support for "history of page" and authors of edits.
- diffs between page versions (if possible)
- wiki links within preformatted text for the script to be annotated.

example script (e.g.
http://smallwiki.unibe.ch/smallwiki/pier/installationofseasidemagmaandpier/ 
)

3. Allow updates to be monticello, sm, or change set based, or some
other alternative. i.e. anything that may be found on mantis.
Allow/Prefer the install script to directly download source from the
mantis file repository (possible?)

4. A user can register with the wiki, adding their proposed submission
to 3.9.? to the script page.

4. Testers can then Start with the prescribed image, select the whole
script from the wiki page, and update their local image.
    - Run the tests which (hopefully) come with the updates
    - Test their own packages/projects with the proposed image.

5. Improve SUnit slightly to enable publishing more than a single test
suite. This allows a TestCase class to publish multiple suites of tests.
Then you can run all the #tests and the #testsFor39Only but not the
#testsFor38Only.

6. Each item in the script wiki page may be marked as a link for
feedback, or perhaps to the appropriate mantis page.

7. Have some criteria that we would like submissions to meet, and be
willing to allow our submissions to be commented out and marked as not
ready yet by benevolent testers.
- insufficient test coverage
- breaks something
- tests fail
etc.

8. Be nice to each other

---
If this process can informally chug along while the 3.10 team is
forming. I propose that they then be freer to take on these "big dont
fit monticello tasks on".

The release team begins with the same starting point as this informal
process. When their change is done. They can test it against the
informal process script. They can then post the new image and users can
see how the fix install script and the tests handle the new image. Then
the process of integrating the fixes to the new image can if necessary
be a shared responsibility.

Alternatively the release team can review the current status of the
informal process, declare that a new release, and begin their "big task"
from there, at the same time beginning a new wiki page install script to
harvest more fixes in parallel.

For loadable packages, package universes seem like a viable option.
Again the idea is to raise the visibility of the process and the ability
to involve as many people as want to get involved at whatever level of
commitment they can offer, as and when. I am not sure how package
universes would handle variants. For example, there is Pier, Pier with
Unix Security, Pier with ACL Security, Pier with 4 different Persistency
schemes, and My own snazzy-pier. Those would have to be marked as
mutually exclusive within the universe.

does this idea sound like it has practical potential or am I musing far
too idealistically?


Keith


 






Send instant messages to your online friends http://uk.messenger.yahoo.com 

1234567