December 2011 - Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

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(a)gmail.com>: >> 2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> 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 >>> >> >> 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(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 >>>> > <Fix-Error-description.st>

Dec. 2, 2011

[Pharo-project] A commercial question

by GermÃ¡n Arduino

Hi: I'm only starting in the Apple software market and would like to ask the viability of sell desktop software developed with Pharo (I mean commercial sort of trialware software). I know my question is very general, but is focused mainly in the look and feel (I'm pretty sure that can develop any functionality I want) but not sure about the look and feel. The average Apple user could accept the look and feel of a morphic pharo application? (Very different than the osx l&f). Other options? Experiences, suggestions, are more than welcome. I know that the Apple store don't accept Pharo apps, but still if they have sales possibilities, I could try by my own. What do you think? Thanks. -- ============================================ GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com Promoter http://www.arsol.biz ============================================

Dec. 2, 2011

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

by Nicolas Cellier

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(a)gmail.com>: > 2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 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 >> > > 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(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

[Pharo-project] GZipWriteStream crashing my VM when serializing ?

by Mariano Martinez Peck

Hi guys. We are doing some experiments with Fuel and GZip streams... Now I have a beatiful test like this: testMethodContextThisContext | materializedContext context | context := thisContext copy. materializedContext := self resultOfSerializeAndMaterialize: context. and it crashes like crazy. From the VM crash stack, I can see: Smalltalk stack dump: 0xbff66ba4 M GZipWriteStream(DeflateStream)>deflateBlock 447551436: a(n) GZipWriteStream 0xbff66bc8 M GZipWriteStream(DeflateStream)>nextPutAll: 447551436: a(n) GZipWriteStream 0xbff66be4 M GZipWriteStream(DeflateStream)>next:putAll:startingAt: 447551436: a(n) GZipWriteStream 0xbff66c08 M FLBufferedWriteStream>flushBuffer 448048664: a(n) FLBufferedWriteStream 0xbff66c20 M FLBufferedWriteStream>nextBytesPutAll: 448048664: a(n) FLBufferedWriteStream 0xbff66c40 M FLBufferedWriteStream>nextStringPut: 448048664: a(n) FLBufferedWriteStream 0xbff66c5c M FLByteStringCluster>serialize:on: 448054196: a(n) FLByteStringCluster 0xbff66c7c M FLByteStringCluster(FLPrimitiveCluster)>serializeInstance:with: 448054196: a(n) FLByteStringCluster 0xbff66ca0 M [] in FLByteStringCluster(FLIteratingCluster)>serializeInstances: 448054196: a(n) FLByteStringCluster 0xbff66cc8 M IdentitySet(Set)>do: 451711680: a(n) IdentitySet 0xbff66ce4 M FLByteStringCluster(FLIteratingCluster)>serializeInstances: 448054196: a(n) FLByteStringCluster 0xbff66d00 M FLByteStringCluster(FLIteratingCluster)>serializeInstancesStepWith: 448054196: a(n) FLByteStringCluster 0xbff66d1c M FLSerialization>clusterInstancesStepOf: 448053428: a(n) FLSerialization 0xbff66d38 M [] in FLSerialization>instancesStep 448053428: a(n) FLSerialization 0xbff66d58 M OrderedCollection>do: 449989736: a(n) OrderedCollection 0xbff66d74 M FLSerialization>instancesStep 448053428: a(n) FLSerialization 0xbff66d8c M FLSerialization>run 448053428: a(n) FLSerialization 0xbff66db0 I [] in FLSerializer>defaultSerialization 447550464: a(n) FLSerializer 0xbff66dd8 M [] in FLSerializer>serialize:on: 447550464: a(n) FLSerializer 0xbff66df8 M BlockClosure>ensure: 448052884: a(n) BlockClosure 0xbff66e18 M FLSerializer>serialize:on: 447550464: a(n) FLSerializer 0xbff66e3c M [] in FLMethodContextSerializationTest(FLSerializationTest)>serialize: 447235380: a(n) FLMethodContextSerializationTest 0xbff66e60 M [] in GZipWriteStream class(PositionableStream class)>on:do: 419845144: a(n) GZipWriteStream class 0xbff66e80 M BlockClosure>ensure: 448048616: a(n) BlockClosure 0xbff66ea0 M GZipWriteStream class(PositionableStream class)>on:do: 419845144: a(n) GZipWriteStream class 0xbff66ec4 M [] in FLGZipStrategy>writeStreamDo: 447550896: a(n) FLGZipStrategy 0xbff66ee0 M FLByteArrayStreamStrategy>writeStreamDo: 447550884: a(n) FLByteArrayStreamStrategy 0xbff66efc M FLGZipStrategy>writeStreamDo: 447550896: a(n) FLGZipStrategy 0xbff66f18 M FLMethodContextSerializationTest(FLSerializationTest)>serialize: 447235380: a(n) FLMethodContextSerializationTest 0xbff66f34 M FLMethodContextSerializationTest(FLSerializationTest)>resultOfSerializeAndMaterialize: 447235380: a(n) FLMethodContextSerializationTest 0xbff66f58 M FLMethodContextSerializationTest>testMethodContextThisContext 447235380: a(n) FLMethodContextSerializationTest any idea of where I should start to look at? Thanks -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

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

by Nicolas Cellier

2011/12/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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 > 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(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] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

> WRT clean closures, check what I did in Cuis to serialize >> SortedCollections. See implementors and senders of #isClean. >> >> >> Nice. Thanks Juan. I was checking your code, and that's exactly why I >> asked Eliot. In your method you say: >> >> isClean >> "A clean closure is one that doesn't really need the home context >> because: >> - It doesn't send messages to self or super >> - It doesn't access any instance variable >> - It doesn't access any outer temp >> - It doesn't do ^ return" >> ..... >> >> So... my question is, WHAT do I need to serialize if I want to be able to >> serialize also "non clean". I mean, for each item on that list, what do I >> need apart from the closure instance and the receiver and method from the >> outerContext ? the whole stack of contexts ? >> >> > I think it is needed to know why you need to serialize a non-clean > closure. If it is just to be able to evaluate it, well, some people may just need that, but there are cases where I need it completely. I mean, I need to serialize the whole possible graph of objects. This is an example for what I am doing in my PhD. We are also experiment with remote messages and things like that and sometimes we pass a whole stack. In that case I thin it also make sense. But again, these are particular cases. I agree that most of the times the closure will be "clean" > maybe you don't need the stack at all. My trick could be augmented by > serializing any referenced objects, but not the stack. > > Yes, maybe I was not clear. When I refer to "stack" I refer all instances of ContextPart (well, subclasses) and all the objects reachable from there. > Cheers, > Juan Vuletich > > > >> Thanks a lot in advance! >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

The following method looks complicated for me. Do you know if it is still valid in latest Cog ? Thanks :) eliotsClosureMeasurementsOn: m over: aFiveArgBlock " See senders. Or try something like: Smalltalk eliotsClosureMeasurementsOn: FileList >> #defaultContents over: [ :closuresCount :hasCopiedValuesForClosure :hasIndirectTemps :anyClosureHasCopied :anyClosureDoesUAR :anyClosureUsesSelf | (Array with: closuresCount with: hasCopiedValuesForClosure with: hasIndirectTemps with: anyClosureHasCopied with: anyClosureDoesUAR with: anyClosureUsesSelf)] From http://www.mirandabanda.org/cogblog/2008/11/14/mechanised-modifications-and… by Eliot Miranda " | s nextScanStart thisClosureHasCopied closuresCount hasIndirectTemps blkPc blkSz anyClosureHasCopied anyClosureDoesUAR anyClosureUsesSelf analyzedClosures | closuresCount := 0. hasIndirectTemps := false. anyClosureHasCopied := anyClosureDoesUAR := anyClosureUsesSelf := false. s := InstructionStream on: m. s scanFor: [ :b | b = 16r8F "16r8F = 143 closure creation" ifTrue: [ closuresCount := closuresCount + 1]. (b = 16r8A "16r8A = 138indirect temp vector creation" and: [ s followingByte <= 127]) ifTrue: [ hasIndirectTemps := true]. false]. nextScanStart := m initialPC. analyzedClosures := 0. [ analyzedClosures < closuresCount ] whileTrue: [ s pc: nextScanStart; scanFor: [ :b | b = 16r8F ]. "16r8F = 143 Search for first closure" analyzedClosures := analyzedClosures + 1. thisClosureHasCopied := s followingByte >= 16r10. anyClosureHasCopied := anyClosureHasCopied | thisClosureHasCopied. blkSz := s interpretNextInstructionFor: BlockStartLocator new. "Findout size of first closure" blkPc := s pc. s scanFor: [ :b | s pc >= (blkPc + blkSz) ifTrue: [ nextScanStart := s pc. true] ifFalse: [ b = 16r8F ifTrue: [ thisClosureHasCopied := s followingByte >= 16r10. anyClosureHasCopied := anyClosureHasCopied | thisClosureHasCopied. analyzedClosures := analyzedClosures + 1 ]. anyClosureDoesUAR := anyClosureDoesUAR or: [s willReturn and: [s willBlockReturn not]]. anyClosureUsesSelf := anyClosureUsesSelf or: [b = 16r70 "pushSelf" or: [b < 16r10 "pushInstVar" or: [(b = 16r80 and: [s followingByte <= 16r3F]) "pushInstVar" or: [(b between: 16r60 and: 16r60 + 7) "storePopInstVar" or: [(b = 16r82 and: [s followingByte <= 63]) "storePopInstVar" or: [(b = 16r81 and: [s followingByte <= 63]) "storeInstVar" or: [b = 16r84 and: [s followingByte = 160]]]]]]]]. false]]]. ^aFiveArgBlock valueWithArguments: (Array with: closuresCount with: hasIndirectTemps with: anyClosureHasCopied with: anyClosureDoesUAR with: anyClosureUsesSelf) On Fri, Dec 2, 2011 at 9:40 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > >> Eliot Miranda wrote: >> >>> >>> >>> On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>**> wrote: >>> >>> Thanks both. I am right to assume that if the block refers to temp >>> vars, parameters, or whatever in another scope, then such solution >>> won't work. I mean, if I have this example for example: >>> >>> | bytes result blah | >>> blah := 42. >>> bytes := FLSerializer serializeToByteArray: (SortedCollection >>> sortBlock: [:a :b | (a + blah) > b ]). >>> >>> Then the 'blah' is in a different context. So the mentioned >>> solution works for "clean" closures, which are "self contained". >>> In the other cases (such as this example), we should serialize the >>> whole stack. Is this correct? >>> >>> >>> No. The closure implementation arranges that any and all temporary >>> variables accessed by the closure are directly accessible from the closure >>> without accessing the outer contexts. >>> ... >>> >> >> WRT clean closures, check what I did in Cuis to serialize >> SortedCollections. See implementors and senders of #isClean. >> >> > Nice. Thanks Juan. I was checking your code, and that's exactly why I > asked Eliot. In your method you say: > > isClean > "A clean closure is one that doesn't really need the home context > because: > - It doesn't send messages to self or super > - It doesn't access any instance variable > - It doesn't access any outer temp > - It doesn't do ^ return" > ..... > > So... my question is, WHAT do I need to serialize if I want to be able to > serialize also "non clean". I mean, for each item on that list, what do I > need apart from the closure instance and the receiver and method from the > outerContext ? the whole stack of contexts ? > > > Thanks a lot in advance! > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Eliot Miranda wrote: > >> >> >> On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>**> wrote: >> >> Thanks both. I am right to assume that if the block refers to temp >> vars, parameters, or whatever in another scope, then such solution >> won't work. I mean, if I have this example for example: >> >> | bytes result blah | >> blah := 42. >> bytes := FLSerializer serializeToByteArray: (SortedCollection >> sortBlock: [:a :b | (a + blah) > b ]). >> >> Then the 'blah' is in a different context. So the mentioned >> solution works for "clean" closures, which are "self contained". >> In the other cases (such as this example), we should serialize the >> whole stack. Is this correct? >> >> >> No. The closure implementation arranges that any and all temporary >> variables accessed by the closure are directly accessible from the closure >> without accessing the outer contexts. >> ... >> > > WRT clean closures, check what I did in Cuis to serialize > SortedCollections. See implementors and senders of #isClean. > > Nice. Thanks Juan. I was checking your code, and that's exactly why I asked Eliot. In your method you say: isClean "A clean closure is one that doesn't really need the home context because: - It doesn't send messages to self or super - It doesn't access any instance variable - It doesn't access any outer temp - It doesn't do ^ return" ..... So... my question is, WHAT do I need to serialize if I want to be able to serialize also "non clean". I mean, for each item on that list, what do I need apart from the closure instance and the receiver and method from the outerContext ? the whole stack of contexts ? Thanks a lot in advance! -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] VM page in pharo book is outdated

by Mariano Martinez Peck

On Tue, Nov 29, 2011 at 10:51 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > > Hi Esteban. I DID notice that the book was "outdated". The thing is that > we have to decide, as the Pharo community, if it is outdated or just > another alternative. > > Eliot's way of building the VM is different than "our". We use > ConfigurationOfCog + CMakeVMMaker + Git. Eliot uses another way. > > So what is documented in the pharo book is kind of Eliot way. > > We have to decide as a community what do we expect when building cog. Is > ConfigurationOfCog + CMakeVMMaker + Git the OFFICIAL Pharo way of building > the VM? If we do agree on this, then yes, we should update the book. > Something different is if ConfigurationOfCog + CMakeVMMaker + Git is just > ANOTHER way of bulding the VM, in which case I don't see as incorrect what > is in the pharo book. > > > Guess my answer :) > Why would we throw away the three months igor spent making sure that idiot > like me can compile the VM without problems. > I know your answer. I would recommend that way also, but (answering to Esteban), I don't have such time. My effort is in writing as much as I can (for example, in the blog). I cannot do more right now, since I am getting inside the last year of my PhD. Apart from that, Stef took some of my posts and transform them into PBE2 chapters.... we don't have manpower to have to books talking about the same. So I would rather go in the effort of continuing such chapters. Is there someone willing to help? > And more important Git (which I hate for my article) is socially the way > to go for the VM = message to cool C hackers > yes you are welcome to clean and improve our VM (it deserves it and once > of these days we will have to do somethingâ¦ because > we are losing against simpler, nicer VM like lua (C-embedding, â¦.). > JB is fighting to get the stack vm compiling on a funky micro pro and the > VM dusty code is getting in our way. > > Stef > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

Re: [Pharo-project] latest VM sources

by Mariano Martinez Peck

On Fri, Dec 2, 2011 at 6:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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 :) > no, it is not. > > > - 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. > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011