December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Does OCompletion depend on ECompletion?

by Mariano Martinez Peck

On Sat, Dec 26, 2009 at 7:12 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I cannot answer your questions, but you could use Package-Dependencies > from http://source.lukas-renggli.ch/packaging (it used to be in > /unsorted, but I now created a new repository) to explain you all > details of dependencies of packages. We use the tools in there to > build the Seaside distributions and to detect errors in dependencies. > > Thanks Lukas for the point! I know there is also the dependency walker. But I just asked because it is probably that the mainteiner/developer known the answer and maybe in 5' he can asnwer me :) I will give a shoot with this two tools. CHeers Mariano > Lukas > > 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Sorry, I have much more questions about OCompletion: > > > > 0) (mail before) OCompletion depend on ECompletion? If true, which > packages > > ? > > > > 1) Does the package OCForOB depend on OCompletion ? > > > > 2) Does the package OCForO2 depend on OCompletion or in OCForOB or in > both ? > > > > 3) Can we put the tests that are in the category "Ocompletion-Tests" > under > > the package "OCompletion" in a SEPARATE package called > "Ocompletion-Tests" > > (the same as the category if you want). > > > > 4) Which packages does OCForOB depend on from OB? Just OmniBrowser or > more? > > Which ones? > > > > 5) Which packages does OCForO2 depend on from EnhancedOB? Just > OmniBrowser2 > > or more? Which ones? > > > > 6) Does OCompletions depend of Shout ? If true, what packages? > > > > Sorry for the amount of questions but I need this information in order to > > create the metacello configurations. > > > > Thanks > > > > Mariano > > > > > > On Sat, Dec 26, 2009 at 6:00 PM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> I thought that yes, but in my dev image I have OCompletion but not > >> ECompletion. Can someone clarify me this ? > >> > >> Thanks > >> > >> Mariano > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 26, 2009

Re: [Pharo-project] Does OCompletion depend on ECompletion?

by Lukas Renggli

I cannot answer your questions, but you could use Package-Dependencies from http://source.lukas-renggli.ch/packaging (it used to be in /unsorted, but I now created a new repository) to explain you all details of dependencies of packages. We use the tools in there to build the Seaside distributions and to detect errors in dependencies. Lukas 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Sorry, I have much more questions about OCompletion: > > 0) (mail before)Â OCompletion depend on ECompletion? If true, which packages > ? > > 1) Does the package OCForOB depend on OCompletion ? > > 2) Does the package OCForO2 depend on OCompletion or in OCForOB or in both ? > > 3) Can we put the tests that are in the category "Ocompletion-Tests" under > the package "OCompletion" in a SEPARATE package called "Ocompletion-Tests" > (the same as the category if you want). > > 4) Which packages does OCForOB depend on from OB? Just OmniBrowser or more? > Which ones? > > 5) Which packages does OCForO2 depend on from EnhancedOB? Just OmniBrowser2 > or more? Which ones? > > 6) Does OCompletions depend of Shout ? If true, what packages? > > Sorry for the amount of questions but I need this information in order to > create the metacello configurations. > > Thanks > > Mariano > > > On Sat, Dec 26, 2009 at 6:00 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> I thought that yes, but in my dev image I have OCompletion but not >> ECompletion. Can someone clarify me this ? >> >> Thanks >> >> Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 26, 2009

Re: [Pharo-project] Does OCompletion depend on ECompletion?

by Mariano Martinez Peck

Sorry, I have much more questions about OCompletion: 0) (mail before) OCompletion depend on ECompletion? If true, which packages ? 1) Does the package OCForOB depend on OCompletion ? 2) Does the package OCForO2 depend on OCompletion or in OCForOB or in both ? 3) Can we put the tests that are in the category "Ocompletion-Tests" under the package "OCompletion" in a SEPARATE package called "Ocompletion-Tests" (the same as the category if you want). 4) Which packages does OCForOB depend on from OB? Just OmniBrowser or more? Which ones? 5) Which packages does OCForO2 depend on from EnhancedOB? Just OmniBrowser2 or more? Which ones? 6) Does OCompletions depend of Shout ? If true, what packages? Sorry for the amount of questions but I need this information in order to create the metacello configurations. Thanks Mariano On Sat, Dec 26, 2009 at 6:00 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I thought that yes, but in my dev image I have OCompletion but not > ECompletion. Can someone clarify me this ? > > Thanks > > Mariano >

Dec. 26, 2009

Re: [Pharo-project] Refactoring Browser depenences

by Lukas Renggli

AFAIK, RoelTyper is not a hard dependency, but if loaded eCompletion provides better results. Don't have a computer to check right now. Lukas On Saturday, December 26, 2009, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Dec 18, 2009 at 6:31 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Exactly, > >> Refactoring-Spelling depends on Refactoring-Core >> Refactoring-Core depends on AST-Core > > AST-Core doesn't depend on anything. > >> There are more ?Â and dependences with external packages? > > No more dependencies. > > However, this configuration is hardly any useful, because there is no > user-interface, this is just the model of the refactoring engine. To > get the UI tools consider loading these packages with the following > dependencies: > > Â Â OB-Refactory --> Refactoring-Core, OB-Standard > Â Â OB-Regex --> Refactoring-Core, OB-Standard > Â Â OB-Shout --> OB-Morphic > Â Â OB-SUnitIntegration --> OmniBrowser > Â Â OB-Standard --> OmniBrowser > Â Â OB-Morphic --> OmniBrowser > Â Â OmniBrowser --> (none) > Â Â ECompletionOmniBrowser --> ECompletion > Â Â ECompletion --> Shout > > > Lukas, the ECompletion wiki says "Requires the packages RoelTyper and Shout 4" . Is this still true ? Or as you said it now only requieres Shout (no RoelTyper) ? > > Thanks > > Mariano > Â Â Â ShoutWorkspace --> Shout > > > Â Â Shout --> (none) > > HTH, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 26, 2009

Re: [Pharo-project] Refactoring Browser depenences

by Mariano Martinez Peck

On Fri, Dec 18, 2009 at 6:31 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Exactly, > > > Refactoring-Spelling depends on Refactoring-Core > > Refactoring-Core depends on AST-Core > > AST-Core doesn't depend on anything. > > > There are more ? and dependences with external packages? > > No more dependencies. > > However, this configuration is hardly any useful, because there is no > user-interface, this is just the model of the refactoring engine. To > get the UI tools consider loading these packages with the following > dependencies: > > OB-Refactory --> Refactoring-Core, OB-Standard > OB-Regex --> Refactoring-Core, OB-Standard > OB-Shout --> OB-Morphic > OB-SUnitIntegration --> OmniBrowser > OB-Standard --> OmniBrowser > OB-Morphic --> OmniBrowser > OmniBrowser --> (none) > ECompletionOmniBrowser --> ECompletion > ECompletion --> Shout > Lukas, the ECompletion wiki says "Requires the packages RoelTyper and Shout 4" . Is this still true ? Or as you said it now only requieres Shout (no RoelTyper) ? Thanks Mariano > ShoutWorkspace --> Shout > > Shout --> (none) > > HTH, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 26, 2009

[Pharo-project] Does OCompletion depend on ECompletion?

by Mariano Martinez Peck

I thought that yes, but in my dev image I have OCompletion but not ECompletion. Can someone clarify me this ? Thanks Mariano

Dec. 26, 2009

Re: [Pharo-project] [update 1.1] #11115

by Michael Roberts

That stuff is horrible. Good luck! Mike On Saturday, December 26, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok I see. So if you can sort that out. Excellent. > > RIght now I'm fighting with expanding "mousse" to fix some cold air problem.... > No debugger so far. :) > > Stef > > On Dec 26, 2009, at 10:20 AM, Michael Roberts wrote: > >> Ok, I take your point but I had given system version the ability to >> write out the image name. Â Now it doesn't have enough information or >> we need this special case. This is with a view to automatic building. >> Anyway it is not important at the moment. We can solve it later. >> >> Mike >> >> On Friday, December 25, 2009, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> we can keep alpha for us and just have the name of the image tagged UNSTABLE >>> because else we may have to change the update list and so on. >>> So I would not do more than I did because we can spend good energy on something else. >>> >>> Stef >>> On Dec 25, 2009, at 8:53 PM, Michael Roberts wrote: >>> >>>> re: #1624 >>>> >>>> you need to do this ;-) >>>> >>>> SystemVersion current suffix: 'UNSTABLE' >>>> >>>> thanks, >>>> Mike >>>> >>>> On Fri, Dec 25, 2009 at 10:50 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> 11115 >>>>> ----- >>>>> >>>>> Issue 1683: Â Â From The Trunk: minor improvement of MethodDictionary>>includesKey: >>>>> Â Â Â Â N. Cellier and Traits :) >>>>> Issue 1664: Â Â Long method can not be compiled using #compile: aString >>>>> Issue 1158: Â Â System Browser vs Class Browser tx David R. >>>>> Issue 1624: Â Â 1.1#alpha should be renamed to 1.1#unstable >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 26, 2009

Re: [Pharo-project] [update 1.1] #11115

by StÃ©phane Ducasse

Ok I see. So if you can sort that out. Excellent. RIght now I'm fighting with expanding "mousse" to fix some cold air problem.... No debugger so far. :) Stef On Dec 26, 2009, at 10:20 AM, Michael Roberts wrote: > Ok, I take your point but I had given system version the ability to > write out the image name. Now it doesn't have enough information or > we need this special case. This is with a view to automatic building. > Anyway it is not important at the moment. We can solve it later. > > Mike > > On Friday, December 25, 2009, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> we can keep alpha for us and just have the name of the image tagged UNSTABLE >> because else we may have to change the update list and so on. >> So I would not do more than I did because we can spend good energy on something else. >> >> Stef >> On Dec 25, 2009, at 8:53 PM, Michael Roberts wrote: >> >>> re: #1624 >>> >>> you need to do this ;-) >>> >>> SystemVersion current suffix: 'UNSTABLE' >>> >>> thanks, >>> Mike >>> >>> On Fri, Dec 25, 2009 at 10:50 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> 11115 >>>> ----- >>>> >>>> Issue 1683: From The Trunk: minor improvement of MethodDictionary>>includesKey: >>>> N. Cellier and Traits :) >>>> Issue 1664: Long method can not be compiled using #compile: aString >>>> Issue 1158: System Browser vs Class Browser tx David R. >>>> Issue 1624: 1.1#alpha should be renamed to 1.1#unstable >>>> _______________________________________________ >>>> 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

Dec. 26, 2009

Re: [Pharo-project] Point name Point class name are not both symbol

by Adrian Lienhard

Maybe you've also run into the problem with the symbol table that had very bad performance characteristics: http://code.google.com/p/pharo/issues/detail?id=1047 It was fixed in Pharo last summer. Adrian On Dec 25, 2009, at 22:45 , Adrian Kuhn wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> I was wondering if it would make sense to have >> Point name >> Point class name >> both returning a symbol and not in one case a symbol and the other a >> string. > > To my understanding, the role of a symbol is to be a speed-optimized > identifier > (of either a class or method) and #'Point class' is not an > identifier but an > expression which does not evaluate faster when being a symbol. > > Also creating too many symbols might harm system performance. I > learned that > the hard way with Moose, it used to use symbols everywhere and > eventually it > would take 10 seconds to open autocompletion. So I am always > reluctant to make > too many symbols. > > --AA > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 26, 2009

Re: [Pharo-project] [update 1.1] #11115

by Michael Roberts

Ok, I take your point but I had given system version the ability to write out the image name. Now it doesn't have enough information or we need this special case. This is with a view to automatic building. Anyway it is not important at the moment. We can solve it later. Mike On Friday, December 25, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > we can keep alpha for us and just have the name of the image tagged UNSTABLE > because else we may have to change the update list and so on. > So I would not do more than I did because we can spend good energy on something else. > > Stef > On Dec 25, 2009, at 8:53 PM, Michael Roberts wrote: > >> re: #1624 >> >> you need to do this ;-) >> >> SystemVersion current suffix: 'UNSTABLE' >> >> thanks, >> Mike >> >> On Fri, Dec 25, 2009 at 10:50 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> 11115 >>> ----- >>> >>> Issue 1683: Â Â From The Trunk: minor improvement of MethodDictionary>>includesKey: >>> Â Â Â Â N. Cellier and Traits :) >>> Issue 1664: Â Â Long method can not be compiled using #compile: aString >>> Issue 1158: Â Â System Browser vs Class Browser tx David R. >>> Issue 1624: Â Â 1.1#alpha should be renamed to 1.1#unstable >>> _______________________________________________ >>> 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 >

Dec. 26, 2009