- Pharo-dev - lists.pharo.org

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

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

by Lukas Renggli

> 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 -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 12, 2008

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

by Keith Hodges

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

Oct. 12, 2008

[Pharo-project] about classVar

by StÃ©phane Ducasse

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? For me this is a conceptual bug. Stef

Oct. 12, 2008

[Pharo-project] Fwd: food for thoughts :)

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: October 12, 2008 9:29:18 PM CEDT > To: stephane.ducasse(a)free.fr > Subject: food for thoughts :) > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: October 12, 2008 9:29:16 PM CEDT > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: food for thoughts :) > > > http://producingoss.com/ > > p 129 > > At the Apache Software foundation we discourage the use of author > tags in source > code. There are various reasons for this, apart from the legal > ramifications. Collabor- > ative development is about working on projects as a group and caring > for the project > as a group. Giving credit is good, and should be done, but in a way > that does not al- > low for false attribution, even by implication. There is no clear > line for when to add or > remove an author tag. Do you add your name when you change a > comment? When > you put in a one-line fix? Do you remove other author tags when you > refactor the code > and it looks 95% different? What do you do about people who go about > touching every > file, changing just enough to make the virtual author tag quota, so > that their name will > be everywhere? > > There are better ways to give credit, and our preference is to use > those. From a tech- > nical standpoint author tags are unnecessary; if you wish to find > out who wrote a par- > ticular piece of code, the version control system can be consulted > to figure that out. > Author tags also tend to get out of date. Do you really wish to be > contacted in private > about a piece of code you wrote five years ago and were glad to have > forgotten? > > > >

Oct. 12, 2008

Re: [Pharo-project] Pharo Harvesting Infrastructure

by StÃ©phane Ducasse

> I'm rather curious now about how you manage Pharo. I took a look > at http://code.google.com/p/pharo/wiki/HowToContribute and > wondered what happens after that. I now imagine it involves > ScriptBuilder building the update, and then something uploading > it. What is the mechanism? ok so the scriptloader is our friend since early days of 3.9. It is basically a set of functionality which can load a description of packages. two methods are generated - scriptXXX contains the list of packages - update100XX contains now a description code to load the list cleanups We did not use mcm because it did not work for us at that time. We have sometimes the need to load sequentially packages and not all at the same time. > How is Pharo tested? is it regularly tested by someone using > TestRunner, or something fancier? For now there is not automated regression mechahnism Laurent Laffont and Alexandre Bergel are working on a test server. > What are all the auto-generated methods in ScriptLoader for? to be able to go back in the past. we can always know all the packages of a given image. Even if sometimes we cannot take 3.9readyForPharo and simply press the button to reproduce the image. This is due that some changes should be done via cs and produces dirty packages that in the past could not be reloaded. Like MVC having broken initialize method and also due to the fact that atomic loading was not working (we will get there when we will finally use MC1.6 - but you know that we will not do it at the price of bringing code we do not like, but we are making progress on that :). > How do you typically trace a bug from image to problem package > to update to issue? Manually. It sucks! > I'm interested because keith and I are building a build server > that is able to build images, build packages, load packages, run > tests, build VM's and such, all automated and with an easy > interface. So far, we have the easy interface (Installer), but > are still working on making it do more. I know, I discussed about with keith long time ago and I like what he is doing. Now again we will review and give feedback. Bob is important, Installer too. > So I'm interested in learning how it works here, so that we can > at least end up with something as good as this Scriptloader is not good, it is what we made for making progress. As soon as we have something better we throw it away. Believe me this mainly my code :) > > > -- > 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. 12, 2008

[Pharo-project] [ANN] 10093

by StÃ©phane Ducasse

- Network fix by Yann Monclair Modified the deprecation comment on Url>>#toText. It was recommending using Url>>#asText instead, but that would mean the method would return a Text instead of a String as it currently does. I replaced the deprecation comment to recommend replacing #toText with #asString. All NetworkTests run green - Fix by A. Bergel. The method PasteUpMorph>>findAPreferencesPanel: is now an extension of MorphicExtras. Before it was part of Mophic- Worlds. The reason to move findAPreferencesPanel: to MorphicExtras is the method references PreferencesPanel, which is defined in MorphicExtras. PasteUpMorph calls findAPreferencesPanel: within PasteUpMorph>>defaultDesktopCommandKeyTriplets. The cycle is therefore not completely removed. However, defaultDesktopCommandKeyTriplets should be turned into a registration mechanism to completely remove the cycle. - allUnSentMessages -> allUnsentMessages, removeAllUnSentMessages -> removeAllUnsentMessages, allUnSentMessagesIn: -> allUnsentMessagesIn: Stopping for this evening :) Stef

Oct. 12, 2008