Hi Frank,

I return home tonight and I will have my Mac available to me at that point. I will run the tests and post my results to the list. I could also run them on my linux machine as well and post those results if no one has beat me to it.

Jeff

On Tue, Oct 23, 2012 at 10:34 AM, Tom Rushworth tom.b.rushworth@gmail.comwrote:

Hi Frank,

I made a stab at getting the new image to run on my OS X server, but the link below doesn't seem to do anything in a regular browser, or when I paste it into the update-image.st script as the update source.

I'm probably completely misunderstanding what I should be doing... Can you give me a bigger hint? :).

BTW, your message fell prey to my Postini spam filter, so it got delayed a day or so, until I spotted it in the quarantine summary. I've put your address and squeak-dev on my Postini approved list, so it shouldn't happen again.

On 12/10/22 12:21, Frank Shearar wrote:

...

We're down to 6 failing unit tests on the Linux platform, one of which is an expected failure and another of which is a known network issue for the Linux platform.

Would my kind Windows and OSX build volunteers please run builds against the latest trunk image? (

http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/)

...

Note the new URL: that's thanks to Chris Cunnington, who has kindly moved Jenkins to its new home. That will no doubt shortly become the new squeakci.org.

Windows users note please that you'll need to grant permission for the build executables etc to act as servers and to make connections: you can do this through the Windows Firewall configuration screens. (I'd give more detailed instructions, but my Windows machines are far away right now.)

(Dale, this shouldn't affect you much, in the sense that you won't need any changes to builderCI or whatever once the DNS changes have been made. So if they _do_ affect you, they shouldn't affect you for very long.)

It's about time I started with the more admin-y side of the release, making a Changelog and such. I'll make a start on this soon, docs/progress to be on http://wiki.squeak.org/squeak/6188

frank

-- Tom Rushworth

On 12-10-23 1:15 PM, Frank Shearar wrote:

On 23 October 2012 17:34, Tom Rushworth tom.b.rushworth@gmail.com wrote:

...

Hi Frank,

I made a stab at getting the new image to run on my OS X server, but the link below doesn't seem to do anything in a regular browser, or when I paste it into the update-image.st script as the update source.

I'm probably completely misunderstanding what I should be doing... Can you give me a bigger hint? :).

Right. This is the second time we've seen this. There's _supposed_ to be a zip there for you to download.

Chris Cunnington (I'm not saying that with my Dad Voice; there are just lots of people sharing your name on the list), did you do anything to the build server? It looks like all the build history for SqueakTrunk just vanished.

frank

The completed build you're saying missing is #17. Remember when I said yesterday that I had a completed build called #16 and that it just... disappeared. Seems to have happened again. I have no idea why. I logged in and hit Build Now and that created #17. I just did that again. I expect build #18 should be along presently. Why does this happen? I have no idea.

Chris

I think I can sketch out a few details.

1. The first thing is that this is not a medical emergency. I'm saying that for my own peace of mind. System administration under duress is no fun at all.

2. The builds are still there. They don't disappear. They just aren't seen by the webpage. We are not alone in this. It has happened before.

http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-...

3. The problem may be in the reading of an XML file. The solution I've gleaned so far is that instead of creating another build, I could log in and press:

"Reload Configuration from Disk"

Or I could just try restarting.

4. This didn't happen on the older server. It won't last forever on this one.

5. God knows, somebody will come up with a better answer than I can. But since you're all looking at me at this moment, I say this: "Don't panic. We still know where our towel is."

Chris

On 12-10-23 2:29 PM, Igor Stasenko wrote:

Hi, Chris..

Just wanna add own 2 cents:

yes, Jenkins quality remains to be an issue. We also experiencing problems with it time to time.

I wonder if there any better alternatives..

...

From other side, jenkins provides a rich set of features (many from plugins),

which would be hard to match if one would start writing it from scratch.

I was just asking my self: "Do they have this problem at INRIA Lille? They have such a large collection of Jenkins jobs..." And so, it is nice of you to say that it happens sometimes at your site as well. Thanks for that. I figure this stuff will iron itself out over time.

Chris

On 23 October 2012 19:00, Chris Cunnington smalltalktelevision@gmail.com wrote:

I think I can sketch out a few details.

1. The first thing is that this is not a medical emergency. I'm saying that

for my own peace of mind. System administration under duress is no fun at all.

Ideally one shouldn't do system adminstration when feeling under pressure :)

2. The builds are still there. They don't disappear. They just aren't seen

by the webpage. We are not alone in this. It has happened before.

http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-...

3. The problem may be in the reading of an XML file. The solution I've

gleaned so far is that instead of creating another build, I could log in and press:

"Reload Configuration from Disk"

Or I could just try restarting.

4. This didn't happen on the older server. It won't last forever on this

one.

5. God knows, somebody will come up with a better answer than I can. But

since you're all looking at me at this moment, I say this: "Don't panic. We still know where our towel is."

Not panicking. At least, not yet :)

frank

Chris

Isn't the issue simply that Jenkins is looking for the workspace at the wrong place? When we first set up our Jenkins instance it created the workspace directory at a different place than what the documentation[1] says. There was a workspace directory in the JENKINS_HOME directory with subdirectories for each job IIRC. After the first restart it was looking for the workspace directory at the place suggested by the documentation, so our jobs "disappeared". We fixed the directory structure by hand and everything is fine since then.

Levente

[1] https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins

On Tue, 23 Oct 2012, Chris Cunnington wrote:

I think I can sketch out a few details.

1. The first thing is that this is not a medical emergency. I'm saying that for my own peace of mind. System administration under duress is no fun at all.

2. The builds are still there. They don't disappear. They just aren't seen by the webpage. We are not alone in this. It has happened before.

http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-...

3. The problem may be in the reading of an XML file. The solution I've gleaned so far is that instead of creating another build, I could log in and press:

"Reload Configuration from Disk"

Or I could just try restarting.

4. This didn't happen on the older server. It won't last forever on this one.

5. God knows, somebody will come up with a better answer than I can. But since you're all looking at me at this moment, I say this: "Don't panic. We still know where our towel is."

Chris

Err, no. A "workspace" is where slave doing its work. But artifacts made by job(s) are stored in separate place.

By analogy to real life: you have a workshop where you produce things, and storage where you put them after.

On 24 October 2012 00:43, Levente Uzonyi leves@elte.hu wrote:

Isn't the issue simply that Jenkins is looking for the workspace at the wrong place? When we first set up our Jenkins instance it created the workspace directory at a different place than what the documentation[1] says. There was a workspace directory in the JENKINS_HOME directory with subdirectories for each job IIRC. After the first restart it was looking for the workspace directory at the place suggested by the documentation, so our jobs "disappeared". We fixed the directory structure by hand and everything is fine since then.

Levente

[1] https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins

On Tue, 23 Oct 2012, Chris Cunnington wrote:

...

I think I can sketch out a few details.

1. The first thing is that this is not a medical emergency. I'm saying

that for my own peace of mind. System administration under duress is no fun at all.

2. The builds are still there. They don't disappear. They just aren't seen

by the webpage. We are not alone in this. It has happened before.

http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-11938-Jenkins-loses-builds-...

3. The problem may be in the reading of an XML file. The solution I've

gleaned so far is that instead of creating another build, I could log in and press:

"Reload Configuration from Disk"

Or I could just try restarting.

4. This didn't happen on the older server. It won't last forever on this

one.

5. God knows, somebody will come up with a better answer than I can. But

since you're all looking at me at this moment, I say this: "Don't panic. We still know where our towel is."

Chris

On 2012-10-24 10:45 AM, Levente Uzonyi wrote:

On Wed, 24 Oct 2012, Igor Stasenko wrote:

...

Err, no. A "workspace" is where slave doing its work. But artifacts made by job(s) are stored in separate place.

Right, but as I said, the directory structure created by Jenkins didn't match what the wiki says when we set up Jenkins. So, tt's still worth checking the directory structure.

Levente

The directory structure seems to be as it should be:

xxxxxxxxx:/xxxxxxxxx/jobs/SqueakTrunk/builds/20$ ls -la total 864 drwxr-xr-x 3 jenkins xxxxxx 4096 Oct 23 19:26 . drwxr-xr-x 21 jenkins xxxxxx 4096 Oct 23 19:21 .. drwxr-xr-x 3 jenkins xxxxxx 4096 Oct 23 19:26 archive -rw-r--r-- 1 jenkins xxxxxx 2906 Oct 23 19:26 build.xml -rw-r--r-- 1 jenkins xxxxxx 252 Oct 23 19:21 changelog.xml -rw-r--r-- 1 jenkins xxxxxx 857130 Oct 23 19:26 junitResult.xml -rw-r--r-- 1 jenkins xxxxxx 1312 Oct 23 19:26 log

The deliverables are in the archive directory as expected. I think the build.xml is what is read to inform the web page.

Looking at the site it seems a bit more stable than yesterday. Somewhat. Nothing has disappeared so far. Perhaps it's hardening a bit with use.

Chris

On 2012-10-24 1:09 PM, Frank Shearar wrote:

On 24 October 2012 18:06, Chris Cunnington smalltalktelevision@gmail.com wrote:

...

On 2012-10-24 10:45 AM, Levente Uzonyi wrote:

...

On Wed, 24 Oct 2012, Igor Stasenko wrote:

...

Err, no. A "workspace" is where slave doing its work. But artifacts made by job(s) are stored in separate place.

Right, but as I said, the directory structure created by Jenkins didn't match what the wiki says when we set up Jenkins. So, tt's still worth checking the directory structure.

Levente

The directory structure seems to be as it should be:

xxxxxxxxx:/xxxxxxxxx/jobs/SqueakTrunk/builds/20$ ls -la total 864 drwxr-xr-x 3 jenkins xxxxxx 4096 Oct 23 19:26 . drwxr-xr-x 21 jenkins xxxxxx 4096 Oct 23 19:21 .. drwxr-xr-x 3 jenkins xxxxxx 4096 Oct 23 19:26 archive -rw-r--r-- 1 jenkins xxxxxx 2906 Oct 23 19:26 build.xml -rw-r--r-- 1 jenkins xxxxxx 252 Oct 23 19:21 changelog.xml -rw-r--r-- 1 jenkins xxxxxx 857130 Oct 23 19:26 junitResult.xml -rw-r--r-- 1 jenkins xxxxxx 1312 Oct 23 19:26 log

The deliverables are in the archive directory as expected. I think the build.xml is what is read to inform the web page.

Looking at the site it seems a bit more stable than yesterday. Somewhat. Nothing has disappeared so far. Perhaps it's hardening a bit with use.

The glue's setting?

frank

The epoxy. Yes.

Chris

On Wed, 24 Oct 2012, Frank Shearar wrote:

On 23 October 2012 21:25, Herbert König herbertkoenig@gmx.net wrote:

...

Hi,

...

We're down to 6 failing unit tests on the Linux platform, one of which is an expected failure and another of which is a known network issue for the Linux platform.

Would my kind Windows and OSX build volunteers please run builds against the latest trunk image? (http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/)

Yesterday (Oct 22) I could download build #17 and got a TrunkImage.image and .changes. Not the usual zip including the VM.

The VM comes from the repository at https://github.com/frankshearar/squeak-ci. In particular, you can get a copy directly from here: https://github.com/frankshearar/squeak-ci/zipball/master

Sorry, I thought I'd only need to mention the image location.

...

This is update 12251 according to the system reporter. I disable IPV6 support via preferences and run all tests in the Cog VM I used for the previous tests. See http://minus.com/luZyqW2PRhIrq.

I get 3222 run, 3178 passes, 18 expected failures, 5 failures, 21 errors, 0 unexpected passes, as if the network preference is ignored again. See http://minus.com/lpibYAKEi3bw5 I did this twice, as I didn't want to believe it.

If I update this image to trunk, it loads some updates and again claims to be 12251 version. Tests like before result in 3219 run, 3195 passes, 18 expected failures, 5 failures, 1 errors, 0 unexpected passes. See: http://minus.com/l17FSZY5yOnhH

I have no idea but I still have that image if someone wants it.

http://minus.com/mbam1m6GnSJJJH is the complete Folder with the screenshots of all runs I published up to now.

Thanks very much for running the tests, Herbert. I appreciate it!

This is actually what I _expected_, since one of the 6 failing tests is a network issue on the Linux platform. That is, I expect NetworkTests.Kernel.SocketTest.testSendTimeout to _pass_ on Windows.

It randomly passes on Vista, but fails most of the time. The problem is that the test expects that if it fills up the send buffer of a socket, then all subsequent send requests will fail, but I think the OS somehow makes the send buffer larger, so while sending failed at a point in time, later it will work again.

That error is news to me though: FileDirectoryTest.testRelativeNameIfAbsolut...

Would you mind sending more details on that failed test? I'd like to see which assertion fails.

That's an "old" error on Windows. The method (#relativeNameIfAbsoluteFor:) expects that an absolute path begins with the path delimitar, which is obviously not true on windows (C:... doesn't begin with ). There are several absolute path formats on windows, so I think the method has to be implementation in DosFileDirectory.

Levente

Thanks again!

frank

...

Cheers

Herbert

I know that this is quite late, but better late than never. Running the latest from Frank's squeak-ci repo I get 8 errors:

KernelTests: 3 errors 0 failures. NetworkTests: 2 errors 0 failures. Tests: 2 errors 0 failures. ToolsTests: 1 errors 0 failures.

DependencyBrowserTest>>#testClassList LargeNegativeIntegerTest>>#testMinimumNegativeArithmetic LocaleTest>>#testLocaleChanged ReleaseTest>>#testNoObsoleteClasses SocketTest>>#testSocketReuse SocketTest>>#testUDP TimeStampTest>>#testFromSeconds TimeStampTest>>#testReadFromA1

I'll run it on my linux vm momentarily and report the results.

Thanks for all the great work Frank! Jeff

On Wed, Oct 24, 2012 at 11:35 AM, Frank Shearar frank.shearar@gmail.comwrote:

On 22 October 2012 20:21, Frank Shearar frank.shearar@gmail.com wrote:

...

We're down to 6 failing unit tests on the Linux platform, one of which is an expected failure and another of which is a known network issue for the Linux platform.

Would my kind Windows and OSX build volunteers please run builds against the latest trunk image? (

http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/)

...

Note the new URL: that's thanks to Chris Cunnington, who has kindly moved Jenkins to its new home. That will no doubt shortly become the new squeakci.org.

Windows users note please that you'll need to grant permission for the build executables etc to act as servers and to make connections: you can do this through the Windows Firewall configuration screens. (I'd give more detailed instructions, but my Windows machines are far away right now.)

(Dale, this shouldn't affect you much, in the sense that you won't need any changes to builderCI or whatever once the DNS changes have been made. So if they _do_ affect you, they shouldn't affect you for very long.)

It's about time I started with the more admin-y side of the release, making a Changelog and such. I'll make a start on this soon, docs/progress to be on http://wiki.squeak.org/squeak/6188

frank

The latest builds have a few new failures:

• Tests.Compiler.DecompilerTests.testDecompilerInClassesLAtoLM [1]
• TraitsTests.Kernel.ClassTraitTest.testConflictsAliasesAndExclusions [2]

which is kind've surprising.

frank

[1] Error Message

subscript is out of bounds: 1 Stacktrace

Array(Object)>>error: Array(Object)>>errorSubscriptBounds: Array(Object)>>at: Decompiler>>pushTemporaryVariable: Decompiler(InstructionStream)>>interpretNextInstructionFor: Decompiler>>interpretNextInstructionFor: Decompiler>>statementsTo: Decompiler>>blockTo: Decompiler>>doClosureCopyCopiedValues:numArgs:blockSize: Decompiler>>pushClosureCopyNumCopiedValues:numArgs:blockSize: Decompiler(InstructionStream)>>interpretExtension:in:for: Decompiler(InstructionStream)>>interpretNextInstructionFor: Decompiler>>interpretNextInstructionFor: Decompiler>>statementsTo: Decompiler>>blockTo: Decompiler>>decompile:in:method:using: Decompiler>>decompile:in:method: DecompilerTests>>checkDecompileMethod: [] in [] in [] in DecompilerTests>>decompileClassesSelect: MethodDictionary>>keysAndValuesDo: LargeNegativeIntegerTest class(Behavior)>>selectorsAndMethodsDo: [] in [] in DecompilerTests>>decompileClassesSelect: Array(SequenceableCollection)>>do: [] in DecompilerTests>>decompileClassesSelect: BlockClosure>>on:do: CurrentReadOnlySourceFiles class>>cacheDuring: DecompilerTests>>decompileClassesSelect: DecompilerTests>>testDecompilerInClassesLAtoLM DecompilerTests(TestCase)>>performTest

[2] Stacktrace

Parser>>notify:at: Parser>>expected: Parser>>pattern:inContext: Parser>>method:context: [] in Parser>>parse:class:category:noPattern:context:notifying:ifFail: BlockClosure>>on:do: Parser>>parse:class:category:noPattern:context:notifying:ifFail: Compiler>>translate:noPattern:ifFail: Compiler>>compile:in:classified:notifying:ifFail: Metaclass(ClassDescription)>>traitAddSelector:withMethod: [] in Metaclass(ClassDescription)>>installTraitMethodDict: [] in Dictionary>>keysAndValuesDo: Dictionary>>associationsDo: Dictionary>>keysAndValuesDo: Metaclass(ClassDescription)>>installTraitMethodDict: Metaclass(ClassDescription)>>installTraitsFrom: Metaclass(ClassDescription)>>updateTraits Metaclass(ClassDescription)>>classify:under:from:trait: [] in ClassTrait(TraitDescription)>>notifyOfRecategorizedSelector:from:to: Array(SequenceableCollection)>>do: ClassTrait(TraitDescription)>>notifyOfRecategorizedSelector:from:to: TraitOrganizer(ClassOrganizer)>>notifyOfChangedSelector:from:to: TraitOrganizer(ClassOrganizer)>>classify:under:suppressIfDefault:logged: TraitOrganizer(ClassOrganizer)>>classify:under:suppressIfDefault: TraitOrganizer(Categorizer)>>classify:under: [] in ClassTrait(ClassDescription)>>installTraitMethodDict: [] in Dictionary>>keysAndValuesDo: Dictionary>>associationsDo: Dictionary>>keysAndValuesDo: ClassTrait(ClassDescription)>>installTraitMethodDict: ClassTrait(ClassDescription)>>installTraitsFrom: ClassTrait(TraitDescription)>>installTraitsFrom: ClassTrait(ClassDescription)>>updateTraits [] in ClassTrait(TraitDescription)>>addSelectorSilently:withMethod: Array(SequenceableCollection)>>do: ClassTrait(TraitDescription)>>addSelectorSilently:withMethod:

ClassTrait(ClassDescription)>>addAndClassifySelector:withMethod:inProtocol:notifying:

ClassTrait(ClassDescription)>>compile:classified:withStamp:notifying:logSource: ClassTrait(ClassDescription)>>compile:classified:withStamp:notifying: ClassTrait(ClassDescription)>>compile:classified:notifying: ClassTrait(ClassDescription)>>compile:classified: ClassTraitTest>>testConflictsAliasesAndExclusions ClassTraitTest(TestCase)>>performTest

On 27 October 2012 01:21, Jeff Gonis jeff.gonis@gmail.com wrote:

I know that this is quite late, but better late than never. Running the latest from Frank's squeak-ci repo I get 8 errors:

KernelTests: 3 errors 0 failures. NetworkTests: 2 errors 0 failures. Tests: 2 errors 0 failures. ToolsTests: 1 errors 0 failures.

DependencyBrowserTest>>#testClassList

I also saw this guy and was a bit surprised. I mean, the test is fragile in that we examine the current methods of a few classes (String) - I wrote it that way for lack of mocks - but didn't have a chance to see why. It probably broke because of the recent String changes shuffled the method order.

LargeNegativeIntegerTest>>#testMinimumNegativeArithmetic

General question not just for Jeff: Can we mark this as an expected failure?

frank

LocaleTest>>#testLocaleChanged ReleaseTest>>#testNoObsoleteClasses SocketTest>>#testSocketReuse SocketTest>>#testUDP TimeStampTest>>#testFromSeconds TimeStampTest>>#testReadFromA1

I'll run it on my linux vm momentarily and report the results.

Thanks for all the great work Frank! Jeff

On Wed, Oct 24, 2012 at 11:35 AM, Frank Shearar frank.shearar@gmail.com wrote:

...

On 22 October 2012 20:21, Frank Shearar frank.shearar@gmail.com wrote:

...

We're down to 6 failing unit tests on the Linux platform, one of which is an expected failure and another of which is a known network issue for the Linux platform.

Would my kind Windows and OSX build volunteers please run builds against the latest trunk image?

(http://173.246.101.237:8080/job/SqueakTrunk/lastCompletedBuild/artifact/)

Note the new URL: that's thanks to Chris Cunnington, who has kindly moved Jenkins to its new home. That will no doubt shortly become the new squeakci.org.

Windows users note please that you'll need to grant permission for the build executables etc to act as servers and to make connections: you can do this through the Windows Firewall configuration screens. (I'd give more detailed instructions, but my Windows machines are far away right now.)

(Dale, this shouldn't affect you much, in the sense that you won't need any changes to builderCI or whatever once the DNS changes have been made. So if they _do_ affect you, they shouldn't affect you for very long.)

It's about time I started with the more admin-y side of the release, making a Changelog and such. I'll make a start on this soon, docs/progress to be on http://wiki.squeak.org/squeak/6188

frank

The latest builds have a few new failures:

• Tests.Compiler.DecompilerTests.testDecompilerInClassesLAtoLM [1]
• TraitsTests.Kernel.ClassTraitTest.testConflictsAliasesAndExclusions [2]

which is kind've surprising.

frank

[1] Error Message

subscript is out of bounds: 1 Stacktrace

Array(Object)>>error: Array(Object)>>errorSubscriptBounds: Array(Object)>>at: Decompiler>>pushTemporaryVariable: Decompiler(InstructionStream)>>interpretNextInstructionFor: Decompiler>>interpretNextInstructionFor: Decompiler>>statementsTo: Decompiler>>blockTo: Decompiler>>doClosureCopyCopiedValues:numArgs:blockSize: Decompiler>>pushClosureCopyNumCopiedValues:numArgs:blockSize: Decompiler(InstructionStream)>>interpretExtension:in:for: Decompiler(InstructionStream)>>interpretNextInstructionFor: Decompiler>>interpretNextInstructionFor: Decompiler>>statementsTo: Decompiler>>blockTo: Decompiler>>decompile:in:method:using: Decompiler>>decompile:in:method: DecompilerTests>>checkDecompileMethod: [] in [] in [] in DecompilerTests>>decompileClassesSelect: MethodDictionary>>keysAndValuesDo: LargeNegativeIntegerTest class(Behavior)>>selectorsAndMethodsDo: [] in [] in DecompilerTests>>decompileClassesSelect: Array(SequenceableCollection)>>do: [] in DecompilerTests>>decompileClassesSelect: BlockClosure>>on:do: CurrentReadOnlySourceFiles class>>cacheDuring: DecompilerTests>>decompileClassesSelect: DecompilerTests>>testDecompilerInClassesLAtoLM DecompilerTests(TestCase)>>performTest

[2] Stacktrace

Parser>>notify:at: Parser>>expected: Parser>>pattern:inContext: Parser>>method:context: [] in Parser>>parse:class:category:noPattern:context:notifying:ifFail: BlockClosure>>on:do: Parser>>parse:class:category:noPattern:context:notifying:ifFail: Compiler>>translate:noPattern:ifFail: Compiler>>compile:in:classified:notifying:ifFail: Metaclass(ClassDescription)>>traitAddSelector:withMethod: [] in Metaclass(ClassDescription)>>installTraitMethodDict: [] in Dictionary>>keysAndValuesDo: Dictionary>>associationsDo: Dictionary>>keysAndValuesDo: Metaclass(ClassDescription)>>installTraitMethodDict: Metaclass(ClassDescription)>>installTraitsFrom: Metaclass(ClassDescription)>>updateTraits Metaclass(ClassDescription)>>classify:under:from:trait: [] in ClassTrait(TraitDescription)>>notifyOfRecategorizedSelector:from:to: Array(SequenceableCollection)>>do: ClassTrait(TraitDescription)>>notifyOfRecategorizedSelector:from:to: TraitOrganizer(ClassOrganizer)>>notifyOfChangedSelector:from:to: TraitOrganizer(ClassOrganizer)>>classify:under:suppressIfDefault:logged: TraitOrganizer(ClassOrganizer)>>classify:under:suppressIfDefault: TraitOrganizer(Categorizer)>>classify:under: [] in ClassTrait(ClassDescription)>>installTraitMethodDict: [] in Dictionary>>keysAndValuesDo: Dictionary>>associationsDo: Dictionary>>keysAndValuesDo: ClassTrait(ClassDescription)>>installTraitMethodDict: ClassTrait(ClassDescription)>>installTraitsFrom: ClassTrait(TraitDescription)>>installTraitsFrom: ClassTrait(ClassDescription)>>updateTraits [] in ClassTrait(TraitDescription)>>addSelectorSilently:withMethod: Array(SequenceableCollection)>>do: ClassTrait(TraitDescription)>>addSelectorSilently:withMethod:

ClassTrait(ClassDescription)>>addAndClassifySelector:withMethod:inProtocol:notifying:

ClassTrait(ClassDescription)>>compile:classified:withStamp:notifying:logSource: ClassTrait(ClassDescription)>>compile:classified:withStamp:notifying: ClassTrait(ClassDescription)>>compile:classified:notifying: ClassTrait(ClassDescription)>>compile:classified: ClassTraitTest>>testConflictsAliasesAndExclusions ClassTraitTest(TestCase)>>performTest