March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] RC3 - small stuff

by Schwab,Wilhelm K

Hello all, Some time ago, there was (I thought) a patch for saving workspace text to a file; I had hoped to find that in 1.0, but it is not in RC3 that I can find. The first thing I did was load the Loader extensions to Gofer. It installed as expected. I have not looked into the code, but tried #search: and found things like Citezen and Rio missing. That might be "simply" because the Configuration* packages are not in the Metacello repository?? If so, are they not there for a non-trivial reason? I then grabbed ConfigurationOfCitezen, and was hung up by an unsatisfied dependence on SmaCC. The SmaCC runtime is in my RC1 image, but I don't know how/why it was loaded; presumably CZLoader did it. Are these bugs or features? I am leaning toward bugs, but the question is whether any or all of the following appicable: (1) ConfigurationOfCitezen needs to load prerequisites; (2) Loader is in the wrong to not see them; (3) I need to add repositories to Loader; (4) various ConfigurationOf* packages need to be in the Metacello repository. Any ideas? Bill

March 22, 2010

Re: [Pharo-project] Implementing MethodWrappers in Smalltalk

by Lukas Renggli

> 1) For a generic approach to method wrappers, which of those two ways would > you use ? Â should I care about notifying, adding to localSelectors, etc? > Or at is just temporal, I don't care ? > which are the pros and cons you see with each alternative ? I used #at:put: because we put-back the identical compiled methods as fast as possible, even while the tests are running. Triggering notifications while running might also cause undesired side effects. Also note that code doing reflection (iterating over pragmas, literals, ...) might break if you are not super careful. > 2) Do you think it make sense to the packageÂ ObjectsAsMethodsWrapÂ in > PharoCore as a "library" to create lightweight proxies ? It is just 4 > classes and it would be cool to change TestCoverage to that implementation. > Then, you only don't have the library, but also some real examples. Of > course, this can be done if we eleiminate the 30% of slowleness. I guess it is slower because it is very generic and does block activations. > so...what do you think ? There are also MethodWrappers from the RB engine that come with an integration into OB. I wouldn't include the extra package, after all the implementation is pretty simple and also very specific. For a different use-case the implementation would probably look completely different. Check the mailing list, we had some discussions and did various iterations back when this was integrated. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 22, 2010

Re: [Pharo-project] bug in the code of CompiledMethod >> =

by Eliot Miranda

Oops. Find attached. 2010/3/22 Cyrille Delaunay <cy.delaunay(a)gmail.com> > try in a Pharo-1.0-10515-rc3 image : > > |set| > set := Set new. > Collection withAllSubclasses do: [:aClass | > set addAll: aClass methods > ]. > > It will raise an exception telling: "MessageNotUnderstood: ByteSymbol>>analogousCodeTo:". > Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' is send to a > symbol. > > > I opened an Issue: > > http://code.google.com/p/pharo/issues/detail?id=2185 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 22, 2010

[Pharo-project] Implementing MethodWrappers in Smalltalk

by Mariano Martinez Peck

Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation. After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap The main difference between both approaches are: TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver , etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage. ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok. I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc Now...I have two questions: 1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ? 2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness. so...what do you think ? Cheers Mariano

March 22, 2010

[Pharo-project] [update 1.1] #11287

by Marcus Denker

11287 ----- Issue 2136: Smalltalk and SmalltalkImage -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2010

[Pharo-project] [update 1.1] #11286

by Marcus Denker

11286 ----- Issue 2179: Tweak from nicolas in sync Pharo and Squeak Issue 2181: CompiledMethod >>getSourceFor: selector in: class Issue 2173: MC browser selection Issue 2186: Adding some methods to the WorldMenu for deprecation Issue 2142: isInMemory should be removed. -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de 2denker UG (haftungsbeschrÃ¤nkt) Sitz KÃ¶ln Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker

March 22, 2010

[Pharo-project] [update 1.1] #11285

by Marcus Denker

11285 ----- - Issue 2180: Move MetaObjectTools from core to PharoDev - Issue 2165: CleanUp unused packages -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2010

Re: [Pharo-project] isInMemory :)

by StÃ©phane Ducasse

good! Stef On Mar 22, 2010, at 2:59 PM, Adrian Lienhard wrote: > My plan is to extract ImageSegments into an external package and maintain it there. Since I will probably not be able to make the class swapping work, this part of image segments will be dropped. > > If you start with removing #isInMemory, thats fine with me. I can do the rest later. > > Cheers, > Adrian > > > On Mar 22, 2010, at 14:42 , StÃ©phane Ducasse wrote: > >> so do we remove imageSegments support? >> >> Stef >> >>>>>> The reason why the #isInmemory checks are there at all is the following: >>>>>> >>>>>> -> they used imageSegements (and before, the ObjectOut stuff) to swap out objecs to disk >>>>>> -> Now if you access the class, it is loaded again. >>>>>> -> doing anything that looks at "all classes" would load the classes. (all of them) >>>>>> -> this includes things like "Object subclasses". or "Smalltalk classNames". >>>>>> -> e.g. Openign a browser would load all classes. >>>>>> -> so we put #isInMemory everywhere >>>>> >>>>> Yes I know that :) >>>>> Now I was wondering what adrian meant. >>>>> >>>>>> -> this of course means that #subclasses would just return those that by chance are >>>>>> in memory... I don't understand how that can work. Honestly :-) >>>>>> >>>>>> I think we shoud remove all that stuff and do it "for real". c.f. Loom. >>>>> >>>>> probably. >>>> >>>> >>>> so I was wondering: what exactly is bad in swapping in all classes when opening a browser? >>>> >>>> 1) no need to swap in *everything*. Classe are large because they reference *lots* of methods (which in turn reference >>>> lots of literals). >>>> But most cases where we iterate over all classes we will not touch the methods (other than when we *want* >>>> the methods). >>>> >>>> => be fine grained. Loading all classes does not imply loading all methodDictcs. >>>> >>>> 2) If I am interested in all classes, I am interested in all classes. Give them to me! >>>> And get rid of them as soon as I am not interested anymore >>>> >>>> => on-demand loading is half of the story. On-No-Demand-*Unloading* is needed, too. >>>> >>>> This means, when developing, we will have all classes (or at least parts of them) in memory. >>>> (*because we look at them*). But in Deployment, the working set of objects will be different, and >>>> only those classes that are needed for *execution* will stay in memory. >>>> >>>> 3) Intelligent caching. Of course we don't load objects one-by-one, we will have an intelligent cache. >>>> We will do intelligent pre-fetching, too, to not have to go to disk for each object when it's clear that >>>> probably we will load more that just that one object (or it's cheap to load more). >>>> >>>> But that is orthogonal and invisible. >>> >>> Exactly! If granularity even was at the method level (executing 100 methods of Morph would not bring in all 1000 methods), we could get a system that is *really* small (and also faster because GC has to do less work). >>> >>> Adrian >>> _______________________________________________ >>> 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

March 22, 2010

[Pharo-project] [ANN 1.1] prebuild Core#11284

by Marcus Denker

https://gforge.inria.fr/frs/download.php/26693/PharoCore-1.1-11284-UNSTABLE… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2010

Re: [Pharo-project] isInMemory :)

by Adrian Lienhard

My plan is to extract ImageSegments into an external package and maintain it there. Since I will probably not be able to make the class swapping work, this part of image segments will be dropped. If you start with removing #isInMemory, thats fine with me. I can do the rest later. Cheers, Adrian On Mar 22, 2010, at 14:42 , StÃ©phane Ducasse wrote: > so do we remove imageSegments support? > > Stef > >>>>> The reason why the #isInmemory checks are there at all is the following: >>>>> >>>>> -> they used imageSegements (and before, the ObjectOut stuff) to swap out objecs to disk >>>>> -> Now if you access the class, it is loaded again. >>>>> -> doing anything that looks at "all classes" would load the classes. (all of them) >>>>> -> this includes things like "Object subclasses". or "Smalltalk classNames". >>>>> -> e.g. Openign a browser would load all classes. >>>>> -> so we put #isInMemory everywhere >>>> >>>> Yes I know that :) >>>> Now I was wondering what adrian meant. >>>> >>>>> -> this of course means that #subclasses would just return those that by chance are >>>>> in memory... I don't understand how that can work. Honestly :-) >>>>> >>>>> I think we shoud remove all that stuff and do it "for real". c.f. Loom. >>>> >>>> probably. >>> >>> >>> so I was wondering: what exactly is bad in swapping in all classes when opening a browser? >>> >>> 1) no need to swap in *everything*. Classe are large because they reference *lots* of methods (which in turn reference >>> lots of literals). >>> But most cases where we iterate over all classes we will not touch the methods (other than when we *want* >>> the methods). >>> >>> => be fine grained. Loading all classes does not imply loading all methodDictcs. >>> >>> 2) If I am interested in all classes, I am interested in all classes. Give them to me! >>> And get rid of them as soon as I am not interested anymore >>> >>> => on-demand loading is half of the story. On-No-Demand-*Unloading* is needed, too. >>> >>> This means, when developing, we will have all classes (or at least parts of them) in memory. >>> (*because we look at them*). But in Deployment, the working set of objects will be different, and >>> only those classes that are needed for *execution* will stay in memory. >>> >>> 3) Intelligent caching. Of course we don't load objects one-by-one, we will have an intelligent cache. >>> We will do intelligent pre-fetching, too, to not have to go to disk for each object when it's clear that >>> probably we will load more that just that one object (or it's cheap to load more). >>> >>> But that is orthogonal and invisible. >> >> Exactly! If granularity even was at the method level (executing 100 methods of Morph would not bring in all 1000 methods), we could get a system that is *really* small (and also faster because GC has to do less work). >> >> Adrian >> _______________________________________________ >> 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

March 22, 2010