- Pharo-dev - lists.pharo.org

Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass

by Nicolas Cellier

2011/12/2 Marcus Denker <marcus.denker(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr >>>>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Larry White >>>>>>>> [ljw1001(a)gmail.com] >>>>>>>> Sent: Thursday, December 01, 2011 12:56 PM >>>>>>>> To: Pharo-project(a)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(a)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(a)acm.org > http://www.marcusdenker.de >

Dec. 2, 2011

Re: [Pharo-project] SubscriptOutOfBounds while Debugging

by Nicolas Cellier

2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I got strange behaviour when stepping other, the wrong argument is not other, over (just because my bloody french brain doesn't make a difference between songs) > sometimes sent, so there's definitely something broken in the > Debugger... > > Nicolas > > 2011/12/2 Sean P. DeNigris <sean(a)clipperadams.com>: >> In Pharo1.4a Latest update: #14238, I keep getting the error while stepping >> through code. Also, the tools (Browser, Implementors, etc.) take *forever* >> to appear. Is anyone else experiencing either? >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/SubscriptOutOfBounds-while-Debugging-tp4148106p414810… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>

Dec. 2, 2011

Re: [Pharo-project] SubscriptOutOfBounds while Debugging

by Nicolas Cellier

I got strange behaviour when stepping other, the wrong argument is sometimes sent, so there's definitely something broken in the Debugger... Nicolas 2011/12/2 Sean P. DeNigris <sean(a)clipperadams.com>: > In Pharo1.4a Latest update: #14238, I keep getting the error while stepping > through code. Also, the tools (Browser, Implementors, etc.) take *forever* > to appear. Is anyone else experiencing either? > > Sean > > -- > View this message in context: http://forum.world.st/SubscriptOutOfBounds-while-Debugging-tp4148106p414810… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 2, 2011

Re: [Pharo-project] Prune stack serialization

by Nicolas Cellier

2011/12/2 Martin Dias <tinchodias(a)gmail.com>: > Hi folks > > In Fuel, we serialize a block closure with its state, including its > outerContext. This enables to serialize a sorted collection with its > sortBlock: > > | bytes result | > bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock: [:a > :b | a > b ]). > result := FLMaterializer materializeFromByteArray: bytes. > result > addAll: #(1 2 3); > yourself. > ---> a SortedCollection(3 2 1) > > Here the problem: theÂ byte array is huge! (800kb) because we are serializing > unneeded context for the sort block. > > We wonder how to prune it and save time and space. > > Thanks in advance > MartÃn In the case of such clean block, there is no need of outer context during block execution. However I don't know if implementation makes it possible to ignore the context... That's more a question directed to Eliot ;) Nicolas

Dec. 2, 2011

[Pharo-project] Prune stack serialization

by Martin Dias

Hi folks In Fuel, we serialize a block closure with its state, including its outerContext. This enables to serialize a sorted collection with its sortBlock: | bytes result | bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock: [:a :b | a > b ]). result := FLMaterializer materializeFromByteArray: bytes. result addAll: #(1 2 3); yourself. ---> a SortedCollection(3 2 1) Here the problem: the byte array is huge! (800kb) because we are serializing unneeded context for the sort block. We wonder how to prune it and save time and space. Thanks in advance MartÃn

Dec. 2, 2011

[Pharo-project] SubscriptOutOfBounds while Debugging

by Sean P. DeNigris

In Pharo1.4a Latest update: #14238, I keep getting the error while stepping through code. Also, the tools (Browser, Implementors, etc.) take *forever* to appear. Is anyone else experiencing either? Sean -- View this message in context: http://forum.world.st/SubscriptOutOfBounds-while-Debugging-tp4148106p414810… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 2, 2011

Re: [Pharo-project] startup errors

by Igor Stasenko

We invented a way to hack an image with Camillo. Instead of hacking VM :) THis is easy and fast. On 2 December 2011 15:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote >> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> > > I don't always know I'm going to destroy my image in advance :) It would be > nice to have a way to recover anyway. > > -- > View this message in context: http://forum.world.st/startup-errors-tp3736966p4147365.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko.

Dec. 2, 2011

Re: [Pharo-project] latest VM sources

by Igor Stasenko

On 1 December 2011 15:39, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Yes, I showed him CI configurations. I tried to follow them manually > and I have two notices: > > - loading of VMMaker raises a warning window (dependency on squeak lanucher) long known, insignificant issue :) > - the generated archive StackUnixConfig-sources.tar.gz contains in > cmake configuration full paths related to CI server so it can not be > compiled out-of-the-box > yes. you need to manually change them. it is because these paths are generated from image, and they could be set separately (to be completely in different paths on system). that's why they are there, not a relative to each other or to some common root. > Cheers, > -- Pavel > > On Thu, Dec 1, 2011 at 3:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi Pavel, >> >> you can find all sources in our >> jenkins:Â https://ci.lille.inria.fr/pharo/view/VM/ >> >> cheers, >> Esteban >> >> El 01/12/2011, a las 5:22a.m., Pavel Krivanek escribiÃ³: >> >> Hi, >> >> a guy from Red Hat owes me a favor so he promised me to create >> official Fedora packages for latest Pharo/Squeak related projects >> (virtual machines and images). But he wants some information like >> where to find latests virtual machines source codes, what are the >> dependencies etc. >> >> Looking at squeakvm.org, there is only a link to 3.11-3.2135 svn repository. >> >> Can you please summarize me the links to latest StackVM and CogVM >> sources? I guess he will not want to fight to VMMaker - at least at >> start ;-). >> >> Cheers, >> -- Pavel >> >> > > -- Best regards, Igor Stasenko.

Dec. 2, 2011

[Pharo-project] MethodDictionary rehash crash [WAS]Issue 4914 in pharo: #14196 VM crash on #cleanUpForRelease

by Mariano Martinez Peck

Wierd...maybe Nicolas o Levente can help us? ---------- Forwarded message ---------- From: <pharo(a)googlecode.com> Date: Fri, Dec 2, 2011 at 5:00 PM Subject: Re: [Pharo-bugtracker] Issue 4914 in pharo: #14196 VM crash on #cleanUpForRelease To: pharo-bugtracker(a)lists.gforge.inria.fr Comment #9 on issue 4914 by marcus.d...(a)gmail.com: #14196 VM crash on #cleanUpForRelease http://code.google.com/p/**pharo/issues/detail?id=4914<http://code.google.com/p/pharo/issues/detail?id=4914> But ScriptLoader new cleanUpForRelease crashes the VM with that change and does not crash without. ______________________________**_________________ Pharo-bugtracker mailing list Pharo-bugtracker(a)lists.gforge.**inria.fr<Pharo-bugtracker(a)lists.gforge.inria.fr> http://lists.gforge.inria.fr/**cgi-bin/mailman/listinfo/**pharo-bugtracker<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker> -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

[Pharo-project] [update 1.4] #14242

by Marcus Denker

14242 ----- Issue 1817: [etoy] Should remove project http://code.google.com/p/pharo/issues/detail?id=1817 -- Marcus Denker -- http://marcusdenker.de

Dec. 2, 2011