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

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

[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