Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass
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: On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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
On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
On Fri, Dec 2, 2011 at 10:29 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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.
+1
Nicolas
On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 < bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
-- best, Eliot
2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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 <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
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 <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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 <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
Again, thanks a lot Nicolas for digging in this problem and finding a solution. I think your solution looks good. But you are essentially avoiding the problem that there is an object involved that cannot print itself. Marcus tried to tackle that problems, and I think that he was right to change the printOn: so that it works and does not have side effects. Would it not be possible to have a 'safe' way to print instances ? [ object printString ] on: Exception do: [ ' unprintable object of class ', object class ] Sven On 02 Dec 2011, at 23:52, Nicolas Cellier wrote:
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 <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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 <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
<Fix-Error-description.st>
Sven, I was taught to never trap Exception - Error is ok to trap, AFAIK. Beyond that, where does this code live? How often/when does it execute? Exception handlers are expensive to set up and even more expensive when used. This is not really an exceptional condition; it is a predictable failure and one that can be handled locally rather than needing to be left to the application layer. IMHO, it is not a good place to use an exception handler. Hanging in place of opening a walkback is bad. I suggest fixing that first (the printing defect seems to be a nice way top reproduce the hang that should not happen), and THEN fix the #printOn: so the walkback does not appear. BTW, so much for my inability to reproduce this. Print-it in my 1.4 image did not go well - had to kill the vm, so it happens on Linux too. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Friday, December 02, 2011 6:08 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass Again, thanks a lot Nicolas for digging in this problem and finding a solution. I think your solution looks good. But you are essentially avoiding the problem that there is an object involved that cannot print itself. Marcus tried to tackle that problems, and I think that he was right to change the printOn: so that it works and does not have side effects. Would it not be possible to have a 'safe' way to print instances ? [ object printString ] on: Exception do: [ ' unprintable object of class ', object class ] Sven On 02 Dec 2011, at 23:52, Nicolas Cellier wrote:
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 <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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 <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
<Fix-Error-description.st>
Bill, On 03 Dec 2011, at 00:36, Schwab,Wilhelm K wrote:
I was taught to never trap Exception - Error is ok to trap, AFAIK. Beyond that, where does this code live? How often/when does it execute? Exception handlers are expensive to set up and even more expensive when used.
This is not really an exceptional condition; it is a predictable failure and one that can be handled locally rather than needing to be left to the application layer. IMHO, it is not a good place to use an exception handler.
Hanging in place of opening a walkback is bad. I suggest fixing that first (the printing defect seems to be a nice way top reproduce the hang that should not happen), and THEN fix the #printOn: so the walkback does not appear.
I totally agree on letting all exception bubble up instead of silently swallow them. However, this is a special case: the infrastructure (debugger, exception system) handling the exception is failing while doing its job (agreed: because of somebody else not doing their own job, but that happens), so the infrastructure should protect itself. Have a look at Inspector>>#selectionPrintString What I suggest would be the same. [ object printString ] on: Exception do: [ ' unprintable object of class ', object class ] It does not swallow the exception silently. Maybe the text in Inspector>>#printStringErrorText is better. Sven
On Dec 2, 2011, at 10:07 PM, Nicolas Cellier wrote:
2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2011/12/2 Marcus Denker <marcus.denker@inria.fr>:
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.
Thanks
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.
I agree now the problem is that it is not clear who is "responsible" and so far the change in context I see are the changes of eliot in runUntilError. So I will take a set of image and try one by oneâ¦. Stef
Nicolas
On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
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.
Yes if you saw my mail about what features to be fixed when esteban arrives (or before) the debugger is there. Now I do not have the time nor the knowledge to do it. We will clean and simplify this parts slowly too so that idiots like me can fix that. Stef
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 <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
On Fri, Dec 2, 2011 at 6:16 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
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).
Yes, but the real problem is either the debugger or the the redefinition of subclassResponsibility. When I try Stream basicNew printString in a Squeak image I get a notifier which says: Stream(Object)>>error: Stream(Object)>>subclassResponsibility Stream>>contents Stream>>printContentsOn: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Stream>>printOn: [] in Stream(Object)>>printStringLimitedTo: String class(SequenceableCollection class)>>streamContents:limitedTo: Stream(Object)>>printStringLimitedTo: Stream(Object)>>printString But in Pharo this is crashing. I think you need to fix either the debugger or subclassResponsibility,
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:
On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 < bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
-- best, Eliot
We will have to track when this error was introduced may be this is the runtimeError fix that we pushed. We should check on images to spot this regression. Now printing the contents of a stream by default looks to me a bad idea. May be when the stream is positionable it makes sense but why would I force to read the complete contents of a stream when I open an inspector on it. Stef On Dec 2, 2011, at 7:30 PM, Eliot Miranda wrote:
On Fri, Dec 2, 2011 at 6:16 AM, Marcus Denker <marcus.denker@inria.fr> wrote: 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).
Yes, but the real problem is either the debugger or the the redefinition of subclassResponsibility. When I try Stream basicNew printString in a Squeak image I get a notifier which says:
Stream(Object)>>error: Stream(Object)>>subclassResponsibility Stream>>contents Stream>>printContentsOn: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Stream>>printOn: [] in Stream(Object)>>printStringLimitedTo: String class(SequenceableCollection class)>>streamContents:limitedTo: Stream(Object)>>printStringLimitedTo: Stream(Object)>>printString
But in Pharo this is crashing. I think you need to fix either the debugger or subclassResponsibility,
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:
On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <ljw1001@gmail.com>:
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 <ljw1001@gmail.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Larry White [ljw1001@gmail.com] Sent: Thursday, December 01, 2011 12:56 PM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 -- denker@acm.org http://www.marcusdenker.de
-- best, Eliot
On 3 December 2011 01:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We will have to track when this error was introduced may be this is the runtimeError fix that we pushed. We should check on images to spot this regression.
Now printing the contents of a stream by default looks to me a bad idea. May be when the stream is positionable it makes sense but why would I force to read the complete contents of a stream when I open an inspector on it.
I think that 'contents' concept in streams are controversial. Just consider: - a stream which generates random numbers. every time you send #next, you get another random number. what is a contents of such stream? all random numbers it can generate till universe die? - a real-time stream broadcasting video/audio. what is a contents of such stream? you cannot capture whole contents of it, because these kinds of streams has no 'end'. It is because streams are for processing data in portions, and when you requesting contents of it, you turning it into collection. Here the Collection class comment: " I am the abstract superclass of all classes that represent a group of elements. " And Stream: " I am an abstract class that represents an accessor for a sequence of objects. This sequence is referred to as my "contents". " Yes. Of course, abstractly speaking, all streams containing something , but you can access it only by portions. Otherwise they will be no different to collections and therefore we won't need them. -- Best regards, Igor Stasenko.
+100 On 04 Dec 2011, at 00:07, Igor Stasenko wrote:
On 3 December 2011 01:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We will have to track when this error was introduced may be this is the runtimeError fix that we pushed. We should check on images to spot this regression.
Now printing the contents of a stream by default looks to me a bad idea. May be when the stream is positionable it makes sense but why would I force to read the complete contents of a stream when I open an inspector on it.
I think that 'contents' concept in streams are controversial. Just consider: - a stream which generates random numbers. every time you send #next, you get another random number. what is a contents of such stream? all random numbers it can generate till universe die?
- a real-time stream broadcasting video/audio. what is a contents of such stream? you cannot capture whole contents of it, because these kinds of streams has no 'end'.
It is because streams are for processing data in portions, and when you requesting contents of it, you turning it into collection.
Here the Collection class comment: " I am the abstract superclass of all classes that represent a group of elements. "
And Stream: " I am an abstract class that represents an accessor for a sequence of objects. This sequence is referred to as my "contents". " Yes. Of course, abstractly speaking, all streams containing something , but you can access it only by portions. Otherwise they will be no different to collections and therefore we won't need them.
-- Best regards, Igor Stasenko.
I agree with you. Nevertheless it seems that there is a bug in the debugger.
In a workspace, type this and debug it: Stream basicNew printString.
Step over basicNBew. Step into printString. Step into printStringLimitedTo: 50000 Step into streamContents: [:s | self printOn: s] limitedTo: limit Step over 100 min: sizeLimit Step over self new: (100 min: sizeLimit) --> error: the debugger tries to execute (String new: String)
I also note that all class methods in stack window left column are miss-printed - like 'Block in class)' new:
Stef On Dec 4, 2011, at 12:07 AM, Igor Stasenko wrote:
On 3 December 2011 01:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We will have to track when this error was introduced may be this is the runtimeError fix that we pushed. We should check on images to spot this regression.
Now printing the contents of a stream by default looks to me a bad idea. May be when the stream is positionable it makes sense but why would I force to read the complete contents of a stream when I open an inspector on it.
I think that 'contents' concept in streams are controversial. Just consider: - a stream which generates random numbers. every time you send #next, you get another random number. what is a contents of such stream? all random numbers it can generate till universe die?
- a real-time stream broadcasting video/audio. what is a contents of such stream? you cannot capture whole contents of it, because these kinds of streams has no 'end'.
It is because streams are for processing data in portions, and when you requesting contents of it, you turning it into collection.
Here the Collection class comment: " I am the abstract superclass of all classes that represent a group of elements. "
And Stream: " I am an abstract class that represents an accessor for a sequence of objects. This sequence is referred to as my "contents". " Yes. Of course, abstractly speaking, all streams containing something , but you can access it only by portions. Otherwise they will be no different to collections and therefore we won't need them.
-- Best regards, Igor Stasenko.
participants (7)
-
Eliot Miranda -
Igor Stasenko -
Marcus Denker -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe