- Pharo-dev - lists.pharo.org

[Pharo-project] Postgresql + pharo

by HervÃ© Darce

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

April 11, 2009

Re: [Pharo-project] [on] why can't I write on a WriteStream on an OrderedCollection?

by Lukas Renggli

Squeak streams only work on Array and String instances. The power of objects ;-) Lukas On Saturday, April 11, 2009, Oscar Nierstrasz <oscar(a)iam.unibe.ch> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

April 11, 2009

[Pharo-project] [on] why can't I write on a WriteStream on an OrderedCollection?

by Oscar Nierstrasz

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

April 11, 2009

Re: [Pharo-project] SUnit GUI

by Lukas Renggli

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

April 11, 2009

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