- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by Eliot Miranda

2010/8/27 Marcus Denker <marcus.denker(a)inria.fr> > > Smalltalk.true. > > takes a while, but it does not try to call #quitPrimitive. Which it would > if Methodfinder would not be based on a positive list. > > > Ah, and a negative list was I think not used as it is too dangerous wrt. to > completenes. If the positive list is incomplete, you miss > a hit. If the negative list is incomplete, you woud crash in some nasty > way. > > Just look at the lists and how many methods you find that have been removed > years ago... > > It's not just methods like #quitPrimitive. In general, with the image based > nature you could end up modifying state of objects > in the image by accident, and realize it weeks later. > e.g. this means one would very carefully protect the reflective model, to > not accidentally modify the methodDictionary, for example. > So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. best, Eliot > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 27, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by Eliot Miranda

2010/8/27 Marcus Denker <marcus.denker(a)inria.fr> > > On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote: > > Dear list, > > I was showing off Pharo to a colleague today and was surprised that. > > My quick introduction of adding new methods on existing system classes > > String>>firstLetter > ^self copyFrom: 1 to: 1 > > - extension on String worked immediately. But that: > > in the MethodFinder evaluating: 'tried'.'t' > did not return my method I just added .... :-( > > Turns out that MethodFinder has a class side Set of Approved and > AddAndRemove methods. > What is the rationale of this? Should we not allow any method, but exclude > some tricky ones (doesNotUnderstand:, ... )? > > > The rational is that the MethodFinder would, if it would not have a > positive list, quite likely call methods that do bad things > to the state of the system. Remember that is just calls all methods to > check if some leads to the return value that you gave! > > e.g. > > Smalltalk.true. > > takes a while, but it does not try to call #quitPrimitive. Which it would > if Methodfinder would not be based on a positive list. > > It would of course be nice to be able to not need a positive list. > The question of how to control side-effects (and how to realize a secure > yet reflective language in general) is > of course a very interesting one... > I'd love for someone to try and implement MethodFinder using simulation. If one used something based on ContextPart runSimulated: to execute the tests the simulation could maintain the set of objects that get instantiated as execution proceeds and only allow writes to these objects. Any attempt to write an object outside the set would cause an error and abandon exploring that alternative. This *might* be fast enough for use, but the experiment would show whether this was the case or not. best Eliot > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 27, 2010

Re: [Pharo-project] [update 1.2] #12116

by Sven Van Caekenberghe

On 27 Aug 2010, at 21:19, StÃ©phane Ducasse wrote: > Strange > where is the other tests packages? > in the inbox? No, I mean the latest version in Andreas' WebClient repo.

Aug. 27, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by Marcus Denker

> > Smalltalk.true. > > takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 27, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by StÃ©phane Ducasse

Now what we should do is probably to get a more dynamic way to tag methods because not methodFinder has a huge baglog of selectors and it is probably not in sync with the system We were thinking about using pragma to tag methods that should not be executed but we need a proof of concept. Stef On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote: > Dear list, > > I was showing off Pharo to a colleague today and was surprised that. > > My quick introduction of adding new methods on existing system classes > > String>>firstLetter > ^self copyFrom: 1 to: 1 > > - extension on String worked immediately. But that: > > in the MethodFinder evaluating: 'tried'.'t' > did not return my method I just added .... :-( > > Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. > What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? > > Kind Regards, > > Bart > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] Why is Stack extending from LinkedList?

by StÃ©phane Ducasse

On Aug 27, 2010, at 6:32 PM, Levente Uzonyi wrote: > On Thu, 26 Aug 2010, Bart Gauquie wrote: > >> Hi list, >> >> is there a specific reason Stack is extending from LinkedList, instead of >> using a LinkedList internally? >> To me, it seems that the protocol that LinkedList, SequenceableCollection, >> ... provides is not the protocol you expect from a Stack? >> >> Any thoughts on this? > > Originally it used encapsulation, when where? > but for some reason it was changed to use inheritance, probably for a "cleaner" system. IMHO the changes should be reverted. I was not aware that Stack was a subclass of linkedList, it looks again subclassing versus subtyping. And subtyping is better. Stef > > > Levente > >> >> Kind regards, >> >> Bart >> >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you everywhere - >> Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The important thing >> is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - Albert >> Einstein >> However beautiful the strategy, you should occasionally look at the results. >> - Sir Winston Churchill >> It's not enough that we do our best; sometimes we have to do what's >> required. - Sir Winston Churchill >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] about ValueAdapter

by StÃ©phane Ducasse

On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: > Stef, > > Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - arrrrggggGGGGGG!!!!! :) > > Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. > > Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? > You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. > > Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Friday, August 27, 2010 9:07 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about ValueAdapter > > there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. > > Stef > > On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? >> >> As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. >> >> What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] >> Sent: Friday, August 27, 2010 4:28 AM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Subject: [Pharo-project] about ValueAdapter >> >> Bill >> >> I scanned the code. >> Could you >> - reformat your code? >> put space after : >> align on the first tab >> - get some more tests? >> - I could not see the class comments but if there are none then please adde something. >> - did you check the padded printon methods and others? >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] what about putting RBengine in pharo1.2 core?

by StÃ©phane Ducasse

> > Hudson isn't your friend for this ? no when I batch fixes I cannot wait for something that start and can take 15 min. I prefer to update often to separate commit for tracebility so speed in making new image is important. It is already so slow. Stef

Aug. 27, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by Nicolas Cellier

2010/8/27 Bart Gauquie <bart.gauquie(a)gmail.com>: > Dear list, > I was showing off Pharo to a colleague today and was surprised that. > > My quick introduction of adding new methods on existing system classes > String>>firstLetter > ^self copyFrom: 1 to: 1 > > - extension on String worked immediately. But that: > in the MethodFinder evaluating: 'tried'.'t' > did not return my method I just added .... :-( > Turns out that MethodFinder has a class side Set of Approved and > AddAndRemove methods. > What is the rationale of this? Should we not allow any method, but exclude > some tricky ones (doesNotUnderstand:, ... )? > Kind Regards, > Bart > > Suppose you feed MethodFinder with Array and #() just to check whether #new is found. Will you be happy after MethodFinder has tried if ever Array removeFromSystem just wouldn't return #() ? Nicolas

Aug. 27, 2010

Re: [Pharo-project] [update 1.2] #12116

by StÃ©phane Ducasse

On Aug 27, 2010, at 3:46 PM, Sven Van Caekenberghe wrote: > > On 27 Aug 2010, at 15:16, StÃ©phane Ducasse wrote: > >> >> 12116 >> ----- >> >> merging webclient pmm 73 > > It seems that every time I upgrade 1.2a using System>Software Update, the version of WebClient-Test reverts as well. Strange where is the other tests packages? in the inbox? > > As I told you, your (older) version gives more unit test errors ;-) > > Sven > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010