- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Help fixing tests

by Mariano Martinez Peck

On Fri, Apr 10, 2009 at 11:44 PM, John M McIntosh < johnmci(a)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(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 > = > = > = > ======================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2009

Re: [Pharo-project] Closure compiler

by Michael van der Gulik

On 4/12/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. I certainly didn't mean any disrespect or lack of admiration for what Marcus has done. It was just a name to avoid ambiguity. Do you have another suggestion for a name? Gulik. -- http://gulik.pbwiki.com/

April 11, 2009

Re: [Pharo-project] SUnit GUI

by Oscar Nierstrasz

Wow. I naively assumed that the entire run-time context was still there as long as the red/yellow test was not garbage collected. Rerunning is obviously the smart thing to do, but snafus non-deterministic tests. So you should just click on those yellow tests over and over till the debugger pops up? ;-) - on On Apr 11, 2009, at 23:15, Lukas Renggli wrote: >> indeed but when this is yellow we should be able to click on it? > > Clicking on a yellow or red test just re-runs that test. If the test > then suddenly passes, you are out of luck. > > The problem could be solved by capturing and storing a continuation > when a test fails. Like this a debugger could be opened on the > original stack that caused the error. This however would require a > major rewrite of SUnit, as extra care has to be take when and how to > release resources. > > Lukas > > -- > 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

> indeed but when this is yellow we should be able to click on it? Clicking on a yellow or red test just re-runs that test. If the test then suddenly passes, you are out of luck. The problem could be solved by capturing and storing a continuation when a test fails. Like this a debugger could be opened on the original stack that caused the error. This however would require a major rewrite of SUnit, as extra care has to be take when and how to release resources. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 11, 2009

Re: [Pharo-project] Postgresql + pharo

by HervÃ© Darce

StÃ©phane Ducasse a Ã©crit : > Hi herve > > which image are you using? > which vm? > which os + number + version ... > > Stef > Hi Stef, vm : squeak 3.10 image : pharo 10213 os : GNU Linux Gentoo 2008 Same configuration on my computer and my web server. But I don't use virtualization on my computer. Herve Darce

April 11, 2009

Re: [Pharo-project] Postgresql + pharo

by HervÃ© Darce

Hi Adrian, > > Its hard to tell what the problem is. Can you post more detailed > information about your server and the VM you are using? I use virtualization : GNU Linux Gentoo + UML (user mode linux). Postgresql et Pharo are on the same virtual machine. I use Pharo 10213 > Does it crash > always with the same stack? Yes, the same stack > Does it crash immediately the first time > you access the DB or after some time? I go without any problems to seaside and pier. But, my server crash immediately the first time I access the DB > Can you even reproduce the crash? > I can't reproduce the crash on my computer. I don't understand. > Two things to try out: > - if you are on Linux, start the VM with the option -notimer > - start the VM with option -mmap 200MB > I have the same problem Cheers, Herve Darce

April 11, 2009

Re: [Pharo-project] Postgresql + pharo

by StÃ©phane Ducasse

Hi herve which image are you using? which vm? which os + number + version ... Stef On Apr 11, 2009, at 9:51 PM, HervÃ© Darce wrote: > Hi, > > I run my server with "squeak -vm display=none myimage.image" > > I use postgresql to store data : > * class YoGlorpDb for connection with postgresql > * class YoDbRootComponent for for web display > > On my computer, the display was without error. But on the web server, > the image stops abruptly with the message : > > ---------------- > Segmentation fault > > 37940600 Socket>connectNonBlockingTo:port: > 37940508 Socket>connectTo:port:waitForConnectionFor: > 37940416 Socket>connectTo:port: > 37932200 PGConnection>openSocket > 37932108 PGConnection>stStartup: > 37931924 PGActiveObject>processEvent: > 37931832 PGActiveObject>saProcessEventsUntil: > 37931304 PGConnection>startup > 37931740 [] in SqueakDatabaseAccessor>loginIfError: > 37931212 BlockContext>on:do: > 37931120 DatabaseAccessor>execute:ifError: > 37910208 SqueakDatabaseAccessor>loginIfError: > 37910116 DatabaseAccessor>login > 37910392 [] in YoGlorpDb>connect > 37910024 BlockContext>on:do: > 37909380 BlockContext>ifError: > 37874356 YoGlorpDb>connect > 37874264 YoGlorpDb>initialize > 37874172 Behavior>new > 37874080 >new > 37873988 YoDbRootComponent>initialize > 37873896 >new > 37871628 WARenderLoopMain>createRoot > 37871536 WARenderLoopMain>start: > 37862092 WASession>start: > 37862000 [] in WASession>performRequest: > 37860588 Dictionary>at:ifAbsent: > 37860496 WASession>performRequest: > 37861632 [] in WASession>responseForRequest: > 37860404 BlockContext>on:do: > 37861724 [] in WASession>withErrorHandler: > 37860312 BlockContext>on:do: > 37860196 WASession>withErrorHandler: > 37861448 [] in WASession>responseForRequest: > 37860008 BlockContext>on:do: > 37859916 >use:during: > 37859548 [] in WASession>responseForRequest: > 37859732 [] in WASession>withEscapeContinuation: > 37859824 >currentDo: > 37859640 WASession>withEscapeContinuation: > 37859272 WASession>responseForRequest: > 37858296 [] in WASession>incomingRequest: > 37859144 BlockContext>on:do: > 37859364 [] in WAProcessMonitor>critical:ifError: > 37859052 BlockContext>ensure: > 37858868 [] in WAProcessMonitor>critical:ifError: > 37858960 [] in BlockContext>newProcess > Abandon > ---------------- > > What is the problem on my web server? > > Cheers, > > Herve Darce > > _______________________________________________ > 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] [on] why can't I write on a WriteStream on an OrderedCollection?

by StÃ©phane Ducasse

Lukas already replied and this is for this reason that we should continue to work on Nile because with Nile you get real streams. Stef On Apr 11, 2009, at 7:39 PM, Oscar Nierstrasz wrote: > > Can anyone explain to me why this works fine: > > ((WriteStream on: (Array new)) nextPut: #foo) contents. > > but this doesn't? > > ((WriteStream on: (OrderedCollection new)) nextPut: #foo) contents. > > The debugger shows that WriteStream>>nextPut: invokes > WriteStream>>pastEndPut: which invokes at:put: on the collection. > > This is ok for an array, but not for an OrderedCollection, as > OrderedCollection>>at:put: explicitly states it cannot be used to > append stuff to the end of the collection. > > Is it a bug in WriteStream that it sends at:put:, or does it just not > make sense to have a WriteStream on an Ordered Collection? > > (This is related to the split and join methods -- because of this > limitation, an OrderedCollection cannot be used as a joiner, it > seems.) > > - on > > > _______________________________________________ > 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

indeed but when this is yellow we should be able to click on it? no? Stef On Apr 11, 2009, at 6:54 PM, Lukas Renggli wrote: > Mhh no. In some rare cases it is yellow. > > There is definitely something non-deterministic or something with > side-effects in those tests. > > Lukas > > On Sat, Apr 11, 2009 at 6:52 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: >> 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 >> > > > > -- > 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] Postgresql + pharo

by Adrian Lienhard

Hi Herve, Its hard to tell what the problem is. Can you post more detailed information about your server and the VM you are using? Does it crash always with the same stack? Does it crash immediately the first time you access the DB or after some time? Can you even reproduce the crash? Two things to try out: - if you are on Linux, start the VM with the option -notimer - start the VM with option -mmap 200MB HTH, Adrian On Apr 11, 2009, at 21:51 , HervÃ© Darce wrote: > Hi, > > I run my server with "squeak -vm display=none myimage.image" > > I use postgresql to store data : > * class YoGlorpDb for connection with postgresql > * class YoDbRootComponent for for web display > > On my computer, the display was without error. But on the web server, > the image stops abruptly with the message : > > ---------------- > Segmentation fault > > 37940600 Socket>connectNonBlockingTo:port: > 37940508 Socket>connectTo:port:waitForConnectionFor: > 37940416 Socket>connectTo:port: > 37932200 PGConnection>openSocket > 37932108 PGConnection>stStartup: > 37931924 PGActiveObject>processEvent: > 37931832 PGActiveObject>saProcessEventsUntil: > 37931304 PGConnection>startup > 37931740 [] in SqueakDatabaseAccessor>loginIfError: > 37931212 BlockContext>on:do: > 37931120 DatabaseAccessor>execute:ifError: > 37910208 SqueakDatabaseAccessor>loginIfError: > 37910116 DatabaseAccessor>login > 37910392 [] in YoGlorpDb>connect > 37910024 BlockContext>on:do: > 37909380 BlockContext>ifError: > 37874356 YoGlorpDb>connect > 37874264 YoGlorpDb>initialize > 37874172 Behavior>new > 37874080 >new > 37873988 YoDbRootComponent>initialize > 37873896 >new > 37871628 WARenderLoopMain>createRoot > 37871536 WARenderLoopMain>start: > 37862092 WASession>start: > 37862000 [] in WASession>performRequest: > 37860588 Dictionary>at:ifAbsent: > 37860496 WASession>performRequest: > 37861632 [] in WASession>responseForRequest: > 37860404 BlockContext>on:do: > 37861724 [] in WASession>withErrorHandler: > 37860312 BlockContext>on:do: > 37860196 WASession>withErrorHandler: > 37861448 [] in WASession>responseForRequest: > 37860008 BlockContext>on:do: > 37859916 >use:during: > 37859548 [] in WASession>responseForRequest: > 37859732 [] in WASession>withEscapeContinuation: > 37859824 >currentDo: > 37859640 WASession>withEscapeContinuation: > 37859272 WASession>responseForRequest: > 37858296 [] in WASession>incomingRequest: > 37859144 BlockContext>on:do: > 37859364 [] in WAProcessMonitor>critical:ifError: > 37859052 BlockContext>ensure: > 37858868 [] in WAProcessMonitor>critical:ifError: > 37858960 [] in BlockContext>newProcess > Abandon > ---------------- > > What is the problem on my web server? > > Cheers, > > Herve Darce > > _______________________________________________ > 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