October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about classVar

by StÃ©phane Ducasse

But you can access a classVar from a class method. So the Smalltalk MOP is quite strange and hackish. Stef > >> Hi >> >> to my stupefaction I discovered that the classVariables of a class >> are >> not the same as the ones of its metaclass. >> >> TheRoot classVarNames ~= TheRoot class classVarNames >> >> Does any body have some ideas why this is like that? > > Metaclasses don't have class variables > >> For me this is a conceptual bug. > > I think the conceptual bug is that TheRoot class classVarNames > does not raise a DNU > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 13, 2008

Re: [Pharo-project] [ANN] 10092

by StÃ©phane Ducasse

excellent! Stef On Oct 13, 2008, at 12:02 AM, Matthew Fulmer wrote: > On Sun, Oct 12, 2008 at 08:35:12PM +0200, St?phane Ducasse wrote: >>> - FullScreen refactoring by mike Roberts >>> - fixed a bug in PluggableListMorph>>basicKeyPress introduced in >>> 10087 by Matthew Fulmer >>> - improve SUnit history (removed PopUpMenu) >>> - Issue 235: 0007205: Monticello Snapshot Speedup via new >>> MethodReference ivar (http://bugs.squeak.org/view.php?id=7205) by >>> Matthew Fulmer >>> >>> >>> Stef >> >> Matthew could you sign the agreement? > > It's on its way. I mailed it yesterday. Should arrive in 6-10 > days > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 13, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Lukas Renggli

> > Dot suffixes are traditionally used for branches. We use them > > extensively in Seaside. > > I dont think you do, are you telling me that he package Seaside2.8a1 > has a branch called ".8a1" Yes, that's the 2.8 branch. Up to 2.8 every version had its own branch. There are smaller examples in the 2.9 repository. For example you have these 3 branches of the core package Seaside-Core: Seaside-Core-pmm.configcleanup.53.mcz, Seaside-Core-jf.cache.3.mcz, Seaside-Core-jf.painter.10.mcz. The first two have been merged at some point, the latter one has been dropp-. The original Monticello UI once grouped and sorted these branches nicely. Somebody broke that a long time ago. Another problem is that some people decided to use a dot within their initials, that 'breaks' it too ;-) Out of the 40 000 versions on SqueakSource there are almost 2 000 versions that use named branching (200 without Seaside). Furthermore, I know many commercial projects that use named branches as part of their development/release cycles. So it is certainly not some feature that you can just ignore when changing Monticello. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 13, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Keith Hodges

StÃ©phane Ducasse wrote: > Keith > > the problems with such approaches is that each of these nice little > extensions will break the > analysis tools we are developing. I would prefer a good and stable > solution > over everybody can hack its own. > I want some invariants on top of which we can build other tools. > > Stef That is entirely the point. When people roll their own, you end up with endless variations. (i.e. no stable situation) This at least attempts to capture and codify the use-cases that people have. Since PackageInfo is in charge of what is and is not in a package then your "tools" have to query package info anyway. Keith

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Keith Hodges

Lukas Renggli wrote: >> MC1.5+ Comes with a version of PackageInfo that has the notion of >> package types. Predefined package types that you can make use of through >> a simple dot suffix package name. >> > > Dot suffixes are traditionally used for branches. We use them > extensively in Seaside. > > Lukas > I dont think you do, are you telling me that he package Seaside2.8a1 has a branch called ".8a1" Keith

Oct. 12, 2008

Re: [Pharo-project] faster snapshotting

by Matthew Fulmer

On Sun, Oct 12, 2008 at 07:51:49PM +0200, St?phane Ducasse wrote: > Hi matthew > > I'm checking your > > http://code.google.com/p/pharo/issues/detail?id=235&colspec=ID%20Type%20Sta… > > "Adding the ivar 'category' to methodReference allows a 25% speedup in > Monticello snapshotting, after source caching. This capability is > exploited as of PackageInfo-Base-mtf.56" > > for 10092 now. > > http://code.google.com/p/pharo/issues/detail?id=235&colspec=ID%20Type%20Sta… > > Several questions > > - I do not know what you mean by PackageInfo-Base-mtf.56? > Where is it? > Is this package uses your setter method category:? It is in the Monticello public repository: http://www.squeaksource.com/mc Yes, that PackageInfo uses the setter. > - why the category and category: methods are not in the *monticello > extension? > (There were in *monticello in 10091) I moved them, since the category is no longer used by Monticello alone, but by both PackageInfo and by Monticello. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 12, 2008

Re: [Pharo-project] about classVar

by Matthew Fulmer

On Sun, Oct 12, 2008 at 10:10:38PM +0200, St?phane Ducasse wrote: > Hi > > to my stupefaction I discovered that the classVariables of a class are > not the same as the ones of its metaclass. > > TheRoot classVarNames ~= TheRoot class classVarNames > > Does any body have some ideas why this is like that? Metaclasses don't have class variables > For me this is a conceptual bug. I think the conceptual bug is that TheRoot class classVarNames does not raise a DNU -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 12, 2008

Re: [Pharo-project] [ANN] 10092

by Matthew Fulmer

On Sun, Oct 12, 2008 at 08:35:12PM +0200, St?phane Ducasse wrote: > > - FullScreen refactoring by mike Roberts > > - fixed a bug in PluggableListMorph>>basicKeyPress introduced in > > 10087 by Matthew Fulmer > > - improve SUnit history (removed PopUpMenu) > > - Issue 235: 0007205: Monticello Snapshot Speedup via new > > MethodReference ivar (http://bugs.squeak.org/view.php?id=7205) by > > Matthew Fulmer > > > > > > Stef > > Matthew could you sign the agreement? It's on its way. I mailed it yesterday. Should arrive in 6-10 days -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by Alexandre Bergel

Maybe, one easy step to make MC simpler, is to remove (sub)categories in packages. In that case, two packages, 'Moose' and 'Moose-Test' will be completely unrelated. Cheers, Alexandre On 12 Oct 2008, at 22:20, StÃ©phane Ducasse wrote: > Keith > > the problems with such approaches is that each of these nice little > extensions will break the > analysis tools we are developing. I would prefer a good and stable > solution > over everybody can hack its own. > I want some invariants on top of which we can build other tools. > > Stef > > On Oct 12, 2008, at 10:12 PM, Keith Hodges wrote: > >> StÃ©phane Ducasse wrote: >>> I lukas I see that you group together all the tests and I would >>> prefer >>> to have test associate with the package they test. >>> >>> stef >> Traditional PackageInfo users are expected to use the standard >> implementation or roll their own, for each package that needs a >> custom >> definition. >> >> MC1.5+ Comes with a version of PackageInfo that has the notion of >> package types. Predefined package types that you can make use of >> through >> a simple dot suffix package name. >> >> So Package developers can pick from a list of predetermined package >> types which should cover most existing use cases. For example, you >> could >> have different packaging of a package for different platforms, i.e. >> Seaside.squeak vs Seaside.vw Seaside.gs vs Seaside.dolphin >> >> Thus rolling your own package definition, is no longer intended for >> defining just one package, but rather a class of packages. >> >> Example: >> >> Monticello.impl (implementation) >> Monticello.test (tests) >> >> Are two such package names, which are automatically managed by >> subclasses of PackageInfo >> >> The PackageInfoImpl class excludes test categories, while the >> PackageInfoTests class includes them. >> >> ====== >> testCategoryMatches >> >> ^ #('*-Tests-*' '*-Tests') >> ====== >> >> This is so that your tests can live alongside your implementation, >> without cluttering up the images with Test categories at the top >> level. >> >> So if you want to manage the Tests together with the >> Implementation, add >> a package named 'Monticello', this will include all of the classes. >> If >> you want to publish the implementation only, then add a package named >> 'Monticello.impl' etc etc... >> >> Keith >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2008

Re: [Pharo-project] [MC] Adding a constraint when declaring a required package

by StÃ©phane Ducasse

Keith the problems with such approaches is that each of these nice little extensions will break the analysis tools we are developing. I would prefer a good and stable solution over everybody can hack its own. I want some invariants on top of which we can build other tools. Stef On Oct 12, 2008, at 10:12 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> I lukas I see that you group together all the tests and I would >> prefer >> to have test associate with the package they test. >> >> stef > Traditional PackageInfo users are expected to use the standard > implementation or roll their own, for each package that needs a custom > definition. > > MC1.5+ Comes with a version of PackageInfo that has the notion of > package types. Predefined package types that you can make use of > through > a simple dot suffix package name. > > So Package developers can pick from a list of predetermined package > types which should cover most existing use cases. For example, you > could > have different packaging of a package for different platforms, i.e. > Seaside.squeak vs Seaside.vw Seaside.gs vs Seaside.dolphin > > Thus rolling your own package definition, is no longer intended for > defining just one package, but rather a class of packages. > > Example: > > Monticello.impl (implementation) > Monticello.test (tests) > > Are two such package names, which are automatically managed by > subclasses of PackageInfo > > The PackageInfoImpl class excludes test categories, while the > PackageInfoTests class includes them. > > ====== > testCategoryMatches > > ^ #('*-Tests-*' '*-Tests') > ====== > > This is so that your tests can live alongside your implementation, > without cluttering up the images with Test categories at the top > level. > > So if you want to manage the Tests together with the Implementation, > add > a package named 'Monticello', this will include all of the classes. If > you want to publish the implementation only, then add a package named > 'Monticello.impl' etc etc... > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 12, 2008