Are you guys done now with beating up Mark?

Okay, now how about coming back to the point he made?  Which was: Do we 
consider breaking "official" packages to be the problem of the person who 
breaks it or the person who is listed maintainer? While there is not much we 
can do about non-official packages (I sure hope it would be different but I 
don't see how) there is a lot we can do about the official packages. For 
starters we could agree to work in a "full" image instead of a "basic" one 
just so that we can actually *see* what we break if we break it (and maybe 
even fix it).

Second, it would be really helpful if there were some tests which would 
point out what is wrong and where. As a matter of fact I'm surprised there 
aren't any such tests - given the faith in tests shown by the Berne group 
one would expect to find a few of those.

Third, the particular issue with Balloon3D isn't in fixing the (trivial) 
problems - it's the inability to repackage the whole damn thing. Now, to 
anyone of you who has been beating on Mark and who is actually willing to 
fix the problem - you are more than welcome to help out. Just send me your 
info and I'll add you as a co-maintainer to the package. Thanks in advance.

Cheers,
  - Andreas

----- Original Message ----- 
From: "stéphane ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, December 10, 2004 12:31 AM
Subject: Re: A roadmap for 3.9 (Plus, [BUG][FIX] Wonderland in Squeak 3.7)


Hi mark

I tried to include your fixes and ....
surprise....Alice is a project (that apparently I did to be able to
introduce fixes in the past)....so this means that I will have to load
(and prey that I can still load it without crashing my image)
then .... it will takes me may be half and hour if I'm lucky.
Of course if we would have a good packaging system this would take me
around 5 min. But this is a software engineering problem...

> I'll raise a small note of concern.  Having a strong Squeak for powerful 
> engineering and research is good, but only if we don't lose the features 
> that make Squeak so exciting and on the path to a Dynabook.
>
> Case in point: Attached are two changesets for fixing Wonderland in Squeak 
> 3.7.  I haven't been Squeaking for awhile, but had the opportunity 
> recently to explore eToys with Wonderland with my son.  The very first 
> thing I did, "Wonderland new," generated TWO Wonderland editors, with only 
> one of them wired to the renderer.  I did some digging and discovered the 
> change (recent?) making "new" automatically send "initialize," so 
> Wonderland's class method "new" returning "super new initialize" was 
> sending "initialize" twice.  Whump the initialize, and then we can start 
> using Wonderland again.  The second changeset is from Scott Wallace, and 
> it allows for more eToy scripting with Wonderland actors (e.g., for 
> getting and setting X, Y, and Z coordinates).  Thank you, Scott!  (The 
> opinions about Squeak 3.9 voiced in this note are my own and may not be 
> shared by Scott.)
>
> I don't mean to start a debate over whether "new" should send 
> "initialize".  I'll bet that there's a darn good argument based in 
> software engineering for making such a change.

Read the archive because it should talk to you as a teacher.

> The concern I have is that the change was made WITHOUT propagating the 
> necessary changes through the rest of the system.  Wonderland broke, and 
> nobody fixed it.

Yes nobody.

> Wonderland is one of the really cool features in Squeak that I'd really 
> miss if someone forced me to use VW or Dolphin.  In my opinion, a 
> developer making deep changes to a large system has a responsibility

as we would not be concerned. :(
Marc I can tell you building stuff on top of squeak is MUCH more
rewarding than cleaning its inside.
But imagine a city in which the trashes are not removed......So you can
give money to these people for christmax

And thanks for the lesson....I will do some alan kays and dna ingalls
candle burning and may be "flagelations" for our faults.

> to make sure that the rest of the system still works.
>
> A strong software engineering infrastructure is great, but not if it comes 
> at a cost to the media and playful aspects of Squeak.

So if you care so much about Wonderland why don't you maintain it.
There is not often bugs there and this is easy
just takes some times.

Stef

>
> Mark
>
> <OtherWonderlandFix.1.cs><wonderlandFixes-sw.cs.gz>
> On Dec 9, 2004, at 7:38 AM, stéphane ducasse wrote:
>
>> hi all
>>
>> I have been discussing with marcus/alex and also thinking about that 
>> after my remarks on andreas remarks related to
>> changes, interfaces/ cleaning vs changes. So to avoid get frustration 
>> from all the parts and to state clearly what is our
>> plan for 3.9 we would like you to read the following and let us know. 
>> Depending on the reactions, we (the guys from berne) may decide to 
>> produce our own stream, because we must work too ;). But we understand 
>> that other people cannot deal with a system changing. But in that case we 
>> should draw the consequences.
>>
>> Our part that we will work on for 3.9 is to get the system improved from 
>> a developers point of view. We
>> think that having a good foundation is important for everybody.
>>
>> The overall idea is to slowly improve one aspect of Squeak: The idea to 
>> have a System to build the next
>> System with.
>>
>> This has lots of consquences, one is that you want the system to be in a 
>> shape that e.g., students that are not yet
>> complete Squeak experts can start to do experiments with it on a quite 
>> deep level, e.g., change the compiler or
>> add a feature to the Browser.  Another aspect is to have a System for 
>> research. The Traits project has been hugely
>> successful, but it has shown that Squeak does have real problems if you 
>> use it for stuff like that. If Squeak is supposed
>> to be the system of choice for research like this, we need to fix those 
>> problems, we need to make sure that the
>> lessons learned from those projects get fed back into the system. (One 
>> example is the change-notification that was added to 3.7, it is a direct 
>> result of the Traits project)
>>
>> All this does not mean that 3.9 will only be about that stuff: We surely 
>> want to see e.g. the work of Diego beeing
>> included, also any changes that other people would need are welcome.
>>
>> For our perspective here what we would like to have: we put in (p) the 
>> code that  will be in external packages,
>> which likely will be "full".
>>
>> - services
>> - new preferences pane
>> - OB (p?) + browseUnit new version
>> - MC in the base image
>> - rbengine (p)
>> - shout (p)
>> - SqueakMap II (yes we want it)
>> - eCompletion or another package
>> - keybinding
>> - traits
>> - new compiler framework of anthony adapted by marcus to produce
>> not full block. Note that for Etoy the old compiler will still be in the 
>> image so from that point of view
>> it should not have an impact.
>> - refactoring of systemDictionary. (see below this point)
>>
>> We are sure that we forgot something but this is what we have on top of 
>> my head.
>>
>> Now for systemDictionary here is the situation and here is where we would 
>> like to be after 3.9
>>
>> In the past we created SmalltalkImage out of SystemDictionary in the hope 
>> to have SystemDictionary be a nice
>> and simple namespace class. Lot of stuff has been put in coherent places 
>> (SystemNavigation, SpaceTally, Changeset....)
>> But this will not work since people get used to add stuff there and 
>> Smalltalk is a cool name.
>> So the new proposal is the following one and is partly implemented. Note 
>> however that it will require
>> from us a lot of work so if you are against it please say it and we will 
>> only do it for us.
>>
>> from a user point of view we want to have:
>> only one class: SmalltalkImage/SystDict for all the image related 
>> services
>> (VM pluggins, ....) but the namespace behavior will be delegated to 
>> Namespace.
>>
>>        All the previous code referencing Smalltalk will work but with 
>> deprecation for the namespace interface.
>>
>> From the language programmer point of view:
>> there will be a namespace that can be used for experimentation
>> this class will replace the environment class of dan that is now obsolete
>>
>> We plan to proceed that way:
>> - create a class namespace with a new interface (done)
>> - delegate from systemDictionary to this new class (done but not 
>> published)
>> - deprecate all the namespace method of systemDictionary (but we likely 
>> want to keep them for some time)
>> - fix all the in image senders of Smalltalk as a namespace to use the new 
>> class (using self environment for example).
>> (partly done over the previous years)
>> - merge back SmalltalkImage into SystemDictionary: the idea here is to 
>> not have SystemDict as a subclass of Dictionary
>> - have Smalltalk pointing to an instance of this new entity, so that 
>> everybody is happy.
>>
>>
>>
>> Stef and Marcus
>>
>>
>>
>>
>>
> __________
> Mark Guzdial : Georgia Tech : College of Computing/GVU
> Atlanta, GA 30332-0280
> Collaborative Software Lab, http://coweb.cc.gatech.edu/csl
> http://www.cc.gatech.edu/~mark.guzdial/
>