- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello enhancing

by Mariano Martinez Peck

On Sat, Dec 3, 2011 at 12:23 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks tobias > This is cool to have that! > With your experiment are loading MC definitions using fuel? > yes, loading and writing. Basically, for writing, for example, it is to change #writeSnapshot: or #serializeInBinary: to use Fuel instead of DataStream. For loading, #loadDefinitions Cheers > > 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> > > > -- Mariano http://marianopeck.wordpress.com

Dec. 3, 2011

Re: [Pharo-project] A commercial question

by Larry White

Esteban, What is Mars? On Sat, Dec 3, 2011 at 8:07 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi GermÃ¡n, > > As others said, mac users will not be willing to accept pharo look&feel > except for rare situations (thats one of the reasons I started Mars in > first instance...). Also, Mars is still far for being really usable > (sadly), so I don't think you have a real native option right now. > I'm commited to finish Mars "some time"... but time is being a big > bottleneck this year. > I hope in the future I can, at least, advance the project enough to make > other people contributions possible, so Carla, German, and any other can > help me to finish :) > > cheers, > Esteban > > > El 02/12/2011, a las 11:04p.m., Sean P. DeNigris escribiÃ³: > > > > > fstephany wrote > >> > >> you can probably have a look at MacRuby > >> > > > > MacRuby is pretty cool, and if you go this route, maybe you can have a > very > > thin MacRuby GUI layer on top of Pharo (I would start with REST as the > IPC, > > but you could go with sockets if it wasn't fast enough). That would be my > > first experiment if I wanted to make a Mac desktop app while waiting for > > Mars. > > > > > > HTH, > > Sean > > > > > > -- > > View this message in context: > http://forum.world.st/A-commercial-question-tp4150440p4151542.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

Dec. 3, 2011

Re: [Pharo-project] A commercial question

by Esteban Lorenzano

Hi GermÃ¡n, As others said, mac users will not be willing to accept pharo look&feel except for rare situations (thats one of the reasons I started Mars in first instance...). Also, Mars is still far for being really usable (sadly), so I don't think you have a real native option right now. I'm commited to finish Mars "some time"... but time is being a big bottleneck this year. I hope in the future I can, at least, advance the project enough to make other people contributions possible, so Carla, German, and any other can help me to finish :) cheers, Esteban El 02/12/2011, a las 11:04p.m., Sean P. DeNigris escribiÃ³: > > fstephany wrote >> >> you can probably have a look at MacRuby >> > > MacRuby is pretty cool, and if you go this route, maybe you can have a very > thin MacRuby GUI layer on top of Pharo (I would start with REST as the IPC, > but you could go with sockets if it wasn't fast enough). That would be my > first experiment if I wanted to make a Mac desktop app while waiting for > Mars. > > > HTH, > Sean > > > -- > View this message in context: http://forum.world.st/A-commercial-question-tp4150440p4151542.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 3, 2011

[Pharo-project] [update 1.4] #14243

by Marcus Denker

14243 ----- Issue 5052: #subclassResponsibility should not print the object but the class name http://code.google.com/p/pharo/issues/detail?id=5052 Issue 5050: restart UIProcess in next postscript http://code.google.com/p/pharo/issues/detail?id=5050 Issue 5049: Remove TestNewParagraphFix http://code.google.com/p/pharo/issues/detail?id=5049 Issue 5051: [ENH]: Clean up Mail code http://code.google.com/p/pharo/issues/detail?id=5051 -- Marcus Denker -- http://marcusdenker.de

Dec. 3, 2011

[Pharo-project] [COTDC] 89 - NullStream

by sean＠clipperadams.com

Continuing in Collections... Today: NullStream Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 3, 2011

Re: [Pharo-project] GUI Testing Library

by Tudor Girba

Hi Sean, I just wrote the first test case for Glamour using the BDDExtensions. This was for a bug that that was present in Glamour since several months, but I just did not know how to test. With the new facilities, it got as simple as: testExplicitAcceptDoesNotAffectTextPort ... textMorph := self find: GLMPluggableTextMorph in: window. textMorph simulateClick. self simulateKeyStrokes: '4'. self assert: (browser panes first port: #text) value = '1234'. self simulateKeyStroke: $s command. self simulateKeyStrokes: '56'. self assert: (browser panes first port: #text) value = '123456' It's just cool. Thanks, Doru On 23 Nov 2011, at 16:17, Tudor Girba wrote: > Wow, this looks brilliant! > > I will definitely give it a try in the following days. > > Doru > > On Wed, Nov 23, 2011 at 4:10 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tudor Girba-2 wrote >>> >>> Could you provide more information? Or maybe an example? >>> >> Sure. Thanks for the push to write tests :) >> >> I just uploaded a new version with some simple tests. Here is a snippet: >> testSimulateCmdKeystroke >> >> | ws | >> ws := Workspace open. >> self simulateKeyStrokes: 'var := 3.'. >> >> self simulateKeyStroke: $s command. >> >> self assert: ws hasUnacceptedEdits = false. >> >> I'll be adding functionality as I go because I'm using it to test my own >> GUIs, but let me know if there's anything specific that you'd really love to >> see here... >> >> Sean >> >> p.s. only in a live, open, dynamic system like Smalltalk could I do this so >> easily. I've read books devoted to this topic, but I coded this up in a few >> minutes. >> >> -- >> View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4099975.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > > -- > www.tudorgirba.com > "Every thing has its own flow" -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

Dec. 3, 2011

[Pharo-project] Consortium memberships brainstorming and ideas

by StÃ©phane Ducasse

HI We would like to get your point of view about the following (we discussed with INRIA lawyer and others. Goal: Remember we want to be able to pay an engineer (cost 55K). Constraints: We do not want a special license for people participating to the consortium and the others. It means that members may not have immediate advantages like 10% reduction :). But it also means that the system is clean, simple, â¦. Proposals: Individual Member: - Free membership Institutional Member: (like Lab, Universityâ¦.) - 1000 Euros Company - First level support: 2000-3000 Euros - Extended Support: 5000-6000 Euros Then finally we want to have a donation for >500 Euros Now with these numbers: we can do it. It may be tight but this would be a huge success! we need 20 first level support 2000 Euros * 20 = 40000 two extended 5000 Euros * 2 = 12000 5 institutionals 5* 1000 = 5000 Gift: 500 * 10 = 5000 So let us know what do you think? Stef

Dec. 3, 2011

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

by StÃ©phane Ducasse

>> > > 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. Yes if you saw my mail about what features to be fixed when esteban arrives (or before) the debugger is there. Now I do not have the time nor the knowledge to do it. We will clean and simplify this parts slowly too so that idiots like me can fix that. Stef > 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. 3, 2011

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

by StÃ©phane Ducasse

On Dec 2, 2011, at 10:07 PM, Nicolas Cellier wrote: > 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. Thanks > > 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. I agree now the problem is that it is not clear who is "responsible" and so far the change in context I see are the changes of eliot in runUntilError. So I will take a set of image and try one by oneâ¦. Stef > > 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. 3, 2011

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

by Sven Van Caekenberghe

Bill, On 03 Dec 2011, at 00:36, Schwab,Wilhelm K wrote: > 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. I totally agree on letting all exception bubble up instead of silently swallow them. However, this is a special case: the infrastructure (debugger, exception system) handling the exception is failing while doing its job (agreed: because of somebody else not doing their own job, but that happens), so the infrastructure should protect itself. Have a look at Inspector>>#selectionPrintString What I suggest would be the same. [ object printString ] on: Exception do: [ ' unprintable object of class ', object class ] It does not swallow the exception silently. Maybe the text in Inspector>>#printStringErrorText is better. Sven

Dec. 3, 2011