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

Re: [Pharo-project] How to execute code before and after a package is load?

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > I **never** used scripts. I have no idea what they are (even if I guess) and > more important the door that they open into a space that we do not control is > dangerous. They are pre- and postload code snippets. If you add 4 missing methods on package info you get them in monticello (but sometimes they seem not to execute when loading a package, so I gave up at that point...) > In metacello there is a preload and postload if I remember. How do I use metacello, any documentation / tutorial available? cheers, AA

Dec. 29, 2009

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

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > class := ClassFactory newSubclass: Point with: [ :f | > f metaSide compile: 'somePoint ^ self x: 2 y: 3'. > f compile: '+ arg ^ self x + arg x ..... 3' ]. > ]. Looks nicer, gekauft :) --AA

Dec. 29, 2009

Re: [Pharo-project] How to execute code before and after a package is load?

by StÃ©phane Ducasse

On Dec 29, 2009, at 4:09 AM, Adrian Kuhn wrote: > It need to turn off system notifications for TestCase while gofer updates > SUnit. One way I see would be to execute some code snippet before and after > loading. However the Script button in Monticello seems to be broken. I cannot > add scripts to the package. I **never** used scripts. I have no idea what they are (even if I guess) and more important the door that they open into a space that we do not control is dangerous. (Imagine people publishing a hell of scripts with no tool and metamodel support for them). So please do not use them. Use the model with have, class, method, package. In metacello there is a preload and postload if I remember. May be Gofer should have a silent: #TestCase > What can I do? > > So the current way to load akuhn SUnit is > > [SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TestCase. > Gofer it > displabePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load ] ensure: [ TestCase initialize ]. > > which is well ... quite ugly for a Gofer script. > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

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

by StÃ©phane Ducasse

> 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' ]]. the forClass: is not really good to indicate class side. Then why all these blocks? Do we need a specific DSL (it looks to me that smalltalk got into dsl plague). why without the block is it not good: class := ClassFactory newSubclass: Point with: [ :f | f metaSide compile: 'somePoint ^ self x: 2 y: 3'. f compile: '+ arg ^ self x + arg x ..... 3' ]. ].

Dec. 29, 2009

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

by StÃ©phane Ducasse

yes expect: seems better. Stef On Dec 29, 2009, at 7:21 AM, Julian Fitzell wrote: > On Mon, Dec 28, 2009 at 2:19 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: >> For example, when your test case depends on the availability of a certain >> database you can write >> >> testBlob >> self assumeThat: Database default = DatabaseWithBlobs. >> ... >> > > Can I suggest simply #assume: ? The colon kind of has the same meaning > as "that" so it ends up redundant (would be the same with existing > methods: #assert(That): #deny(That):). > > Then, having said that, #assume: sounds a bit like the test should > assume the statement is true and then carry on running with that > assumption. Maybe #expect: would be more descriptive? Or > #precondition: ? Not sure... > > Julian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] Tests of OmniBrowser

by StÃ©phane Ducasse

Adrian you should send an email to lukas and david when you report a bug in OB or related Apparently the mail on code.google.com/p/pharo does not reach lukas when you add it to the form. Stef On Dec 28, 2009, at 10:37 PM, Adrian Kuhn wrote: > 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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Lukas Renggli

> 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? OB has its bug tracker at <http://code.google.com/p/omnibrowser/>. In the past people have been committing fixes to http://source.wiresong.ca/ob. The problem with this approach was that there is no control over what got integrated. People submitted changes to wrong packages, untested changes, changes that broke the tests, changes that broke the meta-model, or changes that simply broke some browsers. Then people merged random branches and it was not clear what to load, what worked and what didn't. I don't know what the take on this is from Colin? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 29, 2009

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

by Julian Fitzell

On Mon, Dec 28, 2009 at 2:19 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > For example, when your test case depends on the availability of a certain > Â database you can write > > Â Â testBlob > Â Â Â Â self assumeThat: Database default = DatabaseWithBlobs. > Â Â Â Â ... > Can I suggest simply #assume: ? The colon kind of has the same meaning as "that" so it ends up redundant (would be the same with existing methods: #assert(That): #deny(That):). Then, having said that, #assume: sounds a bit like the test should assume the statement is true and then carry on running with that assumption. Maybe #expect: would be more descriptive? Or #precondition: ? Not sure... Julian

Dec. 29, 2009

Re: [Pharo-project] How to execute code before and after a package is load?

by Alexandre Bergel

To obtain the after behavior, the classical way is to define an 'initialize' method on the class side of one your class. Cheers, Alexandre On 29 Dec 2009, at 04:09, Adrian Kuhn wrote: > It need to turn off system notifications for TestCase while gofer > updates > SUnit. One way I see would be to execute some code snippet before > and after > loading. However the Script button in Monticello seems to be broken. > I cannot > add scripts to the package. > > What can I do? > > So the current way to load akuhn SUnit is > > [SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > TestCase. > Gofer it > displabePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load ] ensure: [ TestCase initialize ]. > > which is well ... quite ugly for a Gofer script. > > --AA > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 29, 2009

[Pharo-project] How to execute code before and after a package is load?

by Adrian Kuhn

It need to turn off system notifications for TestCase while gofer updates SUnit. One way I see would be to execute some code snippet before and after loading. However the Script button in Monticello seems to be broken. I cannot add scripts to the package. What can I do? So the current way to load akuhn SUnit is [SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TestCase. Gofer it displabePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load ] ensure: [ TestCase initialize ]. which is well ... quite ugly for a Gofer script. --AA

Dec. 29, 2009