On 4/7/2010 3:25 AM, Edgar J. De Cleene wrote:
> On 4/6/10 2:21 PM, "Josh Gargus"<josh at schwa.ca>  wrote:
>
>> I'm looking at the SL3dot11-9579-alpha.image... is this what you mean by
>> SqueakCore?  I'll assume so.
>>
>> I'm still don't understand what you're trying to achieve, so please help me to
>> understand...
>
> The point is have a common ground between forks.
> As less packages have , more forks could you build on top.

Okay, I still don't get it. Are you saying you expect Pharo, or Cuis to 
build on your kernel image just for its technical merits? That's an 
illusion. Nobody will do that for technical reasons only; the issue is 
decided entirely based on whether the goals and prejudices are aligned.

Moreover, it doesn't make any sense for us to reduce Squeak to the 
smallest common denominator between forks. There could be a basis of 
Squeak that is also the basis for other projects (modulo the comment 
above) but that's not Squeak itself. It's Squeak-core or Squeak-kernel 
or whatever we name it. But "Squeak" is a larger image than that, it's 
the image that we as a community agree on is useful for us.

>> We have that already... anything not in trunk needs to be maintained
>> externally or die.  Is the issue which packages should be included in Core?
>>
>> When I glance at SqueakCore side-by-side with 4.1rc2, they look mostly the
>> same.  There are some packages removed (Nebraska, SqueakMap, Tests,
>> PreferenceBrowser, ScriptLoader, Etoys, Services, Universes, XML-Parser).
>
> Yes. If you read all I put in swiki this years, all this could now live out
> of image.
> All possible users of Squeak need all ? NO.

But the opposite isn't true either. The goal of the standard image is to 
provide a *useful* set of packages, not to be minimal, not to be 
exhaustive. After 4.1 is released I'll be making an argument to 
reshuffle some of the packages - for example, I'd like to see 
Announcements, FFI, Games in, and Services and some others out. My take 
is that the default image currently is actually not large enough and 
doesn't include things that it absolutely should include.

On the other end, I think that the kernel image should eventually get 
down to some 400k in size (this is doable; I have images of that size). 
But to get there, these images will be *useless* for the average 
Squeaker, shipping them as the default image makes absolutely no sense.

> I don't think you need any loader except my modified CodeLoader, but if any
> wish SqueakMap could load on top.
>
> Or Pharo people could load Gofer + Metacello.
>
> We want some similar to Linux or not?

I actually think the Linux model horribly broken from a user 
perspective. But be that as it may, Linux *does* come with package 
loader(s) so your argument is completely backwards. If you want a model 
like Linux you should be *for* package management (rpm, apt, yum) in the 
image.

> SL3dot11-9579-alpha could update and made .cs.
> Also could update the image  using regular .cs in the updates folder , local
> or in Experiments .
> IMHO this opens the doors for any could do local divergent forks using plain
> .cs.
> And share the experiences.

Your fixation with change sets is irritating. Why does it matter what 
exactly happens when you hit the "update" button? I can somewhat 
understand Juan's perspective when having an entirely different image 
where he's basically just cherry picking and steadfastedly refuses to 
use Monticello :-) but since you're only trying to update your image the 
insistence on change sets is irritating, in particular given the 
advantages of Monticello for merging.

> SL3dot11-9579-alpha have a DNU recursive logic which lets download the
> 'missed' classes from server.
> This is the Ladrillos idea of have a Class repository , not a package
> repository like we have now.

That is something I have a fundamental issue with. Stable systems aren't 
built that way. Stable systems are built by using functional components 
(packages) not individual classes. Class references can be used to 
identify package dependencies (in fact that's one of the best ways to do 
it) but the dependency is on the package not the individual class. But 
we can have that discussion some other time.

>> Please, what are some concrete examples of how SqueakCore is easier and more
>> consistent than 4.1?  Even better would be some general principles that we
>> could follow to improve either SqueakCore or 4.1.
>
> So following you, Çuis do not should exist and Pavel Krivanek and Pharo
> people was a lot of fools working all years hard on trying to get a smaller,
> modular and (in my view) smarter Squeak.
> And Craig never should start Squeak 5.0 , Spoon or whatever.
> Digression, what was of this ?

None of these answer the question. BTW, it is really to your 
disadvantage to respond to a concrete question with an attack like this. 
It makes you look as if you can't provide an example of how exactly your 
stuff is better.

> What is easier, maintain a 3000 classes base .image or a 300 classes one?
> If we do not put hard work, never reach a 300 classes image from where grow
> to all happiness.

It is easier to maintain but the other question is: Is a 300 class image 
*useful* for the majority of Squeak users? From my perspective, the 300 
class image is useful only for an extremely small number of users who 
want to build specific images that there nothing with the default Squeak 
image. But it's not a useful image for the Squeak community by and large.

Let me summarize this: I am in favor of providing regular small kernel 
images. I am in favor of ensuring that going forward the core images 
only get smaller, as small as we can make it. I am *stricly* against 
shipping any of these images as "the Squeak image" because they're not 
useful for the average Squeaker. The default image needs to be a 
reasonable tradeoff between compactness, convenience, and exploration.

Cheers,
   - Andreas