- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Protecting against stack overflow ?

by Chris Muller

>> I don't understand how setting a fixed-size stack could ever be >> useful. No one would risk blowing up a production app only because >> they guessed wrong about the stackDepthLimit, so for production it >> would always be set to 0. > > I kind of disagree: any system has limits, and most server software is set up to enforce limits earlier (maximum connections, file descriptors per process, â¦) and deal as gracefully as possible with them, to protect itself from external abuse or internal errors. Yes this might involve some guessing, so what. You can't accurately guess an arbitrary stack limit and still have it be effective for what you want it to do (application stability). The limit will be exceeded at 3am and grumpy on-call support will increase it so that server will run out of memory first anyway. Server software needs to enforce its memory limit anyway, so that may as well be also the solution for a runaway stack. One solution for two problems. > I would rather be able to deal with an infinite recursion and return an internal server error, than have the whole server crash. If the app registers with LowSpaceSemaphore and implements #freeSomeSpace then the whole server wouldn't crash.

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by adrians

Marcus, I guess you answered my question regarding priority - i.e. it's not right at the top. For myself, if I used one tool in everything I did, and it was broken, fixing it would have to be close to the number one thing to address, otherwise every job would take longer than it has to. This, unfortunately, seems to happen often in any domain as the experts are good enough not to be slowed down significantly even with problem tools. This seems to be shortsighted since the complaint is that there is not enough time for everything that needs fixing, but probably a good number of things that need looking at could be corrected by less expert people if only the tools were more solid. What can you do when you live in a shoe? Wait... -- Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Marcus Denker

On Dec 11, 2012, at 5:10 PM, adrians <nmanole(a)gmail.com> wrote: > Hi Marcus, > > I figured it must be the complexity of fixing the debugger that's keeping it > in the broken state that it is for this long. Mainly I wanted to get a sense > of how important is fixing this relative to the other things that need > fixing. It would seem to me that fixing the tool that you use to fix things > in general would be right up there, but maybe, possibly because the people > capable of fixing this aren't significantly handicapped by the issues, this > is not as much a priority as it could be. > A lot of things are important, yet the day has just 24 hours. > Would you know if there is any chance some of these problems will be fixed > for 2.0? > I they are fixed they are fixed, if not then not. :-) Marcus

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Frank Shearar

On 11 December 2012 15:37, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: > Just out of curiosity.. How does the cutting edge of LISP compare to > what we have in Pharo at the moment? I've read somewhere that > smalltalk has the best refactoring/debugging tools. Would you agree > with that? Are there object centric lisp debuggers? If someone asked > you 'why are you working on a smalltalk implementation and not some > lisp?', what would your answer be? I suppose nicer syntax might be the > first thing that comes to mind, but I don't see that as being super > important. Of course, I realise lispers might use a more functional > style, but you could be writing smalltalk style code in CLOS or > something, right? The state of the art in debugging etc. in Clojure at least, is abominable. Mainly, I guess, because of a lack of time. Regarding style, there doesn't have to be that big a difference between the Lisps and Smalltalk. As a probable example of Smalltalk in Clojure, take a look at https://github.com/frankshearar/clj-derp. I didn't really _intend_ to write Smalltalk-like code, but that's how it happened. I don't really have a good example of Clojure written in Smalltalk, partly because I'm quite new to Clojure. http://ss3.gemstone.com/ss/ParsingDerivatives.html might come close, if you look in methods like DerivingParser class >> deriverBlock. Of course, both the above examples might be firmly in the class of "don't do that". frank > Feel free to ignore these questions if you're not interested. I'm just musing. > > On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> Yes, we should improve the debuggerâ¦ >> >> There are some nice things happening around the debugger >> -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. >> In the current Debugger, Model and View >> are completely mixed (and the implementation is kind of old style, that is, very >> low level and complex) >> Last week He and Ben did an experiment to get a second UI working (Spec). >> >> -> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating >> if this can not replace the context step simulator based partsâ¦ >> >> -> For later, we would like to integrate the idea of object centric debugging >> (halt on next ivar change, halt on next messageâ¦) >> >> -> â¦ >> >> The problem right now is that the debugger infrastructure is far more complicated than >> it should be, making is hard to change, fix and improve it. >> >> Marcus >> >> On Dec 9, 2012, at 11:07 PM, adrians <nmanole(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm a Smalltalk newbie and I would like to help fix some simpler issues. For >>> example, I've recently logged some issues surrounding smart character use. I >>> set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded >>> to debug. >>> >>> Now, I understand that for the old-timers stepping through a selector is >>> straightforward, no matter what help the debugger gives you. For myself, and >>> likely many other Smalltalk noobs who'd like to help, I need all the help I >>> can get. One such support is an accurate indication of where the PC is as >>> you step through a body of code. Currently, in the 2.0 one-click image >>> (build 20431), things seem quite broken wrt getting accurate visual feedback >>> of where you are. >>> >>> First, as you step over message sends, the highlighted selection is shown in >>> a totally incorrect spot. Sometimes, just a bit off from where you expect to >>> be, but sometimes quite a bit off, for example in a block that should not >>> even be entered. In the selector I mentioned above, the highlighted location >>> enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" >>> returns false. >>> >>> Second, the PC location highlight is removed when you click somewhere inside >>> the code. This should never turn off - it's as if you switch the lights off, >>> for people not familiar with some particular code. I know you can use the >>> "Where" button to re-establish the highlight, but other than the fact that >>> you shouldn't have to do this, the highlighted selection is sometimes shown >>> in the wrong place. >>> >>> Third, as you step through code, you would expect that the values of >>> variables as shown in the bottom right panel of the debugger are accurately >>> updated as state changes. I've seen cases, relatively frequent, where this >>> is not so. Current values are shown only after some further advancement >>> through code. >>> >>> There is an old issue tracking debugger selection, >>> http://code.google.com/p/pharo/issues/detail?id=709 >>> <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the >>> problem seems to have stalled. Additionally, I'm not sure that this >>> particular issue addresses the third point I made about stale variable >>> values being shown. >>> >>> Could I ask that making the debugger work be made a priority? Of course one >>> can muddle through some code even with visually broken indicators, but it >>> should not be so, IMO. The old timers can make the case that there are other >>> more pressing issues to be addressed, but IMO it makes sense to make the >>> actual tool used to fix problems as helpful as possible for everyone so that >>> even non-experts can be productive and lend a helping hand. >>> >>> >>> Cheers, >>> Adrian >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by dimitris chloupis

Good point. ________________________________ From: Esteban Lorenzano <estebanlm(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Tuesday, 11 December 2012, 17:57 Subject: Re: [Pharo-project] About (backwards) Compatibility problem is that in Pharo, the difference between "the language" and "the library" is subtle :) On Dec 11, 2012, at 4:34 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: Well in summary he says "get out of your comfort zone and deal with it" , bare in mind that the video *is not* about backward compatibility but about implementing new features in general. He also speak in purely a library and not a language perspective.Â > > >He makes some valid points. I am not totally against braking backward compatibility , but overall I have to agree with the first youtube comment that overall the presentation is boring and could be easily summarized in a 3 minute talk.Â > > >And of course I do disagree strongly with his point that "learning the hard way of doing things will make you a better coder" because the success of python and ruby clearly show quite the opposite. I do agree however that "we do not need to babysit new coders" and that "beginner coders should be diving neck deep to coding as fast as possible because they are far more capable than they think they are" . So he definitely makes some valid points . > > > > >________________________________ > From: H. Hirzel <hannes.hirzel(a)gmail.com> >To: Pharo-project(a)lists.gforge.inria.fr >Sent: Tuesday, 11 December 2012, 17:05 >Subject: Re: [Pharo-project] About (backwards) Compatibility > >Marcus, thank you for the link. >May I ask somebody who has watched the video to post a few words of a >summary here....(keywords are fine) > >--Hannes > >On 12/11/12, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> The inventor of Ruby on Rails gave a talk about this topic: >> >> Â Â Â https://www.youtube.com/watch?v=VOFTop3AMZ8 >> >> >> On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> yeah, but that's a directÂ path to stagnation, and that's what happened >>> with fortran, java and all the languages that have put backward >>> compatibility as top priority. >>> in other side, .net is not backward compatible and it has success anyway >>> so, is not so clear for me. >>> >>> I still prefer to drop backward compatibility time to time to drop a full >>> language each 10 years :) >>> >>> Esteban >>> >>> On Dec 11, 2012, at 10:23 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> >>> wrote: >>> >>>> I have to say I am on of those people who love backward compatibility. I >>>> actually come from a programming language that did exactly what the quote >>>> says. It was not a fun experience. Python 3 broke compatibility with >>>> python 2. Most of the libraries did ignore python 3 for quite some time >>>> and some still do. Actually if you google for "python 3" the second >>>> search result of it is the "python wall of shame" where you will find >>>> many of python libraries still stuck to python 2. The reason is that is a >>>> lot of work to rewrite parts of library to make it compatible with python >>>> 3. And note that python 3 has been around for 5 years. And is most likely >>>> it will be another 5 till most major python libraries are finally ported >>>> to python 3. >>>> >>>> http://python3wos.appspot.com/ >>>> >>>> Usually when I see "tragic fate" , "dead" , "declined"Â etc mentioned in >>>> the same sentence with a programming language I am certain that it will >>>> mention some "big flaw" of the language and I am going to facepalm >>>> myself. In 99% of all case of "dead" languages it has nothing to do with >>>> the language itself and has everything to do with hype and lack of good >>>> marketing. >>>> >>>> I can tell you one thing, AFAIK the decision to brake compatibility with >>>> python is still a big reason why one should not use python and is >>>> considered one of the big flaw of python. I know that some people are in >>>> denial, and I agree that python has been improved but not without paying >>>> a big price as the "wall of shame" clearly shows. >>>> >>>> I can bring you another example, blenderpython, its the well known >>>> Blender python api of the well known open source 3d app. Well if you take >>>> a look at it you will find two things. a) blender 2.5 has been a rewrite >>>> which is a very good thing but that ment sacrificing many useful addons >>>> because not only the library changed but also they moved from python 2 to >>>> 3 and b) API keeps braking compatibility in almost every single version. >>>> The result is an army of addons that are left unmaintained because the >>>> author makes something but he is not able to maintain every second month >>>> because the developer decided to brake compatibility. Users ask for >>>> updates to the addons and usually developers search for another developer >>>> to maintain but most of those addons are left for dead. And that is >>>> thousands of lines of code gone to waste. Actually very few developers >>>> stick to blenderpython for this very reason. >>>> >>>> So no I have to disagree there, between choosing a better language or a >>>> useful library and code that works in long term, I choose the second. I >>>> am full on progress but I do find braking compatibility is just the easy >>>> , convinient solution that does not quite work well in practice . >>>> >>>> From: Fernando Olivero <fernando.olivero(a)usi.ch> >>>> To: "Pharo-project(a)lists.gforge.inria.fr" >>>> <pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Tuesday, 11 December 2012, 10:36 >>>> Subject: [Pharo-project] About (backwards) Compatibility >>>> >>>> Hi, i wanted to share an "old" quote which i find relevant to our >>>> community. Just replace FORTRAN's with loads of stuff we had in the >>>> bloated images in the past,Â most of them useful to get were we are right >>>> now. >>>> >>>> "FORTRAN's tragic fate has been its wide acceptance, mentally chaining >>>> thousands and thousands of programmers to our past mistakes. I pray daily >>>> that more of my fellow-programmers may find the means of freeing >>>> themselves from the curse of compatibility." >>>> >>>> Dijkstra, The Humble Programmer, 1972 >>>> >>>> >>>> >>>> >>> >> >> > > > >

Dec. 11, 2012

Re: [Pharo-project] Protecting against stack overflow ?

by Sven Van Caekenberghe

On 11 Dec 2012, at 16:54, Chris Muller <asqueaker(a)gmail.com> wrote: > I don't understand how setting a fixed-size stack could ever be > useful. No one would risk blowing up a production app only because > they guessed wrong about the stackDepthLimit, so for production it > would always be set to 0. I kind of disagree: any system has limits, and most server software is set up to enforce limits earlier (maximum connections, file descriptors per process, â¦) and deal as gracefully as possible with them, to protect itself from external abuse or internal errors. Yes this might involve some guessing, so what. I would rather be able to deal with an infinite recursion and return an internal server error, than have the whole server crash. > So that leaves the development use-case. During development the > system is already under heavy scrutiny, the real requirement is just > the ability to _get back control_ when the system doesn't seem to be > doing anything so that infinite recursions can be debugged. So if > simply Command+. interrupt could be made to just work then there's no > need to fiddle with the "guess the stack-limit" game. With a reasonable stack or low memory limit, you won't even have to press cmd-. when something goes wrong ;-) But of course, cmd-. should just work. > I like Eliots idea of paying attention to how long the > LowSpaceSemaphore fires, except not trying to analyze the stack. > Instead, check how much space was _freed_ by the handlers of low-space > (#freeSomeSpace I think) and, if it is Zero or very low, THEN open a > debugger. > > > > On Tue, Dec 11, 2012 at 8:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> i would be happy to have something, which can be expressed as >> following 'unit test': >> >> Smalltalk vm setStackDepthLimit: 100. >> >> self should: [ self recurseTimes: 101 ] throw: Exception. >> >> Smalltalk vm setStackDepthLimit: 0. "no limit" >> >> self shouldNot: [ self recurseTimes: 101 ] throw: Exception. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Esteban Lorenzano

problem is that in Pharo, the difference between "the language" and "the library" is subtle :) On Dec 11, 2012, at 4:34 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Well in summary he says "get out of your comfort zone and deal with it" , bare in mind that the video *is not* about backward compatibility but about implementing new features in general. He also speak in purely a library and not a language perspective. > > He makes some valid points. I am not totally against braking backward compatibility , but overall I have to agree with the first youtube comment that overall the presentation is boring and could be easily summarized in a 3 minute talk. > > And of course I do disagree strongly with his point that "learning the hard way of doing things will make you a better coder" because the success of python and ruby clearly show quite the opposite. I do agree however that "we do not need to babysit new coders" and that "beginner coders should be diving neck deep to coding as fast as possible because they are far more capable than they think they are" . So he definitely makes some valid points . > > From: H. Hirzel <hannes.hirzel(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Tuesday, 11 December 2012, 17:05 > Subject: Re: [Pharo-project] About (backwards) Compatibility > > Marcus, thank you for the link. > May I ask somebody who has watched the video to post a few words of a > summary here....(keywords are fine) > > --Hannes > > On 12/11/12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > The inventor of Ruby on Rails gave a talk about this topic: > > > > https://www.youtube.com/watch?v=VOFTop3AMZ8 > > > > > > On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > > wrote: > > > >> yeah, but that's a direct path to stagnation, and that's what happened > >> with fortran, java and all the languages that have put backward > >> compatibility as top priority. > >> in other side, .net is not backward compatible and it has success anyway > >> so, is not so clear for me. > >> > >> I still prefer to drop backward compatibility time to time to drop a full > >> language each 10 years :) > >> > >> Esteban > >> > >> On Dec 11, 2012, at 10:23 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> > >> wrote: > >> > >>> I have to say I am on of those people who love backward compatibility. I > >>> actually come from a programming language that did exactly what the quote > >>> says. It was not a fun experience. Python 3 broke compatibility with > >>> python 2. Most of the libraries did ignore python 3 for quite some time > >>> and some still do. Actually if you google for "python 3" the second > >>> search result of it is the "python wall of shame" where you will find > >>> many of python libraries still stuck to python 2. The reason is that is a > >>> lot of work to rewrite parts of library to make it compatible with python > >>> 3. And note that python 3 has been around for 5 years. And is most likely > >>> it will be another 5 till most major python libraries are finally ported > >>> to python 3. > >>> > >>> http://python3wos.appspot.com/ > >>> > >>> Usually when I see "tragic fate" , "dead" , "declined" etc mentioned in > >>> the same sentence with a programming language I am certain that it will > >>> mention some "big flaw" of the language and I am going to facepalm > >>> myself. In 99% of all case of "dead" languages it has nothing to do with > >>> the language itself and has everything to do with hype and lack of good > >>> marketing. > >>> > >>> I can tell you one thing, AFAIK the decision to brake compatibility with > >>> python is still a big reason why one should not use python and is > >>> considered one of the big flaw of python. I know that some people are in > >>> denial, and I agree that python has been improved but not without paying > >>> a big price as the "wall of shame" clearly shows. > >>> > >>> I can bring you another example, blenderpython, its the well known > >>> Blender python api of the well known open source 3d app. Well if you take > >>> a look at it you will find two things. a) blender 2.5 has been a rewrite > >>> which is a very good thing but that ment sacrificing many useful addons > >>> because not only the library changed but also they moved from python 2 to > >>> 3 and b) API keeps braking compatibility in almost every single version. > >>> The result is an army of addons that are left unmaintained because the > >>> author makes something but he is not able to maintain every second month > >>> because the developer decided to brake compatibility. Users ask for > >>> updates to the addons and usually developers search for another developer > >>> to maintain but most of those addons are left for dead. And that is > >>> thousands of lines of code gone to waste. Actually very few developers > >>> stick to blenderpython for this very reason. > >>> > >>> So no I have to disagree there, between choosing a better language or a > >>> useful library and code that works in long term, I choose the second. I > >>> am full on progress but I do find braking compatibility is just the easy > >>> , convinient solution that does not quite work well in practice . > >>> > >>> From: Fernando Olivero <fernando.olivero(a)usi.ch> > >>> To: "Pharo-project(a)lists.gforge.inria.fr" > >>> <pharo-project(a)lists.gforge.inria.fr> > >>> Sent: Tuesday, 11 December 2012, 10:36 > >>> Subject: [Pharo-project] About (backwards) Compatibility > >>> > >>> Hi, i wanted to share an "old" quote which i find relevant to our > >>> community. Just replace FORTRAN's with loads of stuff we had in the > >>> bloated images in the past, most of them useful to get were we are right > >>> now. > >>> > >>> "FORTRAN's tragic fate has been its wide acceptance, mentally chaining > >>> thousands and thousands of programmers to our past mistakes. I pray daily > >>> that more of my fellow-programmers may find the means of freeing > >>> themselves from the curse of compatibility." > >>> > >>> Dijkstra, The Humble Programmer, 1972 > >>> > >>> > >>> > >>> > >> > > > > > > >

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by adrians

Hi Marcus, I figured it must be the complexity of fixing the debugger that's keeping it in the broken state that it is for this long. Mainly I wanted to get a sense of how important is fixing this relative to the other things that need fixing. It would seem to me that fixing the tool that you use to fix things in general would be right up there, but maybe, possibly because the people capable of fixing this aren't significantly handicapped by the issues, this is not as much a priority as it could be. Would you know if there is any chance some of these problems will be fixed for 2.0? Regards, Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Marcus Denker

On Dec 11, 2012, at 4:38 PM, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: > Just out of curiosity.. How does the cutting edge of LISP compare to > what we have in Pharo at the moment? I've read somewhere that > smalltalk has the best refactoring/debugging tools. Would you agree > with that? Are there object centric lisp debuggers? If someone asked > you 'why are you working on a smalltalk implementation and not some > lisp?', what would your answer be? I suppose nicer syntax might be the > first thing that comes to mind, but I don't see that as being super > important. Of course, I realise lispers might use a more functional > style, but you could be writing smalltalk style code in CLOS or > something, right? > > Feel free to ignore these questions if you're not interested. I'm just musing. > my problem is timeâ¦ > On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> Yes, we should improve the debuggerâ¦ >> >> There are some nice things happening around the debugger >> -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. >> In the current Debugger, Model and View >> are completely mixed (and the implementation is kind of old style, that is, very >> low level and complex) >> Last week He and Ben did an experiment to get a second UI working (Spec). >> >> -> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating >> if this can not replace the context step simulator based partsâ¦ >> >> -> For later, we would like to integrate the idea of object centric debugging >> (halt on next ivar change, halt on next messageâ¦) >> >> -> â¦ >> >> The problem right now is that the debugger infrastructure is far more complicated than >> it should be, making is hard to change, fix and improve it. >> >> Marcus >> >> On Dec 9, 2012, at 11:07 PM, adrians <nmanole(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm a Smalltalk newbie and I would like to help fix some simpler issues. For >>> example, I've recently logged some issues surrounding smart character use. I >>> set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded >>> to debug. >>> >>> Now, I understand that for the old-timers stepping through a selector is >>> straightforward, no matter what help the debugger gives you. For myself, and >>> likely many other Smalltalk noobs who'd like to help, I need all the help I >>> can get. One such support is an accurate indication of where the PC is as >>> you step through a body of code. Currently, in the 2.0 one-click image >>> (build 20431), things seem quite broken wrt getting accurate visual feedback >>> of where you are. >>> >>> First, as you step over message sends, the highlighted selection is shown in >>> a totally incorrect spot. Sometimes, just a bit off from where you expect to >>> be, but sometimes quite a bit off, for example in a block that should not >>> even be entered. In the selector I mentioned above, the highlighted location >>> enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" >>> returns false. >>> >>> Second, the PC location highlight is removed when you click somewhere inside >>> the code. This should never turn off - it's as if you switch the lights off, >>> for people not familiar with some particular code. I know you can use the >>> "Where" button to re-establish the highlight, but other than the fact that >>> you shouldn't have to do this, the highlighted selection is sometimes shown >>> in the wrong place. >>> >>> Third, as you step through code, you would expect that the values of >>> variables as shown in the bottom right panel of the debugger are accurately >>> updated as state changes. I've seen cases, relatively frequent, where this >>> is not so. Current values are shown only after some further advancement >>> through code. >>> >>> There is an old issue tracking debugger selection, >>> http://code.google.com/p/pharo/issues/detail?id=709 >>> <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the >>> problem seems to have stalled. Additionally, I'm not sure that this >>> particular issue addresses the third point I made about stale variable >>> values being shown. >>> >>> Could I ask that making the debugger work be made a priority? Of course one >>> can muddle through some code even with visually broken indicators, but it >>> should not be so, IMO. The old timers can make the case that there are other >>> more pressing issues to be addressed, but IMO it makes sense to make the >>> actual tool used to fix problems as helpful as possible for everyone so that >>> even non-experts can be productive and lend a helping hand. >>> >>> >>> Cheers, >>> Adrian >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >

Dec. 11, 2012

Re: [Pharo-project] Protecting against stack overflow ?

by Chris Muller

I don't understand how setting a fixed-size stack could ever be useful. No one would risk blowing up a production app only because they guessed wrong about the stackDepthLimit, so for production it would always be set to 0. So that leaves the development use-case. During development the system is already under heavy scrutiny, the real requirement is just the ability to _get back control_ when the system doesn't seem to be doing anything so that infinite recursions can be debugged. So if simply Command+. interrupt could be made to just work then there's no need to fiddle with the "guess the stack-limit" game. I like Eliots idea of paying attention to how long the LowSpaceSemaphore fires, except not trying to analyze the stack. Instead, check how much space was _freed_ by the handlers of low-space (#freeSomeSpace I think) and, if it is Zero or very low, THEN open a debugger. On Tue, Dec 11, 2012 at 8:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i would be happy to have something, which can be expressed as > following 'unit test': > > Smalltalk vm setStackDepthLimit: 100. > > self should: [ self recurseTimes: 101 ] throw: Exception. > > Smalltalk vm setStackDepthLimit: 0. "no limit" > > self shouldNot: [ self recurseTimes: 101 ] throw: Exception. > > > > > -- > Best regards, > Igor Stasenko. >

Dec. 11, 2012