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

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Mariano Martinez Peck

Adrian: Can I still bother you with new requirements ? jajaja First of all, thank you very much for putting a context menu when you press "right button" over a failing or error test. I really hate when it was run again instead of opening a context menu. Now, I noticed that you open a menu with the options "History" "Store..." and "Show progress". I really love one item more called "browse it" and that opens a System Browser with that class, with that test method selected. What do you think? Cheers Mariano On Mon, Dec 28, 2009 at 12:25 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Dec 27, 2009 at 4:03 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > >> Cleanup of SUnit is almost done. There are 179 tests with 75% coverage. >> Missing >> are tests for the new resource setup and tests for the new history >> storage. >> >> Changes >> >> - uses announcements >> - new class factory DSL >> - does not print 'unexpected/expected' when empty >> - factored all assertions into TAssertable >> - copied Niall's 3-valued setup logic for test resources >> - new expectation matcher DSL >> - replaced history dictionary with proper class >> - keeps history as TestResult in memory >> - stores history as array in compiled methods >> - unexpected/expected linked with stored history >> - migrates #expectedDefects to stored history on the fly >> - bug fix: 'run failures/errors' updates history >> - bug fix: coverage is now able to cover itself >> - added flags for compatibility and deprecation >> - removed *a lot of* code duplication >> >> I tried to run *all* tests in the latest image with akuhn/SUnit and it >> seems >> to run fine. There are 5 failures and 2 errors (both with akuhn/SUnit and >> pharo/SUnit). The new test suite starts faster. You click and tests start >> running immediately! >> >> Progress: >> >> numClasses: 13 -> 19 >> numKLOC: 965 -> 1209 >> numMethods: 224 -> 291 >> numStatements: 3086 -> 3903 >> numTestCases: 51 -> 177 >> numTestKLOC: 591 -> 1200 >> numTestStatements: 2175 -> 4663 >> testCoverage: 61% -> 75% >> >> eventually, a SUnit with more test than production code! >> >> Give it a try and lemme know whether it runs with your tests. All your >> tests >> should still run. >> >> > This is great :) > > I run all my SqueakDBX and GlorpDBX tests and I have one only problem: > the expectedFailures are not working any more :( > > I put a halt are they are not even being called. > > All the rest seem to work (I have even test resources in both projects) > > Cheers > > Mariano > > > >> Gofer it >> disablePackageCache; >> squeaksource: 'akuhn'; >> package: 'SUnit'; >> package: 'SUnitGUI'; >> load >> >> cheers, >> AA >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Dec. 27, 2009

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Mariano Martinez Peck

On Sun, Dec 27, 2009 at 4:03 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Cleanup of SUnit is almost done. There are 179 tests with 75% coverage. > Missing > are tests for the new resource setup and tests for the new history > storage. > > Changes > > - uses announcements > - new class factory DSL > - does not print 'unexpected/expected' when empty > - factored all assertions into TAssertable > - copied Niall's 3-valued setup logic for test resources > - new expectation matcher DSL > - replaced history dictionary with proper class > - keeps history as TestResult in memory > - stores history as array in compiled methods > - unexpected/expected linked with stored history > - migrates #expectedDefects to stored history on the fly > - bug fix: 'run failures/errors' updates history > - bug fix: coverage is now able to cover itself > - added flags for compatibility and deprecation > - removed *a lot of* code duplication > > I tried to run *all* tests in the latest image with akuhn/SUnit and it > seems > to run fine. There are 5 failures and 2 errors (both with akuhn/SUnit and > pharo/SUnit). The new test suite starts faster. You click and tests start > running immediately! > > Progress: > > numClasses: 13 -> 19 > numKLOC: 965 -> 1209 > numMethods: 224 -> 291 > numStatements: 3086 -> 3903 > numTestCases: 51 -> 177 > numTestKLOC: 591 -> 1200 > numTestStatements: 2175 -> 4663 > testCoverage: 61% -> 75% > > eventually, a SUnit with more test than production code! > > Give it a try and lemme know whether it runs with your tests. All your > tests > should still run. > > This is great :) I run all my SqueakDBX and GlorpDBX tests and I have one only problem: the expectedFailures are not working any more :( I put a halt are they are not even being called. All the rest seem to work (I have even test resources in both projects) Cheers Mariano > Gofer it > disablePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load > > cheers, > AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 27, 2009

Re: [Pharo-project] about DependencyBrowser

by Mariano Martinez Peck

I have another idea to implement :) It would be really cool not only to see the dependencies of a XXX package but also, who depends on that package. Suppose I am evaluating the package RoelTyper I would like to know which dependencies I have (what you have already implemented) but also "who depends on RoelTyper" Cheers Mariano On Sat, Dec 26, 2009 at 11:58 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Sat, Dec 26, 2009 at 10:06 PM, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> Hi Mariano! >>> Nice to see you liked the Dependency Browser, let's clarify some >>> points about it then, >>> >>> 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> > Hi HernÃ¡n: First let me say that this tool is really great and useful. >>> It is >>> > helping me a lot to build the metacello configurations. Now, I have a >>> couple >>> > of questions: >>> > >>> > 1) What do the colors mean ? (red, orange, etc). I read here >>> > >>> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php >>> > but found nothing :( >>> >>> Colors were originally for idenfitying dependency types of external >>> packages, but the package infos names aren't normalized, E.g. >>> Normalized name = "Collections", Un-normalized name = >>> "Collections-Strings", hence you will see a lot of false external >>> packages colorized. >>> >>> Orange -> Dependecy of class reference of "external" package, or class >>> reference in un-normalized package name. >>> Brown -> Dependency of external package loose method, or loose method >>> in un-normalized package name. >>> Red -> Dependency of inheritance, or inheritance in un-normalized package >>> name. >>> Blue -> Dependency of a unsolved binding (like a class not present in >>> the image). >>> >> >> Thanks for the explanation. Now, as a good programmer you can reuse this >> explanation and put it in the website :) >> >> >>> >>> > >>> > 2) It would be EXCELLENT to be able to distinguish between PharoCore or >>> > exernal packages. Suppose you are building a tool or whatever, it would >>> be >>> > useful to know if it all what it is required is already on a PharoCore >>> or if >>> > it is external (it will require to install also another packages). >>> However, >>> > I am not sure how implement this :( >>> >>> Yes, it would be cool for a new package system to implement a protocol >>> for asking if a package is distributed originally in a release or not, >>> like: >>> >>> aPackage isOfficial >>> >>> With so many forks around, I found difficult to find a single way to >>> detect official packages installed in an image, and there should be an >>> easier solution than scanning though all package dates. Maybe this has >>> changed now? >>> >> >> I really don't know. Maybe we can send a separate thread asking about >> this. >> >> >> Hey! I have more questions :) >> >> 3) Please, take a Pharo dev image and you will see that the package >> OCForOB for example, only depends on OmniBrowser and OB-Standard (using >> dependency browser). However, that package also depends on OCompletion I >> think. Look for example the method >> >> OBTextPanel >> createCompletionController (category ocforob) >> >> and you will see that it uses the class OController which is from the >> package OCompletion....So, shouldn't be OCompletion a dependency ? >> >> 4) There are certain packages that are not listed in the dependency >> browser. Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them >> (maybe all) seem to have the pattern XXX-YYY. Do you know what can be the >> problem here? Maybe something related to what you told me about normalized >> and un-normalized? I would really like to see these packages also. >> >> > Even more: AST-Core, Refactoring-Core and Refactoring-Spelling > > :( > > >> 5) Why there are some packages that have their self as dependency ? For >> example, take OmniBrowser and you will see that has a dependency OmniBrowser >> also (as Inheritance and Reference). >> >> Thank you very much. >> >> Mariano >> >> >> >>> Kind regards, >>> >>> HernÃ¡n >>> >>> > >>> > Thank you very much. >>> > >>> > Mariano >>> > >>> >> >> >

Dec. 27, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Dale Henrichs

Gofer-dkh.105 or whichever later version predates the move of the instance variable would get Metacello back into a bootable form for all versions of Pharo. I agree that for 1.0 a stable version of Gofer be chosen ... I'm trying to restrict the current Metacello changes to avoid significant API changes, but every time Gofer moves out from under me, I'm forced into making fundamental changes. Dale ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | >> | | >> After proceeding these warnings, I have a rollback: MNU | >> | | >> GoferPackageReference class>>name:repository: | >> | | > | >> | | > Can you evaluate | >> | | > | >> | | > Â [ Gofer gofer load ] | >> | | > Â Â Â on: Error | >> | | > Â Â Â do: [ :err | err retry ]. | >> | | > Â Gofer gofer recompile. | >> | | > | >> | | > ? I don't have any senders of #name:repository: to | >> | | > GoferPackageReference. | | We can remove the deprecated warnings, but that will not solve the | real problem. Metacello is using some internal parts of Gofer that | had | to be changed to properly support fetch/push operations on multiple | repositories. | | People have to stick with an old version of Gofer/Monticello. That's | the same as with Pharo 1.1: Do not use the latest one. | | 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. 27, 2009

Re: [Pharo-project] Fwd: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use))

by David T. Lewis

FYI Marcus provided a solution to this problem back in 2006, see http://bugs.squeak.org/view.php?id=4369 (but the original author may be Klaus Witzel). So Marcus will understand the issue well :) Dave On Sun, Dec 27, 2009 at 09:20:20PM +0100, St?phane Ducasse wrote: > Thanks David. > I will look at the methodTrailer fixes soon. Now my knowledge is limited > in this area and I would prefer to have marcus have a look. > I will at least check the code and see if it looks ok. > > Stef > > On Dec 27, 2009, at 8:25 PM, David T. Lewis wrote: > > > Note, the change sets for this update are also on Mantis > > http://bugs.squeak.org/view.php?id=5205 > > along with discussion of other approaches to the problem. > > > > These changes are now in Squeak trunk. > > > > Dave > > > > On Sun, Dec 27, 2009 at 09:19:46PM +0200, Igor Stasenko wrote: > >> ---------- Forwarded message ---------- > >> From: David T. Lewis <lewis(a)mail.msen.com> > >> Date: 2009/12/27 > >> Subject: Re: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR > >> (Re: CompiledMethodTrailers ready for use)) > >> To: The general-purpose Squeak developers list > >> <squeak-dev(a)lists.squeakfoundation.org> > >> > >> > >> I have put the updates for large changes and sources files into the > >> inbox. I would appreciate if someone can review this before moving > >> into trunk. > >> > >> There are three mcz updates: > >> ??Files-dtl.62 > >> ??System-dtl.205 > >> ??Kernel-dtl.347 > >> > >> Important: The changes *must* be loaded in the order listed above. > >> This will require a configuration map update when the changes are > >> moved to trunk. > >> > >> The use of ExpandedSourceFileArray takes effect after the first > >> image restart. To change back to using the StandardSourceFileArray, > >> the procedure is as follows: > >> > >> ??1) Evaluate 'StandardSourceFileArray install' > >> ??2) Edit SourceFileArray class>>concreteClass to answer > >> ?? ??StandardSourceFileArray rather than ExpandedSourceFileArray. > >> > >> Thanks, > >> Dave > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > >> _______________________________________________ > >> 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. 27, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Dale Henrichs

Lukas, With Gofer-dkh.105, I was able to survive the upgrade from Gofer-lr.83 to Gofer-dkh.105. Gofer-lr.83 was the base version of Gofer used during bootstrapping. The change that broke the camel's back was removing the #version iv from GoferOperation. preGofer-dkh.105 there was no accessor for #version so direct access was required. postGofer-dkh.105 an accessor is required and the loader is used as part of the loading process and my subclass of the loader is there to smooth over the changes that have been made to the Gofer API over time - the code in Metacello needs to be able to run both before and after a new version of Gofer is installed. If we had true "atomic load" we'd be able to survive this set of changes, but without it I'm not sure what can be done other than using different bootstrapping code depending upon which version of Gofer is loaded ... which bangs into the other changes to the API that have been made since Gofer-lr.83. Gofer-lr.83 dates back to pharo1.0-10493 which is when Gofer started to be pre-loaded into the RC1 images. There appear to be versionNumber parsing errors in the older versions of Gofer, that prevent me from using Gofer to determine which package is loaded, so I may have to resort to direct Monticello access to detect the loaded package versions, either that or some kind of check as the the methods that are available in Gofer and infer the "version" of Gofer that is loaded ... Once I have my hands on the "version" of Gofer that is loaded, I can arrange to have the correctly compatible Metacello code loaded on top and we're off to the races. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | argh! | lukas is it possible to lower the pain of dale? | | Stef | | On Dec 27, 2009, at 10:27 PM, Dale Henrichs wrote: | | > The latest Gofer API is not backward compatible with the earlier | versions of the Gofer API. This means that I need to have different | versions of Metacello to use with the different versions of Gofer. | Unfortunately, I can't use Gofer to detect which version of Gofer is | loaded because of the API changes. So I will have to write more code | than I'd like to detect which version of Gofer is pre-installed. The | API changes also impact the bootstrapping code. | > | > Solving these problems are a larger project than I can undertake on | a Sunday and I _am_ on vacation the coming week as well. | > | > So until further notice, if you want to use Metacello 1.0-beta.17 | (or earlier) in Pharo you will have to manually ensure Gofer-lr.83 (or | earlier) is loaded into your image before attempting to load any | Metacello configurations. I'm not sure that you use Gofer to load an | earlier version of itself (I'll be finding out in the next few | days)... | > | > Metacello 1.0-beta.18 works with Gofer-lr.107 (in pharo 1.0-10502). | If you want to use Metacello 1.0-beta.18 (currently in development, so | it's subject to change). You will have to manually bootstrap Metacello | by executing: | > | > Gofer new | > gemsource: 'metacello'; | > package: 'ConfigurationOfMetacello'; | > load. | > (Smalltalk at: #ConfigurationOfMetacello) perform: | #ensureMetacello18. | > ((Smalltalk at: #ConfigurationOfMetacello) project version: | '1.0-beta.18') load: 'ALL'. | > | > before loading your configuration. | > | > I won't release 1.0-beta.18 until I've resolved the bootstrapping | problem. I'm pretty sure that there is a technical solution, but it | will take several days for me to get it implemented. | > | > Dale | > | > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | > | > | Version 1.0-beta.18 (development) should have fixes for the | latest | > | Gofer. 1.0-beta.18 is currently in #development so it is | automatically | > | loaded. When I get the chance to test the Metacello fixes with | 10502, | > | I'll #release 1.0-beta.18 (and will be automatically loaded). | > | | > | Dale | > | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | > | | > | | Hi Lukas, | > | | | > | | In a fresh 10502 I evaluated: | > | | -=-=-=-=-=-=-=-=-= | > | | [ Gofer gofer load ] | > | | on: Error | > | | do: [ :err | err retry ]. | > | | Gofer gofer recompile. | > | | Gofer new | > | | squeaksource: 'Mondrian'; | > | | addPackage: 'ConfigurationOfMondrian'; | > | | load. | > | | (Smalltalk at: #ConfigurationOfMondrian) perform: | #loadLastStable. | > | | -=-=-=-=-=-=-=-=-= | > | | | > | | I have the same error. | > | | The error comes from: | > | | | > | | -=-=-=-=-=-=-=-=-= | > | | MetacelloMCProject>>updateProject | > | | "load the latest version of the configuration package" | > | | | > | | | mcLoader | | > | | (mcLoader := self loader) == nil | > | | ifTrue: [ mcLoader := self project loaderClass on: nil ]. | > | | mcLoader doingLoads: [ | > | | | gofer | | > | | gofer := Gofer new. | > | | MCWorkingCopy | > | | managersForClass: self configuration class | > | | do: [:mgr | | > | | gofer add: (GoferPackageReference name: mgr packageName | > | | repository: mgr repositoryGroup) versionReference. | > | | Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' | ]. | > | | gofer load ]. | > | | ^true | > | | -=-=-=-=-=-=-=-=-= | > | | | > | | Cheers, | > | | Alexandre | > | | | > | | On 27 Dec 2009, at 17:27, Lukas Renggli wrote: | > | | | > | | >> After proceeding these warnings, I have a rollback: MNU | > | | >> GoferPackageReference class>>name:repository: | > | | > | > | | > Can you evaluate | > | | > | > | | > [ Gofer gofer load ] | > | | > on: Error | > | | > do: [ :err | err retry ]. | > | | > Gofer gofer recompile. | > | | > | > | | > ? I don't have any senders of #name:repository: to | > | | > GoferPackageReference. | > | | > | > | | > 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 | > | | > | > | | | > | | -- | > | | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | | Alexandre Bergel http://www.bergel.eu | > | | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | | | > | | | > | | | > | | | > | | | > | | | > | | _______________________________________________ | > | | 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. 27, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Lukas Renggli

>> | | >> After proceeding these warnings, I have a rollback: MNU >> | | >> GoferPackageReference class>>name:repository: >> | | > >> | | > Can you evaluate >> | | > >> | | > Â [ Gofer gofer load ] >> | | > Â Â Â on: Error >> | | > Â Â Â do: [ :err | err retry ]. >> | | > Â Gofer gofer recompile. >> | | > >> | | > ? I don't have any senders of #name:repository: to >> | | > GoferPackageReference. We can remove the deprecated warnings, but that will not solve the real problem. Metacello is using some internal parts of Gofer that had to be changed to properly support fetch/push operations on multiple repositories. People have to stick with an old version of Gofer/Monticello. That's the same as with Pharo 1.1: Do not use the latest one. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 27, 2009

Re: [Pharo-project] moose collection extensions

by Levente Uzonyi

On Sun, 27 Dec 2009, StÃ©phane Ducasse wrote: > hi > > here are the collection extensions we use in Moose. > I copied them to PharoTaskForces so that we can discuss and tweak the code if wanted. > I just checked these and most of them are useless misleading or duplicate, like: Collection >> #collectAsSet: -> #collect:as: (ok, it's new in pharo) #equalsTo: misleading name, #containsSameElementsAs: would be better IMO #(1 1 2) equalsTo: #(2 1 1) ===> true #flatCollect: -> #gather: #flatCollectAsSet: -> #gather: + #asSet #flatten -- misleading name, since it doesn't change the object, but returns a new array and it's only flattening one level which is what #gather: does. Tthere's a proper #flattened implementation in squeak treated inbox if you're interested. (guess why it's not in the trunk) #groupBy: -> #groupBy:having: #sum: -> #detectSum: Symbol >> #value (same as super) SequenceableCollection >> #shuffle -> #shuffled OrderedCollection >> #removeAtIndex: -> #removeAt: (-> means that the extension on the left is the same as or worse than the already existing method(s) on the right) I guess you should shrink this package. :) Levente

Dec. 27, 2009

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > > Gofer it > > disablePackageCache; > > squeaksource: 'akuhn'; > > package: 'SUnit'; > > package: 'SUnitGUI'; > > load > > Where is the update of Gofer that understand your > expression? See Lukas's mail. Alternatively use Gofer new "beware, might load wrong version from local cache with latest gofer!" squeaksource: 'akuhn'; addPackage: 'SUnit'; addPackage: 'SUnitGUI'; load the #disablePackageCache is only used to work around a glitch in the latest Gofer. (It attempts to load packages from the local cache that do *not* originate from akuhn. As it seems gofer always loads the package with the highest number independent of its origin. And keith's SUnit does have a higher version number than mine. You see the mess.) --AA

Dec. 27, 2009

Re: [Pharo-project] moose collection extensions

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > Adrian K. (you see we put your name in the comments :)). Humbled :) > Adrian I was wondering if we could have another / faster implementation that does not really on stream. You can, but you'll have to cover Array as a special case. And it probably won't be faster than with a stream (I donnu about Nile's implementation of #nextPutAll: though). --AA

Dec. 27, 2009