12 red tests to go...

After a crash course in how PackageInfo actually works, we're down to
12 failing tests:
http://www.squeakci.org/job/SqueakTrunk/26/testReport/?

(For the curious: while your browser shows 'Compression-Streams' and
'Compression-Archives', these are not packages (i.e., instances of
PackageInfo) but just strings. The PackageInfo you seek is PackageInfo
named: 'Compression', the base token of any category.

Or, if you prefer, if you want to find all packages that contain tests
(in alphabetical order), run:

((((TestCase allSubclasses collect: #category) "Find all
test-containing categories"
    collect: [:cat | (cat splitBy: '-') first]) asSet) "Convert
categories to package names, and remove duplicates"
        intersection: (PackageInfo allPackages collect: #name))
asSortedCollection "Limit to actually occuring PackageInfo instances"

The above's not 100% accurate, because it will include abstract TestCases.

I deliberately flattened the above and stored explicit package names
in the test setup under version control; this lets us easily bisect
the list of packages when hunting down why, say, a Compiler test
crashes the image (because of a missing sound library).

frank

On 6 August 2012 09:26, Frank Shearar <[hidden email]> wrote:
> After a crash course in how PackageInfo actually works, we're down to
> 12 failing tests:
> http://www.squeakci.org/job/SqueakTrunk/26/testReport/?

We've discussed some of these failing tests before:

Tests.Release.ReleaseTest.testNoObsoleteClasses
Tests.Release.ReleaseTest.testUndeclared

These fail because some TestCases hang onto these obselete classes.

Tests.Monticello.MCFileInTest.testStWriter
Tests.Monticello.MCMczInstallerTest.testInstallFromFile
Tests.Monticello.MCMczInstallerTest.testInstallFromStream

These are broken because they sometimes pass and sometimes don't.

This test is rather interesting -
KernelTests.Chronology.TimespanDoTest.testDatesDo. The test fails
because aTimespan dates = dateArray fails. (The former is a test
fixture; the latter is a test-local thing.) #hasEqualElements: returns
false in the line "(size := self size) = otherCollection size ifFalse:
[^ false]."... even though I can inspect size/self size and
otherCollection size as both being SmallInteger: 91. Despite the
equality, the ifFalse: block still executes!

Just for completeness' sake, the remaining failing tests:

KernelTests.Chronology.TimeStampTest.testFromSeconds
CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting
KernelTests.Chronology.TimeStampTest.testReadFromA1
NetworkTests.Kernel.SocketTest.testSendTimeout (apparently Linux-specific)
Tests.Exceptions.ExceptionTests.testHandlerFromAction ("feature request")
Tests.Localization.LocaleTest.testLocaleChanged

frank

> This test is rather interesting -
> KernelTests.Chronology.TimespanDoTest.testDatesDo. The test fails
> because aTimespan dates = dateArray fails. (The former is a test
> fixture; the latter is a test-local thing.) #hasEqualElements: returns
> false in the line "(size := self size) = otherCollection size ifFalse:
> [^ false]."... even though I can inspect size/self size and
> otherCollection size as both being SmallInteger: 91. Despite the
> equality, the ifFalse: block still executes!

I'll take this one Frank.

On 7 August 2012 03:56, Chris Muller <[hidden email]> wrote:
Thanks, Chris!

frank

On Mon, 6 Aug 2012, Frank Shearar wrote:

> After a crash course in how PackageInfo actually works, we're down to
> 12 failing tests:
> http://www.squeakci.org/job/SqueakTrunk/26/testReport/?
>
> (For the curious: while your browser shows 'Compression-Streams' and
> 'Compression-Archives', these are not packages (i.e., instances of
> PackageInfo) but just strings. The PackageInfo you seek is PackageInfo
> named: 'Compression', the base token of any category.

That's not entirely true. Some packages have dash in their names, like
HelpSystem-Tests or XML-Parser

This expression gives you exactly what you need:

(PackageInfo allPackages
  select: [ :each | each classes anySatisfy: [ :ea | ea inheritsFrom: TestCase ] ]
  thenCollect: #name) sort.

It returns 25 packages in my image, while your expression only gives 17.


Levente

>
> I deliberately flattened the above and stored explicit package names
> in the test setup under version control; this lets us easily bisect
> the list of packages when hunting down why, say, a Compiler test
> crashes the image (because of a missing sound library).
>
> frank
>
>

On 13 August 2012 14:53, Levente Uzonyi <[hidden email]> wrote:
So the apparent convention isn't very conventional :/.

OK. Still, simply evaluating PackageInfo named: 'Compression-Streams'
does create a new PackageInfo, and one that looks like it ought to be
related to the PackageInfo named: 'Compression', only it isn't. That's
what got me into trouble in the first place. Your point is that
PackageInfo names can happily contain $- characters.

Thanks!

frank

On 13.08.2012, at 16:17, Frank Shearar <[hidden email]> wrote:

I guess what you really care about would be the packages under source code management. As you noticed, PackageInfo instances are created on the fly so that does not mean it's an actual versioned package. For that you would have to iterate over MCWorkingCopy allManagers (or similar, away from my computer right now). Then ask the working copy for its package info and check classes as before.

- Bert -