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

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

[Pharo-project] [ANN] 10092

by StÃ©phane Ducasse

> - 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? Stef

Oct. 12, 2008

Re: [Pharo-project] DependencyBrowser

by bryce＠kampjes.demon.co.uk

Alexandre Bergel writes: > You should continue to produce your dev image. > I have seen a lot of people using it. Really. I'm using the dev image. Both for pharo and Squeak 3.10. Bryce

Oct. 12, 2008

Re: [Pharo-project] faster snapshotting

by StÃ©phane Ducasse

> 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:? > > - why the category and category: methods are not in the *monticello > extension? > (There were in *monticello in 10091) > > - When I categorized them in *monticello I got problems or my > network is really gettiong slow. I checked and rebooted my network. Now it looks like going much faster. > > > Stef > > _______________________________________________ > 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] faster snapshotting

by StÃ©phane Ducasse

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:? - why the category and category: methods are not in the *monticello extension? (There were in *monticello in 10091) - When I categorized them in *monticello I got problems or my network is really gettiong slow. Stef

Oct. 12, 2008