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

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Dale Henrichs

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > Thanks Adrian. All your improvments are really cool. The only thing that I am > concerned is that if I change all my tests to this style, Squeak people won't > be able to run the tests :( because that method won't be understood. True enough, that applies to any new feature. We cannot have evolution and full compatibility at the same time. I will try to ensure that old tests keep running. But regarding new features there is no guarantees (unless someone backports my changes). --AA

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 12:17 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 28, 2009 at 11:19 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > >> Mariano Martinez Peck <marianopeck@...> writes: >> >> Assumptions are in the box! >> >> If you expect your test case to fail unless a given condition is met, you >> can >> now use assumptions to declare that. Gofer the latest akuhn/SUnit to get >> assumptions. >> >> For example, when your test case depends on the availability of a certain >> database you can write >> >> testBlob >> self assumeThat: Database default = DatabaseWithBlobs. >> ... >> >> if the assumption is true, the test case is run as a normal test case. If >> however the assumption is false, the test case is *not* run but still >> marked >> as passed. This is supposed to replace conditional #expectedFailures in >> the >> new SUnit. >> >> Typically, assumptions are put at the begin of a test case. However, you >> can >> put assumptions anywhere. The running tests case is aborted as soon as >> the >> first failing assumption is reached. >> >> PS regarding the naming: the message #assumeThat: has been preferred over >> a >> simple #assume: to make confusions with a simple #assert: less likely. >> >> > Thanks Adrian. All your improvments are really cool. The only thing that I > am concerned is that if I change all my tests to this style, Squeak people > won't be able to run the tests :( because that method won't be > understood. Anyway, I will si what can I do. > > Sorry I forgot to say that I just realized about that (because you asked me if it was ok and I said that yes). > Thank you very much for doing every day something better from SUnit!!! > > > --AA >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Dec. 28, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 11:19 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > Assumptions are in the box! > > If you expect your test case to fail unless a given condition is met, you > can > now use assumptions to declare that. Gofer the latest akuhn/SUnit to get > assumptions. > > For example, when your test case depends on the availability of a certain > database you can write > > testBlob > self assumeThat: Database default = DatabaseWithBlobs. > ... > > if the assumption is true, the test case is run as a normal test case. If > however the assumption is false, the test case is *not* run but still > marked > as passed. This is supposed to replace conditional #expectedFailures in > the > new SUnit. > > Typically, assumptions are put at the begin of a test case. However, you > can > put assumptions anywhere. The running tests case is aborted as soon as the > first failing assumption is reached. > > PS regarding the naming: the message #assumeThat: has been preferred over a > simple #assume: to make confusions with a simple #assert: less likely. > > Thanks Adrian. All your improvments are really cool. The only thing that I am concerned is that if I change all my tests to this style, Squeak people won't be able to run the tests :( because that method won't be understood. Anyway, I will si what can I do. Thank you very much for doing every day something better from SUnit!!! --AA > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 8:57 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > 2009/12/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Colin! I saw you were committing in the OmniBrowser tests. I am > > interested in loading these tests in Pharo (optionally). But I am not > sure > > which packages to include and their state. > > I spent quite some time to fix all Pharo related bugs in OB. > > Also I fixed all the tests that were broken in Pharo (only if O2 is not > loaded): > > 546 run, 546 passes, 0 failures, 0 errors > > This is really cool Lukas! > > Right now, in our Pharo images we are loading the following packages from > > http://source.wiresong.ca/ob > > AFAIK, the updated code from > http://source.lukas-renggli.ch/omnibrowser hasn't been merged into the > repository of Colin yet. I assume that will happen sometime soon. > > Colin: Right now we are building our official Pharo images using http://source.wiresong.ca/ob repository, not http://source.lukas-renggli.ch/omnibrowser Do you think that this can be merged ? > There are more related to the packages we are including? > > See OB-Umbrella, this loads all code in the right order. > > > should these test be all green? > > Definitely. OB has an excellent test suite. The only problem in the > past was that nobody that changed things run and updated these tests. > > 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. 28, 2009

[Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: Assumptions are in the box! If you expect your test case to fail unless a given condition is met, you can now use assumptions to declare that. Gofer the latest akuhn/SUnit to get assumptions. For example, when your test case depends on the availability of a certain database you can write testBlob self assumeThat: Database default = DatabaseWithBlobs. ... if the assumption is true, the test case is run as a normal test case. If however the assumption is false, the test case is *not* run but still marked as passed. This is supposed to replace conditional #expectedFailures in the new SUnit. Typically, assumptions are put at the begin of a test case. However, you can put assumptions anywhere. The running tests case is aborted as soon as the first failing assumption is reached. PS regarding the naming: the message #assumeThat: has been preferred over a simple #assume: to make confusions with a simple #assert: less likely. --AA

Dec. 28, 2009

[Pharo-project] New class factory for tests (and other use cases)

by Adrian Kuhn

`ClassFactoryForTestCase` is a awesome tool when you need to create throw-away classes for tests. And the new akuhn/SUnit includes a DSL that makes creating anonymous classes even simpler! The new DSL is put in a new class to avoid compatibility issues. To create an anonymous class just do class := ClassFactory newClass. this creates a new subclass of Object. The creates classes is automatically reclaimed by garbage collection when no longer used. That is, tear down of class factory is not required anymore. The class is created without logging and not registered with the system. That is, `Object subclasses` does not include the created class. To create a subclass of a specific class do class := ClassFactory newSubclass: Point. To create a subclass with accessors do class := ClassFactory newSubclass: Point with: [ :f | f compileAccessorsFor: 'color' ]. If you want getters or setters only, use `#compileSetterFor:` or `#compilerGetterFor:`. If you want an instance variable without accessor, use `#declareInstVar:`. To create a subclass with methods do class := ClassFactory newSubclass: Point with: [ :f | f compile: 'answer ^ 42' ]. NB: please note that class factory compiles silently without logging. To create a method on the class side do class := ClassFactory newSubclass: Point with: [ :f | f forClass: [ :cf | cf compile: 'somePoint ^ self x: 2 y: 3' ]]. In fact, the class side factory `cf` supports the same protocol as the instance side factory. Please note that creating instance variables on the class side creates "class instances variables" and not "instance class variables". That is, they are local to the creates class but not to subclasses of the created class. Typically this should not be a limitation since you only create one class without further subclasses. Also, please note that the created classes and all instances created from that class are ment to be thrown away after their use. The created class is not registered with the system, and thus when you change the instance size of its superclass the created instances will not be updated. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load --AA

Dec. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Adrian Kuhn

Lukas Renggli <renggli@...> writes: > Definitely. OB has an excellent test suite. The only problem in the past was > that nobody that changed things run and updated these tests. Good point. When I have a fix for OB under pharo. What is the preferred process. So far I posted them on the bug tracker, is that okay? --AA

Dec. 28, 2009

Re: [Pharo-project] External projects

by Schwab,Wilhelm K

Stef, I used http://gforge.inria.fr/frs/download.php/25122/pharo1.0-10502-rc1web09.12.2.… David is aware of the problems. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Monday, December 28, 2009 3:15 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] External projects > Stef, > > An easy one is to try: > > ScriptLoader > loadLatestPackage:'OSProcess' fromSqueaksource:'OSProcess'; > loadLatestPackage:'Tests-OSProcess' fromSqueaksource:'OSProcess'; > loadLatestPackage:'CommandShell' fromSqueaksource:'CommandShell'. in which version are you loading them? dev-rc1? I suggest you to publish a metacello configuration and also contact david lewis. May be the lastest version is not the one to be loaded. What I do in my code is that I never load the latest versions this way I control other changes when I'm ready to migrate. > For the full effect, leave deprecation warnings activated; even with these warnings disabled, you should be stopped after just enough time to really whack up an automated load. > > > Citezen turns out to be more interesting. The Wiki says to evaluate > > Installer ss project: 'Citezen'; install: 'Citezen-Loader'. > > 12.2 is missing Installer, which is no doubt in the name of progress. > A quick look at Gofer lead me to try > > Gofer new > squeaksource:'Citezen'; > package:'Citezen-Loader'; > load. I should fix the citezen loader.... > > This installs Installer :) Now have a look at #newForWin32; note > that it answers RioLocalDosExecutive, not RioLocalDosExecutive new. > The last time I tried such an image, I could not get it to load on > Windows until I loaded it on another platform, added the #new, and > then reloaded it. The poor folks stuck with Windows have enough to > worry about ;) > > I realize this is not Pharo's fault, but it is Pharo's problem, and hence **our** problem (aka Error 33). > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane > Ducasse [stephane.ducasse(a)inria.fr] > Sent: Monday, December 28, 2009 9:57 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] External projects > > I think that we should have a group of people controling integration. > > Stef > > >> Hello all, >> >> I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode. >> >> When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows. > > apparently this is not pharo's fault. > >> OS Process did not load cleanly. > > Bill what we are trying to with metacello is to have configuration of working packages. > >> Do we have a plan to fix such things? There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work. > > Yes > > Now can you report your problem is a way that we can reproduce them? > >> At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo. PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki?? In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users. >> >> Bill >> >> _______________________________________________ >> 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. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by StÃ©phane Ducasse

On Dec 28, 2009, at 9:10 PM, Lukas Renggli wrote: >>> There are more related to the packages we are including? >> >> No. Only the core bits of OB are tested. There aren't any tests for the refactoring code or Shout. > > The refactoring code is quite well tested with the tests of the > refactoring engine. The thing that is not tested is the RB integration > in OB: hounders of new commands and a couple of extra browsers. I am > sorry, I was too lazy to write these tests. I do not why :) Lukas the job that you are doing with RB is excellent! Thanks for that! Stef

Dec. 28, 2009