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

[Pharo-project] feedback on HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading

by StÃ©phane Ducasse

I would really like to get some feddback on that issue http://code.google.com/p/pharo/issues/detail?id=1152 Issue 1152: HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by StÃ©phane Ducasse

bill load the slice of nicolas and let us know. I integrated in 1.1 and adrian will probably integrate it in 1.0 Stef On Nov 5, 2009, at 8:22 PM, Schwab,Wilhelm K wrote: > > Stef, > > The classes in CommandShell-Piping would be better separated from > CommandShell. That said, I do not terribly much care about loading > CommandShell to get pipes - I care a lot that it won't load w/o > proceeding past two warnings followed by a debug/edit/proceed > cycle. I have no idea whether it is a true fix or not, but I > commented out the offending line and re-saved the package, only to > find that it loads w/o hassles. If it really is that simple, the > repository should be fixed. > > Re Metacello, I looked around for information, found a lot of future > tense writing that looked interesting, and went back to cleaning up > my recreation of Migrate for Pharo. The result is not as flashy as > Migrate, but it adds the search for unpackaged code that I wrote > (something I have never found missing in Dolphin given its IDE) and > it seems to simplify saving all packages of interest. > > I will keep an eye on Metacello, but I do not really need it at the > moment. Of greater concern to me is that I am dead in the water on > RC1. The SharedQueue2 bug stops me cold every time I try to build > an image, and strikes in a way that will not allow me to debug it by > normal means. Do we have a procedure for reverting to SharedQueue? > That might at least get me going. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Thursday, November 05, 2009 1:42 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Error handling failure during load > > > On Nov 3, 2009, at 5:17 PM, Schwab,Wilhelm K wrote: > >> Hello all, >> >> I am gradually approaching a working load "script," but I just hit a >> new wrinkle in RC1: at some point in the process I get offered an >> emergency evaluator, which appears unable to open. There is mention >> of looking for something in the system dictionary, and something >> about >> "system error handling failed." Nothing is logged, and the image is >> helpless at that point. Any ideas for how to debug it? >> >> Creating my own build log comes to mind; the idea would be to open/ >> update/close each time it starts work on a new package. I can also >> load the loader into a clean older image and see what happens. >> >> It would be _really_ nice to have a clean-loading version of OS >> Process/Command Shell. Actually, I do not need the shell at all, but >> I do need the pipeable processes. > > damien told today that it would be nice that some CommandShell class > such as (I do not remember) StdOut/SdtIn could be packaged with > OSProcess and not with CommandShell. Or that they are separated > because people want to get them but not need the CommandShell. > > Now bill did you got a look at Metacello? > Because I'm sure it can help to maintain your packaged code. > > Stef > > > >> >> 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

Nov. 5, 2009

[Pharo-project] [update 1.1] #11033

by StÃ©phane Ducasse

11033 ----- - Issue 1408: SharedQueue2 doesNotUnderstand: #flushAllSuchThat: - Issue 1412: obsolete references - Issue 1384: TransparentColor instance return false when #isSelfEvaluating is called

Nov. 5, 2009

Re: [Pharo-project] Fwd: nice bug with regex

by Nicolas Cellier

2009/11/5 Lukas Renggli <renggli(a)gmail.com>: > 2009/11/5 Lukas Renggli <renggli(a)gmail.com>: >> I don't know, I did not write the code. I trust it, because it passes >> the test suite of Henry Spencer's regexp.c package. >> >> Lukas >> >> >> 2009/11/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> This version does not seem to solve http://bugs.squeak.org/view.php?id=5391 >>> >>> { >>> '15' matchesRegex: '[1-9]|1[0-9]'. >>> '15' matchesRegex: '1[0-9]|[1-9]'. >>> } #(false true) > > I am not saying that this bug is not worth too look at and to fix. I > am just no expert in regular expressions and I don't know what the > desired behavior is? And why? Still looking for a standard that > describes the semantics of regular expressions. > man 7 regex used to be a good start, but it seems quite short on my current distrib of linux... The documentation tells it is POSIX, googleing shouldn't take long... > I think everybody agrees that the updated code is an improvement, even > if it does not fix all problems. No? > > Lukas > Oh yes, of course, thank you ! It was just the occasion to remind the bug to any potential fixer. > >>> >>> >>> 2009/11/4 Lukas Renggli <renggli(a)gmail.com>: >>>> I committed VB-Regex-lr.34 to the PharoInbox that fixes this issue. >>>> >>>> In fact, this is a completely new port of VB-Regex with numerous >>>> bug-fixes and enhancements. The bug you found was fixed in version >>>> 1.1c in December 2004. The version 1.1 we used up to now was from >>>> October 1999. >>>> >>>> The detailed log of changes from Vassily you can see below. >>>> >>>> Cheers, >>>> Lukas >>>> >>>> Name: VB-Regex-lr.34 >>>> Author: lr >>>> Time: 4 November 2009, 10:40:27 pm >>>> UUID: 9254d5aa-3e22-4e3b-83aa-2d633ff05570 >>>> Ancestors: VB-Regex-StephaneDucasse.33 >>>> >>>> VERSION 1.2.3 (November 2007) >>>> >>>> 1. Regexs with ^ or $ applied to copy empty strings caused infinite >>>> loops, e.g. ('' copyWithRegex: '^.*$' matchesReplacedWith: 'foo'). >>>> Applied a similar correction to that from version 1.1c, to >>>> #copyStream:to:(replacingMatchesWith:|translatingMatchesUsing:). >>>> 2. Extended RxParser testing to run each test for >>>> #copy:translatingMatchesUsing: as well as #search:. >>>> 3. Corrected #testSuite test that a dot does not match a null, which >>>> was passing by luck with Smalltalk code in a literal array. >>>> 4. Added test to end of test suite for fix 1 above. >>>> >>>> VERSION 1.2.2 (November 2006) >>>> >>>> There was no way to specify a backslash in a character set. Now [\\] >>>> is accepted. >>>> >>>> VERSION 1.2.1 Â (August 2006) >>>> >>>> 1. Support for returning all ranges (startIndex to: stopIndex) >>>> matching a regex - #allRangesOfRegexMatches:, #matchingRangesIn: >>>> 2. Added hint to usage documentation on how to get more information >>>> about matches when enumerating >>>> 3. Syntax description of dot corrected: matches anything but NUL since 1.1a >>>> >>>> VERSION 1.2 Â Â (May 2006) >>>> >>>> Fixed case-insensitive search for character sets. >>>> >>>> VERSION 1.1c Â Â (December 2004) >>>> >>>> Fixed the issue with #matchesOnStream:do: which caused infinite loops >>>> for matches >>>> that matched empty strings. >>>> >>>> VERSION 1.1b Â Â (November 2001) >>>> >>>> Changes valueNowOrOnUnwindDo: to ensure:, plus incorporates some earlier fixes. >>>> >>>> VERSION 1.1a Â Â (May 2001) >>>> >>>> 1. Support for keeping track of multiple subexpressions. >>>> 2. Dot (.) matches anything but NUL character, as it should per POSIX spec. >>>> 3. Some bug fixes. >>>> >>>> >>>> >>>> 2009/11/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> l := '1Ã¨re partie\nmilieu\nfin'. >>>>>> '.*' asRegex matchesIn l. >>>>> >>>>> -> infinite and freezing loop. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > 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 >

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by Dale Henrichs

Bill, Have you looked at http://code.google.com/p/metacello? I don't think there's a lot of future tense writing there:). Dale ----- "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> wrote: | Stef, | | The classes in CommandShell-Piping would be better separated from | CommandShell. That said, I do not terribly much care about loading | CommandShell to get pipes - I care a lot that it won't load w/o | proceeding past two warnings followed by a debug/edit/proceed cycle. | I have no idea whether it is a true fix or not, but I commented out | the offending line and re-saved the package, only to find that it | loads w/o hassles. If it really is that simple, the repository should | be fixed. | | Re Metacello, I looked around for information, found a lot of future | tense writing that looked interesting, and went back to cleaning up my | recreation of Migrate for Pharo. The result is not as flashy as | Migrate, but it adds the search for unpackaged code that I wrote | (something I have never found missing in Dolphin given its IDE) and it | seems to simplify saving all packages of interest. | | I will keep an eye on Metacello, but I do not really need it at the | moment. Of greater concern to me is that I am dead in the water on | RC1. The SharedQueue2 bug stops me cold every time I try to build an | image, and strikes in a way that will not allow me to debug it by | normal means. Do we have a procedure for reverting to SharedQueue? | That might at least get me going. | | 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: Thursday, November 05, 2009 1:42 PM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] Error handling failure during load | | | On Nov 3, 2009, at 5:17 PM, Schwab,Wilhelm K wrote: | | > Hello all, | > | > I am gradually approaching a working load "script," but I just hit a | | > new wrinkle in RC1: at some point in the process I get offered an | > emergency evaluator, which appears unable to open. There is mention | | > of looking for something in the system dictionary, and something | about | > "system error handling failed." Nothing is logged, and the image is | | > helpless at that point. Any ideas for how to debug it? | > | > Creating my own build log comes to mind; the idea would be to open/ | | > update/close each time it starts work on a new package. I can also | | > load the loader into a clean older image and see what happens. | > | > It would be _really_ nice to have a clean-loading version of OS | > Process/Command Shell. Actually, I do not need the shell at all, | but | > I do need the pipeable processes. | | damien told today that it would be nice that some CommandShell class | such as (I do not remember) StdOut/SdtIn could be packaged with | OSProcess and not with CommandShell. Or that they are separated | because people want to get them but not need the CommandShell. | | Now bill did you got a look at Metacello? | Because I'm sure it can help to maintain your packaged code. | | Stef | | | | > | > 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

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by Schwab,Wilhelm K

Stef, The classes in CommandShell-Piping would be better separated from CommandShell. That said, I do not terribly much care about loading CommandShell to get pipes - I care a lot that it won't load w/o proceeding past two warnings followed by a debug/edit/proceed cycle. I have no idea whether it is a true fix or not, but I commented out the offending line and re-saved the package, only to find that it loads w/o hassles. If it really is that simple, the repository should be fixed. Re Metacello, I looked around for information, found a lot of future tense writing that looked interesting, and went back to cleaning up my recreation of Migrate for Pharo. The result is not as flashy as Migrate, but it adds the search for unpackaged code that I wrote (something I have never found missing in Dolphin given its IDE) and it seems to simplify saving all packages of interest. I will keep an eye on Metacello, but I do not really need it at the moment. Of greater concern to me is that I am dead in the water on RC1. The SharedQueue2 bug stops me cold every time I try to build an image, and strikes in a way that will not allow me to debug it by normal means. Do we have a procedure for reverting to SharedQueue? That might at least get me going. 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: Thursday, November 05, 2009 1:42 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Error handling failure during load On Nov 3, 2009, at 5:17 PM, Schwab,Wilhelm K wrote: > Hello all, > > I am gradually approaching a working load "script," but I just hit a > new wrinkle in RC1: at some point in the process I get offered an > emergency evaluator, which appears unable to open. There is mention > of looking for something in the system dictionary, and something about > "system error handling failed." Nothing is logged, and the image is > helpless at that point. Any ideas for how to debug it? > > Creating my own build log comes to mind; the idea would be to open/ > update/close each time it starts work on a new package. I can also > load the loader into a clean older image and see what happens. > > It would be _really_ nice to have a clean-loading version of OS > Process/Command Shell. Actually, I do not need the shell at all, but > I do need the pipeable processes. damien told today that it would be nice that some CommandShell class such as (I do not remember) StdOut/SdtIn could be packaged with OSProcess and not with CommandShell. Or that they are separated because people want to get them but not need the CommandShell. Now bill did you got a look at Metacello? Because I'm sure it can help to maintain your packaged code. Stef > > 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

Nov. 5, 2009

Re: [Pharo-project] RC1 image build failure

by StÃ©phane Ducasse

On Nov 4, 2009, at 1:55 AM, Schwab,Wilhelm K wrote: > Nicolas, > > I doubt the images are corrupt, unless the download is somehow > damaged. we never know. So we should hunt that. > #findElementOrNil: works; the problem is more likely that the > missing protocol in SharedSet2 lead to an unrecoverable meltdown. > My question is how it worked as long as it did??? > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > Sent: Tuesday, November 03, 2009 7:28 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] RC1 image build failure > > 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> Whatever is happening, it keeps happening, and on two different >> machines, but both Ubuntu 9.10, FWIW. Attached is a shot of the >> whatever-it's-called window; the promised emergency evaluator does >> not appear (not that I would know what to do with it<g>). >> Comparing SharedQueue with SharedQueue2 might be interesting; with >> luck, there will simply be a missing method?? >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > 1) Yeah, SharedQueue2 does not share same public protocol and that > sounds like a bug... > > (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e > | (SharedQueue organization categoryOfElement: e) beginsWith: > 'private']. > -> an IdentitySet(#flushAllSuchThat: #nextOrNilSuchThat: #flush) > > We might also wanter to filter out unsent ones: > (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e > | ((SharedQueue organization categoryOfElement: e) beginsWith: > 'private') or: [(SystemNavigation default allCallsOn: e) isEmpty]] > > > 2) I find it strange your Smalltalk doesNotUnderstand: > #findElementOrNil: > > Did you load some changes related to FasterSets or is your image > damned corrupted ? > Try (Smalltalk findElementOrNil: #Object) and tell us the result. > > Nicolas > > _______________________________________________ > 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

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by StÃ©phane Ducasse

On Nov 3, 2009, at 5:17 PM, Schwab,Wilhelm K wrote: > Hello all, > > I am gradually approaching a working load "script," but I just hit a > new wrinkle in RC1: at some point in the process I get offered an > emergency evaluator, which appears unable to open. There is mention > of looking for something in the system dictionary, and something > about "system error handling failed." Nothing is logged, and the > image is helpless at that point. Any ideas for how to debug it? > > Creating my own build log comes to mind; the idea would be to open/ > update/close each time it starts work on a new package. I can also > load the loader into a clean older image and see what happens. > > It would be _really_ nice to have a clean-loading version of OS > Process/Command Shell. Actually, I do not need the shell at all, > but I do need the pipeable processes. damien told today that it would be nice that some CommandShell class such as (I do not remember) StdOut/SdtIn could be packaged with OSProcess and not with CommandShell. Or that they are separated because people want to get them but not need the CommandShell. Now bill did you got a look at Metacello? Because I'm sure it can help to maintain your packaged code. Stef > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2009

Re: [Pharo-project] Shadowed Variables

by Igor Stasenko

2009/11/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this is good that you can do that. > Now this is a not so good habit for readibility. > Well, with the presence of traits, i don't see how we could avoid that nicely. We could exclude the trait methods from shadowing checking, since traits don't see ivars anyway. And classvars shadowing global, i think is a nice feature rather than bug :) > Stef > > > >> 2009/11/4 Lukas Renggli <renggli(a)gmail.com>: >>> It shows up in the transcript for all users of the trait when the >>> method is accepted. This is nasty, because that introduces ugly >>> dependencies. >>> >>> Of course we might want to relax the semantics of Smalltalk and allow >>> shadowing of variables, so that class variables could shadow globals; >>> instance variables could shadow super instance variables, class >>> variables, and globals; temp variables could shadow outer temp >>> variables, instance variables, class variables, and globals, etc. >>> >>> I thought Python allowed this kind of shadowing? Don't remember if >>> this was cool or not, but it sounds quite bit messy. >>> >> not only Python. >> Most languages i used to know, allowing a local-scope names to shadow >> an outer scope names without any warnings and bashing the user. >> Some IDEs could warn about such things, but not compiler. >> >>> Lukas >>> >>> >>> 2009/11/4 Â <csrabak(a)bol.com.br>: >>>> Em 04/11/2009 17:53, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com >>>> > escreveu: >>>> >>>> Right. Â However, shouldn't the message about shadowing be issued >>>> when >>>> we accept the method in the browser? >>>> >>>> >>>>> Â ??? Â Â Â Â Â Â Just Â Â Â Â Â looking Â Â Â Â Â the >>>>> first >>>>> ArrayTest>>#testCopyReplaceAllWith1Occurence, Â it has Â a Â temp >>>>> named >>>>> result and an inst var named result >>>>> >>>>> Â 2009/11/4 Lukas Renggli : >>>>>> First I thought this is Â because temps in trait methods shadow the >>>>>> inst-vars of Â the classes Â that use these Â traits (ouch!), Â but it >>>>>> doesn't seem to be the case. Â I don't understand either why we get >>>>>> these messages. >>>>>> Lukas >>>>>> 2009/11/4 StÃ©phane Ducasse : >>>>>>> Strange this is related to traits? >>>>>>> Stef >>>>>>> On Nov 4, 2009, at 5:17 PM, Lukas Renggli wrote: >>>>>>> >>>>>>>> When I recompile a Pharo image >>>>>>>> Compiler recompileAll >>>>>>>> I get 819 messages Â complaining about shadowed variables, mostly >>>>>>>> but not only in the new collection tests. Does anybody knows why >>>>>>>> this happens? >>>>>>>> Lukas >>>> [819 messages snipped] >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 5, 2009

Re: [Pharo-project] Author = TestRunner

by Mariano Martinez Peck

On Sat, Oct 31, 2009 at 7:20 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > It happens for instance if you click one of the failing tests after > intially running tests, then fix the bug in the debugger that pops up. > (i.e., you're comitting changes while the test is being run). > > Ok....I have just faced this problem too. I looked at the code but I don't know how to fix it. Anyway, why should tests use a particular Author ? I ask just because of ignorance. Is it because of this http://code.google.com/p/pharo/issues/detail?id=1327 ? The only solution I see is an ugly hack that when you click on the "save" button of the MC browser, if the Author is 'TestRunner' you just ignore it and use the previous. To do this, we should store the previous in an instance variable instead of a temp. The opened ticket is http://code.google.com/p/pharo/issues/detail?id=1379 Best, Mariano > Cheers, > Henry > > On 31.10.2009 18:31, Adrian Lienhard wrote: > > If I understand you correctly, the author is permanently set to > > 'TestRunner' after running tests? > > > > Do you know which tests cause the problem? Reverting to the original > > author is done in an ensure block, so I don't see how that can go > > wrong right now. > > > > Adrian > > > > On Oct 29, 2009, at 20:57 , StÃ©phane Ducasse wrote: > > > > > >> apparently there is a bad interaction between the test runner and the > >> author > >> because from time to time I get author = TestRunner > >> Probably the runner code is not robust enough in case of failure > >> capture or something like that. > >> > >> > >> runCase > >> Author > >> useAuthor: 'TestRunner' > >> during: [ > >> [self setUp. > >> self performTest] > >> ensure: [ > >> self tearDown. > >> self cleanUpInstanceVariables ] ] > >> > >> _______________________________________________ > >> 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 >

Nov. 5, 2009