On Thu, Feb 24, 2011 at 3:15 PM, Dale Henrichs <dhenr...@vmware.com> wrote:
> I haven't released my changes yet ... once I'm satisfied with the the > behavior on PharoCore1.2 (that's where I'm doing development) I now have to > get the new version of Gofer ported to Squeak and GemStone before I can make > the full release ... otherwise the tests will be failing on Squeak/GemStone > ... > > If the goal is to make the tests green on Pharo1.2, you might just add > #expectedFailures as non-metacello extension methods to the troublesome > tests ... I think that this is the exact use case that #expectedFailures is > aimed at ... the tests will be green for Pharo1.2 and I'll be able to take > the necessary time to propogate the necessary changes... > Well, I prefer to not have tests green in this case because Pharo 1.2 cannot be released without the fixed version of Metacello, is it ? Laurent. > > Dale > On Feb 24, 2011, at 5:50 AM, laurent laffont wrote: > > On Thu, Feb 24, 2011 at 2:31 PM, Dale Henrichs <dhenr...@vmware.com > <mailto:dhenr...@vmware.com>> wrote: > Laurent, > > I've actually made a pass and cleaned up the tests ... you can compare with > my work:)... I need to write some more tests to make sure that Metacello is > still behaving correctly, I think I've added enough coverage, but I need to > look a little closer ... > > My guess is that you didn't reset the resource ... the resource structure > is cached, so when you make changes to the code that is used to create the > resource, you need to reset it as well... > > Yes that was that ! Still 9 errors but as you've already done it ..... > your changes has been integrated in PharoCore 1.2 ? > > Laurent. > > > > > Dale > > On Feb 24, 2011, at 12:10 AM, laurent laffont wrote: > > On Thu, Feb 17, 2011 at 12:33 AM, Dale Henrichs <dhenr...@vmware.com > <mailto:dhenr...@vmware.com><mailto:dhenr...@vmware.com<mailto: > dhenr...@vmware.com>>> wrote: > On 02/15/2011 05:46 PM, Guillermo Polito wrote: > Hi Dale! > > There are 13 failing tests on the 1.2 dev build since a week ago ( > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ > ). Do we have the right version? Do you have any clue so I don't dive > in the code blindly? :) > > Cheers, > Guille > > Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, > which means that the sorting order for mcz files has been changed, which > means that the Metacello tests that are sensitive (or validating) the sort > order have broken ... > > It will be at least a couple of days before I can get these issues fixed I > have to propogate the gofer fixes to GemStone and Squeak... the normal > operation of Metacello shouldn't be affected by these failing tests ... the > test cases involved include examples of mcz files with "incorrect" branch > naming scheme... > > I've created Metacello Issue 108: "Need to update Metacello (tests and > Gofer config) to integrate changes from Pharo Issue 3660"[1] to track > progress. > > [1] http://code.google.com/p/metacello/issues/detail?id=108 > > > > I've tried to resolve this past two days (yep, not so easy for a first dive > into Metacello :). If I understand: > 'GoferBar-lr.branch.1' should be 'GoferBar.branch-lr.1' > > so I've changed this for all packages/branches everywhere (in > MetacelloMonticelloResource, MetacelloConfigurationResource, GoferResource > and tests). > > Now a lot of tests are red because in > MetacelloFetchingMCSpecLoader>>retryingResolvePackageSpecReferences: it > cannot find GoferBar-lr.branch.2 > Indeed in MetacelloTestConfigurationOfFoo generated by the tests there's > package: 'GoferBar' with: 'GoferBar-lr.branch.2'; > > This driving me mad: I cannot find how MetacelloTestConfigurationOfFoo is > generated and when a spec with 'GoferBar-lr.branch.2' is created instead of > 'GoferBar.branch-lr.2'. > > > Any hint ? > > Cheers, > > Laurent > > > Dale > > > > > > > >
