I suggest to change the #standardMessageText to rather print signaller class Attached a change set, please open an issue and review carefully.
Nicolas 2011/12/2 Nicolas Cellier <[email protected]>: > 2011/12/2 Nicolas Cellier <[email protected]>: >> 2011/12/2 Marcus Denker <[email protected]>: >>> Hi, >>> >>> We had a look and the problem is that printOn: on Stream is defined to >>> print the contents of the Stream even though it might >>> not be initialized yet (e.g. when creating a Stream instance with >>> #basicNew). >>> >>> The simplest solution is to just not print the contents of Streams in >>> #printOn: >>> >>> http://code.google.com/p/pharo/issues/detail?id=5047 >>> >>> Stream should not print its contents in printOn: >>> >>> Reason: >>> >>> => Debugging leads to change the state of Stream when looking at it >>> => Network streams load all content >>> => unitialized Streams has undefined behavior for printing >>> >>> Solution: remove #printOn: >>> >> >> No, no, no I don't agree, you are hiding the main problem, not solving it. >> The main problem is not this error, the main problem is that the >> debugger does not appear when it should. >> >> Nicolas >> > > The problem with SubclassResponsibility is its #description. > The #description method will send #messageText which will send > #standardMessageText which will try to print the signaller which is > the unprintable (not initialized) Stream basicNew. > Thus when the UnhandledError triggers a (Smalltalk tools debugError: > anException) it fails with a new SubclassResponsibility error... > This does not happen previously with an ordinary Error which has a > more robust #description, thus SubclassResponsibility effectively > introduced a new weakness. > > With current state of debugger in Pharo 1.4, this is not a pleasure, > IMO it's very urgent to fix it. > Who ever messed with Debugger/Context or any such dangerous internals > has a FirstClassResponsibility to make it work or revert. > > Nicolas > >>> On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse >>> <[email protected]> wrote: >>>>>>> >>>>>>> I only had a look in Pharo 1.4 >>>>>>> It sounds like a subtle bug related to introduction of >>>>>>> SubclassResponsibility in Pharo. >>>>>>> If you revert Object>>subclassResponsibility to its previous version >>>>>>> you get a more reliable error. >>>>>> >>>>>> What would be your hypothesis? Because I'm stuck. >>>>>> error: is also signaling an exception >>>>>> >>>>>> error: aString >>>>>> "Throw a generic Error exception." >>>>>> >>>>>> ^Error new signal: aString >>>>>> >>>>>> So I wonder why one is more robust. >>>>>> >>>>> >>>>> I'm stuck too, and the Debugger is currently unusable in Pharo 1.4 (I >>>>> just can't step over…) >>>> >>>> Strange. Because I use it. >>>> Do you have a scenario that we can focus on to fix the problem you see. >>>> >>>> >>>>> I give up. I only had time for an easy task... >>>>> >>>>> Nicolas >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> 2011/12/1 Larry White <[email protected]>: >>>>>>>> I was able to replicate with a clean version of the Seaside 3.0.6 One >>>>>>>> Click >>>>>>>> download by executing Stream #basicNew in a workspace. It did work a >>>>>>>> couple >>>>>>>> times ok using "do it" from the menu, but seems to lock pretty >>>>>>>> regularly >>>>>>>> using print or explore keyboard shortcuts. >>>>>>>> >>>>>>>> thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 1, 2011 at 1:33 PM, Larry White <[email protected]> wrote: >>>>>>>>> >>>>>>>>> I can do it with control-P (print) in the Workspace. I just did it >>>>>>>>> with a >>>>>>>>> single try, though sometimes it takes more than one. Speed isn't an >>>>>>>>> issue, >>>>>>>>> I can wait 10 minutes and see it happen sometimes.. >>>>>>>>> >>>>>>>>> I have to take a break now, but when I get a few minutes, I'll try >>>>>>>>> again >>>>>>>>> with a fresh install of the latest Seaside one-click for the mac. >>>>>>>>> >>>>>>>>> thanks. >>>>>>>>> >>>>>>>>> On Thu, Dec 1, 2011 at 1:20 PM, Schwab,Wilhelm K >>>>>>>>> <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I just tried to hang 1.1.1 (using a traditional linux vm) and a 1.4 >>>>>>>>>> image >>>>>>>>>> with a Cog vm (also linux). No problems, but I do have questions >>>>>>>>>> that might >>>>>>>>>> be important to others trying to reproduce it: >>>>>>>>>> >>>>>>>>>> (1) how fast do you do this? >>>>>>>>>> (2) do you inspect the instances, or just let them get gc'd >>>>>>>>>> immediately? >>>>>>>>>> >>>>>>>>>> Bill >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>> From: [email protected] >>>>>>>>>> [[email protected]] on behalf of Larry >>>>>>>>>> White >>>>>>>>>> [[email protected]] >>>>>>>>>> Sent: Thursday, December 01, 2011 12:56 PM >>>>>>>>>> To: [email protected] >>>>>>>>>> Subject: Re: [Pharo-project] VM freezes sending #basicNew to Stream >>>>>>>>>> subclass >>>>>>>>>> >>>>>>>>>> I can do it with >>>>>>>>>> >>>>>>>>>> Stream basicNew. >>>>>>>>>> >>>>>>>>>> but I have to invoke it twice. The first time it works ok. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Dec 1, 2011 at 12:48 PM, Stéphane Ducasse >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> gary >>>>>>>>>>> >>>>>>>>>>> can you post the smallest code that makes the system hangs? >>>>>>>>>>> >>>>>>>>>>> Stef >>>>>>>>>>> >>>>>>>>>>> On Dec 1, 2011, at 4:48 PM, Larry White wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Throwing this out there because it may be a bug. >>>>>>>>>>>> >>>>>>>>>>>> I'm running the Seaside one-click install on OS X Lion. >>>>>>>>>>>> Pharo1.3 >>>>>>>>>>>> Latest update: #13302 >>>>>>>>>>>> >>>>>>>>>>>> I can reliably cause my VM to freeze up and need to Force-Quit it >>>>>>>>>>>> from >>>>>>>>>>>> the OS. >>>>>>>>>>>> >>>>>>>>>>>> I'm implementing (copying) the probability logic from the blue >>>>>>>>>>>> book. >>>>>>>>>>>> When I tried to create an instance of the Binomial class, the >>>>>>>>>>>> system hung. I >>>>>>>>>>>> can replicate the problem by sending the message #basicNew to >>>>>>>>>>>> ProbabilityDistribution. ProbabilityDistribution is a direct >>>>>>>>>>>> subclass of >>>>>>>>>>>> Stream and I haven't overridden or modified #basicNew. >>>>>>>>>>>> >>>>>>>>>>>> What's happening is that it fails in the BlockClosure [anObject >>>>>>>>>>>> doit], >>>>>>>>>>>> but only when I instantiate a member of this particular class >>>>>>>>>>>> hierarchy. In >>>>>>>>>>>> the probability classes, a #doIt in a Workspace hits the line >>>>>>>>>>>> "self suspend" >>>>>>>>>>>> in the #terminate method of Process and the VM hangs there. >>>>>>>>>>>> >>>>>>>>>>>> I believe they had ProbabilityDistribution subclass from Stream >>>>>>>>>>>> because sampling from a distribution is like reading from a >>>>>>>>>>>> Stream, but I >>>>>>>>>>>> don't think any there's any actual shared code, so I switched the >>>>>>>>>>>> superclass >>>>>>>>>>>> of ProbabilityDistribution to Object and the code works fine now. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> Larry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> -- >>> Marcus Denker -- [email protected] >>> http://www.marcusdenker.de >>>
Fix-Error-description.st
Description: Binary data
