- Pharo-dev - lists.pharo.org

[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

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

by StÃ©phane Ducasse

Thanks cyrille! Stef On Mar 22, 2010, at 2:33 PM, Cyrille Delaunay wrote: > 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

Re: [Pharo-project] isInMemory :)

by StÃ©phane Ducasse

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

March 22, 2010

Re: [Pharo-project] Question about HostMenuSystem

by StÃ©phane Ducasse

This is cool to see a bold guy like that pushing that :) Keep pushing mariano. Stef On Mar 22, 2010, at 12:19 AM, Michael Rueger wrote: > On 3/21/10 4:07 PM, Mariano Martinez Peck wrote: > >> Hi Michael. Let me see if I understood. >> >> - In PharoCore I remove InputEventSensor >> processMenuEvent: and the >> invocation from ImputEventSensor >> processEvent: evt > > correct > And make sure to do it in the right order and have backups of your image ;-) > >> >> - In the package HostMenuSystem, I create a subclass of >> InputEventHandler (Suppose called HostMenuEventHandler). It is correct >> to subclass from this class ? > > Yes > >> - In HostMenuEventHandler I create the method handleEvent: that does >> the if type = EventTypeMenu and do everything > > Yes > >> - In a class side method initialize or similar, I put: >> >> HostMenuEventHandler new registerIn: InputEventFetcher default. >> >> Is that correct? I mean, it is correct to register in InputEventFetcher >> or I should use another class ? > > You understood perfectly :-) > > Now I'm curious if it actually works... > > Will hopefully be a good example of how the new event handling setup allows us to do these things without system overrides. > > Michael > > _______________________________________________ > 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] bug in the code of CompiledMethod >> =

by Cyrille Delaunay

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

March 22, 2010

Re: [Pharo-project] GSoC next steps

by Geert Claes

Janko MivÅ¡ek wrote: > > Hi Geert, > >> Why a private discussion and/or voting? Isn't the whole point of GSoC to >> engage the entire Smalltalk community? > > Smalltalk GSoC Mentors mailing list is actually visible to others, just > that it is created in Slovenian and now I can't change the language. If > someone knows how... Here is the link: > > http://groups.google.si/group/smalltalk-gsoc-mentors > Just use .com instead of .si to see the group in English :) http://groups.google.com/group/smalltalk-gsoc-mentors Janko MivÅ¡ek wrote: > > Also, I think this list should stay semi-public and it is not for > inclusion on the Nabble. Just for interesting public therefore :) This > will then be a right balance between privacy of mentors and public > interest of community, IMO. > > Best regards > Janko > Are you sure about this semi-public thingy? :) -- View this message in context: http://n4.nabble.com/GSoC-next-steps-tp1676708p1677352.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 22, 2010

Re: [Pharo-project] GSoC next steps

by Janko MivÅ¡ek

Hi Geert, On 22. 03. 2010 09:04, Geert Claes wrote: > Mariano Martinez Peck wrote: >> >> I am not sure but I think it is a private mailing list where mentors will >> be able to discuss and vote. >> Anyway, I will ask Janko just in case I am wrong. > Why a private discussion and/or voting? Isn't the whole point of GSoC to > engage the entire Smalltalk community? Smalltalk GSoC Mentors mailing list is actually visible to others, just that it is created in Slovenian and now I can't change the language. If someone knows how... Here is the link: http://groups.google.si/group/smalltalk-gsoc-mentors Also, I think this list should stay semi-public and it is not for inclusion on the Nabble. Just for interesting public therefore :) This will then be a right balance between privacy of mentors and public interest of community, IMO. Best regards Janko

March 22, 2010

Re: [Pharo-project] Getting the website ready for 1.0

by Adrian Lienhard

>> If there is one-click images for Pharo, it might be easier for newbies. >> >> > There is, but experimental: > > look in https://gforge.inria.fr/frs/?group_id=1299 > "One-Click Experiments" > > Adrian offered him self also to do a new one for 1.0 Did I? I think that was Marcus :). But anyway, yes, we want to do 1-click images for the release. Adrian

March 22, 2010

Re: [Pharo-project] isInMemory :)

by Adrian Lienhard

On Mar 21, 2010, at 23:46 , Marcus Denker wrote: > > On Mar 21, 2010, at 11:18 PM, StÃ©phane Ducasse wrote: >>> >>> 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

March 22, 2010