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

Re: [Pharo-project] Question about HostMenuSystem

by Michael Rueger

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

March 21, 2010

Re: [Pharo-project] Question about HostMenuSystem

by Mariano Martinez Peck

On Thu, Mar 18, 2010 at 11:55 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > On 3/18/10 3:38 PM, Mariano Martinez Peck wrote: > >> Hi folks. I want to remove HostMenuSystem from PharoCore image. >> Probably, I can put it on PharoDev image but of course, it will be >> accesible also from squeaksource to download it. I don't this is a >> "core" package. In order to do that, I found the following problem. >> >> Look to InputEventSensor >> processMenuEvent: evt >> > > You could also remove this code completely, including the call to > processMenuEvent: and then the HostMenuSystem could register its own input > event listener upon installation. See UserInterruptHandler for an example > how to do this. > > Hi Michael. Let me see if I understood. - In PharoCore I remove InputEventSensor >> processMenuEvent: and the invocation from ImputEventSensor >> processEvent: evt - In the package HostMenuSystem, I create a subclass of InputEventHandler (Suppose called HostMenuEventHandler). It is correct to subclass from this class ? - In HostMenuEventHandler I create the method handleEvent: that does the if type = EventTypeMenu and do everything - 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 ? Thanks a lot. Mariano > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2010

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

by Mariano Martinez Peck

On Sun, Mar 21, 2010 at 12:48 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi all, > > I've updated the website content, in particular the following pages, which > are linked from the welcome workspace: > > http://www.pharo-project.org/documentation/getting-started > http://www.pharo-project.org/documentation/tutorials-books > > If you have any suggestions to improve the website (e.g., for the FAQ), > please let me know! > > At some moment you will have also to include all the task done in 1.0 that is here: http://code.google.com/p/pharo/wiki/ActionsInPharoOne > Cheers, > Adrian > > BTW, I also updated the download links to the new Pharo RC3 image > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2010

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

by Mariano Martinez Peck

> > BTW, the changelog.txt says in the first line: > > Here is a list of packages included in this PharoCore1.0rc2 (#1 => Here > is a list of packages included in this PharoCore1.0rc3 (#1 > > the first rc2 should be rc3. > > Hi Miguel. Thanks for reporting. I need a diff guru ;) you are the one! The problem is that I am building the changelog with this: function buildChangeLog() { echo 'Please copy/past previous packages.txt and press CTRL+d' cat > old-packages.txt # Adds a new line at the end echo >> old-packages.txt diff --side-by-side --expand-tabs --suppress-common-lines \ --ignore-blank-lines --ignore-matching-lines='Pharo' --text \ old-packages.txt packages.txt \ | sed -e 's/ *| */ => /' > changelog.txt rm -f old-packages.txt } In this case, what I paste is the previous packages.txt which in this case they are something like this: Here is a list of packages included in this PharoCore1.0rc2 (#10508): AST-Core-lr.49 AST-Tests-lr.5 AutomaticMethodCategorizer-DF.25 AutomaticMethodCategorizerOB-DF.1 BogusInfo-lr.18 ConfigurationOfAutomaticMethodCategorizer-MarianoMartinezPeck.4 ConfigurationOfGofer-DaleHenrichs. ---------continues------- And then, packages.txt (the newone) is something like this: Here is a list of packages included in this Pharo-1.0-10515-rc3 (#10515): AST-Core-lr.66 AST-Tests-Core-lr.8 AutomaticMethodCategorizer-DF.25 AutomaticMethodCategorizerOB-DF.1 BogusInfo-lr.18 ConfigurationOfAutomaticMethodCategorizer-MarianoMartinezPeck.4 ConfigurationOfGofer-DaleHenrichs.9 --------continues------- So...the result of the diff is something like this: Here is a list of packages included in this PharoCore1.0rc2 (#1 => Here is a list of packages included in this Pharo-1.0-10515-rc3 AST-Core-lr.49 => AST-Core-lr.66 AST-Tests-lr.5 => AST-Tests-Core-lr.8 ----continues----- First, I don't know why "Here is a list of packages included in this PharoCore1.0rc2 (#1 " is cut, because actually the line is "Here is a list of packages included in this PharoCore1.0rc2 (#10508):" Second maybe I want to exclude the first line and. I mean, I want this: Here are the changes in this Pharo-1.0-10515-rc3 AST-Core-lr.49 => AST-Core-lr.66 AST-Tests-lr.5 => AST-Tests-Core-lr.8 ----continues----- Do you know how can I do both things? Thanks Mariano > Cheers > > Cheers, > > Adrian > > > > > > On Mar 21, 2010, at 14:01 , laurent laffont wrote: > > > > > Hi, > > > > > > "Get the Pharo By Example book" : on this page there's a lot > > more than Pharo > > > By Example. > > > > > > "Watch the Pharo Screencasts" points to > > > http://www.pharo-project.org/documentation/tutorials-books > > > > > > I think I'd rather delete the Getting Started page and put > > its content at > > > the top of the homepage, above Mission section. > > > > > > Cheers, > > > > > > Laurent Laffont > > > > > > > > > On Sun, Mar 21, 2010 at 12:48 PM, Adrian Lienhard > > <adi(a)netstyle.ch> wrote: > > > > > >> Hi all, > > >> > > >> I've updated the website content, in particular the > > following pages, which > > >> are linked from the welcome workspace: > > >> > > >> http://www.pharo-project.org/documentation/getting-started > > >> http://www.pharo-project.org/documentation/tutorials-books > > >> > > >> If you have any suggestions to improve the website (e.g., > > for the FAQ), > > >> please let me know! > > >> > > >> Cheers, > > >> Adrian > > >> > > >> BTW, I also updated the download links to the new Pharo RC3 > > image > > >> > > >> ___________________ > > >> http://www.adrian-lienhard.ch/ > > >> > > >> > > >> _______________________________________________ > > >> 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Marcus Denker

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. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2010

Re: [Pharo-project] isInMemory :)

by StÃ©phane Ducasse

Yes this was implied in my question to adrian. As soon as one query is not covered then you can bring everything back and since they were code that did not check isInMemory you could break everything in a finger snap. So I believe that they were following a specific and heavily restricted scenario and pray that nobody else calls the normal methods... somehow brittle. Stef On Mar 21, 2010, at 11:10 PM, Marcus Denker wrote: > > On Mar 21, 2010, at 10:59 PM, Marcus Denker wrote: >> >> -> 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 :-) >> > > of course, they realized that, too. Thus: #subclasses never checked for #isInMemory. > > But there where strangely names methods to iterate over all subclasses in memory (called #allSubclassesDoGently:). > > But Smalltalk>>#classNames foes check for #isInmemory. Which means you could have a case where a subclass would not be > in Smalltalk classNames... > > This is all fundamentally broken, sorry. > > 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

March 21, 2010

Re: [Pharo-project] isInMemory :)

by StÃ©phane Ducasse

On Mar 21, 2010, at 10:59 PM, Marcus Denker wrote: > > On Mar 21, 2010, at 10:51 PM, StÃ©phane Ducasse wrote: > >>>>> Well... it is needed for the swapping out of classes. If we remove #isInMemory, we should also remove the whole image segment stub mechanism because it becomes useless without the isInMemory protection. >> >> what I was thinking to remove is the use of isInMemory from SystemDictionary>>allClasses and friends. >> Now I do not get 100% what you are saying. >> Do you say that all the queries should be protected against bringing back classes on disc? > > 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. > > 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

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Marcus Denker

On Mar 21, 2010, at 10:59 PM, Marcus Denker wrote: > > -> 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 :-) > of course, they realized that, too. Thus: #subclasses never checked for #isInMemory. But there where strangely names methods to iterate over all subclasses in memory (called #allSubclassesDoGently:). But Smalltalk>>#classNames foes check for #isInmemory. Which means you could have a case where a subclass would not be in Smalltalk classNames... This is all fundamentally broken, sorry. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Marcus Denker

On Mar 21, 2010, at 10:51 PM, StÃ©phane Ducasse wrote: >>>> Well... it is needed for the swapping out of classes. If we remove #isInMemory, we should also remove the whole image segment stub mechanism because it becomes useless without the isInMemory protection. > > what I was thinking to remove is the use of isInMemory from SystemDictionary>>allClasses and friends. > Now I do not get 100% what you are saying. > Do you say that all the queries should be protected against bringing back classes on disc? 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 -> 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. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2010

Re: [Pharo-project] isInMemory :)

by StÃ©phane Ducasse

>>> Well... it is needed for the swapping out of classes. If we remove #isInMemory, we should also remove the whole image segment stub mechanism because it becomes useless without the isInMemory protection. what I was thinking to remove is the use of isInMemory from SystemDictionary>>allClasses and friends. Now I do not get 100% what you are saying. Do you say that all the queries should be protected against bringing back classes on disc? Stef >>> >> >> >> But was this ever working? Was this ever *used* the last 10 years? Are actually all cases covered? So are there enough #isInmemory checks to not end up with loading >> everything anyways? >> >> We already removed the *gently variants for iterating over subclasses, for example. or the "ifPresentAndInMemory" things.... > > Yes, I did some experiments with it lately and managed to create 4MB images. Cases which are not protected are indeed a problem. > >>> I would like to keep that working and extract it with the image segments code into an external package. How to do this cleanly is an interesting question, though... >>> >> >> I think we should ask the question: Do we intent to *use* this mechanism *at all* the next 5 years? > > Probably not. Nevertheless, I think its a nice idea but if it is not properly working the chances are small anybody will use. > > In any case, the question of how this *could* be factored out in a clean way is interesting if we want to further strip and modularize the image. It seems we are missing appropriate abstractions to modify from external packages behavior like the #isInMemory sends. Overrides are an unsatisfactory solution. So there is a limitation to the kind of code can be made external packages. > > > >> >> -- >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 21, 2010