Proposal for a Squeak migration meeting

Exact

I think that having first class interface or tools to understand what  
is happening at the interface level
is important.

Stef

>
> Colin
>

I would like to reply to all the points in all.
  Andreas I think that the point you raised is correct however
here are some points to consider:

        - We always payed attention not to break (there are lot of changes
        that were never integrated just because of that)
        I can tell you that we have always in mind people making their  
living with Squeak
        the ones that earn real money because they build systems for real  
customers.
        So we are not just academix, daily I talk with netstyle guys and we  
do our best to
        help all the small shops around to make money with Squeak.

        Insulting people never helps (even if they are idiots they have memory)
        I can tell you that when your call us random refactorers we were  
really pleased.
        I wondered why I was pushing squeak. Marcus just dropped because he  
was SICK.
        Of course this does not mean that we have the right to do anything and
        we did not we payed attention not to break but indeed we have failed  
in some points

        Been a victim is always easy (even if this is good that you raise  
this **important** question
        this is important since we are always thinking about it: else we  
would not have push
        unit testing, writing article to educate people on that, pushing a  
lot of engineering tools
        such as a good test coverage testing tool and may be soon a test  
server).

        Now did you compute the ratio of changes and the numbers of problems?
        Because your noise ratio should also be computed: is it 1 on 5000  
changes? 1 on 2?
        What are the tradeoffs/how much? What is the overall quality  
improvement?
        How much tests did we bring inside the system?
        How much bug fixes? If changes would be for less quality this would  
be really a HUGE
        problem to me.

        Of course we made mistakes like letting people introducing wrong  
dependencies.
        I think that we lack some integration analysis tools: to compute the  
interface per client
        but this is difficult.

        - For some changes we let diego pushed his changes because we wanted  
to avoid
        forks, and this is our big mistake. We should have say to Diego that
        what he was doing was cool but that we could not integrate and let him
        grows his own basis until the point where we cannot communicate  
anymore.
        Because nobody would have reviewed 600 k of changes. Or this would have
        been taken 2 more years and everybody would have been frustrated:  
but may
        be having a not moving community is also a goal.
       
        I will talk with him this week about that face to face.
        Apparently this is a common strategy, when I see that SqueakLand was  
not really
        communicating with one of his biggest believer. It was fun to see  
the rush to
        do a fast track 3.8 as soon as we announced that we wanted to push  
in Squeak
        his changes. I understand that people should control their software  
basis, hence
        I understand iSqueak and all the rest.

        - A good way to make sure  that changes
        happen in the way you do not like is to say nothing during months
        and just complain at the end. Of course, you did not have the time (and
        we are so "random refactorers" that we have so much time doing  
nothing).

        - All in all I think that migrating to the changes after a year
        (because 3.9 started more than a year ago) is fair, especially if  
you have no time before.
        There is nothing like a free lunch and some stuff should be changed.
       
        - I think that we should have more tests and interface checking at  
package level
        if this is possible (I have no idea) and this would help us.

        - I think that the general solution to all these problems is  
certainly what we will
        do in the future. Create our own fork like that everybody will get a  
stable
        immutable version, and this will fit well the plans of certain people.
        Because this situation is not satisfactory for us too. We would like  
to move much faster
        and deeper. So we will count our forces and see what we do after 3.9.

        - After you can say a lot on 3.9 and a lot of negative points:
                we used MC (and this is slow xxxxx)
                this is bigger than expected
                ...
                this is all true
                we take responsibility for that and we would have loved to do it  
better
                but so far none of us is payed to work on any squeak projects.
                So giving the context, the constraints I think that we did well
                it does not mean that we cannot improve but we did well.
Stef

Andreas Raab a écrit :

No, you get a very good point. API change is the nightmare of software
developer. You just fell frustrated to spend time to re-write already
done things. I remember experiencing such frustration with pre-2.0 Gnome
libraries.
We may want to have cycle of stable API version of Squeak, inlcuded in
the road-map.

Hilaire

>> True.  Though if few enough people are moving to new versions as they  
>> come out, it's not a very good sign.

That is true, but also depends on what "coming out" means. We usually
don't consider moving to a new version until the final release is out.
I, for my part, am more than willing to go through some major efforts to
port stuff to a new version, once it's out.
But, and that is the same in other systems as well, if you have a
running system in maintenance mode, you don't port it anyways. Fortran
IV anyone?

Regarding backward compatibility: many moons ago I had to port a system
with about 100 packages to a new ObjectWorks version and used the
backward compatibility packages to make my life easier. So I thought. I
would have saved a lot time and effort and gained a much more robust
system if I hadn't done it.

New major Squeak versions come out about once a year, the last two gave
us m17n and now traits. I think it is well worth the change in APIs.

And if the people doing the harvesting work made mistakes in
refactoring, who is the flawless developer who is going to throw the
first stone?

But then, I'm just the engineer...

Michael

Hi Stef -

I'm actually way beyond where I want to discuss these issues. I've been
trying to leave that stuff behind but when a message like Lex' comes in
where it basically says that it's my fault that Tweak doesn't work in
3.9 (as if it were by my choice) it just annoys me to no end.

The question I was raising, however, was and is serious: What, if any,
is the plan for the metaclass kernel? Are there, for example, any plans
for major traits refactoring? If so, it'd be nice if a little bit of a
strategy could be layed out so that, for example, I can plan accordingly.

Cheers,
   - Andreas

stéphane ducasse wrote:

Hi Stef,

on Tue, 11 Jul 2006 08:35:44 +0200, you wrote:

> I think that having first class interface or tools to understand what is  
> happening at the interface level
> is important.

And I think that interface is only a word instead of a discipline. For a  
Smalltalker any Smalltalk interface is highly dynamic but she can only  
master (achieve, use, etc) it by carfully coding her needs resp. obeying  
the other side's requirements (on and on, from release to release, as  
Andreas illustrated recently). Encapsulation etc does not help much when  
dealing with interfaces...

Is anybody out there considering interfaces as first class objects, for  
example negotiable where both sides can ask for and offer capabilities  
*before* they are used?

/Klaus

> Stef

> I'm curious but is my position in this discussion really so outrageous?
>
> Cheers,
>    - Andreas
>

No, you are right. There will be no good for Squeak "going forward"
and ignoring things that got broken it is illusion of progress.

Vaidotas Didžbalis

[hidden email] puso en su mail :

> My first job in that department would be to give KomHttpServer a 3.9
> overhaul of course.
What you mind here , Goran ?
I have KomHttpServer (and HttpView2) working happy in 3.9

Edgar



               
_________________________________________________________
Horóscopos, Salud y belleza, Chistes, Consejos de amor:
el contenido más divertido para tu celular está en Yahoo! Móvil.
Obtenelo en http://movil.yahoo.com.ar

Thanks mike.
We need to improve and build tools to help us controling changes.
I can tell you that merging fixes of parts you believe you know is  
difficult so when you do not known this is terrible.
Especially since I care not damaging the system.

Stef


On 11 juil. 06, at 09:19, Michael Rueger wrote:

Andreas Raab <[hidden email]> writes:
> Lex Spoon wrote:
> > This is
> > different from Morphic, where Morphic was initially available in
> > Squeak right beside MVC.
>
> But what is your point, exactly?
[...]
>
> And for the records, the reason why Morphic was initially available in
> Squeak right beside MVC was because the people who worked on it (SqC)
> had control over BOTH.


I had no point.  There are more people involved in Squeak now, and
there is more going on, and so things are just more complicated now.


Distributions would help with this problem.  I did a distribution for
Squeak 3.7 [1], and I think the basic techniques would work fine for a
3.8-based distribution.  A distributions approach would mean that the
primary development groups only need to *generally* cooperate;
distribution maintainers would then do all the little details needed
to make all this different software coexist.


-Lex



[1] http://minnow.cc.gatech.edu/squeak/3835

On 11 juil. 06, at 09:27, Andreas Raab wrote:

> Hi Stef -
>
> I'm actually way beyond where I want to discuss these issues. I've  
> been trying to leave that stuff behind but when a message like Lex'  
> comes in where it basically says that it's my fault that Tweak  
> doesn't work in 3.9 (as if it were by my choice) it just annoys me  
> to no end.

true I did not read that :)

> The question I was raising, however, was and is serious: What, if  
> any, is the plan for the metaclass kernel? Are there, for example,  
> any plans for major traits refactoring? If so, it'd be nice if a  
> little bit of a strategy could be layed out so that, for example, I  
> can plan accordingly.

Right now we do not have plans. But I would be really interested  
discussing one.
What adrian tried is to avoid duplication. I do not believe that this  
is the best design and
I would really favor a rewrite of the kernel from scratch but this is  
not high priority.  I think that the metaclass kernel
is stable and I would like to get back one of your test green.

Stef

I know I was thinking something in the vein of dynamic interfaces of  
Benny Sadeh (JOT)
to check changes /dynamic changes. Hence I was interested in the  
application of Goya.



On 11 juil. 06, at 09:38, Klaus D. Witzel wrote:

Hi Stef,

on Tue, 11 Jul 2006 14:27:24 +0200, you wrote:

> I know I was thinking something in the vein of dynamic interfaces of  
> Benny Sadeh (JOT) to check changes /dynamic changes.

Yes, JOT is a good approach but, because its J-mimicry suffers from the  
possibility to use reflection for offering (and for negotiating) an  
interface (sorry Mr. co-author ;-) What I have in mind is a single method  
on the class side which answers the *offered* interface in form of an  
intelligent object which is modeled analogue to Teachable, see draft at  
the bottom.

> Hence I was interested in the application of Goya.

Here we go: tell me two system categories or two non-overlapping subsets  
of classes and, if the interface is covered somehow by TestCase(s), using  
Goya I can tell you who does what (re. my informal pres. in Bern).

/Klaus

=========draft==================

!MyObject class methodsFor: 'interface-negotiation'!
interface
        | negotiable |
        " offer getter+setter for value named #attribute "
        negotiable := NegotiableInterface on: self " <= self is MyObject, a  
behavior ".
        negotiable offer: #attribute initialValue: nil.
        negotiable offer: #attribute: subDomain: Collection.
        ^ negotiable!!

...use...

        interfaceOnMyObject := MyObject interface " <= this is analogue to #new  
but returns an interface instead of an instance ".
        self assert: (interfaceOnMyObject offers: #attribute forMeAs: #getter)  
description: 'bad interface'
        self assert: (interfaceOnMyObject offers: #attribute: forMeAs: #setter:)  
description: 'not allowed to change this value'
        " imagine the use of blocks for queries "

...etc

Andreas,

I am going to jump in here; apologies if I am out of synch with the
thread.


=================================
Well, if you were me, you would *want* to update. But you would have
noticed that things got so inconsistently broken at the metaclass level
that unless there are major pay-offs, it simply isn't worth the effort.
That's what happened from 3.6 to 3.7. In 3.8 there was a major payoff -
the m17n integration. That's why I then spent the time needed. For 3.9,
from a Tweak POV there isn't that much interesting in there, so rather
than going through the painful porting exercise yet again I'll probably
spend my time on bootstrapping a stable (3.8-based) metaclass kernel
which can be used in parallel to the 3.9 kernel. Which is not
particularly nice but in the absence of any inclination towards stable
APIs the only alternative that I can see.
=================================

One of the great things about Squeak is one's ability to pick a version
and stick with it if appropriate/necessary, but in general, I would
rather benefit from continued development.


=================================
> I have some legacy Seaside applications in ancient 3.6 images that run
> just fine. They rarely change. They simply run fine. I won't port them
> to 3.9 and a recent version of Seaside. These applications don't
> require anything more as it is available in 3.6. However, for new
> applications I take 3.9, I love
> Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to
> keep up-to-date as long as it improves my productivity.

You're totally missing my point. Let's take one example from your list:
ToolBuilder. Let's say you've got some work that uses it, would you
really expect that in each new Squeak version you have to spend major
effort to port your code to the latest ToolBuilder version? Or wouldn't
you rather expect that there is a stable API that can be used and that
may be extended over time, or even broken, but if it's broken that you
may get some notice about it beforehand? Or, in particular when the
changes get really fundamental, that instead of modifying ToolBuilder
in-place you get the offer to use either ToolBuilder (working the way it
always did) and whatever the brand-new framework of the day is?

I'm curious but is my position in this discussion really so outrageous?
=================================

Agreed about stable APIs in general, and ToolBuilder in particular.  One
can go further by having deprecated features that lurk for a release or
two giving people time to make a smooth conversion.

Now for the controversial part:  I have a concern about Tweak's compiler
extensions.  At STS05, I saw a demo of Tweak's bleeding edge state at
the time, and could not help thinking the extensions were creating an
avoidable complexity, or were at least in the wrong place.  If you want
to simplify life for beginners, then I think you could manage the event
wiring for them w/o forcing it on advanced users.

I wonder whether some of the resistance you sense is regarding Tweak's
design rather than any of your thoughts about frameworks, which seem
quite reasonable to me, at least as far as I have been able to follow
the discussion.

Sincerely,

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

"Philippe Marschall" <[hidden email]> wrote:
> > As a datapoint I work in 3.8. I will try to move to 3.9 when it seems
> > fruititious - but I probably will not work in it until Seaside, Magma
> > and a few other important pieces are stabilized in it.
> >
> > My first job in that department would be to give KomHttpServer a 3.9
> > overhaul of course.
>
> Seaside and Kom work quite nicely in 3.9 today :)

Oh, good! :)

> Philippe

regards, Göran

> As a datapoint I work in 3.8. I will try to move to 3.9 when it seems
> fruititious - but I probably will not work in it until Seaside, Magma
> and a few other important pieces are stabilized in it.

As a datapoint Magma will be ported to 3.9, but I have not had time to
even look at that yet.

 - Chris

Hi Bill -

> Now for the controversial part:  I have a concern about Tweak's compiler
> extensions.  At STS05, I saw a demo of Tweak's bleeding edge state at
> the time, and could not help thinking the extensions were creating an
> avoidable complexity, or were at least in the wrong place.  If you want
> to simplify life for beginners, then I think you could manage the event
> wiring for them w/o forcing it on advanced users.

This is an interesting question: I'd be curious why you feel the event
wiring is forced on advanced users, since you can always replace, e.g.,

Foo>>onBar: arg
      <on: bar>

with:

Foo>>initialize

     self startScript: #onBar: when: {self. #bar}.

And if you have a proposal for how one can avoid the two problems that
annotations are addressing (the ability to have multiple methods react
to the same event and the ability to avoid "extra" initializers to set
up the wiring) I'd really be interested. There are other advantages by
formalizing the event wiring, such as the ability to display this
information in the browser and to update running instances when the
wiring changes, but I'd certainly think about it if you have a proposal
for how to do it differently.

Cheers,
   - Andreas

On Tue, 11 Jul 2006 00:56:21 +0200, Andreas Raab wrote:
...
I'm trying to understand the issue, broken at the metaclass level, and  
downloaded (and updated </phew>) Tweak3.8-6665 and begun browsing the  
code. Mind to give a handful of directions what to look for to find things  
broken at the metaclass level, thank you in advance.

Also, does "broken at the metaclass level" rather belong to the structural  
phenomena species or is it perhaps possible to specify an interface which  
makes your code, without changing anything except perhaps use of #new,  
adaptable to the various versions of metaclass level. I'm willing and able  
to write such an interface, and Tweak for me would be a large enough  
system for pulling out of the "proof of concept" corner a new kind of  
interface.

And, btw, is there ANYTHING (google was of no help) which documents what  
you've done to the compiler, for example a new syntax diagram and/or a  
COMPLETE list with "what is for what"?

> I'm curious but is my position in this discussion really so outrageous?

Not at all :) It's all request-and-response and if Hilaire would have  
known the answers in advance then nobody else would have learned anything.

/Klaus

> Cheers,
>    - Andreas
>
>

Klaus D. Witzel wrote:
> And, btw, is there ANYTHING (google was of no help) which documents what
> you've done to the compiler, for example a new syntax diagram and/or a
> COMPLETE list with "what is for what"?

No there isn't, but fortunately it's not much ;-) Here you go:

a) Method Triggers: These are annotations which bind events to methods.
Three forms exist:

   <on: eventName>
   <on: eventName in: signaler>
   <ticking: frequency>

The first two bind specific events (potentially signaled in a field of
the receiver) the latter binds the ticking event to a frequency.

b) "Remote" assignments: Simply a transformation of assignment to
message form that allows you to write stuff like:
        foo color := Color white.

which gets translated into

        foo color: Color white.

I like this a lot because it allows us to be precise about whether we
think of changing an attribute or requesting a service.

c) Positional arguments: This is only used in Croquet right now and
allows you to call methods with foo(a, b, c) syntax, e.g.,

        opengl glVertex3f(0.0, 0.0, 0.0)

Very, very useful if you want to integrate an existing API.

Cheers,
   - Andreas

Kewl, very kewl. Thanks for taking the time.

/Klaus

On Thu, 13 Jul 2006 10:39:37 +0200, Andreas Raab wrote: