3.0.4 status
Locked
 
|
PharoCore1.0:
- WAHtmlFileHandlerListingTest>>testFileLibraries results in a WAAttributeNotFound being signalled (test error). I'll dig into this one a little bit more tomorrow. - several WAFileLibraryTests fail the first time tests run, pass on rerunning of tests ... I'll ignore these for now PharoCore1.1.1: - several WAFileLibraryTests fail the first time tests run, pass on rerunning of tests ... I'll ignore these for now Seaside-Core-jf.696: - WABaseElement>>target: is still in the package, so Philippe's edits weren't committed (presumably). If the only change that was made at the time was to move WABaseElement>>target: from Seaside-Core to Seaside-HTML5 then I can do the edit tomorrow (it's getting late here:) - no other (unexpected) dirty packages Grease-Pharo-Core and WAUrlEncoder: - I'll do these edits tomorrow as well... I also plan on making a pass at loading Seaside3.0 into Pharo1.2 and Pharo1.3 according to mail I've seen the only problem with Seaside3.0 on Pharo1.2 is related to using the proper version of OB and that's what symbolic versions are for, so I should be able to address that issue. Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
2011/2/10 Dale Henrichs <[hidden email]>:
> PharoCore1.0: > > - WAHtmlFileHandlerListingTest>>testFileLibraries results in a > WAAttributeNotFound being signalled (test error). I'll dig into this > one a little bit more tomorrow. > - several WAFileLibraryTests fail the first time tests run, pass > on rerunning of tests ... I'll ignore these for now > > PharoCore1.1.1: > > - several WAFileLibraryTests fail the first time tests run, pass > on rerunning of tests ... I'll ignore these for now That is quite strange. File libraries now do a configuration look up but when the configuration caches are reset they should pass. > Seaside-Core-jf.696: > > - WABaseElement>>target: is still in the package, so Philippe's edits > weren't committed (presumably). If the only change that was made at > the time was to move WABaseElement>>target: from Seaside-Core to > Seaside-HTML5 then I can do the edit tomorrow (it's getting late > here:) > - no other (unexpected) dirty packages > > Grease-Pharo-Core and WAUrlEncoder: > > - I'll do these edits tomorrow as well... > > I also plan on making a pass at loading Seaside3.0 into Pharo1.2 and > Pharo1.3 according to mail I've seen the only problem with Seaside3.0 on > Pharo1.2 is related to using the proper version of OB and that's what > symbolic versions are for, so I should be able to address that issue. Besides OB I'm aware of two issues: - there several deprecation warnings - file library and tests don't work out of the box because we use Preferences >> #valueOfFlag: #compileUseNewCompiler:ifAbsent: In general it looks like a Grease for Pharo 1.2 is needed. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Phillipe,
Could it be that the file library tests are failing because of the configurations' cache of search contexts? I remember hitting a WAAttributeNotFound several times before making it work... Cheers, Avi. On Thu, Feb 10, 2011 at 9:00 AM, Philippe Marschall <[hidden email]> wrote: 2011/2/10 Dale Henrichs <[hidden email]>: _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
2011/2/10 Avi Shefi <[hidden email]>:
> Phillipe, > Could it be that the file library tests are failing because of the > configurations' cache of search contexts? > I remember hitting a WAAttributeNotFound several times before making it > work... I don't know. They seem to work in the build [1] http://hudson.lukas-renggli.ch/view/Seaside%203.0/job/Seaside%203.0/ Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Philippe Marschall
2011/2/10 Philippe Marschall <[hidden email]>:
> 2011/2/10 Dale Henrichs <[hidden email]>: >> PharoCore1.0: >> >> - WAHtmlFileHandlerListingTest>>testFileLibraries results in a >> WAAttributeNotFound being signalled (test error). I'll dig into this >> one a little bit more tomorrow. >> - several WAFileLibraryTests fail the first time tests run, pass >> on rerunning of tests ... I'll ignore these for now >> >> PharoCore1.1.1: >> >> - several WAFileLibraryTests fail the first time tests run, pass >> on rerunning of tests ... I'll ignore these for now > > That is quite strange. File libraries now do a configuration look up > but when the configuration caches are reset they should pass. > >> Seaside-Core-jf.696: >> >> - WABaseElement>>target: is still in the package, so Philippe's edits >> weren't committed (presumably). If the only change that was made at >> the time was to move WABaseElement>>target: from Seaside-Core to >> Seaside-HTML5 then I can do the edit tomorrow (it's getting late >> here:) >> - no other (unexpected) dirty packages >> >> Grease-Pharo-Core and WAUrlEncoder: >> >> - I'll do these edits tomorrow as well... >> >> I also plan on making a pass at loading Seaside3.0 into Pharo1.2 and >> Pharo1.3 according to mail I've seen the only problem with Seaside3.0 on >> Pharo1.2 is related to using the proper version of OB and that's what >> symbolic versions are for, so I should be able to address that issue. > > Besides OB I'm aware of two issues: > - there several deprecation warnings > - file library and tests don't work out of the box because we use > Preferences >> #valueOfFlag: #compileUseNewCompiler:ifAbsent: > > In general it looks like a Grease for Pharo 1.2 is needed. Should be decide to do this there are a couple of options to do it: - a Monticello branch ( <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz) - a new package for Pharo 1.2 eg. Grease-Pharo12-Core - move Grease-Pharo-Core to 1.2 and have some class extensions in Grease-Pharo11-Core like Grease-Pharo10-Core Does anybody have an preferences? Does Metacello support MC branches? Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 02/10/2011 12:16 AM, Philippe Marschall wrote:
> 2011/2/10 Philippe Marschall<[hidden email]>: >> 2011/2/10 Dale Henrichs<[hidden email]>: >>> I also plan on making a pass at loading Seaside3.0 into Pharo1.2 and >>> Pharo1.3 according to mail I've seen the only problem with Seaside3.0 on >>> Pharo1.2 is related to using the proper version of OB and that's what >>> symbolic versions are for, so I should be able to address that issue. >> >> Besides OB I'm aware of two issues: >> - there several deprecation warnings >> - file library and tests don't work out of the box because we use >> Preferences>> #valueOfFlag: #compileUseNewCompiler:ifAbsent: >> >> In general it looks like a Grease for Pharo 1.2 is needed. > > Should be decide to do this there are a couple of options to do it: > - a Monticello branch ( > <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz) > - a new package for Pharo 1.2 eg. Grease-Pharo12-Core > - move Grease-Pharo-Core to 1.2 and have some class extensions in > Grease-Pharo11-Core like Grease-Pharo10-Core > > Does anybody have an preferences? Does Metacello support MC branches? Metacello supports MC branches, so all three options could be viable. I'll do a quick load of 3.0.4 into Pharo1.2 and let you know what my preference would be ... right off the bat, I'll just say that branches require constant merging so a structural solution (i.e., isolating the changes in unique packages) is preferable. The branch would make sense if the affected methods cannot be refactored easily... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by littleSmalltalker
On 02/09/2011 11:56 PM, Avi Shefi wrote:
> Phillipe, > Could it be that the file library tests are failing because of the > configurations' cache of search contexts? > I remember hitting a WAAttributeNotFound several times before making it > work... > Cheers, > Avi. Avi, This does seem to be an introduced bug. I loaded Seaside3.0.3 into PharoCore1.0 and all of the tests pass, so if you could point to some classes and methods that might be involved I could look into this. BTW, there are no spurious failures of the other tests either, so that behavior was introduced in the recent bug fixes... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Dale,
The fix I committed to issue 641 should be reverted since Julian has a better version. Julian - would you like your fix to be included? Regarding my question to Phillipe - all tests regarding the issue at hand work fine. The tests that fail seem to be related to other possible issues, ones which I'm not familiar with. Phillipe/Julian, have you been able to sort out the tests failures? Cheers, Avi. On Thu, Feb 10, 2011 at 8:13 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
2011/2/11 Avi Shefi <[hidden email]>:
> Dale, > The fix I committed to issue 641 should be reverted since Julian has a > better version. Julian - would you like your fix to be included? I merged the one from Julian. All the open issues were present previously and his version is better the current one. > Regarding my question to Phillipe - all tests regarding the issue at hand > work fine. The tests that fail seem to be related to other possible issues, > ones which I'm not familiar with. > > Phillipe/Julian, have you been able to sort out the tests failures? No. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
In reply to this post by Dale Henrichs
On 02/09/2011 05:49 PM, Dale Henrichs wrote:
> PharoCore1.0: > > - WAHtmlFileHandlerListingTest>>testFileLibraries results in a > WAAttributeNotFound being signalled (test error). I'll dig into this > one a little bit more tomorrow. I've done a little poking around this test failure and I discovered that if I reach in the instance of WaConfiguration where the test was failing and niled out the cachedSearchContexts instance variable, all of the tests pass from here on out ... so somewhere, somehow a bad search context got cached ... This makes me wonder if the problem just happened to appear in PharoCore1.0 and is an indication of potential issues on other platforms ... or ... there really is something in PharoCore1.0 that is the source of this bug? Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.1.1)
|
|
In reply to this post by Dale Henrichs
On 02/09/2011 05:49 PM, Dale Henrichs wrote:
> PharoCore1.1.1: > > - several WAFileLibraryTests fail the first time tests run, pass > on rerunning of tests ... I'll ignore these for now > Here's the list of tests that fail immediately after load: 1704 run, 1695 passes, 2 expected failures, 0 failures, 7 errors, 0 unexpected passes Failures: Errors: WAHtmlFileHandlerListingTest>>#testFileLibraries WAHtmlFileHandlerListingTest>>#testFileLibrary WAFileLibraryTest>>#testSamplePng WAFileLibraryTest>>#testUrlOf WAFileHandlerTest>>#testHandleFileRequest WAFileHandlerTest>>#testResourceBaseUrlConfigured WAFileHandlerTest>>#testResourceBaseUrlNotConfigured and upon rerunning the Errors WAHtmlFileHandlerListingTest>>#testFileLibraries is still failing ... this is the same test that failed in PharoCore1.0. In order to reproduce the problem I had to first load Seaside 3.0.3 and then load 3.0.4 (actually I'm still loading the latest mcz files at this stage). If I load the latest mcz files into a virgin PharoCore1.1.1 image I don't see any of these test failures... which explains why the hudson server doesn't see these issues... Sooooo, what do you say? Go ahead and ship with these known issues (I can submit bug reports...I'll need to update and commit the configs before submitting the bugs, so you can reproduce the problem I'm seeing) or should I hold off release until they are fixed? FWIW, Seaside3.0.4 loads and passes all tests on both Squeak4.1/2 (I haven't tried the load 3.0.3 then load 3.0.4 trick yet). Today I will go ahead and start the work of porting 3.0.4 to GemStone and MagLev. Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
In reply to this post by Dale Henrichs
If I load latest mcz files into Pharo1.0 and run the tests they run
clean ... so the problem is strictly an upgrade problem and probably exists on all platforms ... Dale On 02/11/2011 09:58 AM, Dale Henrichs wrote: > On 02/09/2011 05:49 PM, Dale Henrichs wrote: >> PharoCore1.0: >> >> - WAHtmlFileHandlerListingTest>>testFileLibraries results in a >> WAAttributeNotFound being signalled (test error). I'll dig into this >> one a little bit more tomorrow. > > I've done a little poking around this test failure and I discovered that > if I reach in the instance of WaConfiguration where the test was failing > and niled out the cachedSearchContexts instance variable, all of the > tests pass from here on out ... so somewhere, somehow a bad search > context got cached ... > > This makes me wonder if the problem just happened to appear in > PharoCore1.0 and is an indication of potential issues on other platforms > ... or ... there really is something in PharoCore1.0 that is the source > of this bug? > > Dale > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
Dale,
Please use the following for the build process: WAConfiguration allInstancesDo: [ :instance | instance clearSearchContexts ]. WAConfiguration allSubInstancesDo: [ :instance | instance clearSearchContexts ]. After running these the tests seem to clear. We will continue discussion on issue 643 on the issues tracker.
Cheers, Avi. On Fri, Feb 11, 2011 at 11:35 PM, Dale Henrichs <[hidden email]> wrote: If I load latest mcz files into Pharo1.0 and run the tests they run clean ... so the problem is strictly an upgrade problem and probably exists on all platforms ... _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
Avi,
In GemStone it is not a good idea to rely on allInstances since a repository can be quite large, so I'm reluctant to put in such a method. Presumably something like the following will work: WASystemConfiguration allSubclasses do: [ :each | each instance clearSearchContexts; clearDescription ]. without resorting to allInstances? In the particular case I've seen clearing the description and search context would do the trick... Dale On 02/11/2011 03:02 PM, Avi Shefi wrote: > Dale, > Please use the following for the build process: > WAConfiguration allInstancesDo: [ :instance | instance > clearSearchContexts ]. > WAConfiguration allSubInstancesDo: [ :instance | instance > clearSearchContexts ]. > > After running these the tests seem to clear. > We will continue discussion on issue 643 on the issues tracker. > Cheers, > Avi. > On Fri, Feb 11, 2011 at 11:35 PM, Dale Henrichs <[hidden email] > <mailto:[hidden email]>> wrote: > > If I load latest mcz files into Pharo1.0 and run the tests they run > clean ... so the problem is strictly an upgrade problem and probably > exists on all platforms ... > > > Dale > > > On 02/11/2011 09:58 AM, Dale Henrichs wrote: > > On 02/09/2011 05:49 PM, Dale Henrichs wrote: > > PharoCore1.0: > > - WAHtmlFileHandlerListingTest>>testFileLibraries > results in a > WAAttributeNotFound being signalled (test error). > I'll dig into this > one a little bit more tomorrow. > > > I've done a little poking around this test failure and I > discovered that > if I reach in the instance of WaConfiguration where the test was > failing > and niled out the cachedSearchContexts instance variable, all of the > tests pass from here on out ... so somewhere, somehow a bad search > context got cached ... > > This makes me wonder if the problem just happened to appear in > PharoCore1.0 and is an indication of potential issues on other > platforms > ... or ... there really is something in PharoCore1.0 that is the > source > of this bug? > > Dale > _______________________________________________ > seaside-dev mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > > _______________________________________________ > seaside-dev mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
Dale,
I didn't mean for those lines to be included in any method, but as an immediate fix for the "unstable" search contexts. Indeed clearing the search contexts solves the tests failures. Cheers, Avi. On Sat, Feb 12, 2011 at 1:24 AM, Dale Henrichs <[hidden email]> wrote: Avi, _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
In reply to this post by Dale Henrichs
2011/2/12 Dale Henrichs <[hidden email]>:
> Avi, > > In GemStone it is not a good idea to rely on allInstances since a repository > can be quite large, so I'm reluctant to put in such a method. > > Presumably something like the following will work: > > WASystemConfiguration allSubclasses do: [ :each | > each instance > clearSearchContexts; > clearDescription ]. > > without resorting to allInstances? In the particular case I've seen clearing > the description and search context would do the trick... Sounds ok, maybe in an a class side #intialize on WASystemConfiguration or something. That makes we wonder whether WASystemConfiguration class >> #clearAllDescriptions should actually clear the cached search contexts as well? Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: 3.0.4 status (PharoCore1.0)
|
|
Phillipe,
Read my last message on issue 643: http://code.google.com/p/seaside/issues/detail?id=643 Cheers, Avi. On Sat, Feb 12, 2011 at 10:19 PM, Philippe Marschall <[hidden email]> wrote: 2011/2/12 Dale Henrichs <[hidden email]>: _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |