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