Smalltalk › Squeak › Squeak - Dev

Squeak4.4 RC1 is available

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

Chris Muller-3

Squeak4.4 RC1 is available

http://ftp.squeak.org/4.4/Squeak4.4-12303.zip

I suggest we use a consistent naming convention that conveys the
general ("4.4") and specific ("-12303") version information. After a
week has gone by for the community to download and verify it, there is
no need to deploy yet another (renamed) image, so the "candidate" is
truly a candidate for release -- the one that was tested. Then all we
have to do is [ANN]ounce.

That it is in the "4.4" release directory rather than the "4.4alpha"
directory, anyone will know this is THE candidate for release. In the
past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip"
-- which could still do for alpha images if we want to be sure the
names themselves carry a "quality disclaimer" tag.

David T. Lewis

Re: Squeak4.4 RC1 is available

On Sun, Dec 16, 2012 at 03:16:23PM -0600, Chris Muller wrote:
> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip
>
> I suggest we use a consistent naming convention that conveys the
> general ("4.4") and specific ("-12303") version information. After a
> week has gone by for the community to download and verify it, there is
> no need to deploy yet another (renamed) image, so the "candidate" is
> truly a candidate for release -- the one that was tested. Then all we
> have to do is [ANN]ounce.

Yay!

One glitch - the image and changes files unpack as read-only on my (linux)
box. If you could re-zip them after a chmod +w, that might save some
confusion.

And a SqueakMap issue (?) The Squeak version is "Squeak4.4" and the
version tag in SqueakMap is "Squeak 4.4". I think this may be causing
SqueakMap to say that the "Squeak 4.4" packages are not compatible
with the image.

Thanks,
Dave

Chris Cunnington

Re: Squeak4.4 RC1 is available

In reply to this post by Chris Muller-3

On 2012-12-16 4:16 PM, Chris Muller wrote:

> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip
>
> I suggest we use a consistent naming convention that conveys the
> general ("4.4") and specific ("-12303") version information. After a
> week has gone by for the community to download and verify it, there is
> no need to deploy yet another (renamed) image, so the "candidate" is
> truly a candidate for release -- the one that was tested. Then all we
> have to do is [ANN]ounce.
>
> That it is in the "4.4" release directory rather than the "4.4alpha"
> directory, anyone will know this is THE candidate for release. In the
> past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip"
> -- which could still do for alpha images if we want to be sure the
> names themselves carry a "quality disclaimer" tag.
>

I like that it's small and avoids the problem I had of the menu opening
up beyond the World. Fits perfectly always.

Chris

Chris Cunnington

Re: Squeak4.4 RC1 is available

In reply to this post by Chris Muller-3

On 2012-12-16 4:16 PM, Chris Muller wrote:

http://ftp.squeak.org/4.4/Squeak4.4-12303.zip

I suggest we use a consistent naming convention that conveys the
general ("4.4") and specific ("-12303") version information.  After a
week has gone by for the community to download and verify it, there is
no need to deploy yet another (renamed) image, so the "candidate" is
truly a candidate for release -- the one that was tested.  Then all we
have to do is [ANN]ounce.

That it is in the "4.4" release directory rather than the "4.4alpha"
directory, anyone will know this is THE candidate for release.  In the
past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip"
-- which could still do for alpha images if we want to be sure the
names themselves carry a "quality disclaimer" tag.

Smalltalk appendChangesTo: 'SqueakV44.sources'

Would shrink the image a couple of M, but fails with Error: Unmatched string quote. (It failed when I tried to use it on 4.3 as well. Which is why Squeak 4.3 did not have a SqueakV43.sources)

Smalltalk unloadAllKnownPackages

in the Future Directions welcome workspace fails with Error: Unmatched string quote. Both of those problems relate to the Scanner.

Chris

Stéphane Rollandin

Re: Squeak4.4 RC1 is available

In reply to this post by Chris Muller-3

Feedback:

When you open a browser in the new image, the "instance" button is not
large enough.

Also, why have system windows become so narrow ? It makes them really
impractical IMO.

Stef

Stéphane Rollandin

Re: Squeak4.4 RC1 is available

> Also, why have system windows become so narrow ? It makes them really
> impractical IMO.

RealEstateAgent initialize makes them 600@400 again, so I guess this is
a glitch in the image building.

Stef

Bert Freudenberg

Re: Squeak4.4 RC1 is available

In reply to this post by Chris Muller-3

On 2012-12-16, at 22:16, Chris Muller <[hidden email]> wrote:

Nobody can know this from the URL. It looks like an actual release, because *nothing* indicates that this is not a stable version.

> In the
> past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip"
> -- which could still do for alpha images if we want to be sure the
> names themselves carry a "quality disclaimer" tag.

I'd prefer this, yes. Although we're way past alpha. This is a release candidate, after all:

http://en.wikipedia.org/wiki/Software_release_life_cycle

- Bert -

Frank Shearar-3

Re: Squeak4.4 RC1 is available

In reply to this post by Stéphane Rollandin

On 17 December 2012 10:09, Stéphane Rollandin <[hidden email]> wrote:
>> Also, why have system windows become so narrow ? It makes them really
>> impractical IMO.
>
>
> RealEstateAgent initialize makes them 600@400 again, so I guess this is a
> glitch in the image building.

I noticed this and thought I'd fixed it. At any rate, it's definitely
fixed now, and a new version's ready for deployment as soon as some
admin's done.

frank

> Stef
>

Frank Shearar-3

Re: Squeak4.4 RC1 is available

In reply to this post by Bert Freudenberg

On 17 December 2012 12:12, Bert Freudenberg <[hidden email]> wrote:

> On 2012-12-16, at 22:16, Chris Muller <[hidden email]> wrote:
>
>> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip
>>
>> I suggest we use a consistent naming convention that conveys the
>> general ("4.4") and specific ("-12303") version information. After a
>> week has gone by for the community to download and verify it, there is
>> no need to deploy yet another (renamed) image, so the "candidate" is
>> truly a candidate for release -- the one that was tested. Then all we
>> have to do is [ANN]ounce.

I would in general be happy with this convention, but right now it's a
lie: this image is 12303 + my ReleaseBuilder and Morphic hacks, which
are in the Inbox (deliberately so) and NOT in trunk.

If people are OK with what they see (other than the 500@400 glitch
Stef caught), I can move these into trunk, and we can have a 12303+n
version.

frank

>> That it is in the "4.4" release directory rather than the "4.4alpha"
>> directory, anyone will know this is THE candidate for release.
>
> Nobody can know this from the URL. It looks like an actual release, because *nothing* indicates that this is not a stable version.
>
>> In the
>> past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip"
>> -- which could still do for alpha images if we want to be sure the
>> names themselves carry a "quality disclaimer" tag.
>
> I'd prefer this, yes. Although we're way past alpha. This is a release candidate, after all:
>
> http://en.wikipedia.org/wiki/Software_release_life_cycle
>
> - Bert -
>
>
>

Frank Shearar-3

Re: Squeak4.4 RC1 is available

On 17 December 2012 12:22, Frank Shearar <[hidden email]> wrote:

> On 17 December 2012 12:12, Bert Freudenberg <[hidden email]> wrote:
>> On 2012-12-16, at 22:16, Chris Muller <[hidden email]> wrote:
>>
>>> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip
>>>
>>> I suggest we use a consistent naming convention that conveys the
>>> general ("4.4") and specific ("-12303") version information. After a
>>> week has gone by for the community to download and verify it, there is
>>> no need to deploy yet another (renamed) image, so the "candidate" is
>>> truly a candidate for release -- the one that was tested. Then all we
>>> have to do is [ANN]ounce.
>
> I would in general be happy with this convention, but right now it's a
> lie: this image is 12303 + my ReleaseBuilder and Morphic hacks, which
> are in the Inbox (deliberately so) and NOT in trunk.

I've just released (with help from Bert), the next iteration;
http://ftp.squeak.org/4.4/Squeak4.4-RC2.tgz

This fixes the 500@400 problem, the doubled Welcome Workspaces (not
immediately apparent because the new windows lay on top of the old
windows) and forces #useOldNetwork:.

frank

> If people are OK with what they see (other than the 500@400 glitch
> Stef caught), I can move these into trunk, and we can have a 12303+n
> version.
>
> frank
>
>>> That it is in the "4.4" release directory rather than the "4.4alpha"
>>> directory, anyone will know this is THE candidate for release.
>>
>> Nobody can know this from the URL. It looks like an actual release, because *nothing* indicates that this is not a stable version.
>>
>>> In the
>>> past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip"
>>> -- which could still do for alpha images if we want to be sure the
>>> names themselves carry a "quality disclaimer" tag.
>>
>> I'd prefer this, yes. Although we're way past alpha. This is a release candidate, after all:
>>
>> http://en.wikipedia.org/wiki/Software_release_life_cycle
>>
>> - Bert -
>>
>>
>>

glenpaling

Re: Squeak4.4 RC1 is available

I get a bunch of Monticello test failures and errors.

Failures:
3272 run, 3227 passes, 18 expected failures, 17 failures, 10 errors, 0 unexpected passes
LocaleTest>>#testLocaleChanged
MCChangeNotificationTest>>#testCoreMethodModified
MCFileInTest>>#testStWriter
MCPackageTest>>#testUnload
MCPatchTest>>#testPatchContents
MCSnapshotBrowserTest>>#testNoSelection
MCSnapshotTest>>#testCreation
MCStWriterTest>>#testMethodDefinition
MCStWriterTest>>#testOrganizationDefinition
MCWorkingCopyTest>>#testBackport
MCWorkingCopyTest>>#testOptimizedLoad
MCWorkingCopyTest>>#testRepeatedMerge
MCWorkingCopyTest>>#testSelectiveBackport
MCWorkingCopyTest>>#testSimpleMerge
MCWorkingCopyTest>>#testSnapshotAndLoad
SocketTest>>#testSocketReuse
SocketTest>>#testUDP

Errors:
MCChangeNotificationTest>>#testExtMethodModified
MCSnapshotBrowserTest>>#testCategorySelected
MCSnapshotBrowserTest>>#testClassSelected
MCSnapshotBrowserTest>>#testClassSideClassSelected
MCSnapshotBrowserTest>>#testComment
MCSnapshotBrowserTest>>#testMethodIsCleared
MCSnapshotBrowserTest>>#testMethodSelected
MCSnapshotBrowserTest>>#testProtocolIsCleared
MCSnapshotBrowserTest>>#testProtocolSelected
MCStWriterTest>>#testInitializerDefinition

Frank Shearar-3

Re: Squeak4.4 RC1 is available

On 17 December 2012 15:20, glenpaling <[hidden email]> wrote:
> I get a bunch of Monticello test failures and errors.

Thanks for trying it out, Glen. I assume this is on OS X, right?

> Failures:
> 3272 run, 3227 passes, 18 expected failures, 17 failures, 10 errors, 0
> unexpected passes
> LocaleTest>>#testLocaleChanged

This one's known to be a broken test.

> MCChangeNotificationTest>>#testCoreMethodModified
> MCFileInTest>>#testStWriter
> MCPackageTest>>#testUnload
> MCPatchTest>>#testPatchContents
> MCSnapshotBrowserTest>>#testNoSelection
> MCSnapshotTest>>#testCreation
> MCStWriterTest>>#testMethodDefinition
> MCStWriterTest>>#testOrganizationDefinition
> MCWorkingCopyTest>>#testBackport
> MCWorkingCopyTest>>#testOptimizedLoad
> MCWorkingCopyTest>>#testRepeatedMerge
> MCWorkingCopyTest>>#testSelectiveBackport
> MCWorkingCopyTest>>#testSimpleMerge
> MCWorkingCopyTest>>#testSnapshotAndLoad

Hm, these are unexpected, and shouldn't be platform specific, and also
don't occur on the CI server.

> SocketTest>>#testSocketReuse
> SocketTest>>#testUDP

These might / are probably platform specific test failures: they don't
occur in CI, but CI runs on a Linux machine.

> Errors:
> MCChangeNotificationTest>>#testExtMethodModified
> MCSnapshotBrowserTest>>#testCategorySelected
> MCSnapshotBrowserTest>>#testClassSelected
> MCSnapshotBrowserTest>>#testClassSideClassSelected
> MCSnapshotBrowserTest>>#testComment
> MCSnapshotBrowserTest>>#testMethodIsCleared
> MCSnapshotBrowserTest>>#testMethodSelected
> MCSnapshotBrowserTest>>#testProtocolIsCleared
> MCSnapshotBrowserTest>>#testProtocolSelected
> MCStWriterTest>>#testInitializerDefinition

These too are unexpected.

Any chance of getting exception messages or stack traces or similar
for them? (You _should_ be able to wangle the info out of the
TestRunner by iterating over its TestCases, but I forget the precise
incantation to use.)

frank

glenpaling

Re: Squeak4.4 RC1 is available

Yes, the Locale and socket test failures are fairly long standing. All the MC failures are quite new. I've been on an internet starved vacation in Mexico, so I'm a little behind in tests. I ran CI build 60, it didn't have the MC problems. I'll to get more details.

glenpaling

Re: Squeak4.4 RC1 is available

In reply to this post by Frank Shearar-3

My XP laptop has the same failures and OSX plus:
Failure: Win32VMTest>>#testWinVM3ButtonMousePreference
and Error: FileDirectoryTest>>#testExtMethodModified

Frank Shearar-3

Re: Squeak4.4 RC1 is available

On 17 December 2012 15:58, glenpaling <[hidden email]> wrote:
> My XP laptop has the same failures and OSX plus:
> Failure: Win32VMTest>>#testWinVM3ButtonMousePreference
> and Error: FileDirectoryTest>>#testExtMethodModified

I'm also seeing the MC failures. MCChangeNotificationTest >>
#testCoreMethodModified fails, for instance, because MCMockClassA has
no #one method, and the test expects there to be one.

And yet the build on CI doesn't see these test failures!

frank

glenpaling

Re: Squeak4.4 RC1 is available

I updated the CI build version 60 I had to trunk version 12303 (same version as RC2). The tests run without Monticello failures. Looks like a CI problem.

Frank Shearar-3

Re: Squeak4.4 RC1 is available

On 17 December 2012 17:07, glenpaling <[hidden email]> wrote:
> I updated the CI build version 60 I had to trunk version 12303 (same version
> as RC2). The tests run without Monticello failures. Looks like a CI
> problem.

No, because build 60 had only 3 test failures. Too, builds #61 - #63
weren't triggered by MC changes, so they're running the same MC tests,
and none of them failed with these errors.

I don't know _why_ it's happening, but I think I know _where_:

MCMethodDefinitionTest >> testLoadAndUnload
|definition|
definition := self mockMethod: #one class: 'MCMockClassA' source:
'one ^2' meta: false.
self assert: self mockInstanceA one = 1.
definition load.
self assert: self mockInstanceA one = 2.
definition unload.
self deny: (self mockInstanceA respondsTo: #one)

However, its #tearDown is supposed to restore order, and is apparently not.

frank

Frank Shearar-3

Re: Squeak4.4 RC1 is available

On 17 December 2012 17:12, Frank Shearar <[hidden email]> wrote:

> On 17 December 2012 17:07, glenpaling <[hidden email]> wrote:
>> I updated the CI build version 60 I had to trunk version 12303 (same version
>> as RC2). The tests run without Monticello failures. Looks like a CI
>> problem.
>
> No, because build 60 had only 3 test failures. Too, builds #61 - #63
> weren't triggered by MC changes, so they're running the same MC tests,
> and none of them failed with these errors.
>
> I don't know _why_ it's happening, but I think I know _where_:
>
> MCMethodDefinitionTest >> testLoadAndUnload
> |definition|
> definition := self mockMethod: #one class: 'MCMockClassA' source:
> 'one ^2' meta: false.
> self assert: self mockInstanceA one = 1.
> definition load.
> self assert: self mockInstanceA one = 2.
> definition unload.
> self deny: (self mockInstanceA respondsTo: #one)
>
> However, its #tearDown is supposed to restore order, and is apparently not.

Glen, when you run the tests, do you have Author initials set?

I've just found that if I _don't_, then the #tearDown doesn't revert
the mock MC package properly... but if I _do_, then the tests pass.
(The CI build explicitly sets the Author initials.)

glenpaling

Re: Squeak4.4 RC1 is available

Frank Shearar-3 wrote

On 17 December 2012 17:12, Frank Shearar <[hidden email]> wrote:
> On 17 December 2012 17:07, glenpaling <[hidden email]> wrote:
>> I updated the CI build version 60 I had to trunk version 12303 (same version
>> as RC2). The tests run without Monticello failures. Looks like a CI
>> problem.
>
> No, because build 60 had only 3 test failures. Too, builds #61 - #63
> weren't triggered by MC changes, so they're running the same MC tests,
> and none of them failed with these errors.
>
> I don't know _why_ it's happening, but I think I know _where_:
>
> MCMethodDefinitionTest >> testLoadAndUnload
> |definition|
> definition := self mockMethod: #one class: 'MCMockClassA' source:
> 'one ^2' meta: false.
> self assert: self mockInstanceA one = 1.
> definition load.
> self assert: self mockInstanceA one = 2.
> definition unload.
> self deny: (self mockInstanceA respondsTo: #one)
>
> However, its #tearDown is supposed to restore order, and is apparently not.

Glen, when you run the tests, do you have Author initials set?

I've just found that if I _don't_, then the #tearDown doesn't revert
the mock MC package properly... but if I _do_, then the tests pass.
(The CI build explicitly sets the Author initials.)

Yes, I'm setting the AuthorInitials. I checked, it's still set to 'egp'.

I located a version of Squeak4.4-alpha (update: 11920). It passes the MC tests.

glenpaling

Re: Squeak4.4 RC1 is available

Frank, I downloaded the SqueakTrunk #64 build artifacts directly from http://www.squeakci.org/job/SqueakTrunk/lastBuild/?. Test have no Monticello failures just:

3272 run, 3250 passes, 18 expected failures, 4 failures, 0 errors, 0 unexpected passes

LocaleTest>>#testLocaleChanged
SocketTest>>#testSocketReuse
SocketTest>>#testUDP
WeakSetInspectorTest>>#testSymbolTableM6812