Squeak 4.1 release candidate 2

On Sun, Apr 04, 2010 at 05:12:05PM -0700, Andreas Raab wrote:
> Folks -
>
> I've prepared rc2 for testing of the 4.1 release on Squeak.org:

> As it stands, we're currently missing updated Unix and Mac VMs (I know
> Ian has been working on it, so I'll ping him and John separately), we
> still don't have all tests green, and there are still a few open issues
> on Mantis [2].

Using a Unix VM at version level 4.0.2-2172 (roughly equivalent to what
I expect Ian to publish), I ran the unit tests in a 4.1 image updated
to 9902. Aside from expected failures, the results are:

- AllocationTest>>testOneGigAllocation passes, but is marked as an
  expected failure and shows up as an "unexpected pass" in the test
  runner. This is due to workarounds in the test to avoid Unix VM
  bugs, which will be corrected after the VMs are updated (but not
  until then because the bugs lead to crashes).

- WeakRegistryTest>>testFinalization failed once when running the
  full test suite, but does not fail when run as an individual test.

- MCChangeNotificationTest>>testCoreMethodModified failed when running
  the full test suite (two out of three times that I tried the full
  suite), but does not fail when run as an individual test.

None of these seem to be show-stopper concerns with respect to the
4.1 release.

Dave

On 4/6/2010 5:34 PM, Levente Uzonyi wrote:
> Without administrator rights (vm in a writeable directory):
> (SourceFiles at: 1) readOnlyCopy next: 100 ==>
> '''From Squeak4.1beta of 5 April 2010 [latest update: #9885] on 4 April
> 2010 at 4:16:30 pm''!
> ely contr'
>
> (Note that the above is correct, but wrong, the timestamp overwrote the
> license.)

Thanks! You will be awarded an extra-special medal for finding this
issue before ship date :-) A couple of comments on how to deal with it:

1) I could just redo the entire sources file for rc3. I would prefer
that because I'd like to have the stamp in the sources file that says
when new changes have been appended.

2) We could just restore the overwritten license header. This would
leave the current sources file (sort of) functioning unless you already
have a copy. I don't really like that too much though.

3) For issues like yours, we could consider verifying the sources file
by adding a verification, i.e., store a check sum in the image and
verify that the sources match the check sum. In fact I've got code to do
that. HOWEVER, it defeats the idea of being able to share the sources
file between versions (the later sources file by necessity would have a
different SHA). Any opinions?

> In all cases the sources file, the changes file and the image was in a
> writeable directory, so this must be some windows trickery.

Most likely. Can you try searching your entire computer for
SqueakV41.sources and see if digs up any "interesting" locations?

Cheers,
   - Andreas

Hi Edgar -

I just wanted to comment on Josh's post that I feel exactly the same.
I've looked at SqueakLight but I don't understand what I am supposed to
be seeing. Mostly it looks like a trunk image with a bat logo :-)

Answering Josh's question would help me as well to understand better
what you're proposing.

Cheers,
   - Andreas

On 4/6/2010 10:21 AM, Josh Gargus wrote:

About the 4.1 candidate Windows installer: first, nice work; it feels
well-done and I like it.  

There's one thing I ran into, though, that seems awkward.  I installed,
started Squeak, saved the image to a new name; then exit.  Now there's
two images in the squeak install directory, so the launcher pops up the
dialog to let me choose... but it's defaulting to a completely different
location -- not the new 4.1 install dir.  No big deal, really; but the
fact that it's installed way down in
"C:\Documents and Settings\Kevin\Local Settings\Application Data\Squeak 4.1
Alpha", makes it pretty hard to navigate there and find my new image.

I've been following the discussion earlier on, about the "proper" install
location, and I can kind of agree that that makes sense.  But, that's
certainly not a place I'd normally look for things, so if that's where
Squeak is going to keep its stuff, I'd say Squeak needs to remember, not
expect a fresh user to know they should go looking three levels down in
a folder that's not even directly available from the desktop.

I'm not sure where that "Squeak: Please select an image file..." dialog
is coming from; in the VM startup, I think.  Somehow it needs to get
defaulted to the install location, if that's possible.


Kevin Kelley

2010/4/7 Kevin <[hidden email]>:
It's obviously not the expected behaviour. Are you sure you've tried
the latest installer officially available? I made sure proper
directories are passed on on the last one, Squeak 4.1 rc1.
http://ftp.squeak.org/trunk/install/

> I'm not sure where that "Squeak: Please select an image file..." dialog
> is coming from; in the VM startup, I think.  Somehow it needs to get
> defaulted to the install location, if that's possible.

Squeak always do that when it has none, two or more images to choose
from. It's expected by all mean. However, you're correct that it
should use the default installation location. I'll test again and see
what I can do.

Thanks for the feedback.

Ian.
--
http://mecenia.blogspot.com/

On 4/6/2010 8:13 PM, David T. Lewis wrote:
> Using a Unix VM at version level 4.0.2-2172 (roughly equivalent to what
> I expect Ian to publish), I ran the unit tests in a 4.1 image updated
> to 9902. Aside from expected failures, the results are:

Thanks for running the tests, that is *very* encouraging!

Yes, and I think I've taken care of the unreliable tests (the allocation
test is just so that VM doesn't crash so I'll discount it :-) It turns
out that three unreliable cases where all (more or less) easily fixed if
you can just catch them in the act:

* StringSocketTestCase has an assumption about network I/O completing
synchronously. A small wait does wonders.

* WeakRegistryTest similarly assumed synchronous completion although
with better reasoning - it isn't clear to me why sometimes the
finalization wouldn't happen synchronously (I have some suspicions but
not enough time to verify them :-) but again a small wait fixes the
problem 100%.

* MCChangeNotificationTest actually points to a real issue since it
shows that the treatment of package names is not consistent, i.e., some
places assume package names are case sensitive, others aren't. Since
fixing that issue is way beyond scope I only fixed it in a minimally
invasive and localized way.

As far as I know, all tests should now be reliable. If people still find
occasional failures please point them out.

Cheers,
   - Andreas

On 4/6/10 2:21 PM, "Josh Gargus" <[hidden email]> 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.
I think today the small set is Pavel Krivanek PharoKernel.
In fact , I try to understand all work Pavel was doing this years after his
MinimalMorphic which I resurrect for short time.

> 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.
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?


> Why remove XML-Parser but add Comanche?
It's only a experiment in course.
I do not think Comanche should be in any Core, this particular one have it
pre-loaded because I have some students and wish easy.
The idea is start SqueakCore from 4.1 using Andreas procedure.
I start from Squeak3.11-9371-alpha and could follow Squeak trunk without
troubles.

>However, when I look at SqueakCore I don't see the difference that you seem to
think should be obvious.  Can you try to explain yourself more slowly and
clearly, so that I can understand?

Good. You discover SqueakCore and SL3dot11-9579-alpha have the same base
code, what is exact my goal.

Differences.
Until now, you can't download SqueakCore and load updates and you image
continue SqueakCore.
I sure Andreas could do all I do better and hope he do.

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.

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.

Also I work a lot with .obj , squeak objects saved on disk and which could
be used in almost all Squeak forks until now.

> 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.
>
> Cheers,
> Josh

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 ?

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 .

Edgar

On 4/7/10 12:57 AM, "Andreas Raab" <[hidden email]> wrote:
Exact!

As I said to Josh, is your SqueakCore made some weeks before you publish it.

In the Change sorter you should see
9400Collections-ul.309
9401Files-cmm.68
9402Kernel-nice.402
ProtocolBrowser
Lexicon
9403Morphic-edc.347
9404Network-cmm.60
9405ST80-dtl.106
9406System-ul.258

So at this points my fork 'discover' need Lexicon and ProtocolBrowser,
silently load the classes from his folder in server.

This is the point in all the videos I put on vimeo and youtube and one of
the small differences between SqueakCore and my fork.
I wish a smarter Squeak!!!
What a kid hit a fancy button and all Etoys coming from Etoys 4 load on top
Squeak 4.2.
A web developer could have the Pharo look instead the green degrade of
Squeak 3.10.beta and the bat morph loading Polymorph and the scripts for
Seaside 3.0

Also all could see

9549Multilingual-ar.109
9550Network-bp.66
DynamicBindings-edc.11
KomServices-edc .21
KomHttpServer-edc .53
9551Collections-nice.348
9552System-nice.300
9553Morphic-ar.395



As I said , we talking about a experiment in process
User .image could have Kom (in this case) and still follow the trunk and
update only SqueakCore packages.

I like to know if you could tell me the exact number when safely we could do
Smalltalk unloadAllKnownPackages.

Now I know more, could re do form before Squeak3.11-9371-alpha.image, reach
trunk to today and made new clean sources.

Edgar

On 4/6/10 1:38 PM, "Andreas Raab" <[hidden email]> wrote:

> What I really don't understand here is why you think that it's easier to
> do that with change sets rather than Monticello. I've merged lots of
> systems and before Monticello this was an insanely painful process. I
> found that with Monticello this became almost reasonable; still
> difficult but no longer outright insane.

Take fresh 4.0.
Unzip this in same folder and filein first PrepareFor311Updates.3.cs
Now you could update local with
"Utilities applyUpdatesFromDisk" using real .cs
Or "Utilities updateFromServer" load from trunk and made this NUMBERED .cs
from the first day, not several updates later.
Also the update number change .

Regards

P.S. I stop with the first monticello complains, think if we use real .cs no
complains, but is just a theory...



Edgar

Hi Edgar. I appreciate your long-time participation in squeak, so I read your last two messages carefully to find out
what you want. I understood two things:

1. you want the squeak trunk image to be smaller

2. you want automatic code loading in squeak

If I got it wrong, please try again, but write it in one sentence.

Otherwise, the above things sound fun, and they are not appropriate for the 4.1 release. The community was polled, and
spoke clearly: we want a quick 4.1 release to make available all the improvements in the trunk, that can be announced
widely together with 4.0. Andreas proposed an aggressive schedule and we all agreed. In this situation, silence was assent.

So, for more ambitious changes, you should try to get them into trunk, after the 4.1 release freeze has been lifted.
That's how the community will get to see/discuss/validate them. This is standard community software release engineering.

If you felt bad about being passed over as release manager, I can understand, but hard feelings are not justified.
Andreas and the SOB and community accepted your offer to serve in that role. You did not deliver what that role requires
and after some time Andreas gracefully picked up the slack, without shaming or blaming. People often get busy or have
different skills, so we go forward with everyone delivering what they can.

On 4/7/2010 3:25 AM, Edgar J. De Cleene wrote:
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.

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

On 4/7/2010 7:58 AM, Edgar J. De Cleene wrote:
But why is any of this advantageous to using Monticello? I'm not arguing
that you can't do what you describe but from my perspective it is
disadvantageous because:

1) You loose the ability to describe what is included in the image at
each stage. A change set is not a package, consequently there is no good
way to describe what is in an image at any given stage and whether the
contents is "correct".

2) Monticello handles conflicts, change sets do not. If I maintain
images that have modifications to certain methods, Monticello will tell
me that there's a conflict and allow me to decide how to resolve it.

3) Monticello provides context, change sets do not. I can merge versions
in the inbox and see what changes are done, and if they conflict with
changes before or after.

4) Monticello now uses (semi-)atomic loading, change sets do not.

*All* of these are killer arguments in my view.  The first one says that
I can hit the "changes" button for any package that looks modified and
find out if I do have local modifications or if the contents of the
package is the same as in the corresponding Squeak version. I don't need
to have a "virgin" image around just because I don't know if the image
at hand may have modifications.

The second one says that I can update without the fear of destroying any
of my work. In the past, when we used update streams I have had several
location where an update nuked parts of work that I was just doing.

The third one says that the work of an integrator is much simplified.
You can merge changes without fear of having conflicts even if you merge
a distant or old version of a package.

The last one says that I don't need to test (and manually edit) load
order in many situations that you had to before. Since method
installation has been tidied up modifying methods in the compiler is no
problem any longer. Change sets still suffer from this.

Really, I fail to see how anyone can reasonably claim superiority of
change sets for what we're doing at this point.

Cheers,
   - Andreas

Andreas Raab wrote: <snip>
 >
> 3) Monticello provides context, change sets do not. I can merge versions
> in the inbox and see what changes are done, and if they conflict with
> changes before or after.
>
<snip>
>
> The third one says that the work of an integrator is much simplified.
> You can merge changes without fear of having conflicts even if you merge
> a distant or old version of a package.

This one leaps out at me. The maintainer/s of a package, or set of
packages in the case of Trunk are a bottleneck. You can't really get
around that. You probably don't _want_ to get around that, because that
bottleneck has another name: gatekeeper.

But being a bottleneck, we really want to make the maintainers' job as
easy as possible, both for their sanity and for the submittor's sake.
Easy job = rapid feedback on your submission. If you make a maintainer's
life easy, it also certainly won't hurt your code's chances of making it
into the package.

frank

On Tue, 6 Apr 2010, Andreas Raab wrote:

1) sounds ok to me.

>
>> In all cases the sources file, the changes file and the image was in a
>> writeable directory, so this must be some windows trickery.
>
> Most likely. Can you try searching your entire computer for SqueakV41.sources
> and see if digs up any "interesting" locations?

I found a broken copy in a virtual folder (or what) which contains files
which shadow the files in C:\Program Files\*. After removing the broken copy
everything was fine.


Levente

>
> Cheers,
>  - Andreas
>
>

On 4/7/10 12:15 PM, "Simon Michael" <[hidden email]> wrote:

> 1. you want the squeak trunk image to be smaller
>2. you want automatic code loading in squeak
Smaller, modular, smarter. It's my long time try

> we want a quick 4.1 release to make available all the improvements in the
trunk,

Yes, me too.

If I insist on the .cs way (see other mails ) is about my task as Release
member in 3.10.
On each .cs going to the image .
1) Run all test and see if this particular .cs arise new non green test to
the list we know.
2) Check if any of the know troubles of 4.1 shows in this particular .cs

If 1) or 2) shows some is wrong, contact to who made the original .mcz from
where the .cs was made.

So this kind of process is kind of harvest trunk instead of harvest Mantis.

IMHO this only could give us a better 4.1 going to be part of Debian as we
hav right now.

And yes, any taking the responsibility sure have hard time as I have
building 3.10

Edgar

On 4/7/10 12:32 PM, "Andreas Raab" <[hidden email]> wrote:

>
> 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?

No my image.
My image is only a step and is not a kernel one.
In the long run if Pharo guys and Cuis agree ,  yes , a common kernel image
and IMHO could be the Pavel proccedure applied to my image,
I have his PharoCore and studying how to get SqueakKernel instead of
PharoKernel.

> But "Squeak" is a larger image than that, it's
> the image that we as a community agree on is useful for us.

Yes, of course.
Remember I build FunSqueak , trying to have all projects used this days and
some from the past working well in today image.

The idea is push SqueakCore, a update process for SqueakCore and a mechanism
for any 8 years kid hits a fancy button and he/she have Etoys 4 .

We still do not have 4.1 out and discuss a release one or two steps in the
future .

> 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.

> 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


So you really don't believe in the idea...
Ok, discuss what should be in standard and let me polish SqueakLight3.
I try to rebuild from 4.0 (see the other mail about) polish and pack with
some fancy buttons for 8 , 28, 68 and 108 kids :=)

My challenge should be SqueakLight3 follow any trunk have and still be
useful to many.
Not to all, as not all have the same taste about how Squeak should be.

Cheers
Edgar

On 4/7/10 1:12 PM, "Andreas Raab" <[hidden email]> wrote:

> Really, I fail to see how anyone can reasonably claim superiority of
> change sets for what we're doing at this point.
>
> Cheers,
>    - Andreas

Can't say any, your argument is  terrific.
Only one question.
Could we have some similar to
Utilities readNextUpdateFromServer retrieving only the next logic .mcz
coming from trunk?
This one ?
Utilities updateFromServerThroughUpdateNumber:

Suppose my wrong technique say the Closures changes is in 7200 and some
thinking like me but not telling in public wish have a 4.0.1 image.

No change sets for feed the image, but he/she wish have numbered in the
ChangeSorter ?

I attach yours with my modifications.

Is so bad and drive you mad this ? Hurt too much ?.

Edgar

On 4/8/2010 4:14 AM, Edgar J. De Cleene wrote:
>> But "Squeak" is a larger image than that, it's
>> the image that we as a community agree on is useful for us.
>
> Yes, of course.
> Remember I build FunSqueak , trying to have all projects used this days and
> some from the past working well in today image.

What you're saying here seems directly contradictory to what you're
saying below. Here you seem to be saying that the default image should
be one that includes many things...

... but this statement sounds as if you want the smallest possible
kernel image to ship as the default image. Which one is it? Please clarify.

Cheers,
   - Andreas

On 4/8/10, Edgar J. De Cleene <[hidden email]> wrote:
[snip]
> Remember I build FunSqueak , trying to have all projects used this days and
> some from the past working well in today image.

Edgar

would it be possible to try out if some of your Morphic projects you
have there still work in Squeak 4.1? Or could  you send the link to
the project files?

Kind regards
Hannes

On 4/8/10 12:47 PM, "Hannes Hirzel" <[hidden email]> wrote:

> Edgar
>
> would it be possible to try out if some of your Morphic projects you
> have there still work in Squeak 4.1? Or could  you send the link to
> the project files?
>
> Kind regards
> Hannes

No, at this point 4.1 can't load old .pr in my knowledge.
The test with John 4.2.4 VM also fails.
I convert by hand.

So for now you need export first the .cs of your old .pr.
Next you should export all .morph in your World .
And import into the target .image.
This is cumbersome but works.

When time lets I try to see if you could make a automatic .sar which have
the .cs and all .morph into.
Thinks this could work for having old projects into.

The another issue with old projects is in most cases use classes not in 4.1.
For this I have SL3dot11 and his DNU look up in the server for re - load any
'missed' class.

SL3dot11  is SqueakCore with minor changes and I polish for solve all
issues.


Edgar