Smalltalk › Squeak › Squeak - Dev

Removing Etoys, Morphic and other friends

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

86 messages Options

12345

Ron Teitelbaum

RE: Removing Etoys, Morphic and other friends

> -----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

karl-8

Morphic reloaded Re: Removing Etoys, Morphic and other friends

In reply to this post by Lex Spoon

Lex Spoon skrev:

> Juan Vuletich <[hidden email]> 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

Juan Vuletich-4

Re: I am standing by Juan's proposal, do you? (was Re: Removing Etoys, Morphic an

In reply to this post by Doug Way

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

Juan Vuletich-4

Re: Morphic reloaded Re: Removing Etoys, Morphic and other friends

In reply to this post by karl-8

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

Juan Vuletich-4

Re: Removing Etoys, Morphic and other friends

In reply to this post by Lex Spoon

Hi Lex,

Lex Spoon escribió:

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

Doug Way

Re: Removing Etoys, Morphic and other friends

In reply to this post by Lex Spoon

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

12345