- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Send a notification

by Sean P. DeNigris

Alexandre Bergel-7 wrote > > We first thought about sending email directly from Pharo, but apparently > it is not easy to send email. I cleaned up Pharo's mail code a little. Issue 5051: [ENH]: Clean up Mail code http://code.google.com/p/pharo/issues/detail?id=5051 Added simpified API, for example: message := MailMessage from: 'sender(a)domain.com' to: { 'recipient(a)domain.com'. 'recipient2(a)domain.com' } about: 'Very Important Subject' asFollows: 'Hi, how are you?'. message sendOn: 'mail.domain.com'. Added some tests to MailMessage -- View this message in context: http://forum.world.st/Send-a-notification-tp3503711p4148595.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 2, 2011

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

by Eliot Miranda

On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck < marianopeck(a)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. You were there for my presentation Mariano :) And you understood the issue then right ? :) Remember the closure compiler *copies* any temporary variables that are not changed after being closed over into a closure's copiedValues, and *moves* any temporary variables that could be changed after being closed over into indirection vectors, and these indirection vectors are copied into the copied values of the closure. But, as I just said, the receiver and method are not copied (to save time at closure creation) since these are in the outerContext already. These are fetched from the outerContext when the closure is activated. That's the trade-off, slower closure creation and larger closures and duplication if a closure refers to its method and receiver directly, faster closure creation, smaller closures, less duplication and very slightly slower activation if closures refer to their receiver and method indirectly. The additional trade-off is this issue; the indirect approach entails more problems for serialization and for implementing compile-time clean closures (since the compiler needs to create an outerContext for the method and nil for the non-existent receiver - clean closures can't refer to self). Is this clear or as clear as mud? > > Thanks! > > > On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> 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 ;) >>> >> >> Arguably there is a bug in my closure implementation, which is that both >> the receiver and the method are fetched from the outerContext. That's not >> a bug which can be fixed without a new VM/image combination and may be >> something I'll look at long-term, but is something we have to live with at >> the moment. This means that you *do* have to serialize the outerContext. >> But the outerContext is used only for the receiver and method. So you >> don't need to full serialize the outerContext. In particular you don't >> need to serialize any of the outerContext's stack contents or its sender. >> This needs special handling, I guess in BlockClosure, to substitute a >> suitably reduced outerContext, but it shouldn't be hard to do. e.g. >> >> BlockClosure methods for: '*Fuel-serialization' >> outerContextForSerialization >> ^MethodContext >> sender: nil >> receiver outerContext receiver >> method: outerContext method >> args: #() >> >> >> BlockClosure methods for: '*Fuel-serialization' >> outerContextForSerialization >> ^MethodContext >> sender: nil >> receiver self receiver >> method: self method >> args: #() >> >> >> >>> Nicolas >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- best, Eliot

Dec. 2, 2011

Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect?

by Eliot Miranda

On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > There is only one possibly correct answer which is raising > BlockCannotReturn, because we're trying to return while we're in the midst > of returning already, so there is no place to return to. That answer is > implemented by the attached change set. > > BTW, the code duplication between ContextPart>>restart > ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate > bothers me greatly. The change set only fixes one of these locations (the > one triggered by your problem statement) but having such critical code > duplicated all over the places can't be good. Any takers? > The first thing is a good set of tests. Do we have some of them? Clearly we don't have them for this case. What's the scope of the tests? The second thing I find related is that I find ContextPart>jump incomprehensible and worrying. Using simulation machinery to advance execution just seems wrong with me and yet this code is used in process termination (via runUntilErrorOrReturnFrom:) and in exception handling (via ContextPart>restart). ContextPart>jump is extremely complex and slow and buggy (I recently ( eem 11/16/2011 10:58) found and fixed a bad bug in runUntilErrorOrReturnFrom: that was causing too much peeling back of the stack in exception delivery when trying to advance a process to a particular point suitable for presenting to the user. If we could simplify this code that would be a relief to me :) The third thing that is related is that if a process is terminated from a different process, then unwinds execute in the context of the process that initiated the termination, not the process being terminated. The fourth thing that is related in my mind is that Cog supports a much faster Mutex which is in use in OpenQwaq and could be ported to Squeak and Pharo. But it needs some work on process termination, to avoid losing a signal when a process is terminated while in a critical section on the mutex. This is related because fixing this requires some work on unwind implementation. I think all of these need addressing, but they shouldn't be conflated. I'm just writing them down here so they don't get forgotten. cheers, Eliot > Cheers, > - Andreas > > > On 12/2/2011 15:18, Tobias Pape wrote: > >> Dear All, >> >> given the following class: >> >> Object subclass: #Foo >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Foo'! >> a >> self b: [^ 1].! ! >> >> b: aBlock >> >> [self c: aBlock] ensure: [^ 2]. >> >> c: aBlock >> >> aBlock value. >> ^ 3 >> >> And you would do >> >> Foo new a >> >> what would you expect? >> >> I am very curious. >> Please, first guess, then execute. >> >> Best >> -Tobias >> >> >> >> >> >> >> > > > > -- best, Eliot

Dec. 2, 2011

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

by Mariano Martinez Peck

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? Thanks! On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> 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 ;) >> > > Arguably there is a bug in my closure implementation, which is that both > the receiver and the method are fetched from the outerContext. That's not > a bug which can be fixed without a new VM/image combination and may be > something I'll look at long-term, but is something we have to live with at > the moment. This means that you *do* have to serialize the outerContext. > But the outerContext is used only for the receiver and method. So you > don't need to full serialize the outerContext. In particular you don't > need to serialize any of the outerContext's stack contents or its sender. > This needs special handling, I guess in BlockClosure, to substitute a > suitably reduced outerContext, but it shouldn't be hard to do. e.g. > > BlockClosure methods for: '*Fuel-serialization' > outerContextForSerialization > ^MethodContext > sender: nil > receiver outerContext receiver > method: outerContext method > args: #() > > > BlockClosure methods for: '*Fuel-serialization' > outerContextForSerialization > ^MethodContext > sender: nil > receiver self receiver > method: self method > args: #() > > > >> Nicolas >> >> > > > -- > best, > Eliot > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2011

[Pharo-project] [TODO 1.3] Issues tagged 1.3

by Marcus Denker

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 ... the interesting thing is that there are 3 issues that have *solutions*, yet nobody looked at them since the last time I sent this email... I wonder how important actually is it to fix bugs? -- Marcus Denker -- http://marcusdenker.de

Dec. 2, 2011

[Pharo-project] [TODO 1.4] Issues tagged 1.4

by Marcus Denker

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 -- Marcus Denker -- http://marcusdenker.de

Dec. 2, 2011

Re: [Pharo-project] Prune stack serialization

by Eliot Miranda

On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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 ;) > Arguably there is a bug in my closure implementation, which is that both the receiver and the method are fetched from the outerContext. That's not a bug which can be fixed without a new VM/image combination and may be something I'll look at long-term, but is something we have to live with at the moment. This means that you *do* have to serialize the outerContext. But the outerContext is used only for the receiver and method. So you don't need to full serialize the outerContext. In particular you don't need to serialize any of the outerContext's stack contents or its sender. This needs special handling, I guess in BlockClosure, to substitute a suitably reduced outerContext, but it shouldn't be hard to do. e.g. BlockClosure methods for: '*Fuel-serialization' outerContextForSerialization ^MethodContext sender: nil receiver outerContext receiver method: outerContext method args: #() BlockClosure methods for: '*Fuel-serialization' outerContextForSerialization ^MethodContext sender: nil receiver self receiver method: self method args: #() > Nicolas > > -- best, Eliot

Dec. 2, 2011

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

by Nicolas Cellier

2011/12/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> 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. > Yes. With user interaction... In a workspace, type this and debug it: Stream basicNew printString. Step over basicNBew. Step into printString. Step into printStringLimitedTo: 50000 Step into streamContents: [:s | self printOn: s] limitedTo: limit Step over 100 min: sizeLimit Step over self new: (100 min: sizeLimit) --> error: the debugger tries to execute (String new: String) I also note that all class methods in stack window left column are miss-printed - like 'Block in class)' new: Nicolas > >> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > >

Dec. 2, 2011

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

by Eliot Miranda

On Fri, Dec 2, 2011 at 10:29 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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. > +1 > > 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 > > > > -- best, Eliot

Dec. 2, 2011

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

by Eliot Miranda

On Fri, Dec 2, 2011 at 6:16 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > We had a look and the problem is that printOn: on Stream is defined to > print the contents of the Stream even though it might > not be initialized yet (e.g. when creating a Stream instance with > #basicNew). > Yes, but the real problem is either the debugger or the the redefinition of subclassResponsibility. When I try Stream basicNew printString in a Squeak image I get a notifier which says: Stream(Object)>>error: Stream(Object)>>subclassResponsibility Stream>>contents Stream>>printContentsOn: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Stream>>printOn: [] in Stream(Object)>>printStringLimitedTo: String class(SequenceableCollection class)>>streamContents:limitedTo: Stream(Object)>>printStringLimitedTo: Stream(Object)>>printString But in Pharo this is crashing. I think you need to fix either the debugger or subclassResponsibility, > The simplest solution is to just not print the contents of Streams in > #printOn: > > http://code.google.com/p/pharo/issues/detail?id=5047 > > Stream should not print its contents in printOn: > > Reason: > > => Debugging leads to change the state of Stream when looking at it > => Network streams load all content > => unitialized Streams has undefined behavior for printing > > Solution: remove #printOn: > > On Fri, Dec 2, 2011 at 9:08 AM, StÃ©phane Ducasse > <stephane.ducasse(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 > > -- best, Eliot

Dec. 2, 2011