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

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

by Mariano Martinez Peck

Thank you very much Eliot and Juan for this nice discussion. I have just commit this new functionality and it seems to work fine. I ended up using Eliot's #abstractBytecodes since the one from Juan didn't work out of the box in Pharo. On Fri, Dec 2, 2011 at 10:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Juan, > > On Fri, Dec 2, 2011 at 11:59 AM, Juan Vuletich <juan(a)jvuletich.org> wrote: > >> Mariano Martinez Peck wrote: >> >>> >>> >>> On Fri, Dec 2, 2011 at 9:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com<mailto: >>> eliot.miranda(a)gmail.**com <eliot.miranda(a)gmail.com>>> wrote: >>> >>> >>> >>> On Fri, Dec 2, 2011 at 12:40 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>**> wrote: >>> >>> >>> >>> On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich >>> <juan(a)jvuletich.org <mailto:juan@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> >>> <mailto:marianopeck@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". >>> >>> >>> IMO, dy default, everything reachable from the closure, including >>> the outerContext chain and their senders. But that's only a >>> default. What makes sense in any given context is up to the >>> application, e.g. see Seaside. One size won't fit all. You >>> should handle the common cases (e.g. clean blocks and everything >>> else) and leave it up to the user to figure out what they need to >>> do in complex situations, making sure you provide them with the >>> hooks they'll need, such as the ability to substitute objects when >>> serializing etc, and perhaps some useful examples. >>> >>> >>> +1 Then we will do the following: we will check whether the closure is >>> clean. If it is, then we serialize just the closure plus its outerContext >>> but only with receiver and method. If it is not clean, then we serialize >>> the whole stack. That's all by default. If then someone needs something >>> different, then to use the hooks :) >>> So the final question is whether what Juan is using in Cuis is up to >>> date. If it is, then I have all I need :) >>> Thank you guys. >>> >> >> I can say that it does indeed work. But I'd be really grateful if Eliot >> took a good look at that code! >> > > There is a much better way, using > InstructionStream>>interpreetNextInstructionFor: which abstracts away from > the bytecode encoding and allows one to simply use messages. e.g. look at > > BlockClosure methods for private > abstractBytecodes > "Answer an OrderedCollection of the abstract bytecodes sent in the > receiver." > | scanner blockCreationMessage end abstractBytecodes | > scanner := InstructionStream new. > "find the creation message to find the extent of the block." > scanner method: self method pc: self method initialPC. > [scanner pc < startpc] whileTrue: > [[scanner interpretNextInstructionFor: nil] > on: MessageNotUnderstood > do: [:ex| blockCreationMessage := ex message]]. > end := blockCreationMessage arguments last + startpc - 1. > "now collect all the bytecode messages in the block." > abstractBytecodes := OrderedCollection new. > scanner method: self method pc: startpc. > [scanner pc < end] whileTrue: > [[scanner interpretNextInstructionFor: nil] > on: MessageNotUnderstood > do: [:ex| abstractBytecodes add: ex message selector]]. > ^abstractBytecodes > > and (SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: > false]) sortBlock abstractBytecodes evaluates to > > an OrderedCollection(#pushTemporaryVariable: #pushTemporaryVariable: > #pushConstant: #send:super:numArgs:) > > So a check for clean blocks would check for a block's abstractBytecodes > not including some particular set of banned messages (which I *think* is > pushReceiver pushReceiverVariable: popIntoReceiverVariable: > storeIntoReceiverVariable: methodReturnConstant: methodReturnReceiver > methodReturnTop). > > e.g. > > isClean > ^(self abstractBytecodes intersection: #(pushReceiver > pushReceiverVariable: popIntoReceiverVariable: storeIntoReceiverVariable: > methodReturnConstant: methodReturnReceiver methodReturnTop)) isEmpty > > >> Cheers, >> Juan Vuletich >> >> >>> >>> >>> 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<http://marianopeck.wordpress.com> >>> >>> >>> >>> >>> >>> >>> >>> -- best, >>> Eliot >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> No virus found in this message. >>> Checked by AVG - www.avg.com <http://www.avg.com> >>> Version: 10.0.1411 / Virus Database: 2102/4052 - Release Date: 12/02/11 >>> >>> >> >> > > > -- > best, > Eliot > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 3, 2011

Re: [Pharo-project] A commercial question

by Francois Stephany

> Thanks for the response Francois! Yep, but do not my answer as the only voice ;) It is just that the people I work with are usually really picky about that. > I imagined approximately the same, but should try Mars (I don't know not > much about it). > Or, try Xcode4 :( If Mars is not stable/productive enough and you are familiar with Ruby you can probably have a look at MacRuby (http://www.macruby.org/) and a free online book (http://ofps.oreilly.com/titles/9781449380373/) Good luck !

Dec. 3, 2011

Re: [Pharo-project] A commercial question

by GermÃ¡n Arduino

Thanks for the response Francois! I imagined approximately the same, but should try Mars (I don't know not much about it). Or, try Xcode4 :( Thanks! 2011/12/2 Francois Stephany <tulipe.moutarde(a)gmail.com> > Hi German, > > > The average Apple user could accept >> the look and feel of a morphic pharo application? (Very different than >> the osx l&f). >> > > Ouch, I gess they dont. Apple users usually expect a GUI that follows both > look and feel of native applications. For some, even Firefox is not 'MacOS' > enough. > > I'm maybe biased on this topic but I would not develop a general purpose > software with Pharo (at least a desktop app). > > If you have niche software, the story is probably different. > > Sorry to sound so pessimist! > > Francois > > > (I would love to be proven wrong!) > > -- > http://tulipemoutarde.be > BE: +32 (0)65 709 131 > CA: +1 778 558 3225 > > -- ============================================ 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] A commercial question

by Francois Stephany

Hi German, > The average Apple user could accept > the look and feel of a morphic pharo application? (Very different than > the osx l&f). Ouch, I gess they dont. Apple users usually expect a GUI that follows both look and feel of native applications. For some, even Firefox is not 'MacOS' enough. I'm maybe biased on this topic but I would not develop a general purpose software with Pharo (at least a desktop app). If you have niche software, the story is probably different. Sorry to sound so pessimist! Francois (I would love to be proven wrong!) -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Dec. 2, 2011

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

by Schwab,Wilhelm K

Sven, I was taught to never trap Exception - Error is ok to trap, AFAIK. Beyond that, where does this code live? How often/when does it execute? Exception handlers are expensive to set up and even more expensive when used. This is not really an exceptional condition; it is a predictable failure and one that can be handled locally rather than needing to be left to the application layer. IMHO, it is not a good place to use an exception handler. Hanging in place of opening a walkback is bad. I suggest fixing that first (the printing defect seems to be a nice way top reproduce the hang that should not happen), and THEN fix the #printOn: so the walkback does not appear. BTW, so much for my inability to reproduce this. Print-it in my 1.4 image did not go well - had to kill the vm, so it happens on Linux too. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, December 02, 2011 6:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass 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

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

by StÃ©phane Ducasse

We will have to track when this error was introduced may be this is the runtimeError fix that we pushed. We should check on images to spot this regression. Now printing the contents of a stream by default looks to me a bad idea. May be when the stream is positionable it makes sense but why would I force to read the complete contents of a stream when I open an inspector on it. Stef On Dec 2, 2011, at 7:30 PM, Eliot Miranda wrote: > > > 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

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

by StÃ©phane Ducasse

Thanks. >>>>> 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] 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