April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit GUI

by Lukas Renggli

I cannot reproduce, for me the tests are always green. What image are you using? Lukas On Sat, Apr 11, 2009 at 5:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > When running the kernelTest-Classes > testClassDescriptionallSubInstances is yellow but when run > individually green. > > > > On Apr 11, 2009, at 2:57 PM, Lukas Renggli wrote: > >> I don't think this is related to #doesNotUnderstand:, but if you tell >> me what test case this is I can have a look. >> >> Lukas >> >> On Saturday, April 11, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> > wrote: >>> >>> On Apr 10, 2009, at 8:41 PM, Lukas Renggli wrote: >>> >>> >>> is it normal that when one doubleclick on an yellow item in the list >>> it does not open a debugger? >>> >>> >>> No, that's not normal. >>> >>> Right now I can think of two possible causes: >>> >>> - The test is not deterministic or has side effects that cause it to >>> sometimes fail and sometimes pass. >>> >>> >>> I do not think that this is the case. >>> I can reproduce the bhevaior run KernelsTests-classes. >>> >>> >>> >>> - Another reason that I recently noticed is related to exceptions and >>> how SUnit runs the tests. When a test is run (when you click on run) >>> the code is wrapped into an [ ... ] on: Error do: ..., thus catching >>> all exceptions. When a test is debugged (when you click on an item on >>> the list) the code is not wrapped in such a handler assuming that >>> this >>> would cause the system to open a debugger. However, depending on the >>> exception raised this causes a custom default action to be evaluated >>> and the test does not fail anymore. Many file-related exceptions have >>> such a default behavior. Oscar recently reported an issue on this: >>> <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why >>> this only appeared now? Was there anything changed related to SUnit >>> or >>> Exceptions? >>> >>> >>> I know that we introduce a fix of eliot in the way does not >>> understand >>> lead to open the debugger. >>> >>> see the mail below >>> The code is attached to a mail of 20 of december in pharo mailing- >>> list >>> Let me know if you understand better than me. Now I do not have the >>> time >>> to look at it. >>> >>> Stef >>> >>> >>> >>> Begin forwarded message: >>> >>> >>> From: "Eliot Miranda" <eliot.miranda(a)gmail.com> >>> Date: December 19, 2008 7:52:21 PM CEST >>> To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org >>> > >>> Subject: Re: [squeak-dev] Re: Resume Problems >>> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> >>> Hi Zulq, >>> >>> Â Â I made sure this was fixed in VisualWorks. Â Steve Dahl and I >>> fixed this together. Â Here's an analogous fix for Squeak. Â The >>> essential change is to make Object>>doesNotUnderstand: check if the >>> MessageNotUnderstood exception was handled or not, so >>> >>> Â Â Â Â MessageNotUnderstood new >>> Â Â Â Â Â Â Â Â message: aMessage; >>> Â Â Â Â Â Â Â Â receiver: self; >>> Â Â Â Â Â Â Â Â signal. >>> Â Â Â Â ^ aMessage sentTo: self. >>> >>> is replaced with >>> >>> Â Â Â Â (exception := MessageNotUnderstood new) >>> Â Â Â Â Â Â Â Â message: aMessage; >>> Â Â Â Â Â Â Â Â receiver: self. >>> Â Â Â Â resumeValue := exception signal. >>> Â Â Â Â ^exception reachedDefaultHandler >>> Â Â Â Â Â Â Â Â ifTrue: [aMessage sentTo: self] >>> Â Â Â Â Â Â Â Â ifFalse: [resumeValue] >>> >>> HTH >>> >>> On Fri, Dec 19, 2008 at 8:13 AM, Zulq Alam <me(a)zulq.net> wrote: >>> Hi Klaus, >>> >>> >>> Klaus D. Witzel wrote: >>> Nah, the result has nothing to do with #on:do: resuming with 1, you >>> better >>> try >>> >>> [('abc' + 1) + 1] >>> Â on: MessageNotUnderstood >>> Â do: [:e | e resume: -1] >>> >>> which still says 2. This because someone, behind you back, put >>> #asNumber >>> arithmethic into ByteString ... now this attempts (Number readFrom: >>> 'abc') >>> which gives 0 for your +1 +1 and so 2. >>> >>> You may want to start DNU testing with ('abc' break; + 1) and then >>> see >>> where it goes. >>> >>> Hmm... I think something is not right or at the very least the >>> semantics are subtly different than I expect. >>> >>> VisualWorks: >>> [Object new blah + 1] >>> Â on: MessageNotUnderstood >>> Â do: [:e | e resume: 1] Â " = 2 " >>> >>> [MessageNotUnderstood signal + 1] >>> Â on: MessageNotUnderstood >>> Â do: [:e | e resume: 1] " = 2 " >>> >>> Squeak: >>> [Object new blah + 1] >>> Â on: MessageNotUnderstood >>> Â do: [:e | e resume: 1] Â " infinite recursion!!! " >>> >>> [MessageNotUnderstood signal + 1] >>> Â on: MessageNotUnderstood >>> Â do: [:e | e resume: 1] " = 2 " >>> >>> >>> If I look at doesNotUnderstand: in both I see that in VW the >>> resumed value is returned. In Squeak is is not... surely this can't >>> be right? >>> >>> As for my problem, I think a simpler solution is to pass an adaptor/ >>> proxy object to the block rather than the tag itself. This adaptor >>> can then marshal behaviour such that it will act as a message >>> eating null if it receives an MNU from the tag it's looking after. >>> >>> Thanks, >>> Zulq. >>> >>> >>> >>> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 11, 2009

Re: [Pharo-project] SUnit GUI

by StÃ©phane Ducasse

When running the kernelTest-Classes testClassDescriptionallSubInstances is yellow but when run individually green. On Apr 11, 2009, at 2:57 PM, Lukas Renggli wrote: > I don't think this is related to #doesNotUnderstand:, but if you tell > me what test case this is I can have a look. > > Lukas > > On Saturday, April 11, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: >> >> On Apr 10, 2009, at 8:41 PM, Lukas Renggli wrote: >> >> >> is it normal that when one doubleclick on an yellow item in the list >> it does not open a debugger? >> >> >> No, that's not normal. >> >> Right now I can think of two possible causes: >> >> - The test is not deterministic or has side effects that cause it to >> sometimes fail and sometimes pass. >> >> >> I do not think that this is the case. >> I can reproduce the bhevaior run KernelsTests-classes. >> >> >> >> - Another reason that I recently noticed is related to exceptions and >> how SUnit runs the tests. When a test is run (when you click on run) >> the code is wrapped into an [ ... ] on: Error do: ..., thus catching >> all exceptions. When a test is debugged (when you click on an item on >> the list) the code is not wrapped in such a handler assuming that >> this >> would cause the system to open a debugger. However, depending on the >> exception raised this causes a custom default action to be evaluated >> and the test does not fail anymore. Many file-related exceptions have >> such a default behavior. Oscar recently reported an issue on this: >> <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why >> this only appeared now? Was there anything changed related to SUnit >> or >> Exceptions? >> >> >> I know that we introduce a fix of eliot in the way does not >> understand >> lead to open the debugger. >> >> see the mail below >> The code is attached to a mail of 20 of december in pharo mailing- >> list >> Let me know if you understand better than me. Now I do not have the >> time >> to look at it. >> >> Stef >> >> >> >> Begin forwarded message: >> >> >> From: "Eliot Miranda" <eliot.miranda(a)gmail.com> >> Date: December 19, 2008 7:52:21 PM CEST >> To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org >> > >> Subject: Re: [squeak-dev] Re: Resume Problems >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> >> Hi Zulq, >> >> I made sure this was fixed in VisualWorks. Steve Dahl and I >> fixed this together. Here's an analogous fix for Squeak. The >> essential change is to make Object>>doesNotUnderstand: check if the >> MessageNotUnderstood exception was handled or not, so >> >> MessageNotUnderstood new >> message: aMessage; >> receiver: self; >> signal. >> ^ aMessage sentTo: self. >> >> is replaced with >> >> (exception := MessageNotUnderstood new) >> message: aMessage; >> receiver: self. >> resumeValue := exception signal. >> ^exception reachedDefaultHandler >> ifTrue: [aMessage sentTo: self] >> ifFalse: [resumeValue] >> >> HTH >> >> On Fri, Dec 19, 2008 at 8:13 AM, Zulq Alam <me(a)zulq.net> wrote: >> Hi Klaus, >> >> >> Klaus D. Witzel wrote: >> Nah, the result has nothing to do with #on:do: resuming with 1, you >> better >> try >> >> [('abc' + 1) + 1] >> on: MessageNotUnderstood >> do: [:e | e resume: -1] >> >> which still says 2. This because someone, behind you back, put >> #asNumber >> arithmethic into ByteString ... now this attempts (Number readFrom: >> 'abc') >> which gives 0 for your +1 +1 and so 2. >> >> You may want to start DNU testing with ('abc' break; + 1) and then >> see >> where it goes. >> >> Hmm... I think something is not right or at the very least the >> semantics are subtly different than I expect. >> >> VisualWorks: >> [Object new blah + 1] >> on: MessageNotUnderstood >> do: [:e | e resume: 1] " = 2 " >> >> [MessageNotUnderstood signal + 1] >> on: MessageNotUnderstood >> do: [:e | e resume: 1] " = 2 " >> >> Squeak: >> [Object new blah + 1] >> on: MessageNotUnderstood >> do: [:e | e resume: 1] " infinite recursion!!! " >> >> [MessageNotUnderstood signal + 1] >> on: MessageNotUnderstood >> do: [:e | e resume: 1] " = 2 " >> >> >> If I look at doesNotUnderstand: in both I see that in VW the >> resumed value is returned. In Squeak is is not... surely this can't >> be right? >> >> As for my problem, I think a simpler solution is to pass an adaptor/ >> proxy object to the block rather than the tag itself. This adaptor >> can then marshal behaviour such that it will act as a message >> eating null if it receives an MNU from the tag it's looking after. >> >> Thanks, >> Zulq. >> >> >> >> > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 11, 2009

Re: [Pharo-project] SUnit GUI

by Lukas Renggli

I don't think this is related to #doesNotUnderstand:, but if you tell me what test case this is I can have a look. Lukas On Saturday, April 11, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Apr 10, 2009, at 8:41 PM, Lukas Renggli wrote: > > > is it normal that when one doubleclick on an yellow item in the list > it does not open a debugger? > > > No, that's not normal. > > Right now I can think of two possible causes: > > - The test is not deterministic or has side effects that cause it to > sometimes fail and sometimes pass. > > > I do not think that this is the case. > I can reproduce the bhevaior run KernelsTests-classes. > > > > - Another reason that I recently noticed is related to exceptions and > how SUnit runs the tests. When a test is run (when you click on run) > the code is wrapped into an [ ... ] on: Error do: ..., thus catching > all exceptions. When a test is debugged (when you click on an item on > the list) the code is not wrapped in such a handler assuming that this > would cause the system to open a debugger. However, depending on the > exception raised this causes a custom default action to be evaluated > and the test does not fail anymore. Many file-related exceptions have > such a default behavior. Oscar recently reported an issue on this: > <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why > this only appeared now? Was there anything changed related to SUnit or > Exceptions? > > > I know that we introduce a fix of eliot in the way does not understand > lead to open the debugger. > > see the mail below > The code is attached to a mail of 20 of december in pharo mailing-list > Let me know if you understand better than me. Now I do not have the time > to look at it. > > Stef > > > > Begin forwarded message: > > > From: "Eliot Miranda" <eliot.miranda(a)gmail.com> > Date: December 19, 2008 7:52:21 PM CEST > To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: Resume Problems > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi Zulq, > > Â Â I made sure this was fixed in VisualWorks. Â Steve Dahl and I fixed this together. Â Here's an analogous fix for Squeak. Â The essential change is to make Object>>doesNotUnderstand: check if the MessageNotUnderstood exception was handled or not, so > > Â Â Â Â MessageNotUnderstood new > Â Â Â Â Â Â Â Â message: aMessage; > Â Â Â Â Â Â Â Â receiver: self; > Â Â Â Â Â Â Â Â signal. > Â Â Â Â ^ aMessage sentTo: self. > > is replaced with > > Â Â Â Â (exception := MessageNotUnderstood new) > Â Â Â Â Â Â Â Â message: aMessage; > Â Â Â Â Â Â Â Â receiver: self. > Â Â Â Â resumeValue := exception signal. > Â Â Â Â ^exception reachedDefaultHandler > Â Â Â Â Â Â Â Â ifTrue: [aMessage sentTo: self] > Â Â Â Â Â Â Â Â ifFalse: [resumeValue] > > HTH > > On Fri, Dec 19, 2008 at 8:13 AM, Zulq Alam <me(a)zulq.net> wrote: > Hi Klaus, > > > Klaus D. Witzel wrote: > Nah, the result has nothing to do with #on:do: resuming with 1, you better > try > > [('abc' + 1) + 1] > Â on: MessageNotUnderstood > Â do: [:e | e resume: -1] > > which still says 2. This because someone, behind you back, put #asNumber > arithmethic into ByteString ... now this attempts (Number readFrom: 'abc') > which gives 0 for your +1 +1 and so 2. > > You may want to start DNU testing with ('abc' break; + 1) and then see > where it goes. > > Hmm... I think something is not right or at the very least the semantics are subtly different than I expect. > > VisualWorks: > [Object new blah + 1] > Â on: MessageNotUnderstood > Â do: [:e | e resume: 1] Â " = 2 " > > [MessageNotUnderstood signal + 1] > Â on: MessageNotUnderstood > Â do: [:e | e resume: 1] " = 2 " > > Squeak: > [Object new blah + 1] > Â on: MessageNotUnderstood > Â do: [:e | e resume: 1] Â " infinite recursion!!! " > > [MessageNotUnderstood signal + 1] > Â on: MessageNotUnderstood > Â do: [:e | e resume: 1] " = 2 " > > > If I look at doesNotUnderstand: in both I see that in VW the resumed value is returned. In Squeak is is not... surely this can't be right? > > As for my problem, I think a simpler solution is to pass an adaptor/proxy object to the block rather than the tag itself. This adaptor can then marshal behaviour such that it will act as a message eating null if it receives an MNU from the tag it's looking after. > > Thanks, > Zulq. > > > > -- Lukas Renggli http://www.lukas-renggli.ch

April 11, 2009

Re: [Pharo-project] status of split join in pharo

by StÃ©phane Ducasse

On Apr 11, 2009, at 10:47 AM, Oscar Nierstrasz wrote: > > Hi Syef, ;-) :) > I am going over the two split-join implementations, merging > functionality, generalizing and making the interfaces consistent. > > About your proposal: > > splitOn: should always return an OrderedCollection containing elements > of the same type as the receiver. > > 'banana' splitOn: 'an' -> an OrderedCollection('b' '' 'a') ok :) > It doesn't make sense for this to return a String. > > When joining, of course the original type should be returned no matter > what kind of sequenceable collection was split. > > I am preparing tests for all the cases. excellent. When I see all the methods that we should remove from morph I'm convinced that this addition will be a good one proportionally to its size Stef

April 11, 2009

Re: [Pharo-project] Closure compiler

by StÃ©phane Ducasse

Oh yes it was appropriate I did not like simply the fact that you could imply that new compiler would be better named HannanCompiler since people could understand that we were stealing things by not mentioning his name. Now of course you may not have implied that and you may not like my comment. Still my point is clear. I'm greatfull to marcus to have resurrected and maintained this software over the years. Stef On Apr 11, 2009, at 2:32 AM, Michael van der Gulik wrote: > On 4/9/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> New name: yes. >>> >>> Umm... HannanCompiler (after the original author?). >> >> umm..... rot and dead compiler that marcus resurrected > > That was an inappropriate and unhelpful comment. > > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 11, 2009

Re: [Pharo-project] SUnit GUI

by StÃ©phane Ducasse

On Apr 10, 2009, at 8:41 PM, Lukas Renggli wrote: >> is it normal that when one doubleclick on an yellow item in the list >> it does not open a debugger? > > No, that's not normal. > > Right now I can think of two possible causes: > > - The test is not deterministic or has side effects that cause it to > sometimes fail and sometimes pass. I do not think that this is the case. I can reproduce the bhevaior run KernelsTests-classes. > > > - Another reason that I recently noticed is related to exceptions and > how SUnit runs the tests. When a test is run (when you click on run) > the code is wrapped into an [ ... ] on: Error do: ..., thus catching > all exceptions. When a test is debugged (when you click on an item on > the list) the code is not wrapped in such a handler assuming that this > would cause the system to open a debugger. However, depending on the > exception raised this causes a custom default action to be evaluated > and the test does not fail anymore. Many file-related exceptions have > such a default behavior. Oscar recently reported an issue on this: > <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why > this only appeared now? Was there anything changed related to SUnit or > Exceptions? I know that we introduce a fix of eliot in the way does not understand lead to open the debugger. see the mail below The code is attached to a mail of 20 of december in pharo mailing-list Let me know if you understand better than me. Now I do not have the time to look at it. Stef Begin forwarded message: > From: "Eliot Miranda" <eliot.miranda(a)gmail.com> > Date: December 19, 2008 7:52:21 PM CEST > To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [squeak-dev] Re: Resume Problems > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Hi Zulq, > > I made sure this was fixed in VisualWorks. Steve Dahl and I > fixed this together. Here's an analogous fix for Squeak. The > essential change is to make Object>>doesNotUnderstand: check if the > MessageNotUnderstood exception was handled or not, so > > MessageNotUnderstood new > message: aMessage; > receiver: self; > signal. > ^ aMessage sentTo: self. > > is replaced with > > (exception := MessageNotUnderstood new) > message: aMessage; > receiver: self. > resumeValue := exception signal. > ^exception reachedDefaultHandler > ifTrue: [aMessage sentTo: self] > ifFalse: [resumeValue] > > HTH > > On Fri, Dec 19, 2008 at 8:13 AM, Zulq Alam <me(a)zulq.net> wrote: > Hi Klaus, > > > Klaus D. Witzel wrote: > Nah, the result has nothing to do with #on:do: resuming with 1, you > better > try > > [('abc' + 1) + 1] > on: MessageNotUnderstood > do: [:e | e resume: -1] > > which still says 2. This because someone, behind you back, put > #asNumber > arithmethic into ByteString ... now this attempts (Number readFrom: > 'abc') > which gives 0 for your +1 +1 and so 2. > > You may want to start DNU testing with ('abc' break; + 1) and then see > where it goes. > > Hmm... I think something is not right or at the very least the > semantics are subtly different than I expect. > > VisualWorks: > [Object new blah + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " = 2 " > > [MessageNotUnderstood signal + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " = 2 " > > Squeak: > [Object new blah + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " infinite recursion!!! " > > [MessageNotUnderstood signal + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " = 2 " > > > If I look at doesNotUnderstand: in both I see that in VW the resumed > value is returned. In Squeak is is not... surely this can't be right? > > As for my problem, I think a simpler solution is to pass an adaptor/ > proxy object to the block rather than the tag itself. This adaptor > can then marshal behaviour such that it will act as a message eating > null if it receives an MNU from the tag it's looking after. > > Thanks, > Zulq. > > > _______________________________________________ Pharo-project mailing list

April 11, 2009

Re: [Pharo-project] i can has TestCase>>#assert:equals: ?

by Alexandre Bergel

SUnit should have this methods for years Alexandre On 10 Apr 2009, at 21:06, Oscar Nierstrasz wrote: > > Hi folks, > > 90% of my tests just test equality of a result to an expected value, > so I waste time trying to find out what the mismatch is. Would be > nice to have this method in SUnit: > > assert: result equals: expected > result = expected > ifFalse: [self signalFailure: 'Assertion failed: (' , result > asString , ') ~= (' , expected asString , ')'] > > Does anyone see a downside, or possible improvements? > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 11, 2009

Re: [Pharo-project] status of split join in pharo

by Oscar Nierstrasz

Hi Syef, ;-) I am going over the two split-join implementations, merging functionality, generalizing and making the interfaces consistent. About your proposal: splitOn: should always return an OrderedCollection containing elements of the same type as the receiver. 'banana' splitOn: 'an' -> an OrderedCollection('b' '' 'a') It doesn't make sense for this to return a String. When joining, of course the original type should be returned no matter what kind of sequenceable collection was split. I am preparing tests for all the cases. - on On Apr 5, 2009, at 10:33, StÃ©phane Ducasse wrote: > then I have a question what splitBy: returns? > does it return a collection that is the same kind of the receiver? > Why do you hard code an OrderedCollection in splitBySubCollection: > aSplitter. > self species would do it too? > Syef

April 11, 2009

Re: [Pharo-project] Help fixing tests

by John M McIntosh

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'. 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(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 11, 2009

Re: [Pharo-project] Closure compiler

by Michael van der Gulik

On 4/9/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> New name: yes. >> >> Umm... HannanCompiler (after the original author?). > > umm..... rot and dead compiler that marcus resurrected That was an inappropriate and unhelpful comment. Gulik. -- http://gulik.pbwiki.com/

April 11, 2009