- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

what is interesting that people don't realize that they can have 2 versions of same software installed, and use one or another, depending on need. -- Best regards, Igor Stasenko.

Dec. 11, 2012

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

by Igor Stasenko

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] Pharo 2

by Esteban Lorenzano

and then you can help us to find the bugs before going to production :) Esteban On Dec 11, 2012, at 10:30 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > thanks for the clarification , Pharo 2 image here I come :D > > From: Marcus Denker <marcus.denker(a)inria.fr> > To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> > Sent: Tuesday, 11 December 2012, 10:58 > Subject: Re: [Pharo-project] Pharo 2 > > > On Dec 11, 2012, at 9:54 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > >> I was wondering if it really worths working with Pharo 2 yet, in terms of stability and new features. >> > > I think soâ¦ there are some bugs left, but not many real showstoppers. > >> First question is the link in the website the link to the latest Pharo 2 image ? >> > yes. > >> Is Athens included in the Pharo 2 image ? >> > No. NativeBoost is, but Athens not. > >> How much production ready Pharo 2 image really is ? >> > To me it looks quite good, but of course only you can decide that as you might use > other parts of the system then me. > >> Should I move to it or is it still a moving target ? >> > > Not at all. We are in Beta, we just allow bug fixes. > >> What new Pharo 2 image offers ? > > We should make a listâ¦ > > Marcus > >

Dec. 11, 2012

Re: [Pharo-project] who is "dfgs"?

by Esteban Lorenzano

... and please, please, please, use real names, not initials when committing packages! Esteban On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I would like to ask who has the initials "dfgs". And I have a question for him/her. The VTermInputDriver initialization methods generate a lot of unimplemented calls because they expect a handler object with protocol that is not defined in the image. Do we need the VTerm classes at all? Can you provide an abstract handler class? Or what about to switch this calls to perform:/perform:with: form. > > Cheers, > -- Pavel > >

Dec. 11, 2012

Re: [Pharo-project] NB squeaksource comits

by Igor Stasenko

On 11 December 2012 11:58, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > On Dec 11, 2012 4:55 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: >> >> On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi Igor, >> > >> > sorry for bothering you again with this issue but again somebody >> > (squeaksource ;)) removed me from the commiters of the NB project. >> > >> added again :) > Thanks > >> >> > Now I have two proposals, a very small one: removing the asm int3, and >> > decrementing the callback counter in >> > #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash >> > on >> > callback error case. >> > >> no, it should not decrement counter in error case, >> because you are not leaved from callback. >> you should always return from callback, otherwise its call will be >> held on stack. > The I guess that we should be able to continue executing after primitive > fail. On my machine VM crashes if I click proceed. It doesn't crash if I > abort though... But when aborting the counter is not decremented... What > shall we do then? Is there any way to gracefully exit to vm, leaving a > proper state? > The only graceful way is to pass the correct return value, so callback will return to caller. If you have an error there, there's little choice.. either user should manually enter the valid value, or quit :) aborting the process with callback is not a good way too.. because you aborting smalltalk process which handling callback, but it is still there, on stack.. So will it make you happy having callback counter decremented, but in fact having not returned from callback? :) -- Best regards, Igor Stasenko.

Dec. 11, 2012

Re: [Pharo-project] NB squeaksource comits

by Ciprian Teodorov

On Dec 11, 2012 4:55 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > Hi Igor, > > > > sorry for bothering you again with this issue but again somebody > > (squeaksource ;)) removed me from the commiters of the NB project. > > > added again :) Thanks > > > Now I have two proposals, a very small one: removing the asm int3, and > > decrementing the callback counter in > > #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash on > > callback error case. > > > no, it should not decrement counter in error case, > because you are not leaved from callback. > you should always return from callback, otherwise its call will be > held on stack. The I guess that we should be able to continue executing after primitive fail. On my machine VM crashes if I click proceed. It doesn't crash if I abort though... But when aborting the counter is not decremented... What shall we do then? Is there any way to gracefully exit to vm, leaving a proper state? > > > Secondly, I have converged to an implementation of NBExternalEnum (using > > SharedPool) which I think it is cool, and I wanted to share it with you. > > Maybe you like it... maybe you don't ... ;) > > > > Cheers, > > -- > > Dr. Ciprian TEODOROV > > IngÃ©nieur DÃ©veloppement CAO > > > > tÃ©l : 06 08 54 73 48 > > mail : ciprian.teodorov(a)gmail.com > > www.teodorov.ro > > > > -- > Best regards, > Igor Stasenko. >

Dec. 11, 2012

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

by Sven Van Caekenberghe

Hi Eliot, On 11 Dec 2012, at 02:33, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 2012/12/9 Sven Van Caekenberghe <sven(a)stfx.eu> > Hi, > > Would it be possible to build some kind of protection against stack overflow ? > > note that there already is some mechanism. The low space mechanism is supposed to protect against stack overflow but with today's memories and the difficulty of testing it, this mechanism often a) takes way too long to kick in, and b) either leaves the system in a very sluggish state or simply fails to kick in and the system crashes with an out-of-memory error. > > Part of the problem is in designing a mechanism which is in keeping with the reflective nature of the system. What I mean is that we now have two different VMs, the Interpreter and the STack/Cog VMs. First one wants a check which is cheap. That means a check which isn't run on every send. In the interpreter a natural time to check for recursion would be on e.g. fullGC, checking for repetition in the current process's context chain. The the Stack/Cog VMs the natural time is on evacuating a stack page when the stack zone is full. But these are two different mechanisms, both of which are deep in the VM, neither of which can be conveniently intercepted from Smalltalk, unlike e.g. doesNotUnderstand:. > > Personally I like the idea of reviving the low space mechanism and maintaining it properly. For example, if the low space mechanism causes the low space semaphore to fire often, because the limit was set only a little way above the current memory size, and not, as it is now, a little below the absolute limit, then when it fires, the low space process could inspect the current process's stack (e.g. via accelerated via a primitive for performance) and see how deep it is, and possibly whether there is recursion (e.g. a bag of context methods would soon reveal high-frequency methods, and then those contexts could be inspected for repetition, but KISS says just have a per-process limit on the maximum depth of stack). Thanks for the reply. Yes, getting a low space warning sooner and then deal with that intelligently at the image level sounds like a good solution. It is probably more portable, requires miminal VM collaboration, allows for many behaviours as a reaction and would catch other problems than just stack overflow. Is this already possible today ? Preferrably, dynamic control over the limit would be nice: in a headless server you want other behavior than during interactive development. Sven > This is actually the most common situation for loop/cycle that either results in an unusable image or a crash. > Interrupting with CMD-. is not always possible. > A possible solution could be to just limit the stack size and throw an exception. > > For example, in LispWorks, it goes like this: > > CL-USER 5 > (defun foo () (cons (random 100) (foo))) > FOO > > CL-USER 6 > (foo) > > Stack overflow (stack size 48128). > 1 (continue) Extend stack by 50%. > 2 (abort) Return to level 0. > 3 Return to top loop level 0. > > Type :b for backtrace or :c <option number> to proceed. > Type :bug-form "<subject>" for a bug report template or :? for other options. > > CL-USER 7 : 1 > :bq > > ERROR <- RUNTIME:BAD-ARGS-OR-STACK <- LENGTH <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO > <- FOO <- FOO <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION > > Obviously, this is possible, the question is, can it be done easily and without paying an unbearable performance price ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > > > > -- > best, > Eliot > -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 11, 2012

[Pharo-project] who is "dfgs"?

by Pavel Krivanek

Hi, I would like to ask who has the initials "dfgs". And I have a question for him/her. The VTermInputDriver initialization methods generate a lot of unimplemented calls because they expect a handler object with protocol that is not defined in the image. Do we need the VTerm classes at all? Can you provide an abstract handler class? Or what about to switch this calls to perform:/perform:with: form. Cheers, -- Pavel

Dec. 11, 2012

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

by Marcus Denker

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] About (backwards) Compatibility

by Esteban Lorenzano

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