Hi folks,
I'm neither a proponent nor an opponent of removing Etoys, Morphic, etc.
Instead, I'm wondering what this debate might be about (myth? conspiracy? who in squeak-dev knows ;-)
Very recently Damien's Squeak-dev image has shown that if there is demand, there comes supply. The same is possibile with Etoys, Morphic, etc. After all, Squeak and ingredients are made of software; neither seat belts nor batteries are included.
So the one and only questions that I hope remains is this: is someone willing to remove Etoys, Morphic, etc such that there be one .image without it and one .image in which it is pre-loaded. This is like if the same factory outputs new, diversified products: always a great idea and always improves the reputation!
And if there is no one who effectively *does* it, let _whatever_it_is_ rot in the image-until someone must fix things in order to support her/his own stuff. Whether you like it or not, the latter happens anyway.
I firmly believe that this community is not capable of doing anything else.
That's my CHF 0.05
/Klaus
Hi Klaus,
What you say is exactly what we're doing.
My problem is that rotten stuff smells bad. Squeak used to be better than that.
I've already removed etoys. You can check http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html . But I won't work on making it loadable again (I already said why).
I believe the standard image badly needs cleaning.
Cheers, Juan Vuletich
Hi folks, ... And if there is no one who effectively *does* it, let _whatever_it_is_ rot in the image-until someone must fix things in order to support her/his own stuff. Whether you like it or not, the latter happens anyway.
I firmly believe that this community is not capable of doing anything else.
Hi Juan,
on Wed, 25 Oct 2006 17:13:24 +0200, you wrote:
Hi Klaus,
What you say is exactly what we're doing.
And therefore I hereby proclaim you are the hero of the day!
Not because you do what I was talking about but because you *do* *it* regardless of me talking!
My problem is that rotten stuff smells bad. Squeak used to be better than that.
And I very much appreciate your effort.
I've already removed etoys. You can check http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html . But I won't work on making it loadable again (I already said why).
Time will come, time will show, who knows who will load it again.
/Klaus
I believe the standard image badly needs cleaning.
Cheers, Juan Vuletich
Hi folks, ... And if there is no one who effectively *does* it, let _whatever_it_is_ rot in the image-until someone must fix things in order to support her/his own stuff. Whether you like it or not, the latter happens anyway.
I firmly believe that this community is not capable of doing anything else.
Hi Klaus,
Hi Juan,
on Wed, 25 Oct 2006 17:13:24 +0200, you wrote:
Hi Klaus,
What you say is exactly what we're doing.
And therefore I hereby proclaim you are the hero of the day!
Not because you do what I was talking about but because you *do* *it* regardless of me talking!
If you're just making fun of me, that's ok. But if you mean this, let me clarify. What you said: 'let it rot' is what we (the Squeak community) are doing. What I answer is: This is not good enough. Squeak should not include rotten stuff. (Maybe SqueakMap could, though.)
My problem is that rotten stuff smells bad. Squeak used to be better than that.
And I very much appreciate your effort.
Thanks!
I've already removed etoys. You can check http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html . But I won't work on making it loadable again (I already said why).
Time will come, time will show, who knows who will load it again.
/Klaus
Yeah, who knows.
Cheers, Juan Vuletich
On Wed, 25 Oct 2006 17:59:14 +0200, Juan wrote:
Hi Klaus, Klaus wrote:
Hi Juan, on Wed, 25 Oct 2006 17:13:24 +0200, you wrote:
Hi Klaus,
What you say is exactly what we're doing.
And therefore I hereby proclaim you are the hero of the day!
Not because you do what I was talking about but because you *do* *it* regardless of me talking!
If you're just making fun of me, that's ok.
Believe me: when I write exclamation marks sans smiley then I don't make fun of you!
But if you mean this, let me clarify. What you said: 'let it rot' is what we (the Squeak community) are doing.
Then you and me would have a subtle difference: I cannot say that we are doing it, because that would come close to a contradiction. Or, perhaps we mean "we do" in one case and different "we do" in the other case.
Unencrypted I mean: yes, the community lets it rot (it *does* it). And no, you attempt to do something against that (you *do* it). Strange words; programming is easier ;-)
What I answer is: This is not good enough. Squeak should not include rotten stuff.
Right you are. But whenever I find rot and: [need to use it anyway] then I *must* do something.
---------break-----------
Since I firmly believe that almost nobody reads our conversation, let me take the opportunity and state the following: Squeak community does not lack developer skills. Squeak community lacks managerial skills, badly. And, Squeak community does not need organizational skills.
/Klaus
(Maybe SqueakMap could, though.)
My problem is that rotten stuff smells bad. Squeak used to be better than that.
And I very much appreciate your effort.
Thanks!
I've already removed etoys. You can check http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html . But I won't work on making it loadable again (I already said why).
Time will come, time will show, who knows who will load it again.
/Klaus
Yeah, who knows.
Cheers, Juan Vuletich
Hi Klaus,
Klaus wrote:
Believe me: when I write exclamation marks sans smiley then I don't make fun of you!
But if you mean this, let me clarify. What you said: 'let it rot' is what we (the Squeak community) are doing.
Then you and me would have a subtle difference: I cannot say that we are doing it, because that would come close to a contradiction. Or, perhaps we mean "we do" in one case and different "we do" in the other case.
Unencrypted I mean: yes, the community lets it rot (it *does* it). And no, you attempt to do something against that (you *do* it). Strange words; programming is easier ;-)
:) That was fun.
What I answer is: This is not good enough. Squeak should not include rotten stuff.
Right you are. But whenever I find rot and: [need to use it anyway] then I *must* do something.
Yes. I hope you trigger a reaction on somebody with this!
---------break-----------
Since I firmly believe that almost nobody reads our conversation, let me take the opportunity and state the following: Squeak community does not lack developer skills. Squeak community lacks managerial skills, badly. And, Squeak community does not need organizational skills.
/Klaus
Cheers, Juan Vuletich
jvuletich@dc.uba.ar puso en su mail :
Yes. I hope you trigger a reaction on somebody with this!
Juan:
I read your page and surprise me what you talk about 3.7.
I have from last summer a prototype SqueakLight 3.8.1 , 7.4 mb and 1054 classes.
Is started from regular Squeak3.8-6665-basic ( very different of my current development), and don't have FFI,Speech, Nebraska, Etoys, Flaps.
It's builded essentially following yours works (and a couple of my tricks).
I don't remember if us talk about this , so I wish you (and others ) know about this for feedback.
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
Hi Edgar,
I'm more focused in my Morphic 3.0 project than on keeping my image updated to the last version.
Thanks anyway.
Cheers, Juan Vuletich
jvuletich@dc.uba.ar puso en su mail :
Yes. I hope you trigger a reaction on somebody with this!
Juan:
I read your page and surprise me what you talk about 3.7.
I have from last summer a prototype SqueakLight 3.8.1 , 7.4 mb and 1054 classes.
Is started from regular Squeak3.8-6665-basic ( very different of my current development), and don't have FFI,Speech, Nebraska, Etoys, Flaps.
It's builded essentially following yours works (and a couple of my tricks).
I don't remember if us talk about this , so I wish you (and others ) know about this for feedback.
Edgar
Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
jvuletich@dc.uba.ar puso en su mail :
Hi Edgar,
I'm more focused in my Morphic 3.0 project than on keeping my image updated to the last version.
Thanks anyway.
Cheers, Juan Vuletich
Yes. It's more productive and important. You know I always ready for work , don't you ?
Edgar
PD) And remember Spanish said "Ladran Sancho , señal que cabalgamos " :=)
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Thanks Edgar!
Of course you, and everybody else is invited to help. You can read a bit and download from www.jvuletich.org . More to come!
Currently I'm working on the coordinate systems. I'd like to discuss about the ideas and the design if you're interested.
Cheers, Juan Vuletich
jvuletich@dc.uba.ar puso en su mail :
Hi Edgar,
I'm more focused in my Morphic 3.0 project than on keeping my image updated to the last version.
Thanks anyway.
Cheers, Juan Vuletich
Yes. It's more productive and important. You know I always ready for work , don't you ?
Edgar
PD) And remember Spanish said "Ladran Sancho , señal que cabalgamos " :=)
Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Hello Klaus,
KDW> Instead, I'm wondering what this debate might be about (myth? conspiracy? KDW> who in squeak-dev knows ;-)
I think this debate is about what me and some (non programming) friends call "killer arguments", arguments that kill the debate.
I's a strong word and I don't know if it is used elsewhere. It does _not_ imply an intention to shut up the other side but it might have that effect. In the context of the debate the killer argument is valid.
KDW> So the one and only questions that I hope remains is this: is someone KDW> willing to remove Etoys, Morphic, etc such that there be one .image KDW> without it and one .image in which it is pre-loaded.
That's oversimplifying because ..
KDW> And if there is no one who effectively *does* it, let _whatever_it_is_ rot KDW> in the image-until someone must fix things in order to support her/his own KDW> stuff. Whether you like it or not, the latter happens anyway.
.... a rotting morpic would make that image more or less useless :-)
Best regards,
Herbert mailto:herbertkoenig@gmx.net
Hi Herbert,
on Wed, 25 Oct 2006 17:14:14 +0200, you wrote:
Hello Klaus,
KDW> Instead, I'm wondering what this debate might be about (myth? conspiracy? KDW> who in squeak-dev knows ;-)
I think this debate is about what me and some (non programming) friends call "killer arguments", arguments that kill the debate.
I's a strong word and I don't know if it is used elsewhere.
Neither do I, so it's a bit mystical, isn't it ;-)
It does _not_ imply an intention to shut up the other side but it might have that effect.
OT: agreed and the consequence is a massive loss of reputation (not that we've ever seen so here in squeak-dev, haven't we :|
In the context of the debate the killer argument is valid.
NP and I agree with this your explanation.
KDW> So the one and only questions that I hope remains is this: is someone KDW> willing to remove Etoys, Morphic, etc such that there be one .image KDW> without it and one .image in which it is pre-loaded.
That's oversimplifying because ..
KDW> And if there is no one who effectively *does* it, let _whatever_it_is_ rot KDW> in the image-until someone must fix things in order to support her/his own KDW> stuff. Whether you like it or not, the latter happens anyway.
.... a rotting morpic would make that image more or less useless :-)
Le'me repeat: until someone must fix things in order to support HER/HIS own stuff. But yes I have to agree that a rotting morphic would have such consequences.
Thanks for taking care.
/Klaus
Best regards,
Herbert mailto:herbertkoenig@gmx.net
I'm neither a proponent nor an opponent of removing Etoys, Morphic, etc> Instead, I'm wondering what this debate might be about (myth? conspiracy? who in squeak-dev knows ;-)
Very recently Damien's Squeak-dev image has shown that if there is demand, there comes supply. The same is possibile with Etoys, Morphic, etc. After all, Squeak and ingredients are made of software; neither seat belts nor batteries are included.
So the one and only questions that I hope remains is this: is someone willing to remove Etoys, Morphic, etc such that there be one .image without it and one .image in which it is pre-loaded. This is like if the same factory outputs new, diversified products: always a great idea and always improves the reputation!
And if there is no one who effectively *does* it, let _whatever_it_is_ rot in the image-until someone must fix things in order to support her/his own stuff. Whether you like it or not, the latter happens anyway.
I firmly believe that this community is not capable of doing anything else.
Hi Klaus, even now is possible to remove Morphic, MVC, eToys etc. from the newest images and load it back, see KernelImage and RestOfSqueak package. Everybody can make step from the endless discussions and contribute with more than several cents :-)
-- Pavel
Hi!
Ok, let's back up a bit. If I got it right it is all about deciding on one of these three ways forward:
1. Stay as now. Keep eToys in Morphic and just live with it, even though the principal maintainers of eToys (Michael? Yoshiki? etc) actually tend to do their work in the Squeakland arena. And even though most with a clue thinks it is a real mess.
2. Throw out eToys (typically using Juan's code - perhaps not as brutal though - flaps might be nice to have around IMHO) and just face the fact that it will at least *initially* not be reloadable back in. Direct users of eToys to the Squeakland image etc in a more clear way, for example by adjusting www.squeak.org to be more clear on this. And then see if anyone steps up making it reloadable, but do not expect it to happen.
3. Make eToys reloadable (and throw it out), of course, this is the "best" route. But who will do it? And if noone steps up to do it, is it okay to pick #2 above instead of #1?
regards, Göran
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
goran@krampe.se puso en su mail :
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Pavel do a quantum leap on shrinking business with his KernelImage.
I repeat here what I said before.
KernellImage with Network , Compression etc (the last what Pavel publish) should be the stone on the rest of 3.10 building rest.
If the fashion now is doing new sources again, then 3.10 sources should be of this setup.
But RestOfSqueak needs partitioning or you don't get something different if apply other ripping technique (his is better and cleaner).
Speech, Nebraska also should go
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
Hi Göran,
on Wed, 25 Oct 2006 14:49:09 +0200, you wrote:
Hi!
Ok, let's back up a bit. If I got it right it is all about deciding on one of these three ways forward:
...
- Make eToys reloadable (and throw it out), of course, this is the
"best" route. But who will do it? And if noone steps up to do it, is it okay to pick #2 above instead of #1?
...
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Well, *this* part of the debate made me "tout" the "conspiracy" question in this thread :|
Did you read Pavel's response to this thread. What he says there is, by the time of this writing, (computer-) ages long known to the community: removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse me for the emphasis).
So, how come you still question it? What is it that I don't understand, what exactly are the unknown requirements (and who does require)?
/Klaus
Il giorno gio, 26/10/2006 alle 06.33 +0200, Klaus D. Witzel ha scritto:
Hi Göran,
on Wed, 25 Oct 2006 14:49:09 +0200, you wrote:
Hi!
Ok, let's back up a bit. If I got it right it is all about deciding on one of these three ways forward:
...
- Make eToys reloadable (and throw it out), of course, this is the
"best" route. But who will do it? And if noone steps up to do it, is it okay to pick #2 above instead of #1?
...
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Well, *this* part of the debate made me "tout" the "conspiracy" question in this thread :|
Did you read Pavel's response to this thread. What he says there is, by the time of this writing, (computer-) ages long known to the community: removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse me for the emphasis).
So, how come you still question it? What is it that I don't understand, what exactly are the unknown requirements (and who does require)?
From what I've understood, Pavel has split the 3.9 image in two: a
Kernel image which contains the basic system and a RestOfSqueak that has everything else. But it seems to me that the RestOfSqueak is as monolithic as the standard image: you can't reload Morphic only without loading Etoys, Nebraska etc.
Pavel, am I correct?
Giovanni
Well, *this* part of the debate made me "tout" the "conspiracy" question in this thread :|
Did you read Pavel's response to this thread. What he says there is, by the time of this writing, (computer-) ages long known to the community: removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse me for the emphasis).
So, how come you still question it? What is it that I don't understand, what exactly are the unknown requirements (and who does require)?
From what I've understood, Pavel has split the 3.9 image in two: a
Kernel image which contains the basic system and a RestOfSqueak that has everything else. But it seems to me that the RestOfSqueak is as monolithic as the standard image: you can't reload Morphic only without loading Etoys, Nebraska etc.
Pavel, am I correct?
Giovanni
Hi Giovanni,
youre right, the RoS is monolithic package and it's not possible to load Morphic and don't load eToys with it. But we will remove network, compression, MC kernel etc. from it because this packages are already independent. This process is done "from bottom". Removing of Nebraska, eToys and others should be done "from top" but RoS shows initialization process of Morphic etc. so it can make removing of this packages more easy.
I hope that we will be able to convert license of whole KernelImage code and enable to load all rest "non-free" content from Internet. That is another important purpose of RoS.
-- Pavel
Pavel Krivanek puso en su mail :
it's not possible to load Morphic and don't load eToys with it.
It's possible, but not easy and not now.
But we will remove network, compression, MC kernel etc. from it because this packages are already independent.
Without network, compression and a few more , Kernel is impractical. Once cleaned, why rip first for loading latter ? You last should be 3.10 start point and .sources produced for this. And the loaded Rest of Squeak , ready to run , should become SqueakMinimal.
load all rest "non-free" content from Internet.
What part is not free ? I hope not endless license thread....
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
On 10/26/06, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
Pavel Krivanek puso en su mail :
it's not possible to load Morphic and don't load eToys with it.
It's possible, but not easy and not now.
But we will remove network, compression, MC kernel etc. from it because this packages are already independent.
Without network, compression and a few more , Kernel is impractical. Once cleaned, why rip first for loading latter ?
You will have the kernel image and the set of basic packages (compression, network, MC). This packages must be loaded from files. Then you will have prepared image with this basic packages that will be able to load RestOfSqueak and other packages. I was talking about the fact, that the current RoS includes this basic packages too.
You last should be 3.10 start point and .sources produced for this. And the loaded Rest of Squeak , ready to run , should become SqueakMinimal.
No, the starting point for the version 3.10a must be standard 3.9 image. Final version can be the the UI-less image but we firstly have to prepare full image for it.
load all rest "non-free" content from Internet.
What part is not free ? I hope not endless license thread....
AFIK the problematic part of current license are for example "Export Law Assurances" that prohibit usage of Squeak by Cuban etc.
-- Pavel
Hi Giovanni,
on Thu, 26 Oct 2006 10:39:50 +0200, you wrote:
Il giorno gio, 26/10/2006 alle 06.33 +0200, Klaus D. Witzel ha scritto:
...
From what I've understood, Pavel has split the 3.9 image in two: a Kernel image which contains the basic system and a RestOfSqueak that has everything else. But it seems to me that the RestOfSqueak is as monolithic as the standard image: you can't reload Morphic only without loading Etoys, Nebraska etc.
Pavel, am I correct?
And now that I've seen Pavel's corresponding response I think that I understand better. Thank you for asking the clearing question.
Giovanni
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
If there isn't anybody suggesting that she/he will divide Morphic by Etoys, starting with 3.9 and targeting for example 3.10 or 4.0, then please treat these questions as 100%[tm] rhetoric, thank you.
/Klaus
Am 26.10.2006 um 14:48 schrieb Klaus D. Witzel:
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
Etoys support is in the Morphic base classes, and even in its design - Morphic really only was made to support Etoys. Now, if you want a lean clean Morphic that just supports "business widgets" you have to rip everything related to Etoys out. I think that's what Juan did - but since the base is missing you cannot go back.
- Bert -
Hi Bert,
Just a comment. My motivation is not "business widgets", but "programmer's morphs". I want to do stuff like EnvelopeEditorMorph. And of course, my Morphic 3.0 project.
Cheers, Juan Vuletich
Am 26.10.2006 um 14:48 schrieb Klaus D. Witzel:
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
Etoys support is in the Morphic base classes, and even in its design
- Morphic really only was made to support Etoys. Now, if you want a
lean clean Morphic that just supports "business widgets" you have to rip everything related to Etoys out. I think that's what Juan did - but since the base is missing you cannot go back.
- Bert -
Hi Juan and all!
I just want to say I am 100% with you on all this.
Could you possibly (as you probably know Morphic/eToys better than most of us) list the parts that we could "decide" about leaving in or ripping out? Lex started a list, but he also included some things that I had not thought were included (like ImageSegment for example).
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan present - he also remarked that Morphic is indeed quite small - if you consider only Morphic itself. But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result etc. We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I think it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Could you possibly (as you probably know Morphic/eToys better than most of us) list the parts that we could "decide" about leaving in or ripping out? Lex started a list, but he also included some things that I had not thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put it there!
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!) - Tile based programming system. Yes. The central part of eToys. - Halos. No. Halos are key to Morphic. - Named morph search. No. I'd put this in 'MorphicExtras'. - Uniclasses. Yes. They were implemented in Squeak to support eToys. And they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me. - SmartRefStream and ImageSegments. No! Why would they? - Projects and saving projects. No. - Paint tool. No. - Flaps. No.
Anyway, I don't want to say what should be removed and what should not. But clearly in my reduced 3.7 image, I removed lots of stuff besides eToys. Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan present
- he also remarked that Morphic is indeed quite small - if you consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I think it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is my vision for morphic improvement. Check www.jvuletich.org !
Cheers, Juan Vuletich
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion again. :)
Juan Vuletich jvuletich@dc.uba.ar wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to feel that people agree - and as I said I am all with you for three major reasons:
1. You are a doer. You have already proved that. 2. You are committed to this. We don't have many people committed to Morphic development (on this low level) these days and I value each and every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve something and has the above 3 things, then there is not much to argue about - I say go. :)
Could you possibly (as you probably know Morphic/eToys better than most of us) list the parts that we could "decide" about leaving in or ripping out? Lex started a list, but he also included some things that I had not thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put it there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support eToys. And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what should not. But clearly in my reduced 3.7 image, I removed lots of stuff besides eToys. Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan present
- he also remarked that Morphic is indeed quite small - if you consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I think it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is my vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
1. Morphic is proven to work. But seems to be in a mess and thus is brittle and also not maintained much because people can't get a grip and are also appalled about lots of the stuff that is in there today (eToys related I think). So it is sitting still today. Btw, this is MY primary objective behind getting eToys out - because I want a more attractive Morphic that then might get maintained instead of just sit there.
2. Tweak came along and people interested in these things probably decided to hang around and wait to see if Tweak would end up replacing Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new ideas etc, but perhaps it is time to grab what we have and make the best of it instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do not know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support in this. And I hope that Juan is willing to take on the Steward role for Morphic together with a few more brave souls with an interest in Morphic (there are a few I think). I bet perhaps even Dan Ingalls could be interested, but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
I don't support what Juan's proposal as stated. I'd like to hear why you, Juan or anyone else don't agree with what Jecel/Guy proposed
if we can unload eToys but not load it back, then let's just include eToys
in the
full image that we distribute and allow everyone the one way option of removing it.
which mirrors what I said in "Smalltalk Reloaded". More specifically, do folks supporting Juan's proposal disagree with my statement:
All other considerations aside, if e-toys is unloaded from the main
distribution and cannot be easily reloaded by a new Squeaker,there will be confusion and for many disappointment and/or some other non-positive experience.
For me it's not that I'm opposed to a cleaner Morphic, I just don't want to add stumbling blocks for wider acceptance at a time when eToy images are getting more and more visibility. Sure it would be nice to see the default image with a cleaner Morphic but not at any price - especially since Spoon is coming. It's not clear to me whether the upside of a cleaner Morphic will be that great or long lasting because I believe we're in the early stages of a big paradigm shift in which Croquet UIhttp://www.meshverse.com/2006/10/18/the-64-billion-dollar-question-reloaded/(oh where is Wicket?) is where the action is. In this new paradigm, I don't know whether a cleaner Morphic is going to have advantages over Tweak.
Cheers,
Laurence
On 10/31/06, goran@krampe.se goran@krampe.se wrote:
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion again. :)
Juan Vuletich jvuletich@dc.uba.ar wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to feel that people agree - and as I said I am all with you for three major reasons:
- You are a doer. You have already proved that.
- You are committed to this. We don't have many people committed to
Morphic development (on this low level) these days and I value each and every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve something and has the above 3 things, then there is not much to argue about - I say go. :)
Could you possibly (as you probably know Morphic/eToys better than
most
of us) list the parts that we could "decide" about leaving in or
ripping
out? Lex started a list, but he also included some things that I had
not
thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put it there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support eToys. And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what should not. But clearly in my reduced 3.7 image, I removed lots of stuff besides
eToys.
Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan
present
- he also remarked that Morphic is indeed quite small - if you
consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result
etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I
think
it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is my vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
- Morphic is proven to work. But seems to be in a mess and thus is
brittle and also not maintained much because people can't get a grip and are also appalled about lots of the stuff that is in there today (eToys related I think). So it is sitting still today. Btw, this is MY primary objective behind getting eToys out - because I want a more attractive Morphic that then might get maintained instead of just sit there.
- Tweak came along and people interested in these things probably
decided to hang around and wait to see if Tweak would end up replacing Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new ideas etc, but perhaps it is time to grab what we have and make the best of it instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do not know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support in this. And I hope that Juan is willing to take on the Steward role for Morphic together with a few more brave souls with an interest in Morphic (there are a few I think). I bet perhaps even Dan Ingalls could be interested, but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
Hi!
"Laurence Rozier" laurence.rozier@gmail.com wrote:
I don't support what Juan's proposal as stated. I'd like to hear why you, Juan or anyone else don't agree with what Jecel/Guy proposed
Ok, let me quote so that you don't need to skip back, Jecel wrote:
This is a plan that is practical and which I fully support: if we can unload eToys but not load it back, then let's just include eToys in the full image that we distribute and allow everyone the one way option of removing it. I don't mind at all eliminating the Flash logo, the welcome windows and other stuff every time I begin working with a newly downloaded image. The fact that I can't get any of these easily back if I want has never been a problem since I could just start over from a clean image.
Sure, a reloadable eToys would be even better but I doubt it will happen.
My problem with that proposal is that it means that Morphic is actually not cleaned up - it would just persist as it is today.
It also means that any cleanup that such a removal-script would do in itself (and Juan has already said that such a delta script is NOT easy to maintain IIRC) would actually fork Morphic itself - people writing code on top of Morphic in the future would have to wonder if it is being run in the image-with-a-clean-morphic-without-etoys or in the image-with-etoys.
In other words, the above sounds like either "status quo" or a fork of Morphic. I dislike both. :)
Note that eToys is not a clean "addon" on top of Morphic - it is in fact an intertwined mess with Morphic methods including lots of logic specifically for eToys. So if you clean out eToys you end up with a different Morphic.
I think it would be much better to lift the burden of eToys, let Juan do his magic and give us an improved Morphic in the baseline - let anyone step up and retrofit eToys on top of that as a cleaner addon, or not. In either case - Squeakland is the place to go for eToys and has always been.
if we can unload eToys but not load it back, then let's just include eToys
in the
full image that we distribute and allow everyone the one way option of removing it.
which mirrors what I said in "Smalltalk Reloaded". More specifically, do folks supporting Juan's proposal disagree with my statement:
All other considerations aside, if e-toys is unloaded from the main
distribution and cannot be easily reloaded by a new Squeaker,there will be confusion and for many disappointment and/or some other non-positive experience.
I am not sure I agree with this. Thing is, eToys in the "main distro" (squeak.org) has been relatively unmaintained for some time I think (others with better knowledge might disagree). I personally would not trust eToys in official Squeak to work as one would expect it to work relative to the Squeakland image.
And this goes especially for 3.9 and beyond, since Squeakland is 3.8 based.
So to rephrase myself - if we aim to minimize the risk of a non-positive experience of eToys I think we should clearly and distinctly direct people towards the Squeakland distro directly from the main page of Squeak.org for those people looking specifically for eToys.
For me it's not that I'm opposed to a cleaner Morphic, I just don't want to add stumbling blocks for wider acceptance at a time when eToy images are getting more and more visibility. Sure it would be nice to see the default image with a cleaner Morphic but not at any price - especially since Spoon is coming.
Mmmm, I don't see how Spoon relates technically to a cleanup of Morphic. I consider those two efforts quite separate.
It's not clear to me whether the upside of a cleaner Morphic wil= l be that great or long lasting because I believe we're in the early stages o= f a big paradigm shift in which Croquet UIhttp://www.meshverse.com/2006/10/18/the-64-billion-dollar-question-reloa= ded/(oh where is Wicket?) is where the action is. In this new paradigm, I don't kno= w whether a cleaner Morphic is going to have advantages over Tweak.
It is not so much about which is "best". Tweak is radically different, and many of those ideas are great (AFAICT). I have on the other hand heard people moaning about it being hard to debug and as we all know - it is not "ready" for Squeak.org yet. Again AFAIK.
I don't think we should sit around and wait for Tweak to save the day - we have already done so to a certain extent and I think we should stop doing that. Morphic is nice and it can be small and lean too. Juan offers to give us that and I think that is great.
Also - yes, the Squeaklanders did spend time to update eToys in 3.8 with the changes that were done in the Squeakland image. But will they keep that up? I am very unsure about that, would be neat to hear more from Michael Rueger (or someone) on that issue.
If they indeed have an intention of maintaining eToys in 3.9 and beyond (which I doubt) then that would indeed make the question more complicated.
Cheers,
Laurence
regards, Göran
PS. I don't claim the almighty truth - these are just my opinions based on my perceptions and hunches. :)
Hi Goran,
I don't. I am with Guy, Jecel, Klaus and probably many others.
On Oct 31, 2006, at 1:15 PM, goran@krampe.se wrote:
Hi!
"Laurence Rozier" laurence.rozier@gmail.com wrote:
I don't support what Juan's proposal as stated. I'd like to hear why you, Juan or anyone else don't agree with what Jecel/Guy proposed
Ok, let me quote so that you don't need to skip back, Jecel wrote:
This is a plan that is practical and which I fully support: if we can unload eToys but not load it back, then let's just include eToys in the full image that we distribute and allow everyone the one way option of removing it. I don't mind at all eliminating the Flash logo, the welcome windows and other stuff every time I begin working with a newly downloaded image. The fact that I can't get any of these easily back if I want has never been a problem since I could just start over from a clean image.
Sure, a reloadable eToys would be even better but I doubt it will happen.
+1
My problem with that proposal is that it means that Morphic is actually not cleaned up - it would just persist as it is today.
Yes, but as long as we don't have sth. cleaned up, I don't see the point in removing the part of Squeak which will be actually the killer application of Squeak - being installed on millions of machines on the OLPC. Several others - newbies and old-time squeakers - have mentioned their interest in Etoys being included in the main squeak-dev. If people/ kids using the OLPC or Squeaklanders come to squeak-dev and see this essential part removed, they will be puzzled about it and we will have difficulties to explain the issue to them.
I also strongly support the view of Ron Teitelbaum who thinks removing Etoys to be a fork. Marcus was able to rip of some changesets for speeding up Squeak 3.9 for inclusion in the olpc- version, I doubt that these synergetic effects will become easier in the future by removing Etoys.
Show us an improved version of Etoys which can substitute the current one and I am all for _replacing_ the current with a new, tidier, and _faster_ one than we currently have. Let the "gothic" people build their streamlined minimal cathedrals as easy as possible, but don't forget us barrock, playfull ones, until we come up with something truly modern.
Concerning Juan's point
Removing eToys implies deleting "eToys awareness" in lots of methods that would not be deleted. Even several instance variables as in MorphExtension. I don't know how to offer the user the option for removing it, let alone keep that option properly maintained in future Squeak versions.
I think, that overwriting would be allowed in the removal process. Maintaining Squeak _with_ some form of Etoys is easier and more important than maintaining it without them. And as Bert stated, making Etoys reloadable is a hard if not impossible task.
Cheers,
Markus
goran@krampe.se wrote:
This is a plan that is practical and which I fully support: if we can unload eToys but not load it back, then let's just include eToys in the full image that we distribute and allow everyone the one way option of removing it. I don't mind at all eliminating the Flash logo, the welcome windows and other stuff every time I begin working with a newly downloaded image. The fact that I can't get any of these easily back if I want has never been a problem since I could just start over from a clean image.
Sure, a reloadable eToys would be even better but I doubt it will happen.
My problem with that proposal is that it means that Morphic is actually not cleaned up - it would just persist as it is today.
as I see it, my problem with *your* proposal is that we need to dump eToys in order to gain a cleaned-up Morphic.
to me "code cleanup" does not mean that any functionality is lost. only that the code is cleaned up. maybe I am too simple-minded :)
so your proposal is to kill etoys, which currently work just fine and is used by many people, for the only reason that it does not seem to be easy to clean it up. we had "if it's not broken, don't fix it", now it seems we have "if it's not broken but ugly, then just kill it".
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Stef
Hi folks!
=?ISO-8859-1?Q?St=E9phane_Rollandin?= lecteur@zogotounga.net wrote:
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Ok, I have for various reasons decided to drop out of this discussion.
I don't think I will be able to make my arguments and views any more clear than the "nonsense" I have produced so far, and since I seem to be the only one publically supporting Juan (perhaps there were a few more) I am clearly outnumbered. And I don't feel encouraged to keep discussing it this particular way, no - I don't know why we should destroy Squeak btw.
And I should be doing other things anyway. ;)
The rest of squeak-dev will simply have to (and the board IMHO) figure this one out.
regards, Göran
PS. I am kinda tired of the fact that hardly any change can be proposed in this community without having tons of arguments raised against it. Sure, this particular case is harder to judge - but the fact remains, how can we keep all the Juans out there interested if they only meet resistance when offering their time and energy? Sure, the medicine does not taste good - dumping eToys hurts, I know that. But this problem is generic. And no, don't bother replying to me specifically about this because I don't have the energy to discuss anything right now.
On 10/31/06, goran@krampe.se goran@krampe.se wrote:
Hi folks!
PS. I am kinda tired of the fact that hardly any change can be proposed in this community without having tons of arguments raised against it. Sure, this particular case is harder to judge - but the fact remains, how can we keep all the Juans out there interested if they only meet resistance when offering their time and energy? Sure, the medicine does not taste good - dumping eToys hurts, I know that. But this problem is generic. And no, don't bother replying to me specifically about this because I don't have the energy to discuss anything right now.
Hi Goran, I know that you don't want to continue this, and that you don't want anyone to reply but anyways :)
I think that we should stop trying to try to reach concensus on these things. Lets allow to have multiple squeak-dev images, don't make any one official, just make all equally public with good descriptions and be done with it. My 0.02 cents
goran@krampe.se wrote:
Hi folks!
=?ISO-8859-1?Q?St=E9phane_Rollandin?= lecteur@zogotounga.net wrote:
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Ok, I have for various reasons decided to drop out of this discussion.
I don't think I will be able to make my arguments and views any more clear than the "nonsense" I have produced so far, and since I seem to be the only one publically supporting Juan (perhaps there were a few more) I am clearly outnumbered. And I don't feel encouraged to keep discussing it this particular way, no - I don't know why we should destroy Squeak btw.
And I should be doing other things anyway. ;)
The rest of squeak-dev will simply have to (and the board IMHO) figure this one out.
regards, Göran
PS. I am kinda tired of the fact that hardly any change can be proposed in this community without having tons of arguments raised against it. Sure, this particular case is harder to judge - but the fact remains, how can we keep all the Juans out there interested if they only meet resistance when offering their time and energy? Sure, the medicine does not taste good - dumping eToys hurts, I know that. But this problem is generic. And no, don't bother replying to me specifically about this because I don't have the energy to discuss anything right now.
Hello All,
I lurk most of the time but have played with Squeak and been on the list a long time. :)
I too would love to see Juan's Morphic in Pavel's image.
It has already been expressly stated that those who use eToys do not use the 3.9+ images. So the bug fixes, improvements, etc to eToys do not occur in 3.9 but in the Squeakland image. So those who want eToys truly will want the Squeakland image.
I cannot verify this but it would naively seem that there is already a divergence between eToys in Squeakland and eToys in the main image. I believe that divergence will only increase. I presume things change with regard to eToys and potentially Morphic in the Squeakland version which do not make to the 3.9 image. I could be wrong. But unless someone makes the effort to track both and insure that those things get brought back to 3.9+ then they are lost to the 3.9+ users. It would seem this is already the case.
It seems that the fact is that if you want eToys don't use 3.9+. Use the Squeakland image.
Pavel and Juan have done nothing to hurt or harm Squeak. What people can do with Squeak only increased not decreased.
We already have image forks. Lots of them. People already pick which image they want. Every release is technically to a certain extent a fork and is used as such by people. There are people here who use a 3.7 image, some a 3.8.1 image, some the 3.9 image, some the new Developers image, the Squeakland image, the Pier image, the Seaside image, etc.
If Squeakland's image has changes to Morphic and eToys that are not in the 3.9+ image, then we no longer truly have a "Full image" because what was once considered a part of that image is no longer present. It would seem the only route to such an image is to either port the changes from one to the other. Which direction is easier I can't say.
But no one to my knowledge has formulated such a plan nor has stepped up to the plate to do it.
So it seems to me that the pro eToys side is a vote for the status quo, because their is no one doing anything to actively pursue Morphic and eToy maintenance current with Squeakland. On the cleaner Morphic and smaller image side we have some people voting with their time and effort.
I am not trying to offend anyone and my apologies if I do so, it is most definitely not my intent. Nor am I attempting to pressure anyone to put their time, effort or money to do anything.
I am explicitly encouraging those who have stepped out to express a vision and a plan with time and effort to pursue such. If there were someone equally passionate about cleaning Morphic and eToys and bringing them current with the current state of the art Morphic and eToys and had a plan to do something. I would gladly cheer them on too.
I would truly love to see Squeak to have build-up-able images as opposed to the distribute all and remove philosophy. And I would love to see some pre-built images which target certain user groups, eToys, business apps, web server, etc.
I believe Spoon, Pavel & Juan, offer hope for such a future.
Squeak is a diverse community. Lets build it up not bring it down.
A small image with Morphic 3 may be the best future eToys 2+ can have. They are not mutually exclusive. It may be easier for a team to pick up the ball to implement a clean eToys on top of Morphic 3. I don't think Juan or Göran or anyone would be opposed.
Any way I am well over my 2cents. And I just saw a plethora of messages flood my Squeak mailbox since I started this message.
Trying to encourage.
Jimmie
Jimmie Houchin wrote:
goran@krampe.se wrote: So it seems to me that the pro eToys side is a vote for the status quo,
there is a name for this kind of status quo: it's called "backward compatibility". this is what I support.
Stef
Hey Goran,
the two of us recently have thrown some "nonsense" words at each other and I was *not* under the impression that you where getting tired just because we did so :)
O.K. you should (also) be doing other things but that is no excuse! Everybody else here should (also) be doing other things.
And if you're concerned that hardly any (major) change can be proposed without having tons of arguments raised against it, then you're perhaps suffering from the image based development of Squeak and other Smalltalks. Imagine how easy it would be if you'd just have to change a handful of "import" imperatives ;-)
Come back into the discussion, please. Your opinion is valuable here in squeak-dev.
/Klaus
On Tue, 31 Oct 2006 15:43:37 +0100, goran@krampe.se wrote:
Hi folks!
=?ISO-8859-1?Q?St=E9phane_Rollandin?= lecteur@zogotounga.net wrote:
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Ok, I have for various reasons decided to drop out of this discussion.
I don't think I will be able to make my arguments and views any more clear than the "nonsense" I have produced so far, and since I seem to be the only one publically supporting Juan (perhaps there were a few more) I am clearly outnumbered. And I don't feel encouraged to keep discussing it this particular way, no - I don't know why we should destroy Squeak btw.
And I should be doing other things anyway. ;)
The rest of squeak-dev will simply have to (and the board IMHO) figure this one out.
regards, Göran
PS. I am kinda tired of the fact that hardly any change can be proposed in this community without having tons of arguments raised against it. Sure, this particular case is harder to judge - but the fact remains, how can we keep all the Juans out there interested if they only meet resistance when offering their time and energy? Sure, the medicine does not taste good - dumping eToys hurts, I know that. But this problem is generic. And no, don't bother replying to me specifically about this because I don't have the energy to discuss anything right now.
Il giorno mar, 31/10/2006 alle 16.43 +0200, goran@krampe.se ha scritto:
Hi folks!
=?ISO-8859-1?Q?St=E9phane_Rollandin?= lecteur@zogotounga.net wrote:
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Ok, I have for various reasons decided to drop out of this discussion.
I don't think I will be able to make my arguments and views any more clear than the "nonsense" I have produced so far, and since I seem to be the only one publically supporting Juan (perhaps there were a few more) I am clearly outnumbered. And I don't feel encouraged to keep discussing it this particular way, no - I don't know why we should destroy Squeak btw.
Just for the record, I agree with Goran.
Giovanni
From: goran@krampe.se Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: I am standing by Juan's proposal,do you? (was Re: Removing Etoys, Morphic and other friends) Date: Tue, 31 Oct 2006 16:43:37 +0200
Hi folks!
=?ISO-8859-1?Q?St=E9phane_Rollandin?= lecteur@zogotounga.net wrote:
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
This may be a stupid question, but is the quote realistic? Is EToys going to be on *millions* of PC's?
Personally I think seaside and/or something seaside related will be the smalltalk killer app.
I guess I also missed the part where what Jaun is doing means that squeak dumps EToys. Can't it just be a different image like the dev image? I don't think that means a fork, per se. Someone can just take the base image, what ever that is, and load/unload until they have a Morphic 3.0 image and release it. Kind of like how the dev image is done (afaik anyway).
_________________________________________________________________ Get FREE company branded e-mail accounts and business Web site from Microsoft Office Live http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
I support Juan's proposal and Goran's comments.
On Nov 1, 2006, at 1:51 PM, J J wrote:
I guess I also missed the part where what Juan is doing means that squeak dumps EToys. Can't it just be a different image like the dev image? I don't think that means a fork, per se. ...
Right. It's not necessarily a fork, although it could end up being a fork.
With Juan's proposal, EToys would be removed from the 3.10alpha "basic" image which follows the update stream. (For better or worse, it looks like the update stream will still be needed for the next release at least.)
This doesn't mean EToys will never work with the squeak-dev 3.10 and beyond images... Ideally, someone would create the loadable EToys package for 3.10 and it would be part of the 3.10 "full" image.
I'd think it wouldn't be *that* hard to make a loadable EToys package for 3.9... it's non-trivial, but I'd think it'd at least be no more difficult than the unloading work Juan has already done. (Any comments on that, Juan?) It is possible, though, that no one will do it. And I certainly wouldn't expect Juan to do it, for example.
If a 3.9 EToys package is created, the 3.10 EToys package would be created from that, adjusting for any Morphic changes from 3.9 to 3.10. (Or even better, it would be ported from the latest OLPC version, although that would be a bigger merge.)
In any case, this sort of basic level of modularity is essential for the survival of the squeak-dev image into the future, and for the community to grow, IMHO. This sort of disentangling has various other benefits such as getting us closer to working on top of Spoon.
- Doug
I can only speak for myself, but I suspect there are others who basically support what you're saying Doug and at the same time like to see a stronger committment from the board towards achieving "this level of modularity". I had said that I didn't support Juan's proposal "as is" because it didn't acknowledge the factors you've addressed. What do I mean by "stronger committment"? I have an idea, but I'm not 100% sure because I think it depends in part on some factors which are not clear to me:
-The Board position on interacting with the major code forks -The Board's committment to Spoon. -Last but most significant in my view, is the Board's position on Squeak kernel ownership which I discussed in another post.
Cheers,
Laurence
On 11/2/06, Doug Way dway@mailcan.com wrote:
I support Juan's proposal and Goran's comments.
On Nov 1, 2006, at 1:51 PM, J J wrote:
I guess I also missed the part where what Juan is doing means that squeak dumps EToys. Can't it just be a different image like the dev image? I don't think that means a fork, per se. ...
Right. It's not necessarily a fork, although it could end up being a fork.
With Juan's proposal, EToys would be removed from the 3.10alpha "basic" image which follows the update stream. (For better or worse, it looks like the update stream will still be needed for the next release at least.)
This doesn't mean EToys will never work with the squeak-dev 3.10 and beyond images... Ideally, someone would create the loadable EToys package for 3.10 and it would be part of the 3.10 "full" image.
I'd think it wouldn't be *that* hard to make a loadable EToys package for 3.9... it's non-trivial, but I'd think it'd at least be no more difficult than the unloading work Juan has already done. (Any comments on that, Juan?) It is possible, though, that no one will do it. And I certainly wouldn't expect Juan to do it, for example.
If a 3.9 EToys package is created, the 3.10 EToys package would be created from that, adjusting for any Morphic changes from 3.9 to 3.10. (Or even better, it would be ported from the latest OLPC version, although that would be a bigger merge.)
In any case, this sort of basic level of modularity is essential for the survival of the squeak-dev image into the future, and for the community to grow, IMHO. This sort of disentangling has various other benefits such as getting us closer to working on top of Spoon.
- Doug
Hi Doug,
Doug Way escribió:
... I'd think it wouldn't be *that* hard to make a loadable EToys package for 3.9... it's non-trivial, but I'd think it'd at least be no more difficult than the unloading work Juan has already done. (Any comments on that, Juan?) It is possible, though, that no one will do it. And I certainly wouldn't expect Juan to do it, for example. ...
Well, doing it right is really a lot of work. Most of the work in what I did is to remove knowledge about eToys in non-eToys methods (that I didn't remove). Lots of them. 'Doing it right' means not keeping duplicated versions of them (one in eToysLessSqueak and one in eToys package), but actually refactoring.
Cheers, Juan Vuletich
On Tue, 31 Oct 2006 17:59:55 +0300, Stéphane Rollandin lecteur@zogotounga.net wrote:
as I see it, my problem with *your* proposal is that we need to dump eToys in order to gain a cleaned-up Morphic.
to me "code cleanup" does not mean that any functionality is lost. only that the code is cleaned up. maybe I am too simple-minded :)
How to change the fundament of a building and in the same time to avoid removing of upper floors?
so your proposal is to kill etoys, which currently work just fine and is used by many people, for the only reason that it does not seem to be easy to clean it up. we had "if it's not broken, don't fix it", now it seems we have "if it's not broken but ugly, then just kill it".
To be honest I never had been an etoys user and probably should not jump in here. But anyway I wonder: if etoys are already working just fine right now (in efficiently forked image) why do they can not be detangled from the current squeak-dev image to allow it move forward?
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Another point of view is that blocking any change going to squeak may finally repell the majority of creative people from it and kill in a different way (by not allowing to create a future). I'm not want to be harsh (still not used to English unfortunately) but for me it if squeak should die - then let it die: people may move to other projects which are lacking support now (including Strongtalk).
Stef
best regards, Danil
danil osipchuk wrote:
to me "code cleanup" does not mean that any functionality is lost. only that the code is cleaned up. maybe I am too simple-minded :)
How to change the fundament of a building and in the same time to avoid removing of upper floors?
I don't know, I'm not into masonry, only computer science.
To be honest I never had been an etoys user and probably should not jump in here. But anyway I wonder: if etoys are already working just fine right now (in efficiently forked image) why do they can not be detangled from the current squeak-dev image to allow it move forward?
I don't know, I did not implement eToys. I just use it, happily.
this is utter nonsense. I just don't understand where we are going here. why destroy Squeak ?
Another point of view is that blocking any change going to squeak may finally repell the majority of creative people from it and kill in a different way (by not allowing to create a future). I'm not want to be harsh (still not used to English unfortunately) but for me it if squeak should die - then let it die: people may move to other projects which are lacking support now (including Strongtalk).
well I'm part of the creative people using Squeak. and if it gets dismantled, I will stop working with it. so your point works the other way round, too.
regards,
Stef
To be honest I never had been an etoys user and probably should not jump in here. But anyway I wonder: if etoys are already working just fine right now (in efficiently forked image) why do they can not be detangled from the current squeak-dev image to allow it move forward?
I don't know, I did not implement eToys. I just use it, happily.
sorry, I think I missed your point. you meant "if eToys work currently well in Squeakland, why not get rid of them in Squeak-dev" ?. in that case my answer is quite simple: I work in Squeak-dev, not Squeakland.
Stef
Stéphane Rollandin wrote:
To be honest I never had been an etoys user and probably should not jump in here. But anyway I wonder: if etoys are already working just fine right now (in efficiently forked image) why do they can not be detangled from the current squeak-dev image to allow it move forward?
I don't know, I did not implement eToys. I just use it, happily.
On the other side I'm extremely unhappy with current state of morphic. Today I have recommended the friend who is willing to study smalltalk to use Dolphin at the first time. This is because I believe that learning of Smalltalk should happen in the cleanly written system and Squeak doesn't qualify for this (because of morphic in a large extent). It is not system that one programmer can understand with reasonable effort anymore. Dolphin is.
sorry, I think I missed your point. you meant "if eToys work currently well in Squeakland, why not get rid of them in Squeak-dev" ?. in that case my answer is quite simple: I work in Squeak-dev, not Squeakland.
I see. So no point to argue who is right. The question is - what should we do in this clear conflict of interests? I would prefer an experimental marginal fork to exist for people who are ready for destabilization of things. Individual work like what Juan does is not quite the same because people tend to burn out and efforts should be joined. At least several people with a common view on this are needed.
regards Danil
I see. So no point to argue who is right. The question is - what should we do in this clear conflict of interests? I would prefer an experimental marginal fork to exist for people who are ready for destabilization of things. Individual work like what Juan does is not quite the same because people tend to burn out and efforts should be joined. At least several people with a common view on this are needed.
what conflict of interest ? I, among many, use eToys. someone proposed that a simple way to unload eToys be provided in 3.10. fine. what is the problem then for people wanting to improve morphic ? I do support the Morphic 3.0 effort. my one and only point is that I want to be able to use eToys in squek-dev. is that really asking to much ?
Stef
I personally wouldn't want to see much forking going on. The active community (i.e. people who are generating code) is small as it is. But there is already a "developers image". Maybe this could use Jaun's work as it's GUI? I mean, me as a developer, I just want the image to not be distracting and run as fast as possible. :)
From: danil osipchuk danil@mtsnet.ru Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: I am standing by Juan's proposal, do you? (was Re: Removing Etoys, Morphic and other friends) Date: Tue, 31 Oct 2006 20:38:34 +0000
Stéphane Rollandin wrote:
To be honest I never had been an etoys user and probably should not jump in here. But anyway I wonder: if etoys are already working just fine right now (in efficiently forked image) why do they can not be detangled from the current squeak-dev image to allow it move forward?
I don't know, I did not implement eToys. I just use it, happily.
On the other side I'm extremely unhappy with current state of morphic. Today I have recommended the friend who is willing to study smalltalk to use Dolphin at the first time. This is because I believe that learning of Smalltalk should happen in the cleanly written system and Squeak doesn't qualify for this (because of morphic in a large extent). It is not system that one programmer can understand with reasonable effort anymore. Dolphin is.
sorry, I think I missed your point. you meant "if eToys work currently well in Squeakland, why not get rid of them in Squeak-dev" ?. in that case my answer is quite simple: I work in Squeak-dev, not Squeakland.
I see. So no point to argue who is right. The question is - what should we do in this clear conflict of interests? I would prefer an experimental marginal fork to exist for people who are ready for destabilization of things. Individual work like what Juan does is not quite the same because people tend to burn out and efforts should be joined. At least several people with a common view on this are needed.
regards Danil
_________________________________________________________________ All-in-one security and maintenance for your PC. Get a free 90-day trial! http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://www...
On 10/31/06, goran@krampe.se goran@krampe.se wrote:
Hi!
"Laurence Rozier" laurence.rozier@gmail.com wrote:
I don't support what Juan's proposal as stated. I'd like to hear why
you,
Juan or anyone else don't agree with what Jecel/Guy proposed
Ok, let me quote so that you don't need to skip back, Jecel wrote:
This is a plan that is practical and which I fully support: if we can unload eToys but not load it back, then let's just include eToys in the full image that we distribute and allow everyone the one way option of removing it. I don't mind at all eliminating the Flash logo, the welcome windows and other stuff every time I begin working with a newly downloaded image. The fact that I can't get any of these easily back if I want has never been a problem since I could just start over from a clean image.
Sure, a reloadable eToys would be even better but I doubt it will happen.
My problem with that proposal is that it means that Morphic is actually not cleaned up - it would just persist as it is today.
... I can see your point but what I had in mind was cleaning up Morphic and being able to "revert to the old Morphic with eToys" ... this is btw also where Spoon comes in(more below) and makes me wonder if there isn't a middle ground that would automatically detect whether a project being loaded is using old Morphic and then load that project as an isolated project along with old Morphic?
It also means that any cleanup that such a removal-script would do in
itself (and Juan has already said that such a delta script is NOT easy to maintain IIRC) would actually fork Morphic itself - people writing code on top of Morphic in the future would have to wonder if it is being run in the image-with-a-clean-morphic-without-etoys or in the image-with-etoys.
In other words, the above sounds like either "status quo" or a fork of
Morphic.
I dislike both. :)
Note that eToys is not a clean "addon" on top of Morphic - it is in fact
an intertwined mess with Morphic methods including lots of logic specifically for eToys. So if you clean out eToys you end up with a different Morphic.
Agreed. However, eToys was originally presented as a Morphic add-on and that is the impression many(most?) new comers will continue to have.
I think it would be much better to lift the burden of eToys, let Juan do
his magic and give us an improved Morphic in the baseline - let anyone step up and retrofit eToys on top of that as a cleaner addon, or not.
I understand the difficulties, but since it's taking away something that currently works, the onus is on the remover in my view.
In
either case - Squeakland is the place to go for eToys and has always been.
Oh if only it were that simple. Now if etoys had started out in a forked image that would be simple, but from the beginning etoys was in the only squeak image. IIRC the early browser plugin images were based on the current Squeak image. The Squeakland website has and continues in many places to make reference to Squeak without distinction and Google has recorded tons of this. No amount of assertion here will change that fact. We can decide that it doesn't matter, but it will be a long time before the close association between squeak.org and etoys is gone. Until then people who are attracted to Squeak because of etoys will continue to have bad impressions. This video http://video.google.com/videoplay?docid=2933987255545037916makes it clear though it is somewhat painful for Squeakers regardless of what distribution they use to watch because it's not only about the etoy experience. Squeak and Smalltalk have done this over and over - we can't blame
if we can unload eToys but not load it back, then let's just include
eToys
in the
full image that we distribute and allow everyone the one way option of removing it.
which mirrors what I said in "Smalltalk Reloaded". More specifically, do folks supporting Juan's proposal disagree with my statement:
All other considerations aside, if e-toys is unloaded from the main
distribution and cannot be easily reloaded by a new Squeaker,there will
be
confusion and for many disappointment and/or some other non-positive experience.
I am not sure I agree with this.
Thing is, eToys in the "main distro"
(squeak.org) has been relatively unmaintained for some time I think (others with better knowledge might disagree). I personally would not trust eToys in official Squeak to work as one would expect it to work relative to the Squeakland image.
I understand but most people coming to the Squeak site don't have your perspective.
And this goes especially for 3.9 and beyond, since Squeakland is 3.8
based.
So to rephrase myself - if we aim to minimize the risk of a non-positive experience of eToys I think we should clearly and distinctly direct people towards the Squeakland distro directly from the main page of Squeak.org for those people looking specifically for eToys.
That makes it less non-positive but it's still not an improvement IMO until the new morphic is used for something ... well new.
For me it's not that I'm opposed to a cleaner Morphic, I just don't want to
add stumbling blocks for wider acceptance at a time when eToy images are getting more and more visibility. Sure it would be nice to see the
default
image with a cleaner Morphic but not at any price - especially since
Spoon
is coming.
Mmmm, I don't see how Spoon relates technically to a cleanup of Morphic. I consider those two efforts quite separate.
The etoy/morphic entanglement will eventually yield to imprinting and with a dynamically configurable image, we'll get the best of both worlds.
It's not clear to me whether the upside of a cleaner Morphic wil=
l be that great or long lasting because I believe we're in the early
stages o=
f a big paradigm shift in which Croquet UI<
http://www.meshverse.com/2006/10/18/the-64-billion-dollar-question-reloa=
ded/>(oh where is Wicket?) is where the action is. In this new paradigm, I don't
kno=
w whether a cleaner Morphic is going to have advantages over Tweak.
It is not so much about which is "best". Tweak is radically different, and many of those ideas are great (AFAICT). I have on the other hand heard people moaning about it being hard to debug and as we all know - it is not "ready" for Squeak.org yet. Again AFAIK.
I don't think we should sit around and wait for Tweak to save the day - we have already done so to a certain extent and I think we should stop doing that. Morphic is nice and it can be small and lean too. Juan offers to give us that and I think that is great.
It is and I wouldn't mind at all seeing it but not at the price that's required for benefits that are not proven. If developers take the new etoyless, improved Morphic and start doing great things with it then a strong case can be made to break with the old. But that's not known yet, we could end up with a core Squeak that can't use etoys AND doesn't have much new to show because more people decide to go with Tweak or wxWidgets or ...
Also - yes, the Squeaklanders did spend time to update eToys in 3.8 with
the changes that were done in the Squeakland image. But will they keep that up? I am very unsure about that, would be neat to hear more from Michael Rueger (or someone) on that issue.
If they indeed have an intention of maintaining eToys in 3.9 and beyond (which I doubt) then that would indeed make the question more complicated.
Cheers,
Laurence
regards, Göran
PS. I don't claim the almighty truth - these are just my opinions based on my perceptions and hunches. :)
I feel the same way. I also am looking at the history of Smalltalker's being our own worst enemy because we didn't consider how big an impact we could have if united in one interoperable ecosystem.
Cheers,
Laurence
All,
I stand by the suggestion of either replacing Morphic and Etoys with Tweak and Tweaks EToy implementation, since there is significant work going into both, or adding a script that removes eToys from the main image upon developer request. If a further development of Morphic is wanted and that development requires the removal of eToys from the main image, I support that also. In other words if we want Morphic 3.0 then the developer is required to unload eToys and then load Morphic 3.0 into their own image.
I do not support removing eToys from the main image without replacing it with Tweak and the new OLPC eToys.
The reason for my position is that I support community bridges which I have discussed at length in previous postings.
My suggestion for 3.10 is to work towards consolidating current advancements from all platforms, Tweak, eToys, Croquet and OLPC into Squeak's main image. This follows the suggestion of finding work that is already completed and ready for inclusion into the main image.
A question for Juan, can your Morphic 3.0 advancements be applied to Tweak?
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of goran@krampe.se Sent: Tuesday, October 31, 2006 3:03 AM To: The general-purpose Squeak developers list Subject: I am standing by Juan's proposal, do you? (was Re: Removing Etoys,Morphic and other friends)
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion again. :)
Juan Vuletich jvuletich@dc.uba.ar wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to feel that people agree - and as I said I am all with you for three major reasons:
- You are a doer. You have already proved that.
- You are committed to this. We don't have many people committed to
Morphic development (on this low level) these days and I value each and every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve something and has the above 3 things, then there is not much to argue about - I say go. :)
Could you possibly (as you probably know Morphic/eToys better than
most
of us) list the parts that we could "decide" about leaving in or
ripping
out? Lex started a list, but he also included some things that I had
not
thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put it there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support eToys. And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what should not. But clearly in my reduced 3.7 image, I removed lots of stuff besides
eToys.
Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan
present
- he also remarked that Morphic is indeed quite small - if you
consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result
etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I
think
it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is my vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
- Morphic is proven to work. But seems to be in a mess and thus is
brittle and also not maintained much because people can't get a grip and are also appalled about lots of the stuff that is in there today (eToys related I think). So it is sitting still today. Btw, this is MY primary objective behind getting eToys out - because I want a more attractive Morphic that then might get maintained instead of just sit there.
- Tweak came along and people interested in these things probably
decided to hang around and wait to see if Tweak would end up replacing Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new ideas etc, but perhaps it is time to grab what we have and make the best of it instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do not know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support in this. And I hope that Juan is willing to take on the Steward role for Morphic together with a few more brave souls with an interest in Morphic (there are a few I think). I bet perhaps even Dan Ingalls could be interested, but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
Hi,
I just wanted to state something that I think most of all proponents of keeping etoys are missing. Sorry in advance if its not the case or this statement of mine sound a little harsh. (please blame my lack of a better english, and time to write it better)
I kept reading and reading this thread and the other ones related to it, and everybody who asked to keep etoys on squeak-dev seemed to me that they were not aware that the currently etoy image isn't the current squeak-dev. If you want to use etoys you need to use the squeakland image.
While its true that etoys works on 3.9, remember that the maintainance of etoys is done on the squeakland image (which is not even a squeak-dev 3.8image, only one based on it)
So what I don't understand is why everybody insists on using etoys in squeak-dev 3.9, when the people behind etoys don't use, nor maintain, nor can make any kind of assurance about etoys in 3.9.
In fact I think its contraproducent to keep etoys in this setup. Because we risk that anyone wanting to use squeak because of etoys, they might have a bad etoy experience because they are using 3.9. I, on the other hand, would always direct all the people interested in etoys to an squeakland image instead.
Lastly I would like to ask Ron, Klaus, Jecel, Lex, Marcus, and the other people that on this thread said that wanted to keep etoys if they have considered this issue and I would like to know what they think. Again. Apologies if my mail didn't sound right. I am just curious and no offense was meant to anyone.
Regards, Hernán
On 10/31/06, Ron Teitelbaum Ron@usmedrec.com wrote:
All,
I stand by the suggestion of either replacing Morphic and Etoys with Tweak and Tweaks EToy implementation, since there is significant work going into both, or adding a script that removes eToys from the main image upon developer request. If a further development of Morphic is wanted and that development requires the removal of eToys from the main image, I support that also. In other words if we want Morphic 3.0 then the developer is required to unload eToys and then load Morphic 3.0 into their own image.
I do not support removing eToys from the main image without replacing it with Tweak and the new OLPC eToys.
The reason for my position is that I support community bridges which I have discussed at length in previous postings.
My suggestion for 3.10 is to work towards consolidating current advancements from all platforms, Tweak, eToys, Croquet and OLPC into Squeak's main image. This follows the suggestion of finding work that is already completed and ready for inclusion into the main image.
A question for Juan, can your Morphic 3.0 advancements be applied to Tweak?
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of goran@krampe.se Sent: Tuesday, October 31, 2006 3:03 AM To: The general-purpose Squeak developers list Subject: I am standing by Juan's proposal, do you? (was Re: Removing Etoys,Morphic and other friends)
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion again. :)
Juan Vuletich jvuletich@dc.uba.ar wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to feel that people agree - and as I said I am all with you for three major reasons:
- You are a doer. You have already proved that.
- You are committed to this. We don't have many people committed to
Morphic development (on this low level) these days and I value each and every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve something and has the above 3 things, then there is not much to argue about - I say go. :)
Could you possibly (as you probably know Morphic/eToys better than
most
of us) list the parts that we could "decide" about leaving in or
ripping
out? Lex started a list, but he also included some things that I had
not
thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put
it
there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support eToys.
And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what should
not.
But clearly in my reduced 3.7 image, I removed lots of stuff besides
eToys.
Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan
present
- he also remarked that Morphic is indeed quite small - if you
consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result
etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for
one
applaud and greatly appreciate your diligence in this matter and I
think
it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is
my
vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
- Morphic is proven to work. But seems to be in a mess and thus is
brittle and also not maintained much because people can't get a grip and are also appalled about lots of the stuff that is in there today (eToys related I think). So it is sitting still today. Btw, this is MY primary objective behind getting eToys out - because I want a more attractive Morphic that then might get maintained instead of just sit there.
- Tweak came along and people interested in these things probably
decided to hang around and wait to see if Tweak would end up replacing Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new ideas etc, but perhaps it is time to grab what we have and make the best of it instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do not know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support in this. And I hope that Juan is willing to take on the Steward role for Morphic together with a few more brave souls with an interest in Morphic (there are a few I think). I bet perhaps even Dan Ingalls could be interested, but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
Hi Hernán,
That is a perfectly reasonable question.
My main concern is collaboration and community. While I support Juan and would like to know more about his work, it is very difficult for me to believe that Juan will be able to provide more of an advancement for Squeak then Tweak and Croquet will. eToys is today is a bridge, even if it is outdated. Morphic in my opinion may be good for development tools, but fails to provide an interface that is usable for more then that. The question is should we move Morphic forward without eToys so that it meets the requirements of users. My answer is that we have not listened to users enough to know, we have not engaged enough resources to make it worth while and we have not proven that our efforts will produce more then the large scale development which is Tweak and Croquet will.
Does it make sense to work with and incorporate these new developments into Squeak? Yes I believe it does. I would like to see Juan and other Squeak developers work towards getting Tweak ready and include it in Squeak. This would be the best of both worlds, we could then better support Croquet out of the box, and we would have a new cleaner Morphic model and eToys that squeakland could help support.
I also support greater control and participation of the volunteer community. I know that we are in transition and these issues are very important to everyone. While I support greater independence I believe the only way that the community at large will progress is if we find a way to organize our efforts in a way that allows us to provide valuable contributions. That involves greater user engagement, and in my opinion, a greater focus on useful applications, or tools/components to build applications. I do not support cutting off our founders to gain that control and, as I have said earlier, I believe that the competition and tension that these competing groups create is a good thing.
Can Morphic 3.0 be implemented in Tweak?
Ron Teitelbaum
________________________________________ From: Hernan Tylim Sent: Tuesday, October 31, 2006 10:59 AM
Hi,
I just wanted to state something that I think most of all proponents of keeping etoys are missing. Sorry in advance if its not the case or this statement of mine sound a little harsh. (please blame my lack of a better english, and time to write it better)
I kept reading and reading this thread and the other ones related to it, and everybody who asked to keep etoys on squeak-dev seemed to me that they were not aware that the currently etoy image isn't the current squeak-dev. If you want to use etoys you need to use the squeakland image.
While its true that etoys works on 3.9, remember that the maintainance of etoys is done on the squeakland image (which is not even a squeak-dev 3.8 image, only one based on it)
So what I don't understand is why everybody insists on using etoys in squeak-dev 3.9, when the people behind etoys don't use, nor maintain, nor can make any kind of assurance about etoys in 3.9.
In fact I think its contraproducent to keep etoys in this setup. Because we risk that anyone wanting to use squeak because of etoys, they might have a bad etoy experience because they are using 3.9. I, on the other hand, would always direct all the people interested in etoys to an squeakland image instead.
Lastly I would like to ask Ron, Klaus, Jecel, Lex, Marcus, and the other people that on this thread said that wanted to keep etoys if they have considered this issue and I would like to know what they think. Again. Apologies if my mail didn't sound right. I am just curious and no offense was meant to anyone.
Regards, Hernán On 10/31/06, Ron Teitelbaum Ron@usmedrec.com wrote: All,
I stand by the suggestion of either replacing Morphic and Etoys with Tweak and Tweaks EToy implementation, since there is significant work going into both, or adding a script that removes eToys from the main image upon developer request. If a further development of Morphic is wanted and that development requires the removal of eToys from the main image, I support that also. In other words if we want Morphic 3.0 then the developer is required to unload eToys and then load Morphic 3.0 into their own image.
I do not support removing eToys from the main image without replacing it with Tweak and the new OLPC eToys.
The reason for my position is that I support community bridges which I have discussed at length in previous postings.
My suggestion for 3.10 is to work towards consolidating current advancements from all platforms, Tweak, eToys, Croquet and OLPC into Squeak's main image. This follows the suggestion of finding work that is already completed and ready for inclusion into the main image.
A question for Juan, can your Morphic 3.0 advancements be applied to Tweak?
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of goran@krampe.se Sent: Tuesday, October 31, 2006 3:03 AM To: The general-purpose Squeak developers list Subject: I am standing by Juan's proposal, do you? (was Re: Removing Etoys,Morphic and other friends)
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion again. :)
Juan Vuletich < jvuletich@dc.uba.ar> wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to feel that people agree - and as I said I am all with you for three major reasons:
- You are a doer. You have already proved that.
- You are committed to this. We don't have many people committed to
Morphic development (on this low level) these days and I value each and every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve something and has the above 3 things, then there is not much to argue about - I say go. :)
Could you possibly (as you probably know Morphic/eToys better than
most
of us) list the parts that we could "decide" about leaving in or
ripping
out? Lex started a list, but he also included some things that I had
not
thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put it there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support eToys. And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what should not. But clearly in my reduced 3.7 image, I removed lots of stuff besides
eToys.
Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan
present
- he also remarked that Morphic is indeed quite small - if you
consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result
etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I
think
it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is my vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
- Morphic is proven to work. But seems to be in a mess and thus is
brittle and also not maintained much because people can't get a grip and are also appalled about lots of the stuff that is in there today (eToys related I think). So it is sitting still today. Btw, this is MY primary objective behind getting eToys out - because I want a more attractive Morphic that then might get maintained instead of just sit there.
- Tweak came along and people interested in these things probably
decided to hang around and wait to see if Tweak would end up replacing Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new ideas etc, but perhaps it is time to grab what we have and make the best of it instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do not know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support in this. And I hope that Juan is willing to take on the Steward role for Morphic together with a few more brave souls with an interest in Morphic (there are a few I think). I bet perhaps even Dan Ingalls could be interested, but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
Hi Hernan,
So what I don't understand is why everybody insists on using etoys in squeak-dev 3.9, when the people behind etoys don't use, nor maintain, nor can make any kind of assurance about etoys in 3.9.
Because I truly believe that this is lack of energy and _not_ lack of good will on their part. We should strive to bring them back and not to exclude them. Having all the tools available for 3.9 helps the etoys developers as much as the seaside developers.
So I fully support Ron's view:
My suggestion for 3.10 is to work towards consolidating current advancements from all platforms, Tweak, eToys, Croquet and OLPC into Squeak's main image. This follows the suggestion of finding work that is already completed and ready for inclusion into the main image.
Having universes from Lex should support us in doing so.
In fact I think its contraproducent to keep etoys in this setup. Because we risk that anyone wanting to use squeak because of etoys, they might have a bad etoy experience because they are using 3.9. I, on the other hand, would always direct all the people interested in etoys to an squeakland image instead.
Lastly I would like to ask Ron, Klaus, Jecel, Lex, Marcus,
This would be Markus in that case... ;-)
and the other people that on this thread said that wanted to keep etoys if they have considered this issue and I would like to know what they think. Again. Apologies if my mail didn't sound right. I am just curious and no offense was meant to anyone.
Cheers,
Markus
Hernan Tylim wrote on Tue, 31 Oct 2006 12:59:14 -0300
I just wanted to state something that I think most of all proponents of keeping etoys are missing. Sorry in advance if its not the case or this statement of mine sound a little harsh. (please blame my lack of a better english, and time to write it better)
I kept reading and reading this thread and the other ones related to it, and everybody who asked to keep etoys on squeak-dev seemed to me that they were not aware that the currently etoy image isn't the current squeak-dev. If you want to use etoys you need to use the squeakland image.
Perhaps it would be better to say "it is recommended that you use the Squeakland image".
While its true that etoys works on 3.9, remember that the maintainance of etoys is done on the squeakland image (which is not even a squeak-dev 3.8 image, only one based on it)
While it is natural that you have this impression, my own impression is a bit different (it might be wrong). I see the following options available to someone wanting to use eToys:
Squeak 3.9 Squeakland (based on 3.8) SmallLand (based on 3.8) OLPC (based on the Squeakland one)
This last option is the one that has the latest fixes and enhancements to eToys but I am not sure that there is no plan to make this stuff available to the others. My impression is that the current situation is more due to the urgent deadlines of the OLPC project than to some plan to fork things.
So what I don't understand is why everybody insists on using etoys in squeak-dev 3.9, when the people behind etoys don't use, nor maintain, nor can make any kind of assurance about etoys in 3.9.
I looked back at the last couple of month's discussions in this list and found people speculating what the plans of the Squeakland group are but not actual details from people in a position to know. So I will avoid guessing myself and will wait to hear from them.
In fact I think its contraproducent to keep etoys in this setup. Because we risk that anyone wanting to use squeak because of etoys, they might have a bad etoy experience because they are using 3.9. I, on the other hand, would always direct all the people interested in etoys to an squeakland image instead.
Having helped people on the #squeak IRC channel who were following some tutorials about eToys and Kedama I agree this can be a problem. But telling them to get a Squeakland image is not always a good solution.
Lastly I would like to ask Ron, Klaus, Jecel, Lex, Marcus, and the other people that on this thread said that wanted to keep etoys if they have considered this issue and I would like to know what they think. Again. Apologies if my mail didn't sound right. I am just curious and no offense was meant to anyone.
What I want to avoid is a squeak-dev / squeakland fork. If this has already happened (in a definitive way, temporary forks happen all the time) then all my arguments are silly and should be ignored.
-- Jecel
Hernan Tylim wrote:
Lastly I would like to ask Ron, Klaus, Jecel, Lex, Marcus, and the other people that on this thread said that wanted to keep etoys if they have considered this issue and I would like to know what they think. Again. Apologies if my mail didn't sound right. I am just curious and no offense was meant to anyone.
speaking for myself: I have no experience of the contents of the squeakland image, so the only eToys I know are the ones from "our" Squeak image.
Stef
+1
I wonder, what is the opinion of the Squeakland people?
The arguments for keeping etoys in Squeak seem even weaker to me if the actual stakeholders do not state "yes, this is important for us because we plan to keep our Squeakland fork in sync with future Squeak versions". If this is not the case it does not make sense to have a non maintained version in the main image (and that is what we have now). If there are people willing to remove etoys we should not miss the opportunity!
Cheers, Adrian
On Oct 31, 2006, at 16:59 , Hernan Tylim wrote:
Hi,
I just wanted to state something that I think most of all proponents of keeping etoys are missing. Sorry in advance if its not the case or this statement of mine sound a little harsh. (please blame my lack of a better english, and time to write it better)
I kept reading and reading this thread and the other ones related to it, and everybody who asked to keep etoys on squeak-dev seemed to me that they were not aware that the currently etoy image isn't the current squeak-dev. If you want to use etoys you need to use the squeakland image.
While its true that etoys works on 3.9, remember that the maintainance of etoys is done on the squeakland image (which is not even a squeak-dev 3.8 image, only one based on it)
So what I don't understand is why everybody insists on using etoys in squeak-dev 3.9, when the people behind etoys don't use, nor maintain, nor can make any kind of assurance about etoys in 3.9.
In fact I think its contraproducent to keep etoys in this setup. Because we risk that anyone wanting to use squeak because of etoys, they might have a bad etoy experience because they are using 3.9. I, on the other hand, would always direct all the people interested in etoys to an squeakland image instead.
Lastly I would like to ask Ron, Klaus, Jecel, Lex, Marcus, and the other people that on this thread said that wanted to keep etoys if they have considered this issue and I would like to know what they think. Again. Apologies if my mail didn't sound right. I am just curious and no offense was meant to anyone.
Regards, Hernán
On 10/31/06, Ron Teitelbaum Ron@usmedrec.com wrote: All,
I stand by the suggestion of either replacing Morphic and Etoys with Tweak and Tweaks EToy implementation, since there is significant work going into both, or adding a script that removes eToys from the main image upon developer request. If a further development of Morphic is wanted and that development requires the removal of eToys from the main image, I support that also. In other words if we want Morphic 3.0 then the developer is required to unload eToys and then load Morphic 3.0 into their own image.
I do not support removing eToys from the main image without replacing it with Tweak and the new OLPC eToys.
The reason for my position is that I support community bridges which I have discussed at length in previous postings.
My suggestion for 3.10 is to work towards consolidating current advancements from all platforms, Tweak, eToys, Croquet and OLPC into Squeak's main image. This follows the suggestion of finding work that is already completed and ready for inclusion into the main image.
A question for Juan, can your Morphic 3.0 advancements be applied to Tweak?
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org
[mailto:squeak-dev-
bounces@lists.squeakfoundation.org] On Behalf Of goran@krampe.se Sent: Tuesday, October 31, 2006 3:03 AM To: The general-purpose Squeak developers list Subject: I am standing by Juan's proposal, do you? (was Re: Removing Etoys,Morphic and other friends)
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion
again. :)
Juan Vuletich < jvuletich@dc.uba.ar> wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to
feel
that people agree - and as I said I am all with you for three major reasons:
- You are a doer. You have already proved that.
- You are committed to this. We don't have many people committed to
Morphic development (on this low level) these days and I value
each and
every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve
something and
has the above 3 things, then there is not much to argue about - I
say
go. :)
Could you possibly (as you probably know Morphic/eToys better
than
most
of us) list the parts that we could "decide" about leaving in or
ripping
out? Lex started a list, but he also included some things
that I had
not
thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why
I put it
there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post
because I
think the list should be built by the community, and I didn't
want to
sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support
eToys. And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what
should not.
But clearly in my reduced 3.7 image, I removed lots of stuff
besides
eToys.
Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan
present
- he also remarked that Morphic is indeed quite small - if you
consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the
result
etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But
I for one
applaud and greatly appreciate your diligence in this matter
and I
think
it would be GREAT to have a small "isolated" clean Morphic in
Squeak
that is maintained and proven. And I am probably not alone in
that.
Well, I hope you're interested in my Morphic 3.0 project then.
It is my
vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
- Morphic is proven to work. But seems to be in a mess and thus is
brittle and also not maintained much because people can't get a
grip and
are also appalled about lots of the stuff that is in there today
(eToys
related I think). So it is sitting still today. Btw, this is MY
primary
objective behind getting eToys out - because I want a more
attractive
Morphic that then might get maintained instead of just sit there.
- Tweak came along and people interested in these things probably
decided to hang around and wait to see if Tweak would end up
replacing
Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new
ideas
etc, but perhaps it is time to grab what we have and make the
best of it
instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do
not
know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support
in this.
And I hope that Juan is willing to take on the Steward role for
Morphic
together with a few more brave souls with an interest in Morphic
(there
are a few I think). I bet perhaps even Dan Ingalls could be
interested,
but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
-- Saludos, Hernán
I wonder, what is the opinion of the Squeakland people?
The arguments for keeping etoys in Squeak seem even weaker to me if the actual stakeholders do not state "yes, this is important for us because we plan to keep our Squeakland fork in sync with future Squeak versions". If this is not the case it does not make sense to have a non maintained version in the main image (and that is what we have now). If there are people willing to remove etoys we should not miss the opportunity!
Cheers, Adrian
+1
Ramon Leon http://onsmalltalk.com
I wonder, what is the opinion of the Squeakland people?
The arguments for keeping etoys in Squeak seem even weaker to me if the actual stakeholders do not state "yes, this is important for us because we plan to keep our Squeakland fork in sync with future Squeak versions". If this is not the case it does not make sense to have a non maintained version in the main image (and that is what we have now). If there are people willing to remove etoys we should not miss the opportunity!
Cheers, Adrian
+1
I also vote for a cleaner version of Morphic. But I think that it will be less painfull if we take a different route. Instead of having an OldMorph and doing the experiments on the (new) Morph class, I propose to leave that class as it is and do the experiments on a new class (eg. SqMorph). Once we get a nice and clean model, we can think on how to migrate the old morphs to the new ones (if necessary).
Juan, I attach a ChangeSet that can be load on a 3.9 image. Unfortunately, as the following workspace code shows, it's not fully working at the moment... (maybe there is a missing method required by your new model in the old Morph hierarchy).
sqWorld := PasteUpMorph new. sqWorld openInWorld. sqWorld extent: 300@300. sqWorld addMorph: EllipseMorph new. sqWorld delete. sqWorld addMorph: SqTestMorph new. sqWorld halt openInWorld
Saludos, Francisco
Adrian Lienhard writes:
+1
I wonder, what is the opinion of the Squeakland people?
The arguments for keeping etoys in Squeak seem even weaker to me if the actual stakeholders do not state "yes, this is important for us because we plan to keep our Squeakland fork in sync with future Squeak versions". If this is not the case it does not make sense to have a non maintained version in the main image (and that is what we have now). If there are people willing to remove etoys we should not miss the opportunity!
+1
A cleaner smaller Morphic helps for all non-eToy's uses. Unless eToys is actively maintained in the squeak-dev images then it's better to remove it and point eToys users to the "good" versions.
Letting it rot will create confusion.
Bryce
I think this is a pointless discussion until there is real code to adopt.
Just my $0.02.
What Juan is doing sounds great to me. The musical notes thing sounded especially cool.
From: goran@krampe.se Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: I am standing by Juan's proposal, do you? (was Re: Removing Etoys,Morphic and other friends) Date: Tue, 31 Oct 2006 10:03:17 +0200
Hi all!
Since it feels that we are getting more concrete here I decided to rename the subject. Perhaps people join up in the discussion again. :)
Juan Vuletich jvuletich@dc.uba.ar wrote:
Hi Goran!
goran@krampe.se escribió:
Hi Juan and all!
I just want to say I am 100% with you on all this.
Thanks. It's nice to know that.
Though I am just one of "us" you know. :) But yes, it is nice to feel that people agree - and as I said I am all with you for three major reasons:
- You are a doer. You have already proved that.
- You are committed to this. We don't have many people committed to
Morphic development (on this low level) these days and I value each and every one highly. 3. You have a plan.
And my principle is that if someone is itching to improve something and has the above 3 things, then there is not much to argue about - I say go. :)
Could you possibly (as you probably know Morphic/eToys better than
most
of us) list the parts that we could "decide" about leaving in or
ripping
out? Lex started a list, but he also included some things that I had
not
thought were included (like ImageSegment for example).
To me eToys what you can find in the eToys package. That's why I put it there!
:)
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support eToys. And
they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
I think this list sounds perfect to me.
Anyway, I don't want to say what should be removed and what should not. But clearly in my reduced 3.7 image, I removed lots of stuff besides
eToys.
Let me repeat: To me eToys what it is in the eToys package.
I think it would be a nice way forward in this discussion.
regards, Göran
PS. This subject came up around an OOPSLA hacking table with Dan
present
- he also remarked that Morphic is indeed quite small - if you
consider
only Morphic itself.
:)
But we did not discuss the issue at any great length. Also Doug applied your recipe to have a look at the result
etc.
Doug, I'd like to know what were your impressions on this!
We never got around to any personal conclusions, though. But I for one applaud and greatly appreciate your diligence in this matter and I
think
it would be GREAT to have a small "isolated" clean Morphic in Squeak that is maintained and proven. And I am probably not alone in that.
Well, I hope you're interested in my Morphic 3.0 project then. It is my vision for morphic improvement. Check www.jvuletich.org !
I am. Let me put this interest in some perspective btw:
- Morphic is proven to work. But seems to be in a mess and thus is
brittle and also not maintained much because people can't get a grip and are also appalled about lots of the stuff that is in there today (eToys related I think). So it is sitting still today. Btw, this is MY primary objective behind getting eToys out - because I want a more attractive Morphic that then might get maintained instead of just sit there.
- Tweak came along and people interested in these things probably
decided to hang around and wait to see if Tweak would end up replacing Morphic in "official Squeak". Now it seems to not go that route, at least not in a hurry. I love the fact that we have Tweak and new ideas etc, but perhaps it is time to grab what we have and make the best of it instead of waiting for Tweak.
So... Juan stepping up and offering his time to produce a clean, maintainable and rejuvenated Morphic is IMHO Right On Cue.
I hope that people raise their voices and give him their support. I then hope that the next release team (3 people that we still do not know who they are) considers giving Juan a slot in 3.10 for this rejuvenation, and I also hope that the board show their support in this. And I hope that Juan is willing to take on the Steward role for Morphic together with a few more brave souls with an interest in Morphic (there are a few I think). I bet perhaps even Dan Ingalls could be interested, but he might be too busy at work.
Cheers, Juan Vuletich
regards, Göran
_________________________________________________________________ Find a local pizza place, music store, museum and more then map the best route! http://local.live.com?FORM=MGA001
I have changed the subject back, because the fastest way to get people angry at each other is to stand by named proposals instead of getting into the substance.
Separating etoys from Squeak will cement a fork. Currently, Squeakland is basically just a different starting point from squeak.org Squeak, because most of the code is the same. If EToys is permenantly removed from Squeak, then the two groups will be divided much more thoroughly. If that happens, then future code improvements will tend to happen to just one fork or the other. Which fork do you think will get Tweak? Think of all your favorite Squeak-using groups, and think of them all independently deciding which fork they will follow for the future.
Sharing an image is painful, but there are benefits to both camps if it can be accomplished. I believe it is doable, but the heads of both the Squeak gruop and the Squeakland group thus far appear to be uninterested.
Let me put it in a positive way. Ultimately, Squeak's direction will be decided by the people who actively take part in it. I still think we should try to be inclusive, as I argued long ago [1]. Further, I think it is too soon to throw in the towel on the squeakland gang. Deleting EToys means we say goodbye to those guys, and we should not yet do that.
-Lex
-----Original Message----- From: Lex Spoon Sent: Thursday, November 02, 2006 12:55 PM
Which fork do you think will get Tweak?
What is the potential that Croquet development will surpass Squeak and make Squeak irrelevant? The advancements that we can expect from Croquet are not just UI based. If we move towards more isolated systems what is the incentive to continue collaboration?
I'm not suggesting that removing eToys will be the cause of major problems; there have been good arguments both ways. I'm saying that we are already isolated and need to work towards being a central location for hosting these advancements. There are a number of diverse community interests that are best served by the Squeak community. Imagine contributing business applications to a croquet community? Hopefully the community will rise to the challenge and work to integrate other efforts.
What I'm suggesting is that we need to find ways to encourage this cross pollination and if we want to benefit from the other development efforts in Smalltalk we need to find a way to mobilize our volunteer community to make this happen. Far from telling people what to do; I'm suggesting that we would benefit from building integration teams to bring in Strongtalk, Tweak, Croquet and the new eToys. We will all benefit from having more users input to help direct where base Squeak goes, instead of letting Squeak float along and possibly sink, or get off track.
As Lex said, "Sharing an image is painful, but there are benefits to both camps if it can be accomplished." I agree.
Ron Teitelbaum
Juan Vuletich jvuletich@dc.uba.ar writes:
To me eToys what you can find in the eToys package. That's why I put it there!
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support
eToys. And they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
You propose to keep almost everything that makes Morphic complicated. Basically, you propose removing the tile-based programming; I'll ignore the uniclasses proposal for now because it is a small amount of code.
I wonder how much impact tile-based programming really has on Morphic, and in particular on class Morph? My gut instinct is (a) a little bit, and (b) that we can do this little bit without making a non-reversable change.
There is an argument that every little bit of simplification can help. But I do not find it such an amount of simplification to be worth cutting off part of the community with such finality. I'd rather have the extra mess, if it meant the Squeakland guys were still associated with squeak.org.
Further, I see nothing that is so hard about making the tile-based programming unloadable and reloadable. It is just like any other partitioning project. Make a tile-based-programming project on Squeaksource, start recategorizing methods and classes, and go from there. If someone cannot do this much, can they really do a major Morphic cleanup?
-Lex
Lex Spoon skrev:
Juan Vuletich jvuletich@dc.uba.ar writes:
To me eToys what you can find in the eToys package. That's why I put it there!
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support
eToys. And they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
You propose to keep almost everything that makes Morphic complicated. Basically, you propose removing the tile-based programming; I'll ignore the uniclasses proposal for now because it is a small amount of code.
I wonder how much impact tile-based programming really has on Morphic, and in particular on class Morph? My gut instinct is (a) a little bit, and (b) that we can do this little bit without making a non-reversable change.
There is an argument that every little bit of simplification can help. But I do not find it such an amount of simplification to be worth cutting off part of the community with such finality. I'd rather have the extra mess, if it meant the Squeakland guys were still associated with squeak.org.
Further, I see nothing that is so hard about making the tile-based programming unloadable and reloadable. It is just like any other partitioning project. Make a tile-based-programming project on Squeaksource, start recategorizing methods and classes, and go from there. If someone cannot do this much, can they really do a major Morphic cleanup?
I just downloaded Juan's removal stuff and the change set sizes are daunting! The changes are massive and it is a enormous job getting the stuff back in the image. I guess a really good packaging, merging and versioning system can help, Monticello2 anyone ?
Karl
Hi Karl,
Karl escribió:
I just downloaded Juan's removal stuff and the change set sizes are daunting! The changes are massive and it is a enormous job getting the stuff back in the image. I guess a really good packaging, merging and versioning system can help, Monticello2 anyone ?
Karl
Great! It is sooo nice to see someone actually looking at it to know what we're talking about! Really refreshing.
Cheers, Juan Vuletich
Hi Lex,
Lex Spoon escribió:
Juan Vuletich jvuletich@dc.uba.ar writes:
To me eToys what you can find in the eToys package. That's why I put it there!
Going thru Lex's list. (Lex, I didn't answer to your post because I think the list should be built by the community, and I didn't want to sound authoritative on this!)
- Tile based programming system. Yes. The central part of eToys.
- Halos. No. Halos are key to Morphic.
- Named morph search. No. I'd put this in 'MorphicExtras'.
- Uniclasses. Yes. They were implemented in Squeak to support
eToys. And they are not Smalltalky to me. However, 'make own subclass' is not eTtoys, and distinct from uniclasses to me.
- SmartRefStream and ImageSegments. No! Why would they?
- Projects and saving projects. No.
- Paint tool. No.
- Flaps. No.
You propose to keep almost everything that makes Morphic complicated. Basically, you propose removing the tile-based programming; I'll ignore the uniclasses proposal for now because it is a small amount of code.
You got me wrong. That is not what I propose to remove or keep. I was asked 'what is eToys?'. That was my answer to that question. This list is useful to open the debate on what to remove and what to keep. But I didn't say my opinion in that debate. I'd glad to remove whatever the community agrees on. If you really want to know what I think, check http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html .
... Further, I see nothing that is so hard about making the tile-based programming unloadable and reloadable. It is just like any other partitioning project. Make a tile-based-programming project on Squeaksource, start recategorizing methods and classes, and go from there. If someone cannot do this much, can they really do a major Morphic cleanup?
If you check http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html you'll see what can I really do. Really. I did it. It is there. Download it and take a look! A look at the scripts can also give you an idea of how hard would it be to make it reloadable.
Cheers, Juan Vuletich
On Nov 2, 2006, at 1:04 PM, Lex Spoon wrote:
... Further, I see nothing that is so hard about making the tile-based programming unloadable and reloadable. It is just like any other partitioning project. Make a tile-based-programming project on Squeaksource, start recategorizing methods and classes, and go from there.
That's not a bad idea. I don't know if we necessarily want to require that a reloadable Etoys package exists before it is removed from the release (however that decision goes), but it would certainly make the decision easier if it did exist.
As Juan mentioned, it sounds like the main problem is a lot of individual methods which had to be edited to remove Etoys references. The quick solution for the reloadable Etoys 3.10alpha package would be for the package to simply contain the original code for these methods as method overrides (overwrites), as a first cut. Of course this is fragile and not too maintainable across releases, so the package could be refactored/improved over time to reduce the number of overrides.
- Doug
Hi Bert,
ahh, this was for stupid me! Great, now (I hope :) I got it.
So it's about Juan's work (which perhaps can be combined with Pavel's work, somehow, or perhaps not: who knows).
For me the speculation now has and end. All that remains is, I will wait for the respective announcement(s), they both will want us to test their good work.
And I'm happy to see that Edgar offered his support to Juan.
Thank you all for the constructive conversation, may the fruits follow!
/Klaus
On Thu, 26 Oct 2006 14:57:38 +0200, Bert wrote:
Am 26.10.2006 um 14:48 schrieb Klaus D. Witzel:
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
Etoys support is in the Morphic base classes, and even in its design - Morphic really only was made to support Etoys. Now, if you want a lean clean Morphic that just supports "business widgets" you have to rip everything related to Etoys out. I think that's what Juan did - but since the base is missing you cannot go back.
- Bert -
Klaus D. Witzel puso en su mail :
And I'm happy to see that Edgar offered his support to Juan.
I support Pavel too, but seems I wish go bolder.
Repeat, I have 3.8.1 SqueakLight (23/12/05) following Juan work .
Without Flaps, Speech, Nebraska, Etoys...
So from a independent source all could know what is doable, and what each new release the unload is harder.
Also try to have small pieces what actual packages , remember "Ladrillos " idea ?
And I do experiments all time ...
How about a votation about a list of system parts what people use, love and think was Squeak becomes a ugly place without ?
Could someone arrange a list of "features " on SqueakPeople and collect result is say a week or two ?
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
Hi Edgar,
I do not believe that Squeak community will run a voting on your suggestions. I learned that Squeak community does not function this way. They probably fear a) to commit themselves without having later a chance to bail out, b) that such a voting could be run quite frequently (2-3 times/year) because everybody can ask for a new run and c) whatever their very personal reasons are: for example a possible incompatibility with one of their favorite package(s), which might be overruled by a voting, to their incovenience.
Instead Squeak community is expecting, IIANM, from you the initial "promoter" of your own ideas:
a - a formal release announcement (alpha, beta, gamma, rc, release), perhaps more or less of these steps.
b - a reasonable commitment that the maintainer fully supports her/his "thing" for a long time, now and in the future.
c - ease of use, (almost) no "do this, then do that, else whatsoever" scripts, easy "how-to", ease of integration, have fun.
This all can (but must not) be done without asking *anybody* whether they like your ideas or not. But being a bit trendy would not harm ;-)
Perhaps you reconsider your suggestion?
/Klaus
On Thu, 26 Oct 2006 18:57:08 +0200, Lic. Edgar J. De Cleene wrote:
Klaus D. Witzel puso en su mail :
And I'm happy to see that Edgar offered his support to Juan.
I support Pavel too, but seems I wish go bolder.
Repeat, I have 3.8.1 SqueakLight (23/12/05) following Juan work .
Without Flaps, Speech, Nebraska, Etoys...
So from a independent source all could know what is doable, and what each new release the unload is harder.
Also try to have small pieces what actual packages , remember "Ladrillos " idea ?
And I do experiments all time ...
How about a votation about a list of system parts what people use, love and think was Squeak becomes a ugly place without ?
Could someone arrange a list of "features " on SqueakPeople and collect result is say a week or two ?
Edgar
Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Klaus D. Witzel puso en su mail :
Instead Squeak community is expecting, IIANM, from you the initial "promoter" of your own ideas:
a - a formal release announcement (alpha, beta, gamma, rc, release), perhaps more or less of these steps.
But I can't do such announcement. What I could, I doing.
1) Following all what Pavel do and supporting. Maybe pushing he a little sometimes.
2) As I was with Juan in Morphic Team and we email sometimes, I know the quality of his works. Maybe I see some work of he not in the public view.
3) I still learning the deeps o Smalltalk/Squeak.
b - a reasonable commitment that the maintainer fully supports her/his "thing" for a long time, now and in the future.
I have for SqueakLight. And hope what someone with more deep Smalltalk made the 3.9 version (and the reason for help/disturb to Pavel and Juan).
SqueakLight began before Pavel works and have different ideas and long time goal.
At this time is one small practical image, have almost all my forces and I try to listen all complaints and do fixes.
I do not believe that Squeak community will run a voting on your suggestions. I learned that Squeak community does not function this way. They probably fear a) to commit themselves without having later a chance to bail out, b) that such a voting could be run quite frequently (2-3 times/year) because everybody can ask for a new run and c) whatever their very personal reasons are: for example a possible incompatibility with one of their favorite package(s), which might be overruled by a voting, to their incovenience.
Not writing to list our feelings or wish list for Squeak raise havoc ? If this is how the cookie scrambles, well , I try to not email for a long time.
Thanks for perspective view. Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
Hi Edgar,
on Thu, 26 Oct 2006 23:01:00 +0200, you wrote:
Klaus D. Witzel puso en su mail :
...
I do not believe that Squeak community will run a voting on your suggestions. I learned that Squeak community does not function this way. They probably fear a) to commit themselves without having later a chance to bail out, b) that such a voting could be run quite frequently (2-3 times/year) because everybody can ask for a new run and c) whatever their very personal reasons are: for example a possible incompatibility with one of their favorite package(s), which might be overruled by a voting, to their incovenience.
Not writing to list our feelings or wish list for Squeak raise havoc ?
Noooo! I was talking about your suggested formal voting process. Apologies if that went wrong. Please post your wishes and concerns. I make this comparision: the community opinion is somethings else than the communities' members opinion: the whole ~= the sum.
If this is how the cookie scrambles, well , I try to not email for a long time.
:) C'mon, you're addicted as everybody else here is, aren't you :)
/Klaus
Thanks for perspective view. Edgar
Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Klaus D. Witzel puso en su mail :
Noooo! I was talking about your suggested formal voting process. Apologies if that went wrong. Please post your wishes and concerns. I make this comparision: the community opinion is somethings else than the communities' members opinion: the whole ~= the sum.
I understand the first time. My Advocatus Diaboli side answer :=)
communities' members opinion: the whole ~= the sum.
Yes . Like Smalltalk/Squeak is a living thing more what a dumb list of classes.
Wait and see.
Maybe follow Pavel and Juan from a loooong distance is safer and wiser.
Or try to see if Etoys load in a image without Etoys is Mission Impossible IV or only something what no squeaker was lucky enough to do. ( Stay tuned)
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
Bert Freudenberg bert@freudenbergs.de writes:
Am 26.10.2006 um 14:48 schrieb Klaus D. Witzel:
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
Etoys support is in the Morphic base classes, and even in its design
- Morphic really only was made to support Etoys. Now, if you want a
lean clean Morphic that just supports "business widgets" you have to rip everything related to Etoys out. I think that's what Juan did - but since the base is missing you cannot go back.
What exactly counts as EToys? It's an honest question. Let's go through some of the potential pieces.
The tile-based programming scripting system? Sure.
The halo system, where every morph can have a halo pop up? That sounds like a generic Morphic thing to me. Anyway, it's very useful, and gives Squeak a lot of its flavor.
The named morphs business, where every morph can be given a name and then searched using morphNamed: ? I find this nice, especially when hacking the system via inspectors.
Uniclasses? I do not use them directly, but I do use "make own subclass", so I hope that much continues to work.
SmartRefStream and ImageSegment's ? I frequently upgrade to a new Squeak image by snapshotting my old workspace and then loading it into the new one. I would hate to lose that. There are also many other uses of serialization.
Saving projects to the network or to disk? I guess this is EToys, and I guess it can be lived without for a suit-wearing programmer writing shades-of-gray programs. Nonetheless, it's pretty cool to have available, although I grant it appears to be a little messy.
The paint tool for bitmap images? Okay, it's not businessy, and EToys requires it, but is it really a part of EToys? I dunno. I'd sure hate to lose this tool though.
Flaps, as Goran mentioned? Flaps are excellent! I sure hope they do not go away!
Hmm, I did not start with a point, but seem to have come to a couple.
1. There is no good definition of EToys. Most of the above things make sense on their own and have their own pros and cons. We should be more specific in this discussion instead of just saying "EToys". Talking about "the EToys code" is a recipe for a silly discussion.
2. There are several components that could be logically carved out. Many of the items in the above list should be removable IMHO. Specifically, I see no reason not to have removable and reloadable packages for: tile-based programming, the paint tool, and the stuff for sharing projects on the network.
2b. Several of these seem very much part of Squeak and/or Morphic. Serialization and uniclasses are core features of Squeak. Flaps, halos, and named morphs are core parts of Morphic.
3. I sure wish I had more time to play with Squeak. :) It would be a lot of fun to tidy up things in the above list and put them in individual packages.
-Lex
Hi Klaus,
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
Elegance and maintainability. Also to make it easier to use Morphic for other purposes (for example, writing applications), that won't use eToys.
If there isn't anybody suggesting that she/he will divide Morphic by Etoys, starting with 3.9 and targeting for example 3.10 or 4.0, then please treat these questions as 100%[tm] rhetoric, thank you.
/Klaus
Well, In this very thread I said I have already done it in 3.7 (meaning I showed that it can be done, that I can do it, and that you can check the quality of my work). I also said I volunteer for doing it once more, in the latest image, if the community wants to adopt it.
I also add here that I would remove only what the community wants removed. I mean, Goran said recently he would like to keep Flaps in. Ok. If we can decide what to remove and what to keep, I'll be happy to follow that decision.
Note that I'm not volunteering to make eToys loadable back in. I already said why.
So, you see, the question is not rethoric at all.
Cheers, Juan Vuletich
Hi Juan,
on Thu, 26 Oct 2006 15:01:12 +0200, you wrote:
Hi Klaus,
Concentrating on the remaining issue(s): why is it so important that Morphic must be independent of Etoys, are they (have they) subclasses etc of each other? Or are there political reasons for having such an independence, or license reasons? Or what (perhaps elegance, perhaps maintainability)?
Elegance and maintainability. Also to make it easier to use Morphic for other purposes (for example, writing applications), that won't use eToys.
Great!
If there isn't anybody suggesting that she/he will divide Morphic by Etoys, starting with 3.9 and targeting for example 3.10 or 4.0, then please treat these questions as 100%[tm] rhetoric, thank you.
/Klaus
Well, In this very thread I said I have already done it in 3.7 (meaning I showed that it can be done, that I can do it, and that you can check the quality of my work). I also said I volunteer for doing it once more, in the latest image, if the community wants to adopt it.
Yes, I'm happy to hearing this, and I thank you!
I also add here that I would remove only what the community wants removed. I mean, Goran said recently he would like to keep Flaps in. Ok. If we can decide what to remove and what to keep, I'll be happy to follow that decision.
Why would he want that? What's his use case for it? Personally I would wait for the outcome of
- http://www.google.com/search?q=designer+sex+kilobuck+site:lists.squeakfounda...
Note that I'm not volunteering to make eToys loadable back in. I already said why.
So, you see, the question is not rethoric at all.
:)
/Klaus
Cheers, Juan Vuletich
Hi Klaus!
"Klaus D. Witzel" klaus.witzel@cobss.com wrote:
Hi Göran,
on Wed, 25 Oct 2006 14:49:09 +0200, you wrote:
Hi!
Ok, let's back up a bit. If I got it right it is all about deciding on one of these three ways forward:
...
- Make eToys reloadable (and throw it out), of course, this is the
"best" route. But who will do it? And if noone steps up to do it, is it okay to pick #2 above instead of #1?
...
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Well, *this* part of the debate made me "tout" the "conspiracy" question in this thread :|
Did you read Pavel's response to this thread. What he says there is, by the time of this writing, (computer-) ages long known to the community: removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse me for the emphasis).
So, how come you still question it? What is it that I don't understand, what exactly are the unknown requirements (and who does require)?
As I know that you now understand my question better (having read the rest of the thread) I still must ask, why the heat? And what "conspiracy" are you talking about?
Curious.
regards, Göran
PS. And as for the flaps that you wonder why I want to keep - many Squeakers use the flaps in various ways. Some probably use the Tools flap for example, I have also seen people embed a Workspace in a flap in order to have it handily available. In short - they are useful for other things than making eToys.
Hi Goran,
on Mon, 30 Oct 2006 00:13:09 +0100, you wrote:
Hi Klaus! "Klaus D. Witzel" klaus.witzel@cobss.com wrote:
Hi Goran, on Wed, 25 Oct 2006 14:49:09 +0200, you wrote:
Hi!
Ok, let's back up a bit. If I got it right it is all about deciding on one of these three ways forward:
...
- Make eToys reloadable (and throw it out), of course, this is the
"best" route. But who will do it? And if noone steps up to do it, is
it
okay to pick #2 above instead of #1?
...
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Well, *this* part of the debate made me "tout" the "conspiracy" question in this thread :|
Did you read Pavel's response to this thread. What he says there is, by the time of this writing, (computer-) ages long known to the community: removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse me for the emphasis).
So, how come you still question it? What is it that I don't understand, what exactly are the unknown requirements (and who does require)?
As I know that you now understand my question better (having read the rest of the thread) I still must ask, why the heat?
I have not seen any heat in this thread. I was just asking my questions (instead of misunderstanding other people's questions and answers) and indeed got the information that enlighted me (and others?).
And what "conspiracy" are you talking about?
Well, Pavel's work seems to be not interesting enough for people (like you?) to put their hands on and judge themselves. Instead [and (ab-)using your PS remarks] it, the work, is questioned. No clear picture. What would/could be the reason for a public such a discouragement? If you understand tit-for-tat, that's why I put the "conspiracy" word in this thread.
Curious.
Hopefully ;-)
regards, Göran
PS. And as for the flaps that you wonder why I want to keep - many Squeakers use the flaps in various ways. Some probably use the Tools flap for example, I have also seen people embed a Workspace in a flap in order to have it handily available. In short - they are useful for other things than making eToys.
But not for every application. So flaps are an option at best and when making things unloadable/reloadable I'd vote for flaps becoming an optional package.
/Klaus
Hi Klaus!
"Klaus D. Witzel" klaus.witzel@cobss.com wrote:
Hi Goran,
on Mon, 30 Oct 2006 00:13:09 +0100, you wrote:
Hi Klaus! "Klaus D. Witzel" klaus.witzel@cobss.com wrote:
Hi Goran, on Wed, 25 Oct 2006 14:49:09 +0200, you wrote:
Hi!
Ok, let's back up a bit. If I got it right it is all about deciding on one of these three ways forward:
...
- Make eToys reloadable (and throw it out), of course, this is the
"best" route. But who will do it? And if noone steps up to do it, is
it
okay to pick #2 above instead of #1?
...
PS. If I am not mistaken Pavel's code does not make eToys reloadable with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Well, *this* part of the debate made me "tout" the "conspiracy" question in this thread :|
Did you read Pavel's response to this thread. What he says there is, by the time of this writing, (computer-) ages long known to the community: removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse me for the emphasis).
So, how come you still question it? What is it that I don't understand, what exactly are the unknown requirements (and who does require)?
As I know that you now understand my question better (having read the rest of the thread) I still must ask, why the heat?
I have not seen any heat in this thread. I was just asking my questions (instead of misunderstanding other people's questions and answers) and indeed got the information that enlighted me (and others?).
Well, AFAIK you came onto me quite hard asking if I had indeed read what Pavel wrote etc, and even using capital letters - when in fact you are the one that got it wrong. Which is fine of course - we all make mistakes, but why pushing it so hard? For example you write "So how come you still question it?" etc, no - I don't "question" it. It is just not relevant in this discussion (for the readers not following this in detail: since Pavel indeed has not separated eToys from Morphic, which is the subject at hand).
Perhaps I am misunderstanding your choice of words and tone, so ok, fine.
And what "conspiracy" are you talking about?
Well, Pavel's work seems to be not interesting enough for people (like you?) to put their hands on and judge themselves. Instead [and (ab-)using your PS remarks] it, the work, is questioned. No clear picture. What would/could be the reason for a public such a discouragement? If you understand tit-for-tat, that's why I put the "conspiracy" word in this thread.
Sigh. I am *not* discouraging the work of Pavel - I am actually very impressed! And btw, I have been advocating Pavel's work in other contexts etc, so no - I am definitely not part of any "conspiracy" against Pavel - though I sincerely doubt there is such a thing. :)
But the point remains - we are discussing the *separation* between Morphic and eToys. Pavel has made Morphic+eToys unloadable/reloadable - but that is a totally different story IMHO, albeit an interesting one.
Curious.
Hopefully ;-)
regards, Göran
PS. And as for the flaps that you wonder why I want to keep - many Squeakers use the flaps in various ways. Some probably use the Tools flap for example, I have also seen people embed a Workspace in a flap in order to have it handily available. In short - they are useful for other things than making eToys.
But not for every application. So flaps are an option at best and when making things unloadable/reloadable I'd vote for flaps becoming an optional package.
I agree in theory, but as for the actual practicality I leave that to Juan. When arguing for flaps I was more thinking along the lines of what kind of Morphic experience we would like to have in the "default" dev image - and I can imagine we want flaps to be in there. But I agree - if it can be made a loadable package I am all with ya.
/Klaus
regards, Göran
Hi Goran,
on Mon, 30 Oct 2006 13:24:40 +0100, you wrote:
Hi Klaus! "Klaus D. Witzel" wrote:
Hi Goran, on Mon, 30 Oct 2006 00:13:09 +0100, you wrote:
Hi Klaus! "Klaus D. Witzel" wrote:
Hi Goran, on Wed, 25 Oct 2006 14:49:09 +0200, you wrote:
Hi!
Ok, let's back up a bit. If I got it right it is all about
deciding on
one of these three ways forward:
...
- Make eToys reloadable (and throw it out), of course, this is the
"best" route. But who will do it? And if noone steps up to do it,
is
it
okay to pick #2 above instead of #1?
...
PS. If I am not mistaken Pavel's code does not make eToys
reloadable
with Morphic still being in the image, right? I presume Morphic and eToys are intertwined. If I am wrong, then hey - that means #3 is already done and we can all just go for it.
Well, *this* part of the debate made me "tout" the "conspiracy"
question
in this thread :|
Did you read Pavel's response to this thread. What he says there is,
by
the time of this writing, (computer-) ages long known to the
community:
removable and reloadable Etoys, etc, IN THE ACTUAL 3.9 IMAGE (excuse
me
for the emphasis).
So, how come you still question it? What is it that I don't
understand,
what exactly are the unknown requirements (and who does require)?
As I know that you now understand my question better (having read the rest of the thread) I still must ask, why the heat?
I have not seen any heat in this thread. I was just asking my questions (instead of misunderstanding other people's questions and answers) and indeed got the information that enlighted me (and others?).
Well, AFAIK you came onto me quite hard asking if I had indeed read what Pavel wrote etc
I asked this silly one because it seemed to me that Pavel wrote at the time between: (your message to me) and: (my response to you). This was not meant hard, just a "have you seen it".
and even using capital letters
... for which I excused me in advance. No need to stress this again.
- when in fact you are
the one that got it wrong.
This was nothing about me getting something right or wrong. I started this thread in order to understand. Please point me to what I got wrong in
- http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110648.h...
and/or what I got wrong in
- http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110707.h...
Which is fine of course - we all make mistakes,
How can I be wrong by asking questions? I do not tolerate you blame me "making mistakes" when I post questions.
but why pushing it so hard?
It is perhaps so that you and I got confused (somehow) on utility of Pavel's work.
For example you write "So how come you still question it?" etc, no - I don't "question" it.
O.K. I respect what you write here in response to my question. Thank you.
It is just not relevant in this discussion (for the readers not following this in detail: since Pavel indeed has not separated eToys from Morphic, which is the subject at hand).
Well, I read the sentence with the "relevance" word as: you're reflecting on yourself. No comment, could possibly cause confusion.
Perhaps I am misunderstanding your choice of words and tone, so ok, fine.
That's quite possible. And it's also possible that I misunderstood your remarks on Pavel's good work.
I want to point out that [part of] my intention was to understand why Pavel's good work would not be relevant, and this question *is* subject in this thread.
And what "conspiracy" are you talking about?
Well, Pavel's work seems to be not interesting enough for people (like you?) to put their hands on and judge themselves. Instead [and (ab-)using your PS remarks] it, the work, is questioned. No clear picture. What would/could be the reason for a public such a discouragement? If you understand tit-for-tat, that's why I put the "conspiracy" word in this thread.
Sigh. I am *not* discouraging the work of Pavel - I am actually very impressed! And btw, I have been advocating Pavel's work in other contexts etc,
Great! Will value your words by the actions that will be seen in the future - no offense intended!
so no - I am definitely not part of any "conspiracy" against Pavel - though I sincerely doubt there is such a thing. :)
O.K. I respect your doubts. (BTW and OT: a "conspiracy" is not a conspiracy.)
But the point remains - we are discussing the *separation* between Morphic and eToys.
This was not so at the beginning of this thread (and so perhaps caused some confusion, between you and me). I agree that *separation* is [part of] the outcome of this thread.
Pavel has made Morphic+eToys unloadable/reloadable - but that is a totally different story IMHO, albeit an interesting one.
I disagree, since I asked for the whatabouts of this story. This is perhaps why you felt I was asking so hard (you and me had different stories). For your convenience, I repeat from my very first message:
quote "I'm neither a proponent nor an opponent of removing Etoys, Morphic, etc. Instead, I'm wondering what this debate might be about ..." unquote.
PS. And as for the flaps that you wonder why I want to keep - many Squeakers use the flaps in various ways. Some probably use the Tools flap for example, I have also seen people embed a Workspace in a flap
in
order to have it handily available. In short - they are useful for
other
things than making eToys.
But not for every application. So flaps are an option at best and when making things unloadable/reloadable I'd vote for flaps becoming an optional package.
I agree in theory, but as for the actual practicality I leave that to Juan.
O.K. let Juan the maker decide what he puts his hands on.
When arguing for flaps I was more thinking along the lines of what kind of Morphic experience we would like to have in the "default" dev image - and I can imagine we want flaps to be in there.
Sure, me too can imagine that the developers want to use flaps.
But I agree - if it can be made a loadable package I am all with ya.
Now *this* was [part of] what this thread was about :)
/Klaus
Hi Klaus!
(this thread is really beaten to death, but whatever - let's beat it some more!)
For the rest - this is a meta-post. We just blabber on about ourselves misunderstanding each other in order to get as far away from the subject as possible! :) :) (a joke)
"Klaus D. Witzel" klaus.witzel@cobss.com wrote: [SNIP]
I have not seen any heat in this thread. I was just asking my questions (instead of misunderstanding other people's questions and answers) and indeed got the information that enlighted me (and others?).
Well, AFAIK you came onto me quite hard asking if I had indeed read what Pavel wrote etc
I asked this silly one because it seemed to me that Pavel wrote at the time between: (your message to me) and: (my response to you). This was not meant hard, just a "have you seen it".
and even using capital letters
... for which I excused me in advance. No need to stress this again.
Fine, just pointing out what I meant with "heat".
- when in fact you are
the one that got it wrong.
This was nothing about me getting something right or wrong. I started this thread in order to understand.
Fine, then please don't accuse me of "questioning" Pavel's work or "discouraging" it or whatever, because I have done no such thing. Ever. On the contrary.
Please point me to what I got wrong in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110648.h...
AFAICT you got nothing "wrong" there - even though I don't agree with you. :) (another story)
and/or what I got wrong in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110707.h...
Nothing wrong - it just contains questions AFAICT.
Which is fine of course - we all make mistakes,
How can I be wrong by asking questions? I do not tolerate you blame me "making mistakes" when I post questions.
I was referring to this post:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110 685.html
In which I think you "got it wrong" about what Pavel has and has not done etc.
but why pushing it so hard?
It is perhaps so that you and I got confused (somehow) on utility of Pavel's work.
For example you write "So how come you still question it?" etc, no - I don't "question" it.
O.K. I respect what you write here in response to my question. Thank you.
Your question states that I do indeed question something, which I don't. Ok?
It is just not relevant in this discussion (for the readers not following this in detail: since Pavel indeed has not separated eToys from Morphic, which is the subject at hand).
Well, I read the sentence with the "relevance" word as: you're reflecting on yourself. No comment, could possibly cause confusion.
I don't follow, but it doesn't matter I guess.
Perhaps I am misunderstanding your choice of words and tone, so ok, fine.
That's quite possible. And it's also possible that I misunderstood your remarks on Pavel's good work.
I want to point out that [part of] my intention was to understand why Pavel's good work would not be relevant, and this question *is* subject in this thread.
Sure, but why didn't you just ASK that then instead of rambling about me questioning it and a conspiracy and what not?
And what "conspiracy" are you talking about?
Well, Pavel's work seems to be not interesting enough for people (like you?) to put their hands on and judge themselves. Instead [and (ab-)using your PS remarks] it, the work, is questioned. No clear picture. What would/could be the reason for a public such a discouragement? If you understand tit-for-tat, that's why I put the "conspiracy" word in this thread.
Sigh. I am *not* discouraging the work of Pavel - I am actually very impressed! And btw, I have been advocating Pavel's work in other contexts etc,
Great! Will value your words by the actions that will be seen in the future - no offense intended!
Likewise. Even though I have no idea why you have any reason to doubt my word.
so no - I am definitely not part of any "conspiracy" against Pavel - though I sincerely doubt there is such a thing. :)
O.K. I respect your doubts. (BTW and OT: a "conspiracy" is not a conspiracy.)
Lost you.
But the point remains - we are discussing the *separation* between Morphic and eToys.
This was not so at the beginning of this thread (and so perhaps caused some confusion, between you and me). I agree that *separation* is [part of] the outcome of this thread.
Ehm, well, you started this particular subject (I think) - but you referred to the *ongoing debate* which was AFAIK started by Juan in this post:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110 359.html
So I was pretty convinced that *this* is what we are talking about. And since I felt people were talking in circles I took the liberty of clarifying the subject in this post:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110 678.html
Which Pavel also verified later (that he has not separated eToys from Morphic).
Pavel has made Morphic+eToys unloadable/reloadable - but that is a totally different story IMHO, albeit an interesting one.
I disagree, since I asked for the whatabouts of this story. This is perhaps why you felt I was asking so hard (you and me had different stories). For your convenience, I repeat from my very first message:
quote "I'm neither a proponent nor an opponent of removing Etoys, Morphic, etc. Instead, I'm wondering what this debate might be about ..." unquote.
And I repeat from your first message (which definitely was not the first in the *debate*):
"Instead, I'm wondering what this debate might be about (myth? conspiracy? who in squeak-dev knows ;-)"
And thus I tried explaining to you (and others) *what this debate* is about indeed.
PS. And as for the flaps that you wonder why I want to keep - many Squeakers use the flaps in various ways. Some probably use the Tools flap for example, I have also seen people embed a Workspace in a flap
in
order to have it handily available. In short - they are useful for
other
things than making eToys.
But not for every application. So flaps are an option at best and when making things unloadable/reloadable I'd vote for flaps becoming an optional package.
I agree in theory, but as for the actual practicality I leave that to Juan.
O.K. let Juan the maker decide what he puts his hands on.
Right - doers decide, and he just posted with a very good list IMHO. I agree with it 100%, again. :)
When arguing for flaps I was more thinking along the lines of what kind of Morphic experience we would like to have in the "default" dev image - and I can imagine we want flaps to be in there.
Sure, me too can imagine that the developers want to use flaps.
But I agree - if it can be made a loadable package I am all with ya.
Now *this* was [part of] what this thread was about :)
Flaps? Then I am totally lost. ;)
/Klaus
I really think we got it off in a strange way here - I have no idea why. I really just want the best from all of us, I really don't question anyones work, I really don't think there is any conspiracy going on, and I really am just one of us.
regards, Göran
Hi folks,
on Tue, 31 Oct 2006 08:46:31 +0100, Goran wrote:
Hi Klaus!
(this thread is really beaten to death, but whatever - let's beat it some more!)
For the rest - this is a meta-post. We just blabber on about ourselves misunderstanding each other in order to get as far away from the subject as possible! :) :) (a joke)
So the two of us decided to settle the meta-issues in harmony and did so despite of a mail blocking "spam firewall" :)
Everybody enjoy the rest of the debate about Etoys, Morphic and other friends ;-)
/Klaus
Hi Pavel,
on Wed, 25 Oct 2006 22:18:57 +0200, you wrote:
Klaus wrote:
...
I firmly believe that this community is not capable of doing anything else.
Hi Klaus, even now is possible to remove Morphic, MVC, eToys etc. from the newest images and load it back, see KernelImage and RestOfSqueak package. Everybody can make step from the endless discussions and contribute with more than several cents :-)
See my response to Göran's.
/Klaus
-- Pavel
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Bert Freudenberg -
Bryce Kampjes -
danil osipchuk -
Doug Way -
Edgar J. De Cleene -
Francisco Garau -
Giovanni Corriga -
goran＠krampe.se -
Herbert König -
Hernan Tylim -
J J -
Jecel Assumpcao Jr -
Jimmie Houchin -
Juan Vuletich -
Juan Vuletich -
jvuletich＠dc.uba.ar
-
karl -
Klaus D. Witzel -
Laurence Rozier -
Lex Spoon -
Markus Gaelli -
Pavel Krivanek -
Ramon Leon -
Ron Teitelbaum -
Stéphane Rollandin -
Todd Blanchard