Smalltalk for small projects only?

On 29.01.2012 19:39, Stéphane Ducasse wrote:
>
>>>> No, it does not.
>>>
>>> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.
>>
>> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.
>
>
> You confuse artifacts and models.

No, because in the real world compared to the Smalltalk Theoretic
Perfect World it doesn't matter how things could scale, it matters how
things do scale. See [1]

  [1] http://c2.com/cgi/wiki?SufficientlySmartCompiler

Cheers
Philippe

OOCL and JP Morgan are still using Envy (although I've heard that JPM has purchased a license from IBM and maintains an in-house fork with the latest version of VW). I believe UBS has migrated to Store, but their team is very small and tight-knit. It's been very hard for big distributed shops to migrate SCM from Envy to Store. I think that Cincom has provided consulting support for that but I don't think they've provided any stats on the cost or effort to migrate a typical project.

VA shops continue to use Envy as a supported and effective SCM but I haven't used VA commercially, but I'm assuming it works for them.

It's not surprising that this old stuff doesn't get migrated given how IT projects are funded in general. When you've got hundreds of Java servers spewing errors all day, it's hard to get excited about some old Smalltalk stuff that just keeps the business chugging along.

Cheers,
Steve

On 29.01.2012 19:39, Stéphane Ducasse wrote:
Linus wrote git in two weeks. We would stop all work on the kernel until
we had an SCM that satisfied all this requirements including being fast
and scalable. Isn't Smalltalk supposed to make you super productive?

Cheers
Philippe

I often discuss with Frank Lesser about Smalltalk compiler internals. He has written a Smalltalk VM (GVM), that is written in Assembler and jits Smalltalk directly dynamically into Intel machine code, that is *faster* than C in normal cases, expecially when fine tuned, able to run VS, VA, Squeak, Dolphin, Lesser Smalltalk in their own namespace, and MP!!! Sounds strange, because of different implementations (bytecode, callbacks...). GC runs on a 2.nd processor, what means, no more interruptions, Real Time Availability!!! If you want, you can control all traffic signs of NY within one Intel machine.

He proofes, that Smalltalk, expecially Pharo is far away from being at the end.... :-)

(And yes, i try to convince him to take part in the "language shootout" and make his GVM MIT license) :-)

regards, Guido Stepken

Steve,

Ah yes, the old "it's too hard to do the right thing, so let's do what we want to do" argument. Haha ... no offense taken. As you mention it is easy to fall into that trap.

While it's true that I put a lot of effort into Metacello, it isn't true that "I deserve all the credit" ... nothing happens in a vacuum, significant contributions were made by Stef, Doru, Mariano, Alexandre and others (I guess this is the season for the Academy Awards:) ... thanks, and enough of that:)

Metacello was created to address a specific set of problems that I was having while working on GLASS and those problems were being experienced by a wider group of folks than just myself and the users of GLASS, which lead to it's broad acceptance ...

With that said, I always maintain that there are "more than one way to skin a cat." And Metacello just happens to be one of the ways to skin the cat.

I've been living in the Smalltalk community for most of the last 25+ years so just I don't have the familiarity with the other configuration management systems to do a good job of integrating them into the Smalltalk development environment ...

My take is that it will be "too hard" (right back at ya:), especially for me.

To the extent that I have the time I am willing to offer you (or anyone else working in the area on alternate approaches) constructive criticism as well as advice about what I consider the "barriers to acceptance" are going to be ...

Dale

----- Original Message -----
| From: "Steve Wart" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Cc: "VWNC" <[hidden email]>, "Janko Mivšek" <[hidden email]>, [hidden email]
| Sent: Sunday, January 29, 2012 11:47:34 AM
| Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only?
|
|
| Hi Dale
|
| First let me apologize for using such a horrible IT euphemism. I have
| been hanging around software politicians for far too long. I think
| you deserve all the credit for coming up with an elegant and
| effective configuration management system that has brought many
| parts of the Smalltalk community together to build common, useful
| and practical tools.
|
| Regarding your race suggestion, I think you are right that having
| more choices will be good for the community. I can't claim that I
| don't have resources available - I can come up with a few hours a
| week to work on this. I'll start with the links Frank posted, but I
| think the two approaches in the end may share some common features.
|
| I've been thinking about this idea for a long time but without
| feedback I haven't had the courage to start. Maybe I can finally
| help.
|
| Cheers,
| Steve
|
|
| On Sun, Jan 29, 2012 at 11:13 AM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Steve,
|
| I have two comments:
|
| 1. "inventing the future" doesn't happen by considering
| how "ambitious" it may seem. In the end it is probably
| easier than you think and harder than I think. If it was
| real easy, I'd have been done by now:)
|
| 2. I propose a race:
|
| You start working on your git backend for Smalltalk and
| I'll continue working on Metacello, first one to "git work
| flow" wins ... But then the real winners will be the Smalltalk
| Community...
|
| I have said this before: "I can hardly wait until someone
| invents the replacement for Metacello---it will give me
| more time for other projects:)"
|
|
| Dale
|
| ----- Original Message -----
|
|
| | From: "Steve Wart" < [hidden email] >
| |
| | The idea of building the git workflow on top of metacello strikes
| | me
| | as being somewhat ambitious.
|
|
|
|
|

But the point I think Lawson is making is that there has not yet been
sufficient effort by anyone other than Craig to determine, for sure,
what the exact feasibility of the Spoon system is.

A MNU is too-trivial an issue to give up on the Spoon dream, given the
potential leverage it could offer on the problem of building up from a
micro-image..

On Sat, Jan 28, 2012 at 10:28 PM, Sean P. DeNigris
<[hidden email]> wrote:

But the goal of making the image smaller is congruent with the goal of
making Morphic smaller, which would be congruent with the desire for
Monticello to be "scalable".  So the solution should be smaller
packages, not more and bigger tools.

Besides, the measure of scale you've chosen is an build /
initialization step, which can much more afford to be "slow",
especially if the dream is to just have it sit and build 24 hours a
day.

A better non-scaling measure to recognize in Monticello, IMO, is using
FileBased repositories, which require enumeration of an ever-growing
number of versions for many of its operations.

Using a database-backed MC repository solves that.



On Sun, Jan 29, 2012 at 11:48 AM, Philippe Marschall <[hidden email]> wrote:

On 29.01.2012 22:31, Chris Muller wrote:
> But the goal of making the image smaller is congruent with the goal of
> making Morphic smaller, which would be congruent with the desire for
> Monticello to be "scalable".

What are you talking about? I chose Morphic because it was the first
package I found that had more than a dozen classes.

> So the solution should be smaller
> packages, not more and bigger tools.

You should chose the package size on what makes sense from a software
design point of view, not what the scalability limit of your tools is.

What are we discussing here? What is or the STPF?

Cheers
Philippe

Hi,

We've built a little package that allows us to save all our source in
git. We've been developing with this for 3 months now, and it's pretty
stable. I put a project on github,
https://github.com/finworks/smallsource that contains some more info
on it. Yes, there's more work to do, but there's hope. The repo
contains some examples that I just saved from the image.

In short, we save and load all the monticello packages on our project
as smalltalk source files. We use git to merge and not monticello. We
use metacello, but watered down to essentially just dependencies.

I just want to say thanks to all you people who put in such great
effort into Smalltalk. We are using Smalltalk to create a business and
are slowly getting somewhere.

We've been using git for about 3 years now. This came from a need to
manage files, such as scripts, resources (images and stuff), documents
and recorded selenium (ide) tests with smalltalk code. So, we just
whacked all of this, including our monticello packages into the git
repo.

As you can imagine, storing binary files in a git repo, especially
fairly large packages and lots of integrations / merges / versions,
grew the git repo quite a bit. We also needed to clone the git repo
all over. So we decided to give it a shot and write to files.

It took about 2 weeks to get going and another to sort out some pain,
but the package in the smallsource repo have not changed for 3 months.

We are 5-6 developers on the project, committing numerous times a day.
We currently have about 1100 classes (find repo -type d | wc -l  gives
us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
gives us 23545) managed in this way.

I'm keen to talk about how we can really "do the right thing" and
solve this source code management monster. I know this approach needs
work (I'll list some issues on the project, that I think needs
attention) and I also realise that there could be better approaches.

Here's another idea: we can map class definitions and method
definitions directly to git objects. Git has a great object model
which will allow us to directly track the complete history of a method
or class definition, with commit details and what not. In a sense, I
feel that a tight integration between a smalltalk environment and git
will be a fantastic solution - something like envy, but on git, with
all the fanciness that comes with git!

The only problem with this is a very tight coupling with git. Do we want that?

Thanks again
Otto

On 29.01.2012 21:12, Guido Stepken wrote:
You didn't get my point. My point is tools suck until you fix them. Just
saying you could fix them doesn't fix them.

To rehash the argument:
Me: Monticello doesn't scale
Stef: we could make Monticello scale

Now does this make Monticello scale? In the STPW it does. It the real
world it doesn't until somebody goes there and fixes Monticello.

So what are we discussing the real world or the STPW?

Cheers
Philippe

Chris Muller-3 wrote

A MNU is too-trivial an issue to give up on the Spoon dream

Obviously. I was speaking to the over simplification that no-one-being-willing-to-give-feedback was the key impediment to a bright future, not to Spoon's value.

Otto,

On 29 Jan 2012, at 23:03, Otto Behrens wrote:

This sounds very interesting/promising !

Do you have a writeup/article describing your approach ?

First question: does your system deal with packages as we know them, with extensions ?

Sven

> Do you have a writeup/article describing your approach ?

Some stuff in the README on the
https://github.com/finworks/smallsource. Let me know what you need.
I'm writing more as we speak... :-)

> First question: does your system deal with packages as we know them, with extensions ?

Yes, with extensions. Have not tried traits though.

Otto,

On 29 Jan 2012, at 23:12, Otto Behrens wrote:

> Some stuff in the README on the
> https://github.com/finworks/smallsource. Let me know what you need.
> I'm writing more as we speak... :-)

How can one try this out ?
What to load/install ?

Thx,

Sven

> How can one try this out ?
> What to load/install ?

I added something in the README:

To use it, take a Pharo-1.3 image and just load MonticelloFileTree.
Open a monticello browser and select a package. +Repository has a new
menu item called "file tree"; select any directory on your PC. Save
the package there. You should see a directory <package name>.tree in
the directory after you saved. The GemStone-Extensions package
contains the gemstone hacks to make it work in GLASS.

HTH

Oh, and make some changes in a file (method). Change the timestamp in
the file to be more recent. Load the package. The change should be in
your image.

On Mon, Jan 30, 2012 at 12:46 AM, Otto Behrens <[hidden email]> wrote:

On 01/29/2012 05:02 PM, Sven Van Caekenberghe wrote:
> PS: one of the things that we should take from git, as many others have said on this list, is selective commits.

If I ever get around to picking up Deltas again it would make a really
good tool to enable this on top of current MC (or any other tool of course).

I do have an itch with Deltas but might end up pushing it into Amber first.

regards, Göran

On 01/29/2012 07:02 PM, Frank Shearar wrote:
> - GSOC 2010 had a proposal
> l(http://gsoc2010.esug.org/projects/git-mercurial) - Goran, did this
> get off the ground?

AFAIK, not really.

regards, Göran

Hi all!

I held a presentation regarding SCM in general a few weeks back as part
of a course and in that presentation I try to end it with a view ahead
about what is the Next Step for SCM. So let me go "dreaming" here for a
minute. :)

As many in this thread has correctly identified the main "issue" with
SCM is that when several developers work on the *same* codebase in
parallell it gets hairy, no matter which tool you use. Most open source
projects actually do *not* do that, we normally work on smallish
*different* packages or just a few people on the same package - so we
normally don't get to feel the real *hurt* that a large commercial
project often does. At least that is my perception.

Yes, MC and git are great. Darcs is in some respects even greater in
this particular area (merging, cherry picking etc). But these tools do
not capture what I like to call "developer intent" very good.

git and Darcs etc just manage files, they don't even know what language
we are using. Darcs has something in the "right direction" and that is
the token replace change, which is a small step towards "smarter change
types".

MC knows it is Smalltalk source it is dealing with, but doesn't really
use that knowledge as much as it could.

Deltas that I started working with (and came quite far with the help of
Matthew Fulmer and a few others) goes a few steps further. A Delta
distinguishes developer intent in greater detail than MC and could
potentially be "smarter" because of that.

And this is where the general future of SCM lies I think, in two areas:

- Making SCM tools aware of developer intent. If I use RB to do a
refactoring for example, why not *record that* and not just record the
effects of the recactoring on the source code? If I rename a method in a
class, and fix all senders of it, why not record it as a *method
rename*? That way, if it is merged into another environment it can be
handled much smarter and we could for example fix even more senders.

- Real time collaboration. If we can sit in a shared (in some controlled
fashion) development environment in some kind of real time model, then
lots of merging and conflicts would just say PUFF and go up in smoke. We
are beginning to see this now with the new IDEs running "on the web"
because suddenly it gets very natural to experiment in that direction.

regards, Göran

Hi otto

how to you deal with conflict due to the for example move of methods due to file out?

Stef