- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NativeBoost and Pharo Kernel

by Paul DeBruicker

Igor Stasenko wrote > I am not very good in metacello-fu to write a confing, which will > select various set of stuff to load > depending on image version. > So, if someone can help, i would appreciate that. > I can move those methods into NB-pharo-1.4 package.. > > > > -- > Best regards, > Igor Stasenko. Where is the NB config kept? I could take a look this weekend. -- View this message in context: http://forum.world.st/NativeBoost-and-Pharo-Kernel-tp4658786p4658896.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 11, 2012

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

by Sven Van Caekenberghe

Cool, could you maybe do a proof of concept someday ;-) On 11 Dec 2012, at 19:26, Igor Stasenko <siguctua(a)gmail.com> wrote: > hehe.. > it looks like we can do it: > > - when memory hits the waterline mark, VM should do the following: > - for every currently scheduled process , push an artificial stack > frame on top , which is > StackOverflow signal. > > Then the first thing what this guy should do, when he will get > control, is to analyze > how deep is the stack of given process and if it surpassed the allowed > threshold, > and if there's no handler, then decide whether to kill the process or not. > > Also, since it is exception, a user code can intercept this exception and > either ignore it (effectively forcing system to keep running), or otherwise > terminate process, but in an educated manner, since he might have a > better knowledge, > what can eat so much resources in his code.. as well, as do a gracious failure > handling, e.g., correctly clean associated system resources etc. > > > -- > Best regards, > Igor Stasenko. >

Dec. 11, 2012

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

by Igor Stasenko

hehe.. it looks like we can do it: - when memory hits the waterline mark, VM should do the following: - for every currently scheduled process , push an artificial stack frame on top , which is StackOverflow signal. Then the first thing what this guy should do, when he will get control, is to analyze how deep is the stack of given process and if it surpassed the allowed threshold, and if there's no handler, then decide whether to kill the process or not. Also, since it is exception, a user code can intercept this exception and either ignore it (effectively forcing system to keep running), or otherwise terminate process, but in an educated manner, since he might have a better knowledge, what can eat so much resources in his code.. as well, as do a gracious failure handling, e.g., correctly clean associated system resources etc. -- Best regards, Igor Stasenko.

Dec. 11, 2012

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

by Igor Stasenko

On 11 December 2012 17:41, Chris Muller <ma.chris.m(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. > > 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. You don't need a grumpy guy to do that. you can always do: [ i don't care what happens inside, recurse: 10000000 times ] on: StackOverflow do: [: ex pass ]. or, if you care, you can do: [ inside, recurse: 10000000 times ] on: StackOverflow do: [: ex | self showErrorAndTerminateBugger ]. all you need is a levers to control that. The idea is that you set the stack limit per process, and when it hits the limit, you get a signal, with exact information about who ran onto it. Right now, that "lowspace" is just a notification: you're going to explode...in 5..4..3..2.. now in a few lapses left, you should guess right and cut right wire (among 10000) , and if you cut wrong one... booom.. the point is that you don't know right wire, because you're not imposed any limits(rules) on your model, so you cannot find the violator. > > 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. > -- Best regards, Igor Stasenko.

Dec. 11, 2012

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

by Igor Stasenko

On 11 December 2012 18:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <hannes.hirzel(a)gmail.com> wrote: >> >> >> Constant input in maintenance effort is needed. So any efforts in >> maintaining libraries and maybe compatibility layers are very welcome. >> > Yes, and how did we ever thought we could invent the future with Squeak > when in reality, we could not even change a typo in a comment? > Simple: you just add a wrapper class/method and put fixed comment there :) but i think you're stretching a bit :) > Marcus > > > > -- Best regards, Igor Stasenko.

Dec. 11, 2012

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

by H. Hirzel

Marcus, maybe you could you elaborate your comment. I do not understand it. Changing a typo in a comment is not changing the 'computer language'. I assume you speak about the development process. However both Pharo and Squeak now have a good process. --Hannes On 12/11/12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <hannes.hirzel(a)gmail.com> wrote: >> >> >> Constant input in maintenance effort is needed. So any efforts in >> maintaining libraries and maybe compatibility layers are very welcome. >> > Yes, and how did we ever thought we could invent the future with Squeak > when in reality, we could not even change a typo in a comment? > > Marcus > > > > >

Dec. 11, 2012

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

by Marcus Denker

On Dec 11, 2012, at 6:12 PM, "H. Hirzel" <hannes.hirzel(a)gmail.com> wrote: > > > Constant input in maintenance effort is needed. So any efforts in > maintaining libraries and maybe compatibility layers are very welcome. > Yes, and how did we ever thought we could invent the future with Squeak when in reality, we could not even change a typo in a comment? Marcus

Dec. 11, 2012

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

by H. Hirzel

Dimitris, thank you for the summary of the RoR video. Base line is to deal with it. Interesting to note that with computer languages the same thing happens as with natural languages. Language use changes. Most people would have a hard time understanding Middle English these days. http://en.wikipedia.org/wiki/Middle_English, see sample texts. However the rate at where understanding starts dropping is "digital" with computer languages. A single changed method call breaks compatibility... The process is not robust. Of course that is pretty easy to fix. A call for the construction of various compatibility patches/layers/facades. For example in August this year I loaded PetitParser into Squeak. I had to add a 'Pharo compatibility' package which just contained 1 (one) method! (for the minimal version, not the GUI version and the Smalltalk parser) After some discussion that method was added to Squeak trunk and PetitParser did not need that anymore. http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/16579… Constant input in maintenance effort is needed. So any efforts in maintaining libraries and maybe compatibility layers are very welcome. --Hannes On 12/11/12, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > 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] Helping the noobs help out - i.e. fixing the debugger

by adrians

Of course not all of what needs to be done in Pharo should be of at same priority. It makes sense to first fix the tools one uses for fixing everything else, so that one can speed up one's own work and at the same time open up the possibility for others (less skilled) to help out. In any case I'm sorry if it seems that I'm demanding you or anyone else should make this a higher priority. The thinking was that maybe there is someone (Stephane D?) who, to some degree, can prioritize certain things over others and if so, wouldn't it make sense to fix the most basic tool that is used to help fix everything else? Who knows though, maybe the debugger is not often used by the experts. -- 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:39 PM, adrians <nmanole(a)gmail.com> wrote: > 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. > But isn't that true for everything we use? That is, the whole of Pharo? > 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. Nevertheless, there are only 24 hours in a day. I am full, I can not do more. Marcus

Dec. 11, 2012