- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SubscriptOutOfBounds while Debugging

by StÃ©phane Ducasse

On Dec 2, 2011, at 6:21 PM, Sean P. DeNigris wrote: > 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? Yes this is fixed in later updates (at least the slow opening of lists). > > 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 StÃ©phane Ducasse

We should enhance the recover last changes to be able to pick a different change file too. Stef On Dec 2, 2011, at 3:45 PM, Sean P. DeNigris 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. >

Dec. 2, 2011

Re: [Pharo-project] Monticello enhancing

by StÃ©phane Ducasse

Thanks tobias This is cool to have that! With your experiment are loading MC definitions using fuel? Stef On Dec 2, 2011, at 4:54 PM, Tobias Pape wrote: > Dear all, > > afte Fuel being available for both Squeak and Pharo, > I experimented a little bit. > > So, I put a new snapshot.fuel beside the snapshot.bin in > the mcz zips (same for patch.* in mcd). > > But to make it easier in the future to experiment with things, > I included a small facility to extend serializers/materializers > or similar things more easily. How is it done? > > Example: new serializer in MCZ files: > After my patch, include > > MCMczWriter class>>serializerMine > > ^ [:writer :snapshot | writer writeSnapshotAsMyFormat: snapshot] > > and > > MCMczWriter>>writeSnapshotAsMyFormat: snapshot > > self addString: (self doSomeConversion: aSnapshot) at: 'snapshot.myformat'. > > as Extension methods in MCMczWriter, and execute > > MCMczWriter populateSerializers. > > Now, a new file member is added to every new mcz file. > > As an example, I have done such thing for Fuel. > Don't worry, it just uses the default behavior if > Fuel is not present in either the image or the mcz-file. > > Best, > -Tobias > > PS: for Squeak, see Inbox Monticello-topa.491, > And I also have an MCD attached that should help using the code elsewhere. > > > > <Monticello-topa.491.mcz><Monticello-topa.491(cmm.489).mcd><FuelMonticello-topa.1.mcz>

Dec. 2, 2011

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