A roadmap for 3.9 (Plus, [BUG][FIX] Wonderland in Squeak 3.7)
stéphane ducasse
ducasse at iam.unibe.ch
Sun Dec 12 16:47:56 UTC 2004
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/
>>
>
>
>
More information about the Squeak-dev
mailing list
|