Whither Squeak?

I really to see that.

Stef

On 19 mai 06, at 23:36, Bryce Kampjes wrote:

I agree. We still would like to have all the tests green in 3.9

Stef



>
> However, any serious plan for 3.10 or 4.0 whichever one is next would
> need a few people to volunteer to lead the effort. As always, it's
> those who do the work who get to decide what gets done. Discussion is
> valuable but not decisive.
>
> Bryce
> P.S. I'm away from the internet for the next week on holiday.
>

>
> However, any serious plan for 3.10 or 4.0 whichever one is next would
> need a few people to volunteer to lead the effort. As always, it's
> those who do the work who get to decide what gets done. Discussion is
> valuable but not decisive.

I think that we can talk and create teams and ...
at the end of the day if people do something it happens (see MC1,  
MC2, OB, harvesting).

So I would love to see a spoon-based system (= for my mini image +  
loadable modules)
but I tend to stay away from the team kind of calls where the team  
work one week and
fall apart. (of course this is not the case of Craig) but what we are  
facing now is that
really few people proposed to help for 3.9 harvesting. So each time,  
we have big discussions
about big great plans and people oppose small steps and large ones.
I would say: give me 4 cool developers for 2 years and I will jump in  
big cool plans, now
if you have 2 guys working the night....I let you conclude.

> Bryce
> P.S. I'm away from the internet for the next week on holiday.
Good!

Hi david

We are the faulty guys, but I'm a bit mad, because we spent a lot of  
time trying to improve the system.
And this is like that this is not on purpose that we changed  
ownership. So I will not continue on that path,
but I imagine that you understand what I feel.
Removing mess from this image is not an easy task for multiple reasons.

Stef

On 20 mai 06, at 05:54, David T. Lewis wrote:

On 5/20/06, David T. Lewis <[hidden email]> wrote:
> I'm sorry that I don't have a constructive suggestion to offer, but I
> think it would be really nice if we could come up with a way to preserve
> this kind of contextual information as we evolve and improve the image.
>
I agree.

Personally, though, I think that this could be surved best by a
central repository - the Squeak Museum - where every version of every
method is kept. Add a menu option 'show versions in museum', and
you're there.

This wouldn't make keeping the history dependent on the correctness of
every tool that touches the image.

stéphane ducasse a écrit :

> about big great plans and people oppose small steps and large ones.
> I would say: give me 4 cool developers for 2 years and I will jump in
> big cool plans, now
> if you have 2 guys working the night....I let you conclude.

A promotion job toward corporate and educational institution?
Regarding the corporate supports it looks tricky as the hot stuff is not
 Smalltalk right now. Probably Seaside is really the secret weapon which
can seduce the corporate and try to get support from them. Of course
dealing with the licence is also helpful in this case.
A few big projects related to education would be helpful aswell, but I
don't see any educational institution supporting Squeak development.

Hilaire

Yes this would be nice.

Stef

On 20 mai 06, at 08:51, Cees De Groot wrote:

> Personally, though, I think that this could be surved best by a
> central repository - the Squeak Museum - where every version of every
> method is kept. Add a menu option 'show versions in museum', and
> you're there.

Cees,

you made a great suggestion:

>Personally, though, I think that this could be surved best by a
>central repository - the Squeak Museum - where every version of every
>method is kept. Add a menu option 'show versions in museum', and
>you're there.

I'd visit that museum a lot. And more so if the root is Smalltalk-80 V2.
And much more so if the museum contained some snapshots and sources files from
the past, like from Smalltalk-80 V2. And some virtual machines running on
contemporary platforms, that can read those ancient snapshots, like Hobbes. And
some virtual machines that can save those images as well, like ???.

Greetings
Wolfgang

PS: Only the second part from Dieter Rahm's motto in my signature applies to
this wish list. :-) (in English it says "less but better")

--
Weniger, aber besser.

Hi Dan--

 > I worked out removal of MVC ages ago.  It left a few pieces of
 > Paragraph as I recall, but it was a push-button operation called
 > discardMVC back in those days.

        It may have been automatic to run, but you had to invoke knowledge
about how MVC works to write it. The GC-based removal of inert methods
and classes in Spoon (which removes far more than just MVC) works
independently of the implementation details of the removed behavior, and
is also automatic.

        And it runs in the time it takes to do a full garbage collection (less
than a second).


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Cees De Groot puso en su mail :

> I agree.
>
> Personally, though, I think that this could be surved best by a
> central repository - the Squeak Museum - where every version of every
> method is kept. Add a menu option 'show versions in museum', and
> you're there.
>
> This wouldn't make keeping the history dependent on the correctness of
> every tool that touches the image.
Very, very good !!

As I was talking about a centralized repository of classes of where your
image could load what is needed, this is what want to do.

If nobody objects, I run for being "el portero" (door man / concierge) of
that Museum.

I could start a Museum collecting on "elpelotero" what I share from a while
and when a 24/24 server and management was settled, I put all stuff there.


Edgr



       
       
               
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar 

Hi Ralph

Improving design:
------------------------------
One of the problems is that Squeak did much of its growth without any
explicit package system. As a side effect, these systems usually enforce
a-cyclic dependencies. Cyclic dependencies (considering just
compilation-time-obvious dependencies, like a method in one class
refering to a parent) are rampant in Squeak (see references to Morph),
making it difficult to decompose.

I wrote some code to aid finding, reducing and keeping down the
incidence of such dependencies, called MudPie[1] (available from
SqueakMap, I don't guarantee it works 3.9, but will if there's
interest). DanI wrote some other modularization aid code. Some people
have looked at these efforts, for example Juan, and tried to use them -
I'll let them speak about their usefulness and/or problems. I would call
neither tools, since they didn't include a real UI and such, which is
sufficient cause for them to never have become widely used.

Package system:
--------------------------
I believe that the management of the code of Squeak in tool supported
packages is a critical component of any solution - this is the only way
to keep the boundaries up to date. So the existance of MC exists makes
this task somewhat feasible, but there have been various problems with
its use to manage the whole image.

- Performance (loading updates to the image using MC is much slower than
loading changesets).
- System changes (like introducing Traits) require going through various
intermediate stages, but MC itself only model merging the code in order
to reach the final stage to be loaded.
- Workflow:
-- Support for cherry picking is very basic in current MC (which MC2
should improve).
-- MC is quite workflow agnostic, but maintaining Squeak does require
some workflow (people write fixes, other people merge them), and
maintaining it as a set of packages requires even more of it
(coordination of entry of package changes into the official release).
Right now we use a combination of SqueakSource, Mantis, and email, glued
together by (what seems to me like) lots of overhead.


Daniel Vainsencher
[1] listed in
http://www.informatik.uni-trier.de/~ley/db/journals/cl/cl30.html

Hi Peter,

ineffective is probably the wrong word. Wasteful is better. If 2 software
packages need the same nonstandard base it is likely both would would
bring a copy. This is simple but wasteful and would not work for Squeak.

Torsten

On Sat, 20 May 2006, Peter Crowther wrote:

Hi Stef,
I don't think that this is anybody's "fault" and I apologize if I
sounded that way (especially since I used your initials in the
example, sorry about that).

I just raised the issue because it is important to me, and I hope
that there are ways to improve the tools. For example, Cees suggested
a "Squeak museum", and maybe there are other ideas as well. Thinking
of a "museum" repository makes me think of a sources file implemented
in Magma plus Seaside.

And of course, thanks to Doug Way for Squeak3.9a.from.3.0.image which
shows that the history is not really lost, it's just no longer
visible in recent images:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-January/099299.html

Dave

On Sat, May 20, 2006 at 08:33:59AM +0200, stéphane ducasse wrote: <snip>
> >
> > I'm sorry that I don't have a constructive suggestion to offer, but I
> > think it would be really nice if we could come up with a way to  
> > preserve
> > this kind of contextual information as we evolve and improve the  
> > image.

ok for me.

What I can tell you is that if people do not do it this will not happen.
We will try to get the full history image running but this is not  
really clear that this will work
since MC loading is sooooooooo slow.

Stef

> From: Torsten Sadowski
> ineffective is probably the wrong word. Wasteful is better.

In one sense, I agree with that: Microsoft's MFC libraries must be
copied billions of times around the world, and that's a lot of bits.  In
another sense, I don't: debugging time is expensive, and debugging time
replicated across tens of millions of computers with different
combinations of libraries (so that the same solution cannot be applied
to all) is therefore very expensive indeed.

> If 2 software
> packages need the same nonstandard base it is likely both would would
> bring a copy.

Yes, that's the idea.

> This is simple but wasteful and would not work for Squeak.

At present, it would not work for Squeak.  Maybe it 'should' in some
sense - this would require significant work unless the simplest possible
approach was taken of running each application in its own memory space.
That's the approach taken by most OSs of the last 30 years, now that the
hardware has memory management capabilities.  If we regard Squeak as an
OS-equivalent, maybe we should look at giving some inter-process or at
least inter-application protection.

                - Peter

Peter: "If we regard Squeak as an OS-equivalent, maybe we should look at
giving some inter-process or at least inter-application protection."

Applications are not the core issue, if by "application" one means a
unified, coherent body of code, whose content is governed by a single
distributor (which may be a team or organization,) and where each such
application lives in its own image.  The app dev team can and should be
responsible for ensuring all the necessary versions of the necessary modules
are present and accessible.

The issue is multiple shared libraries (or multiple applications sharing the
same image.)  The former is a necessity.  The latter is only necessary when
Squeak is being used in an OS-like way.

Although some may care deeply about the OS-like usage of Squeak, others may
not.  But integrating shared libraries from multiple, independent sources
into a single image is a problem that affects everyone.  That's the core
issue.  Solve that, and the "multiple application" case will probably be
solved also.

--Alan

On 5/20/06, Alan Lovejoy <[hidden email]> wrote:
> Solve that, and the "multiple application" case will probably be
> solved also.
>
Amen. And I'll just add to that that projects like Islands and
Squeak-E are promising steps into that direction :)

Cees De Groot wrote:
> On 5/20/06, Alan Lovejoy <[hidden email]> wrote:
>> Solve that, and the "multiple application" case will probably be
>> solved also.
>>
> Amen. And I'll just add to that that projects like Islands and
> Squeak-E are promising steps into that direction :)


Yes, if they provide the "Loader Isolation" explained on page 77 of
<http://www.cypherpunks.to/erights/talks/thesis/markm-thesis.pdf>.

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

        Cees writes:

 > ...I think that this could be surved best by a central repository -
 > the Squeak Museum - where every version of every method is kept. Add a
 > menu option 'show versions in museum', and you're there.
 >
 > This wouldn't make keeping the history dependent on the correctness of
 > every tool that touches the image.

        This would be a great remote browsing application for Spoon. Just make
the providing "museum" system read-only.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Daniel, Ralph,

I think Daniel is absolutely right in his focus on cyclic  
dependencies. The difficulty in decomposing Squeak is because of the  
interaction of three factors, IMO:

1) It's awfully difficult to collaborate, especially in ad-hoc,  
distributed communities, without good version control

2) Monticello doesn't deal well at all with large, monolithic bodies  
of code or cyclic dependencies

3) Squeak is large, monolithic body of code rife with ill-defined and  
often cyclic dependencies

As a point of comparison, look at the Seaside sub-community. Seaside2  
has been under version control for its entire life, and the Seaside  
community has generally adopted Monticello for their Seaside  
projects. The issues we've struggled with and repeatedly debated in  
Squeak have been resolved without much discussion or effort in  
Seaside. The code base is modular and generally-well factored. Most  
packages are reasonably well maintained, but even packages with  
absentee maintainers tend to get fixes and "hacked" versions are  
available in one place or another. This works because the Seaside  
community just treats the underlying platform as a mostly opaque  
substrate and builds everything on top of it.

More comments inline:

On May 20, 2006, at 6:42 AM, Daniel Vainsencher wrote:

There are several aspects to this, but the primary one is that MC  
doesn't version code so much as packages. Because of the dependency  
issues in Squeak, packages are either really big, or a "small" change  
touches a lot of them. Either way, it means moving a lot more data  
and doing more work to update image than what is required for a  
change set. In practice, that makes it too slow everyday workflow.

MC2 actually versions code, so it has a lot more flexibility. It  
would be possible, for example, to create an update stream of  
"versioned changesets" that wouldn't carry too much overhead compared  
to the classical update stream.

> - System changes (like introducing Traits) require going through  
> various intermediate stages, but MC itself only model merging the  
> code in order to reach the final stage to be loaded.

Yes. It's surprising how little this has affected at the higher  
levels of the system. (For example, MC can usually update itself  
without problems.) To manage all of Squeak, though, I don't think  
we'll be able to escape having some kind of update stream based on  
filing in arbitrary code.

MC2 can help with this part as well. It can do atomic updates to the  
image, so the cases that require carefully orchestrated migrations  
should be very rare. I'm imagining only issuing updates every year or  
two, and having stuff stay pretty compatible in between updates.

> - Workflow:
> -- Support for cherry picking is very basic in current MC (which  
> MC2 should improve).

Yes. Cherry picking is surprisingly important, and MC2 should do  
merges in general better than MC1 does.

> -- MC is quite workflow agnostic, but maintaining Squeak does  
> require some workflow (people write fixes, other people merge  
> them), and maintaining it as a set of packages requires even more  
> of it (coordination of entry of package changes into the official  
> release). Right now we use a combination of SqueakSource, Mantis,  
> and email, glued together by (what seems to me like) lots of overhead.

Breaking the dependencies is hard work. Monticello is making it even  
harder, because it's really meant to work on systems that are already  
decomposed. It expects to work on packages with stable boundaries and  
acyclical dependencies, and ties versioning very tightly to that  
model. It's too early to say yet, but since MC2 does versioning  
without requiring packages, I'm hopeful that it can help with the  
modularization workflow more effectively than MC1.

Colin