July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

> Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ? :-) synchronous. http://code.google.com/p/pharo/issues/detail?id=2721 SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.1 in PharoInbox I quickly wrote this. I haven't used it yet. Cheers, Alexandre > > On 29 Jul 2010, at 11:08, laurent laffont wrote: > > > Hi, > > > > Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf > > > > and replace: > > > > counter := AutotestHitCounter on: changedMethod. <- this wraps the method > > [aTestResult := runner run: testMethods] > > ensure: [counter uninstall]. > > aTestResult hitCount: counter hitCount. > > > > by > > > > aTestResult := runner run: testMethods > > > > > > to check that the problem is here. > > > > > > I haven't tried Cog yet. Is it working out of the box ? > > > > > > > > Laurent > > > > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > Ah, indeed! I forgot ... sorry for the noise :) > > > > Cheers, > > Doru > > > > > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > > > Hi, > > > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? > > > > Cheers, > > Doru > > > > > > If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. > > > > Cheers, > > Henry > > > > > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > > > Indeed I also want to log for each test: > > - min / max / mean execution time > > - time to first failure > > - % of errors/failures/success > > - run count > > > > That would be cool > > > > so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? > > (Another way is to modify TestResult / TestCase, but it's more intrusive). > > > > Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > www.tudorgirba.com > > > > "One cannot do more than one can do." > > > > > > > > > > > > _______________________________________________ > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2010

Re: [Pharo-project] Request for test

by Mariano Martinez Peck

same here. On Thu, Jul 29, 2010 at 3:42 PM, Max Leske <maxleske(a)gmail.com> wrote: > mac os 10.6.4: Icon is grey with a blue triangle in it, app runs without > problems. System language is english, app language was also english. > > Cheers, > Max > > > On 29.07.2010, at 15:38, Hilaire Fernandes wrote: > > > Dear all, > > > > I am preparing a DrGeo release. > > > > I will be very please if Windows and Mac user could test it for me > please. > > > > I need to know if the application icon is looking like a triangle and if > > DrGeo UI is in French for the French users. > > > > Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip > > > > Thanks > > > > Hilaire > > > > > > _______________________________________________ > > 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 >

July 29, 2010

Re: [Pharo-project] Request for test

by Max Leske

mac os 10.6.4: Icon is grey with a blue triangle in it, app runs without problems. System language is english, app language was also english. Cheers, Max On 29.07.2010, at 15:38, Hilaire Fernandes wrote: > Dear all, > > I am preparing a DrGeo release. > > I will be very please if Windows and Mac user could test it for me please. > > I need to know if the application icon is looking like a triangle and if > DrGeo UI is in French for the French users. > > Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip > > Thanks > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 29, 2010

[Pharo-project] Request for test

by Hilaire Fernandes

Dear all, I am preparing a DrGeo release. I will be very please if Windows and Mac user could test it for me please. I need to know if the application icon is looking like a triangle and if DrGeo UI is in French for the French users. Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip Thanks Hilaire

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

I also agree with Janko idea. Image required changes where integrated in PharoCore 1.2. We can start soon to build Dev images using that core, and, most importantly, build a one click with Cog. Now the problem is.. 1) where to get the latest code from both, SVN and VMMaker. 2) Compile and generate binaries for each platform Who can help us with this? The only binary I saw was the one Lukas did for Mac OS but I guess it should be updated with latests fixes? Cheers Mariano On Thu, Jul 29, 2010 at 3:15 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > This is very good advice. > > Dave > > On Thu, Jul 29, 2010 at 11:15:41AM +0200, Janko Miv??ek wrote: > > Hi guys, > > > > I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: > > > > - encourage Cog usage and discovering all bugs and side effects, which > > will: > > - let the Cog become production ready more quickly, but it: > > - won't mislead people to consider Cog as production ready, because > > such unintential misleading can put Cog unfairly in a bad light. > > > > Best regards > > Janko > > > > On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > > > Hi folks. Hope Eliot is reading this thread. > > > > > > It is time to think in Pharo 1.2 and we need to discuss if we want to > > > have CogVM as the standard Pharo VM. > > > > > > Most of us have tried it and found it incredible fast. So it would be > > > very good to take advantage of it. But I think there are a couple of > > > things to be discussed: > > > > > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot > quotes: > > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > > > > > No effort has been made to maintain 64-bit compatibility. Apologies, > > > this was unaffordable." > > > > > > So...how much important is this for us? do we care? and if we want to > do > > > it, is it "doable" ? is it less doable than the normal squeak VM ? > > > > > > I really would like to have 64bits VM + 64bits images in a near > > > future...but hat's just my thoguhts. > > > > > > 2) The status of the external plugins. Are they working with Cog ? Not > > > only the "core plugings" but FFI, OSProcess (I read some problems with > > > it), TrueType, etc... > > > > > > 3) Is it stable for production use? For example, I read that with > > > seaside there are some crashes. > > > > > > 4) Depends on heroes. I never liked this idea. It has nothing to do > with > > > Eliot. He is very cool and helpful. But I wonder, do we understand the > > > new VM and the changes? are we able to handle and fix it even without > > > eliot ? > > > > > > 5) Integration to VMMaker. I saw that they started to merge cog > > > (actually, I think only stack vm?) to the trunk of VMMaker. This is > > > really good news. I hope everything is there and merged. > > > > > > 6) Binaries. It seems the official released didn't come with binaries. > > > So we should compile it for each OS. > > > > > > > > > Ok..that's all my thoughts. I would really like to have a discussion > > > here and see what to do.....grrrrrr you are all in holidays, aren't > you? > > > hahah > > > > > > cheers > > > > > > Mariano > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Janko Miv??ek > > Svetovalec za informatiko > > Eranova d.o.o. > > Ljubljana, Slovenija > > www.eranova.si > > tel: 01 514 22 55 > > faks: 01 514 22 56 > > gsm: 031 674 565 > > > > _______________________________________________ > > 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 >

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by David T. Lewis

This is very good advice. Dave On Thu, Jul 29, 2010 at 11:15:41AM +0200, Janko Miv??ek wrote: > Hi guys, > > I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: > > - encourage Cog usage and discovering all bugs and side effects, which > will: > - let the Cog become production ready more quickly, but it: > - won't mislead people to consider Cog as production ready, because > such unintential misleading can put Cog unfairly in a bad light. > > Best regards > Janko > > On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > > Hi folks. Hope Eliot is reading this thread. > > > > It is time to think in Pharo 1.2 and we need to discuss if we want to > > have CogVM as the standard Pharo VM. > > > > Most of us have tried it and found it incredible fast. So it would be > > very good to take advantage of it. But I think there are a couple of > > things to be discussed: > > > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > > > No effort has been made to maintain 64-bit compatibility. Apologies, > > this was unaffordable." > > > > So...how much important is this for us? do we care? and if we want to do > > it, is it "doable" ? is it less doable than the normal squeak VM ? > > > > I really would like to have 64bits VM + 64bits images in a near > > future...but hat's just my thoguhts. > > > > 2) The status of the external plugins. Are they working with Cog ? Not > > only the "core plugings" but FFI, OSProcess (I read some problems with > > it), TrueType, etc... > > > > 3) Is it stable for production use? For example, I read that with > > seaside there are some crashes. > > > > 4) Depends on heroes. I never liked this idea. It has nothing to do with > > Eliot. He is very cool and helpful. But I wonder, do we understand the > > new VM and the changes? are we able to handle and fix it even without > > eliot ? > > > > 5) Integration to VMMaker. I saw that they started to merge cog > > (actually, I think only stack vm?) to the trunk of VMMaker. This is > > really good news. I hope everything is there and merged. > > > > 6) Binaries. It seems the official released didn't come with binaries. > > So we should compile it for each OS. > > > > > > Ok..that's all my thoughts. I would really like to have a discussion > > here and see what to do.....grrrrrr you are all in holidays, aren't you? > > hahah > > > > cheers > > > > Mariano > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Janko Miv??ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

On Thu, Jul 29, 2010 at 11:24 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote > Laurent, > > I have similar needs. I would like to extend SUnit before and after each > test method. I was wondering about this: > > - Introduce a registration mechanism in SUnit (a bit like OB commands) > - TestResult>>runCase: aTestCase can be enhanced by executing what has been > registered before and after > - A class TestCommand contains a method #before and #after. TestCommand > define inst var #currentTestCase #currentTestMethod > > Advantages: > - minor addition to SUnit > > > We could then refactor the SUnit history to use a command. > It would then be easy to have a logger or something. > > Does it make sense? > Yes, it doesn't seem hard to implement. Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ? Laurent > > cheers, > Alexandre > > On 29 Jul 2010, at 11:08, laurent laffont wrote: > > > Hi, > > > > Autotest use a wrapper to count hits on changed method. Take a look at > Autotest>>#findRunAndShowTestsOf > > > > and replace: > > > > counter := AutotestHitCounter on: changedMethod. <- this wraps the > method > > [aTestResult := runner run: testMethods] > > ensure: [counter uninstall]. > > aTestResult hitCount: counter hitCount. > > > > by > > > > aTestResult := runner run: testMethods > > > > > > to check that the problem is here. > > > > > > I haven't tried Cog yet. Is it working out of the box ? > > > > > > > > Laurent > > > > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > Ah, indeed! I forgot ... sorry for the noise :) > > > > Cheers, > > Doru > > > > > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > > > Hi, > > > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why > that happen? > > > > Cheers, > > Doru > > > > > > If he went for using MethodWrappers as described below, it will crash on > Cog, as it does not support objects as methods yet. > > > > Cheers, > > Henry > > > > > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > > > Indeed I also want to log for each test: > > - min / max / mean execution time > > - time to first failure > > - % of errors/failures/success > > - run count > > > > That would be cool > > > > so with these datas we know long tests. I think about wrapping run test > methods with an object which then can collect these datas. Would you go this > way ? > > (Another way is to modify TestResult / TestCase, but it's more > intrusive). > > > > Over the last few month I intensively used method wrapper (a.k.a object > as compiled method). Time to time, the image just freezes or crashes. Maybe > due to the garbage collector. Modifying SUnit should not be that complex. It > would be nice to turn SUnit into something more extensible. One shoot two > targets. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > www.tudorgirba.com > > > > "One cannot do more than one can do." > > > > > > > > > > > > _______________________________________________ > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

[Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

Laurent, I have similar needs. I would like to extend SUnit before and after each test method. I was wondering about this: - Introduce a registration mechanism in SUnit (a bit like OB commands) - TestResult>>runCase: aTestCase can be enhanced by executing what has been registered before and after - A class TestCommand contains a method #before and #after. TestCommand define inst var #currentTestCase #currentTestMethod Advantages: - minor addition to SUnit We could then refactor the SUnit history to use a command. It would then be easy to have a logger or something. Does it make sense? cheers, Alexandre On 29 Jul 2010, at 11:08, laurent laffont wrote: > Hi, > > Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf > > and replace: > > counter := AutotestHitCounter on: changedMethod. <- this wraps the method > [aTestResult := runner run: testMethods] > ensure: [counter uninstall]. > aTestResult hitCount: counter hitCount. > > by > > aTestResult := runner run: testMethods > > > to check that the problem is here. > > > I haven't tried Cog yet. Is it working out of the box ? > > > > Laurent > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Ah, indeed! I forgot ... sorry for the noise :) > > Cheers, > Doru > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > Hi, > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? > > Cheers, > Doru > > > If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. > > Cheers, > Henry > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > Indeed I also want to log for each test: > - min / max / mean execution time > - time to first failure > - % of errors/failures/success > - run count > > That would be cool > > so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? > (Another way is to modify TestResult / TestCase, but it's more intrusive). > > Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Janko MivÅ¡ek

Hi guys, I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: - encourage Cog usage and discovering all bugs and side effects, which will: - let the Cog become production ready more quickly, but it: - won't mislead people to consider Cog as production ready, because such unintential misleading can put Cog unfairly in a bad light. Best regards Janko On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > Hi folks. Hope Eliot is reading this thread. > > It is time to think in Pharo 1.2 and we need to discuss if we want to > have CogVM as the standard Pharo VM. > > Most of us have tried it and found it incredible fast. So it would be > very good to take advantage of it. But I think there are a couple of > things to be discussed: > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > "The Cog VM is a just-in-time compiler that currently supports only x86 > > No effort has been made to maintain 64-bit compatibility. Apologies, > this was unaffordable." > > So...how much important is this for us? do we care? and if we want to do > it, is it "doable" ? is it less doable than the normal squeak VM ? > > I really would like to have 64bits VM + 64bits images in a near > future...but hat's just my thoguhts. > > 2) The status of the external plugins. Are they working with Cog ? Not > only the "core plugings" but FFI, OSProcess (I read some problems with > it), TrueType, etc... > > 3) Is it stable for production use? For example, I read that with > seaside there are some crashes. > > 4) Depends on heroes. I never liked this idea. It has nothing to do with > Eliot. He is very cool and helpful. But I wonder, do we understand the > new VM and the changes? are we able to handle and fix it even without > eliot ? > > 5) Integration to VMMaker. I saw that they started to merge cog > (actually, I think only stack vm?) to the trunk of VMMaker. This is > really good news. I hope everything is there and merged. > > 6) Binaries. It seems the official released didn't come with binaries. > So we should compile it for each OS. > > > Ok..that's all my thoughts. I would really like to have a discussion > here and see what to do.....grrrrrr you are all in holidays, aren't you? > hahah > > cheers > > Mariano > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

July 29, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by laurent laffont

Hi, Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf and replace: counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount. by aTestResult := runner run: testMethods to check that the problem is here. I haven't tried Cog yet. Is it working out of the box ? Laurent On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Ah, indeed! I forgot ... sorry for the noise :) > > Cheers, > Doru > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: >> >> Hi, >>> >>> It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why >>> that happen? >>> >>> Cheers, >>> Doru >>> >> >> >> If he went for using MethodWrappers as described below, it will crash on >> Cog, as it does not support objects as methods yet. >> >> Cheers, >> Henry >> >> >>> >>> On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: >>> >>> Indeed I also want to log for each test: >>>>> - min / max / mean execution time >>>>> - time to first failure >>>>> - % of errors/failures/success >>>>> - run count >>>>> >>>> >>>> That would be cool >>>> >>>> so with these datas we know long tests. I think about wrapping run test >>>>> methods with an object which then can collect these datas. Would you go this >>>>> way ? >>>>> (Another way is to modify TestResult / TestCase, but it's more >>>>> intrusive). >>>>> >>>> >>>> Over the last few month I intensively used method wrapper (a.k.a object >>>> as compiled method). Time to time, the image just freezes or crashes. Maybe >>>> due to the garbage collector. Modifying SUnit should not be that complex. It >>>> would be nice to turn SUnit into something more extensible. One shoot two >>>> targets. >>>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010