[ANN] Open meeting regarding the Squeak Release Team

stephane ducasse a écrit :
> Andreas
>
> You are probably right.
> May be we went too down the road.
> Now try to explain this guy that merging sophie, croquet, OLPC package
> problems
> is not due to traits.
>

I am not a maintainer of anything serious as above now, but I speak with
15 years of development on ParcPlace ST80 v2.3, Objectworks then
VisualWorks. Sorry for the long answer.


GREAT Squeak CORE IMAGES ... :
-----------------------------

Plainly agree with the idea of a core squeak Kernel.

It is good to have an up-to-date kernel for newcomers and for starting a
new project.

It is good to have prepared packages guaranteed to load into that image
and don't break each other (Universe).

It is good that an up-to-date code repository be in sync with this core
image, TRACING all the evolutions (Monticello).
Better than traditional change log IMO, because it is accessible on
request, but you do not have to download a change log with whole code
history. (Alternative being compress the changes and forget history).


...ARE IN CONFLICT WITH IMAGE-BASE DEVELOPMENT:
----------------------------------------------

But you can not force anyone to adopt your fresh kernel image at each
release.
This won't happen for big application because it is too much work to do
such a port, and this is not how Smalltalk-80 development takes place.

No you don't rebuild your application image everyday with all the tricky
initializations and bootstrap process (circular dependencies), and all
these objects that are not code, and won't reload that easily with code
management tools...
You have something more comfortable, an already initialized image.

No, you won't go through this porting process when you know that some
messages have been deprecated, renamed, some old crappy class replaced
by new shiny ones, or some behaviour improved, the uncompatible way...

No, all these enhancements are not for free, because you'll have to
review your existing code.

Switching to a new image is simply too many changes at once.

What you do is image base development. Developpers do copy an official
image, perform changes, file out changeSet, Monticello or whatever, and
all is integrated back in the official centralized image, where tested
against non regression tests.

Isn't that pretty well what was done during 3.9 and 3.10 process ?
Yes, you smoothly and carefully change THE image.
I personnally downloaded 2 or 3 copies of each.
That's how it works.
You cannot blame major fork maintainer for doing the same.

When i was a commercial VW user and had to switch image, because the old
VM would not necessarily be ported to new machines, that was a pain,
there were ALWAYS some porting necessary.
We always needed a long transition phase. And development had to
continue, so several images were maintained in parallel. What we did was
backporting some of the changes from new official versions to older in
order to smooth the process a little and reduce the difference between
the branches... with change set and change files.

SO WHAT, NO SURPRISE
--------------------

Yes, this explains forks...
That is not a reason for throwing all your efforts away.
Keep developing a core image. This is the best way for integrating all
these necessary clean up and enhancements.

Yes, the core image SHOULD harvest enhancements made in forks too... A
huge ant work! No magic here, only communication and hard work.
Yes write tests and more tests to ease the process.

And what is needed is fine grained changes, that can be examined and
harvested back in forks. If they ever want to port, this will narrow the
gap. LevelPlayingField attempts to answer this very pragmatic goal.

Don't focus on Traits:
- as long as they are not used, they are harmless and won't prevent any
backport.
- Even if used, you can still export equivalent generated code.
- Traits are not a problem unless you yourself want to change Class and
Metaclass.
- Traits could be removed at will before starting a port

Without a doubt, build 3.11 on 3.10. Or if you really want to backtrack,
build on 1.0 for licensing reasons (No, just kidding).

And please, update Mantis status, current management is a mess (issues
harvested but status not updated).

Nicolas

stephane ducasse a écrit :
Don't know if the french expression has any meaning in English, but
steph are you the "hot blood" south european archetype?

Cool down, don't take things as too personnal.
Be patient as a teacher ought to be.
Repeat and repeat again.

And please, don't leave the community!
Threatening should not be the preferred mode of argumentation in this list.

Nicolas

stephane ducasse wrote:
> Andreas
>
> You are probably right.
> May be we went too down the road.
> Now try to explain this guy that merging sophie, croquet, OLPC package
> problems is not due to traits.

I'd say that THE major problem in trying to port Croquet to 3.9/3.10
(which I attempted multiple times) were the changes to the class kernel
- which are a direct result of applying traits. So I'm not sure that
saying "it is not due to traits" is the correct way to phrase it.

Similarly for OLPC/eToys - I think the fact that the changes in the
class kernel make projects from older versions unloadable (which IIRC
was a well-known problem by the time 3.9 was released) may have
something to do with it.

Cheers,
   - Andreas

Could you be more specific about the problems encountered? I'm about to attempt something similar.

Does Croquet involve modifications to the metaclass hierarchy, or does Croquest use ImageSegments in a way that became problematic? What parts of the system in particular were problematic? (Don't dumb down the answer please).

Gulik.


--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Yes, i understand and identified this problem.
But if it really is the only problem, then the easiest thing is to
remove Trait as the first porting operation.

Not that trivial (bootstrap), but should be easier than replaying all
3.9/3.10 changes.

Nicolas


Andreas Raab a écrit :

then they should be removed and we will not have any problems.


On Feb 3, 2008, at 10:18 PM, Andreas Raab wrote:

On 2/2/08, stephane ducasse <[hidden email]> wrote:
> Hi avi
>
> I was not sure that I was clear when I mentioned the window...
>
> Here are some of the changes that have been done in 3.9

Thanks Stef.

Avi

stephane ducasse a écrit :
> Sure I was replying to you.
> If I would have removed all the stuff that I would not be useful to me,
> this is not the 3.9 that you can work with wth all the bugs fixes on all
> kind of places that you would have in your hands. Believe me.
> Now traits are not a problem. We can remove them in may be 2 hours of work.
> If merging Sophie, Croquet, OLPC  would be solved because of that I
> would do it ***immediately*** but this is
> not the problem and if you believe so then believe it, it will make your
> life easier :)


I think that despite all the good work done by Squeakers in this
mailing-list, we have still some communications problems ...

Maybe we could organize a real meeting of Squeak developers, for example
during next ESUG in Amsterdam next august ? I think that a real meeting
could help the community to have a concrete roadmap and achieve the
great reunification of all Squeak forks (Croquet, EToys, ...).

Maybe ESUG (European Smalltalk User Group) could give some money in
order help the developers to attend this event.

Best regards,

--                                                         oooo
Serge Stinckwich                                         OOOOOOOO
Université de Caen>CNRS UMR 6072>GREYC>MAD               OOESUGOO
                                                           oooooo
Smalltalkers do: [:it | All with: Class, (And love: it)]   \  /
                                                             ##

On Feb 2, 2008 7:00 PM, stephane ducasse <[hidden email]> wrote:
>
> You know PHP people implemented stateful traits and apparently some
> want to push that in the mainstream.

I've read all your papers (at least the ones I found) on traits and
stateful traits, but one thing I never saw was: what is the
fundamental difference between stateful traits and multiple
inheritance?

>> You know PHP people implemented stateful traits and apparently some
>> want to push that in the mainstream.
>
> I've read all your papers (at least the ones I found) on traits

there are all on my web pages or on the scg ones.

> and
> stateful traits, but one thing I never saw was: what is the
> fundamental difference between stateful traits and multiple
> inheritance?

conceptually none except that traits are working in the concept of
single inheritance. The point of traits was how can we get the reuse
and expressive power of MI in the simplicity of single inheritance.

About stateful traits, consider what you read as an experiment.
I do not want to push that in squeak or another language. I would like  
to
learn what is really useful and a lot more. This is why we reimplemented
from scratch streams: to see if we really needed "stateful traits" or  
any version
of it. I think that stateless traits are quite stable now stateful  
traits are introducing
too much operators.... What is important to understand is that this is  
not
because we wrote a paper that we like the results :)

Stef