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

[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

Re: [Pharo-project] TestNewParagraphFix

by StÃ©phane Ducasse

No idea. Now tests are not curved in stone and we can remove them. On Dec 2, 2011, at 3:20 PM, Sean P. DeNigris wrote: > NewParagraph is deprecated in 1.4. TestNewParagraphFix doesn't actually > mention NewParagraph directly. The class comment says "This class tests the > same things as its superclass, but for NewParagraph which is used in the > Morphic environment." but its superclass is TestCase. > > Is TestNewParagraphFix still relevant? What was the original motivation i.e. > why is it called XxxFix? > > Sean > > -- > View this message in context: http://forum.world.st/TestNewParagraphFix-tp4147219p4147219.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 3, 2011

Re: [Pharo-project] A commercial question

by Sean P. DeNigris

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 Schwab,Wilhelm K

This is the "other reason" I sometimes go against my better judgment by advocating in favor of native widgets. The first reason is that it would force us to use events and impose related discipline (input focus, etc.) on Pharo's user interface. The applicable reason here is that Pharo would become part of the host OS far more readily than it can (reasonably be expected to) now. Pinesoft brought us a long way with Polymorph, but emulating happens by reverse engineering and invariably will end at "good enough" (which is pretty good right now) rather than using the same code as the OS. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Francois Stephany [tulipe.moutarde(a)gmail.com] Sent: Friday, December 02, 2011 6:53 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] A commercial question 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. 3, 2011