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

[Pharo-project] pharo-2.0-tests Â» win - Build # 499 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Dec. 11, 2012

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

by dimitris chloupis

There is definitely the other side of things, that side that says you cant have an omelet if you don't brake some eggs. I always admire people that go against the flow , people who are willing to sacrifice convenience for progress.Â Â I do believe in the direction pharo is going , I do believe that keeping code clean and reliable should be main priority. And even though people love to call attempts dead and futile , ideas are near impossible to kill because they always find brains to flourish on. And even a bad idea in time can turn into something great. Because as one Greek philosopher once said "everything is changing" , everything has a life of its own, and as far as software is concern as long as there are coders for it , it aint dead yet. And there definitely benefits to be gained from braking compatibility. But progress is definitely a tricky things full of pitfalls and new is not always better. Its ironic how software seems to going back through time nowdays and rediscovering old relics like smalltalk and lisp. And "old" becomes the new "new". Definitely keeping an open mind is the wise thing to do any direction one may chooses to go. And I am certainly going to follow pharo and squeak progress closely because both have still a lot to say. ________________________________ From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; ma.chris.m(a)gmail.com Sent: Tuesday, 11 December 2012, 22:50 Subject: Re: [Pharo-project] About (backwards) Compatibility 2012/12/11 Chris Muller <asqueaker(a)gmail.com>: > If my goal is to make my computer work for ME, then I want my > development system to maximize my leverage and minimize my effort. > Breaking compatibility for cleaner code subverts this, as Hannes said, > One thing is clear, forking is not anything near minimizing the effort, quite the opposite. It's the way to build one's own jailÂ - some will say to be free ;). Clearly, Marcus and Stephane have other goals and it's a good thing to have both Squeak and Pharo. >>> Constant input in maintenance effort is needed. > > I want to use my time applying Smalltalk to real-world problems, not > API changes. > > A blue-plane innovation is worth breaking backward compatibility, > reinventing the past isn't. > Ah, if future is the past, then I wonder whether it's not yet another damned Smalltalk circularity trick ;) > >>> 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 Nicolas Cellier

2012/12/11 Chris Muller <asqueaker(a)gmail.com>: > If my goal is to make my computer work for ME, then I want my > development system to maximize my leverage and minimize my effort. > Breaking compatibility for cleaner code subverts this, as Hannes said, > One thing is clear, forking is not anything near minimizing the effort, quite the opposite. It's the way to build one's own jail - some will say to be free ;). Clearly, Marcus and Stephane have other goals and it's a good thing to have both Squeak and Pharo. >>> Constant input in maintenance effort is needed. > > I want to use my time applying Smalltalk to real-world problems, not > API changes. > > A blue-plane innovation is worth breaking backward compatibility, > reinventing the past isn't. > Ah, if future is the past, then I wonder whether it's not yet another damned Smalltalk circularity trick ;) > >>> 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 Chris Muller

If my goal is to make my computer work for ME, then I want my development system to maximize my leverage and minimize my effort. Breaking compatibility for cleaner code subverts this, as Hannes said, >> Constant input in maintenance effort is needed. I want to use my time applying Smalltalk to real-world problems, not API changes. A blue-plane innovation is worth breaking backward compatibility, reinventing the past isn't. >> 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

[Pharo-project] another kid born: NBExternalEnumerationType

by Ciprian Teodorov

Hi guys, today I have commited to the NativeBoost repository a new core class, the NBExternalEnumerationType, which reifies the enum declarations in C and offers a nice interface (especially in terms of debug/inspect). To use it just subclass the NBExternalEnumeration and add an #enumDeclmethod to the class side such as: NBExternalEnumeration subclass: #NBTestEnumeration instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NativeBoost-Tests' NBTestEnumeration class>>enumDecl ^ {(#AAA -> 1). (#BBB -> 2). (#CCC -> 3). (#DDD -> 2400)} asDictionary DO NOT FORGET to call the #initialize method on your class. The rest is automatically done ;) You can use your new enum in two ways: - add it to a client class poolDictionaries list (see #NBExternalEnumTests for an example), and then just write CCC in your code -- CCC here is an item of your enum - or you can send the name of an item to your class --- NBTestEnumeration DDD The NBExternalEnumeration implements (instance and class) some more API methods like: - #itemAt: retrieves the item having a specific value --- NBTestEnumeration itemAt: 2 - #includes: checks the existence of a specific item in the enum --- NBTestEnumeration includes: #AAA Having this already gives us a nice interface to working with enums. Now I plan to improve a little bit on performance and usage scenarios: - the possibility to accept smalltalk integers as valid input/output for functions(or callbacks) that use enums as arguments/return. - support the different representation types for the enum values (int/uint) So that will be for now. Feel free to try it out and send me any comments and/or improvement ideas, It will be my pleasure to improve it. 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

Dec. 11, 2012

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