- Pharo-dev - lists.pharo.org

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

by Miguel Enrique CobÃ¡ Martinez

El dom, 21-03-2010 a las 23:47 +0100, Mariano Martinez Peck escribiÃ³: > > > 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? We can work out this script if necessary but, I think, it is really necessary? What about new packages or packages deleted respect to the old release? Also, the it isn't reliable, check the lines: ProfStef-LaurentLaffont.14 => ProfStef-Core-LaurentLaffont.2 Refactoring-Core-lr.101 => ProfStef-Tests-LaurentLaffont.2 Refactoring-Spelling-lr.18 => Refactoring-Core-lr.115 Refactoring-Tests-lr.31 => Refactoring-Spelling-lr.19 I think that this part should be abandoned and at least for now, no changelog released (:) is the first version there isn't anything to compare with in fact). For the 1.1 release, we'll add the changelog, respect to 1.0. So I vote for the easy solution, nuke this part. Or put a new file with the text of the workspace, because for many people, after closing the initial workspace they won't know how to open it again. So instead of a changelog, create a new README file and put that. Cheers :)

March 22, 2010

Re: [Pharo-project] Question about HostMenuSystem

by Mariano Martinez Peck

Thanks Michael. Now I have another question. In the latests PharoCore 1.1 I cannot see the VM menu. I only see the options "Squeak VM" and "Edit". But the HostMenuSystem was only removed in Pharo 1.0 with the ifPresent: in processMenuEvent: In 1.1 that method is correct. Then....I don't understand why I don't see the VM menus like Tools, Debug, etc. Should I see them ? Adrian any idea ? Maybe there is a problem with the Smalltalk startUpList ? I know it has been changed in previous updates. Cheers Mariano On Mon, Mar 22, 2010 at 12:19 AM, Michael Rueger <m.rueger(a)acm.org> 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 21, 2010

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