At 00:35 04.06.00 +0300, danielv at netvision.net.il wrote:
> > IMHO the core problem is the still monolithic all-inclusive image that is
> > [create a "standard" base one can expect]
>Seems to me Squeak is too dynamic for that, and so by intention.

Well, this describes the current situation, but I don't know whether I like 
it.  Remembering what Andrew Green said in another posting (talking about 
Python and Squeak), he stated that Squeak is mainly a research tool, not a 
development tool.  If he's true, I dislike that fact.  For me, it's a 
development tool, if not, I'll have to choose some other language (or try 
to make Squeak one :-)  I don't do research - other than playing around 
with some cool technology - I want do develop software - as fast and 
comfortable as possible.

>I don't know how to make integration easy. But we can make sure the
>transmission is trivial, which it surely isn't now. Maybe we can help
>the integration some, too, by noting conflicts with methods that
>changed.

You're right.  Let's solve one problem at the time ;-)  Actually, the 
FileContentsBrowser is a good helper already.  I only which it would have a 
mode to compare syntax trees instead of text lines - VisualWorks 3 has such 
a tool, I think.

> > Of course, you could simply declare version X with updates Y as your base
> > system and life with that.  Perhaps you don't need the latest keyboard
> > enhancement or the Scamper-fix of the day.
>Sure, and then you send silly bug reports to the list, of things that
>have recently been fixed, with detailed explanations on how to reproduce
>them... ;-)

:-)


> > I imagine a kind of sourceforge for Squeak.  You can set of a swiki page
> > for your project, establish an update channel and then work together with
> > other people on that project, posting updates and allowing anymore (or not
> > - one could easily add password protection) to download the project to try
> > it out.
>Too much work. I'm extreme in few things as I am in my laziness. The way
>I see it - creating a project should be as easy and quick as mailing a
>changeset. Publishing a update - sending another changeset with the same
>name.

Ever worked with Sourceforge - it's that easy.  You get your account, get 
your project approved and then you can check in changes via your CVS tool 
and other can get these chanegs back with a click of a button on their CVS 
tool (assuming graphical frontends here ;-)

It also automatically builds up tarballs (complete, compressed source 
distributions) I think and provides a couple of other neat features for the 
user.

> > However, as Bert already mentioned, with over 1000 updates it's getting
> > difficult to startup from ground.  This problem could also affect other
> > projects.  So I'd like to see a way to somehow accumulate changesets,
> > building larger versions people could download if they want to start from
> > scratch.   Although - if you start with CVS, you also have to download
> > everything at the first time - perhaps not that of a disadvantage.
>Didn't understand this paragraph. Please explain?

Let's say I want to try out your project (BTW, what to do plan to create?) 
after you worked on it for six months, creating 500 or so changes.  If I 
then have do download and filein change by change, that's complicated and 
takes a lot of time.  I'd like to download one file (similar to the tarball 
mentioned) which I can load and try-out.

People here already mentioned that it would be nice, if you could query an 
update server for updates 4-10 or so.

Whatever, using sourceforge and CVS, you have the same problem.  If you 
want to get the latest version, you need to download every file, compressed 
and via CVS, which is the same timly and complicated process.

So it's not better - and this was my point: therefore, one could probably 
live with the simple approach....


bye
--
Stefan Matthias Aust \\ Truth Until Paradox