In Pharo core, it is sometimes green and sometime yellow I put some flags and see this: cdNO: 3933 clsNo: 1955 metaclsNo: 1977 clsNo + metaclsNo: 3932 ------------------------------- cdNO: 3935 clsNo: 1956 metaclsNo: 1978 clsNo + metaclsNo: 3934 ------------------------------- cdNO: 3937 clsNo: 1957 metaclsNo: 1979 clsNo + metaclsNo: 3936 ------------------------------- cdNO: 3938 clsNo: 1958 metaclsNo: 1980 clsNo + metaclsNo: 3938 ------------------------------- cdNO: 3941 clsNo: 1959 metaclsNo: 1981 clsNo + metaclsNo: 3940 ------------------------------- cdNO: 3943 clsNo: 1960 metaclsNo: 1982 clsNo + metaclsNo: 3942 ------------------------------- cdNO: 3945 clsNo: 1961 metaclsNo: 1983 clsNo + metaclsNo: 3944 ------------------------------- cdNO: 3947 clsNo: 1962 metaclsNo: 1984 clsNo + metaclsNo: 3946 ------------------------------- On Fri, Apr 10, 2009 at 9:06 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

I think this is related to what Lukas said in the other mail. I can reproduce what Sted says in Pharo core, but in last pharo-dev, it works ok. I tried to run several times the tests but are green all the time.

Cheers,

Mariano

On Fri, Apr 10, 2009 at 4:28 PM, Damien Cassou <damien.cassou@gmail.com>wrote:

...

issue #727

On Fri, Apr 10, 2009 at 7:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

When running the kernelTest-Classes testClassDescriptionallSubInstances is yellow but when run individually green.

Anybody want to look at it?

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Damien Cassou http://damiencassou.seasidehosting.st

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Fri, Apr 10, 2009 at 11:44 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:

In my past dealings with insanity like this is that Sunits for a test case run technically in no particular order. However if you have cases where a test case A alters things for B, then you get failure if B runs before A. The order is dependent on how the set is created.

Also there can be issues if things like File Handles are over- allocated and you then rely on finalization to fix things, which could interfere with things er it's hard to explain, but once you see it, you know. Technically this should not be a problem but as you see well something is funky.

What I'd suggest is print the context at the point of error in the SUnit error handler so you can get some understanding of the failure case.

Smalltalk logError:'Fatal error: Sunit Fialed' inContext: thisContext to: 'SqueakDebugXXXX.log'.

Thanks for the advice John. Very useful, not only for this case. I will try it. Thanks!

I also altered errorReportOn: to slop more data out, in Tweak based system it's not uncommon to have stack nesting of > 100 methods. Never can have enough debug data at hand.

Contextpart>>errorReportOn: strm "Write a detailed error report on the stack (above me) on a stream. For both the error file, and emailing a bug report. Suppress any errors while getting printStrings. Limit the length."

| cnt aContext startPos | strm print: Date today; space; print: Time now; cr. strm cr. strm nextPutAll: 'VM: '; nextPutAll: SmalltalkImage current platformName asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current platformSubtype asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current osVersion asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current vmVersion asString; cr. strm nextPutAll: 'Image: '; nextPutAll: SystemVersion current version asString; nextPutAll: ' ['; nextPutAll: SmalltalkImage current lastUpdateString asString; nextPutAll: ']'; cr. strm cr. SecurityManager default printStateOn: strm.

"Note: The following is an open-coded version of ContextPart>>stackOfSize: since this method may be called during a low space condition and we might run out of space for allocating the full stack." cnt := 0. startPos := strm position. aContext := self. [aContext notNil and: [(cnt := cnt + 1) < 40]] whileTrue: [aContext printDetails: strm. "variable values" strm cr. aContext := aContext sender].

strm cr; nextPutAll: '--- The full stack ---'; cr. aContext := self. cnt := 0. [aContext == nil] whileFalse: [cnt := cnt + 1. cnt = 40 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -'; cr]. strm print: aContext; cr. "just class>>selector"

strm position > (startPos+150000) ifTrue: [strm nextPutAll: '...etc...'. ^ self]. "exit early" cnt > 200 ifTrue: [strm nextPutAll: '-- and more not shown --'. ^ self]. aContext := aContext sender].

On 10-Apr-09, at 5:19 PM, Mariano Martinez Peck wrote:

...

In Pharo core, it is sometimes green and sometime yellow

I put some flags and see this:

\\ -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project