On 12 déc. 04, at 11:26, Andreas Raab wrote:

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

Andreas I would have no problem to fix what I break if I could access 
it. This is the problem.
The new been called twice cannot be fixed without having access to the 
code. Deprecation practices do not work.

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

Sure. I'm ready for that.

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

:) but the guys from berne have exactly the same number of night day 
that normal humans. So I think that we are doing already much more than 
average.

> Third, the particular issue with Balloon3D isn't in fixing the 
> (trivial) problems - it's the inability to repackage the whole damn 
> thing.

I know.

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

But this is not by adding marcus as maintainer that this will be fixed.

Stef

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