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

Re: [Pharo-project] Issue 3603 in pharo: O/ECompletion failure in Trait methods

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3-DevImage Comment #1 on issue 3603 by marcus.d...(a)gmail.com: O/ECompletion failure in Trait methods http://code.google.com/p/pharo/issues/detail?id=3603 (No comment was entered for this change.)

Feb. 2, 2011

Re: [Pharo-project] Issue 3643 in pharo: TextMorph >> enableTextChange is missing

by pharo＠googlecode.com

Comment #3 on issue 3643 by aplan...(a)gmail.com: TextMorph >> enableTextChange is missing http://code.google.com/p/pharo/issues/detail?id=3643 ok, will do a 1.2 specific slice

Feb. 2, 2011

Re: [Pharo-project] Issue 3643 in pharo: TextMorph >> enableTextChange is missing

by pharo＠googlecode.com

Comment #2 on issue 3643 by marcus.d...(a)gmail.com: TextMorph >> enableTextChange is missing http://code.google.com/p/pharo/issues/detail?id=3643 When merging in 1.2, this wants to change a lot of things that I think have nothing to do with the fix. Comand deleted, change to Worldstate runStepMethodsIn:...

Feb. 2, 2011

Re: [Pharo-project] Issue 3469 in pharo: [Failing Test] ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy

by pharo＠googlecode.com

Comment #9 on issue 3469 by marcus.d...(a)gmail.com: [Failing Test] ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy http://code.google.com/p/pharo/issues/detail?id=3469 See Issue 3617 for another fix

Feb. 2, 2011

Re: [Pharo-project] Issue 3617 in pharo: Hudson 1.2dev : ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3469 Comment #2 on issue 3617 by marcus.d...(a)gmail.com: Hudson 1.2dev : ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy http://code.google.com/p/pharo/issues/detail?id=3617 (No comment was entered for this change.)

Feb. 2, 2011

Re: [Pharo-project] Issue 3469 in pharo: [Failing Test] ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy

by pharo＠googlecode.com

Comment #8 on issue 3469 by marcus.d...(a)gmail.com: [Failing Test] ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy http://code.google.com/p/pharo/issues/detail?id=3469 Issue 3617 has been merged into this issue.

Feb. 2, 2011

[Pharo-project] 1.2: class var #Instance not allowed

by Torsten Bergmann

>When you are already in debugger, you can nicelly 'Mail out bug >report', but how to 'File out bug report' to attach it on issue tracker? I think this is from times where issues were posted to the Squeak list ;) (have to admit it is currently the only place I know where one gets the stack trace directly as text) Anyway: posting to the lists has changed with Mantis on the Squeak side and the Google issue tracker on the Pharo side. You should open another issue and mark it as "enhancement" so this is taking care of too. Best would be to provide the changeset or a "slice" with the fix already ;) Watch the video on http://www.pharocasts.com/2010/03/how-to-contribute-to-pharo.html to see how to do all this. The overall process may look complicated first but once you are used to it it is simple and it is easy to reproduce why something changed and how. It also makes life for integrators easier. And step by step Pharo gets cleaner... Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

Feb. 2, 2011

Re: [Pharo-project] react on low space

by Schwab,Wilhelm K

Max, I'm on your side, really :) Silent failures are a big problem and should not be allowed to persist. What I don't know is whether the remedy for low space is simply to log it and then proceed to crash, or if a handler can do something useful. The handler probably would need to be registered; otherwise, the low space condition might show up in a thread other than the one hogging all of the memory, I think. If a handler had to bail me out, I would probably want that logged, but if it is my handler, I should be able to do the logging. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Max Leske [maxleske(a)gmail.com] Sent: Wednesday, February 02, 2011 3:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] react on low space Bill, I agree that it is important to at least know that there has been a low space condition. But then again, if there is a low space watcher anyway, shouldn't there be a way to register as a listener or something? Igor, I haven't run your code yet but it looks exactly like what I was looking for! Thanks. Max On 01.02.2011, at 14:13, Igor Stasenko wrote: > On 1 February 2011 14:11, Igor Stasenko <siguctua(a)gmail.com> wrote: >> I think you can catch the OutOfMemory exception: >> > Oops. example was a bit wrong. something like that: > > [ | y x | y := x := Array new: 1000. > 1000000 timesRepeat: [ x at: 1 put: (Array new: 10000). x := x at: 1 ] > ] on: OutOfMemory do: [:ex | > .... > ] > > >> >> On 1 February 2011 12:00, Max Leske <maxleske(a)gmail.com> wrote: >>> I'm bumping this message. I think it's an important question and could help >>> other developers who might have the same problem one day. The low space >>> watcher is cool but if you don't get the chance to actually look at the >>> stack it's pretty useless. >>> Max >>> On 30.01.2011, at 13:10, Max Leske wrote: >>> >>> Hi guys >>> Is there an easy way to react on low space? Something like: >>> >>> SmalltalkImage isSpaceLow >>> ifTrue: [ <suspend my process> ] >>> >>> The reason I'm asking is that I have a background process running that >>> causes a low space condition but I never get around to opening the debugger >>> and the image crashes on me. So for debugging purposes I'd like to >>> periodically check the space that is left or alternatively be notified if >>> low space is signalled. >>> Any ideas? >>> Thanks, >>> Max >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 2, 2011

Re: [Pharo-project] For 1.2: default browser size bigger

by StÃ©phane Ducasse

good idea. I went to the doc and he told me "glasses in 2 years" :) > Hi guys, > > Please please, increase default size of System browser to some > reasonable size, in forthcoming 1.2 already. > > Is this manual resizing annoying only to me? I doubt. Or better, what is > a rationale behind so small browser windows? > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Feb. 2, 2011

Re: [Pharo-project] 1.2: class var #Instance not allowed

by Janko MivÅ¡ek

Hi Torsten, done! It takes some time to get used of that issue trackers... :) BTW: When you are already in debugger, you can nicelly 'Mail out bug report', but how to 'File out bug report' to attach it on issue tracker? Janko On 02. 02. 2011 12:49, Torsten Bergmann wrote: > Hi Janko, > > If you think it is a bug please PLEASE OPEN AN ISSUE > on http://issues.pharo-project.org and mark it > as 1.2 in the labels, SO IT CAN BE TRACKED. > > And append the stack trace there not directly to the > list. (Messages from the bug tracker will be > sent to the mailinglist too, so we will notice). > > Otherwise it may get lost. > > Thx > T. > > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 2, 2011