- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 1 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

Oct. 19, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 3 regressions found. Tests.Monticello.MCDirectoryRepositoryTest.testAddAndLoad Tests.Monticello.MCDirectoryRepositoryTest.testIncludesName Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

Oct. 19, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 1 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

Oct. 19, 2013

Re: [Pharo-dev] test failures in downloaded Green CI image - ZnServerTests >> #testRequestLineTooLong

by Sven Van Caekenberghe

Ben, The goal of the test is to confirm that the server returns an error (refuses a request) when any line, in this case the first so called request line, it too long. Hence the artificially constructed URL. Of course, if you make it shorter, at one point it will be short enough so that it no longer fails - but that defeats the purpose of the test ;-) Now, the problem with this test and 3 other ones that are related, checking the reaction to other limits, is that they pass on Mac and Linux, but fail (randomly) on Windows, when ZdcSocketStream is used instead of SocketStream, currently the default. I have already looked into this, but up to now I failed to find the problem. The Socket class uses a number of primitives which have totally different implementations on the 3 platforms. Yes, I could use some help, but this is not easy. I also think there already is an issue for this, but I can't find it. Sven On 19 Oct 2013, at 18:54, btc(a)openinworld.com wrote: > btc(a)openinworld.com wrote: >> In the process of tying to review the slices for a few issues, I downloaded build #30500 Pharo3.0-win.zip from [1]. (Normally I use files.pharo.org but I wanted to ensure it was a "GREEN" build.) However before loading the slice to review I double-checked the baseline test results by running all tests from TestRunner. I had presumed all tests would be green but was surprised by some failures in the result. Well it maybe it has something to do with environment, but it would be nice for it to be clean to help isoalte any errors introduced by the slice under review. Before I log anything on Fogbugz in case someone can advise anything obvious, the Test Runner result is shown below [2]. >> >> My platform is 64-bit Windows 7 Home Premium Service Pack 1. >> I'll try to follow up with more specific info on each line. >> >> cheers -ben >> >> [1] https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/566/ >> >> [2] FAILURE ZnServerTests >> #testRequestLineTooLong > I extracted #testRequestLineTooLong to something I can evaluate from Workspace... > > | numX url fudge | > fudge := 0. > numX := ZnConstants maximumLineLength - fudge . (url := ZnUrl fromString: 'http://localhost:1704/') > addPathSegment: #echo; > addPathSegment: (String new: numX withAll: $X). > ZnClient new > beOneShot; > logToTranscript; > url: url; > get; > response > > That fails with initial fudge factor of 0 - with 'ZnUnknownHttpVerion.' Here is the Transcript (including logging from ZnServer)... > 2013-10-20 00:45:40 489094 D Executing request/response loop > 2013-10-20 00:45:40 505527 I Wrote a ZnRequest(GET /echo/XXXXXXXX...XXXXX) > 2013-10-20 00:45:40 505527 D Sent headers > Accept: */* > User-Agent: Zinc HTTP Components 1.0 > Connection: close > Host: localhost:1704 > > 2013-10-20 00:45:40 489094 D ZnLineTooLong bad request while parsing > 2013-10-20 00:45:40 489094 I Wrote a ZnResponse(400 Bad Request text/plain;charset=utf-8 27B) > 2013-10-20 00:45:40 489094 D Closing streamZnStatusLine > > With a fudge factor of 9 it still fails, but with 10 it succeeds. Interestingly, inspect 'url' shows... > http://localhost:1704/echo/XXXXXXXXXXXXXXXXXXXXXXXXXX...etc > ...and 10 characters = 1704/echo/ > but then correlation does not equal cause. > > How should we proceed? > > cheers -ben >

Oct. 19, 2013

Re: [Pharo-dev] test failures in downloaded Green CI image - ZnServerTests >> #testRequestLineTooLong

by btc＠openinworld.com

btc(a)openinworld.com wrote: > In the process of tying to review the slices for a few issues, I > downloaded build #30500 Pharo3.0-win.zip from [1]. (Normally I use > files.pharo.org but I wanted to ensure it was a "GREEN" build.) > However before loading the slice to review I double-checked the > baseline test results by running all tests from TestRunner. I had > presumed all tests would be green but was surprised by some failures > in the result. Well it maybe it has something to do with environment, > but it would be nice for it to be clean to help isoalte any errors > introduced by the slice under review. Before I log anything on > Fogbugz in case someone can advise anything obvious, the Test Runner > result is shown below [2]. > > My platform is 64-bit Windows 7 Home Premium Service Pack 1. > I'll try to follow up with more specific info on each line. > > cheers -ben > > [1] https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/566/ > > [2] FAILURE ZnServerTests >> #testRequestLineTooLong I extracted #testRequestLineTooLong to something I can evaluate from Workspace... | numX url fudge | fudge := 0. numX := ZnConstants maximumLineLength - fudge . (url := ZnUrl fromString: 'http://localhost:1704/') addPathSegment: #echo; addPathSegment: (String new: numX withAll: $X). ZnClient new beOneShot; logToTranscript; url: url; get; response That fails with initial fudge factor of 0 - with 'ZnUnknownHttpVerion.' Here is the Transcript (including logging from ZnServer)... 2013-10-20 00:45:40 489094 D Executing request/response loop 2013-10-20 00:45:40 505527 I Wrote a ZnRequest(GET /echo/XXXXXXXX...XXXXX) 2013-10-20 00:45:40 505527 D Sent headers Accept: */* User-Agent: Zinc HTTP Components 1.0 Connection: close Host: localhost:1704 2013-10-20 00:45:40 489094 D ZnLineTooLong bad request while parsing 2013-10-20 00:45:40 489094 I Wrote a ZnResponse(400 Bad Request text/plain;charset=utf-8 27B) 2013-10-20 00:45:40 489094 D Closing streamZnStatusLine With a fudge factor of 9 it still fails, but with 10 it succeeds. Interestingly, inspect 'url' shows... http://localhost:1704/echo/XXXXXXXXXXXXXXXXXXXXXXXXXX...etc ...and 10 characters = 1704/echo/ but then correlation does not equal cause. How should we proceed? cheers -ben

Oct. 19, 2013

Re: [Pharo-dev] can Spec applications add additional items to standard SystemWindow menu

by Benjamin

XXXX new openWithSpec is usually the magic :P Ben On Oct 19, 2013, at 5:56 PM, btc(a)openInWorld.com wrote: > wow. so fast!!! > So I am trying to do my bit and test this in a fresh image. I see the Spec-Examples category, but how do I run these. There is not something obvious on the class side like #open. > > cheers -ben > > Benjamin wrote: >> >> Now, you can :P >> >> See case 11958[1] >> >> Ben >> [1] https://pharo.fogbugz.com/default.asp?11958 >> >> On Oct 19, 2013, at 6:49 AM, btc(a)openInWorld.com wrote: >> >> >>> I want a Spec application to add an additional item to the System Window Menu. Is this possible? So far I have missed how it might be done. >>> >>> This System Window Menu seems to come from... >>> >>> SystemWindow>>offerWindowMenu >>> | aMenu | >>> aMenu := self buildWindowMenu. >>> model ifNotNil: >>> [model addModelItemsToWindowMenu: aMenu]. >>> aMenu popUpEvent: self currentEvent in: self world >>> >>> where #buildWindowMenu produces a standard menu from pragmas >>> and custom model specific menu items can be added with #addModelItemsToWindowMenu:. >>> >>> In the case of PharoLauncher, 'model' is a MorphicWindowAdapter for which #addModelItemsToWindowMenu: is a null-method inherited from Object. So maybe 'model' needs to be a different class somehow? >>> Alternatively, I see that SpecWindow inherits from SystemWindow, so maybe #buildWindowMenu can be overridden to add menu items from subclasses of ComposableModel ? >>> >>> cheers -ben >>> >>> >> >> >> >

Oct. 19, 2013

test failures in downloaded Green CI image

by btc＠openinworld.com

In the process of tying to review the slices for a few issues, I downloaded build #30500 Pharo3.0-win.zip from [1]. (Normally I use files.pharo.org but I wanted to ensure it was a "GREEN" build.) However before loading the slice to review I double-checked the baseline test results by running all tests from TestRunner. I had presumed all tests would be green but was surprised by some failures in the result. Well it maybe it has something to do with environment, but it would be nice for it to be clean to help isoalte any errors introduced by the slice under review. Before I log anything on Fogbugz in case someone can advise anything obvious, the Test Runner result is shown below [2]. My platform is 64-bit Windows 7 Home Premium Service Pack 1. I'll try to follow up with more specific info on each line. cheers -ben [1] https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/566/ [2] 11426 run, 11386 passes, 12 skipped, 26 expected failures, 12 failures, 2 errors, 0 unexpected passes FAILURES MetacelloRepositorySqueakCommonTestCase >> #testAsRepositorySpecFor MetacelloRepositorySqueakCommonTestCase >> #testDirectoryRepository MetacelloRepositorySqueakCommonTestCase >> #testFileTreeRepository RPackageReadOnlyCompleteSetupTest >> #testAddTag RPackageReadOnlyCompleteSetupTest >> #testAddTagNames KMDispatcherTestCase >> #testAttach RPackageSetTest >> #testPolymorphicWithPackageInfo BehaviorTest >> #testBehaviorRespectsPolymorphismWithTraitBehavior BehaviorTest >> #testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits ProcessTest >> #testHighPriorityOverridesWaitTime ReleaseTest >> #testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits ReleaseTest >> #testUndeclared ERRORS MetacelloTutorialTestCase >> #testProjectRef14 ZnServerTests >> #testRequestLineTooLong

Oct. 19, 2013

Re: [Pharo-dev] can Spec applications add additional items to standard SystemWindow menu

by btc＠openinworld.com

Oct. 19, 2013

Nautilus saved search 'Examples' folder

by btc＠openinworld.com

I see that at the top of the Nautilus Category Pane** are a few entries that behave like pre-built 'Saved Search Folders' of other applications. e.g. 'Last Modified Classes', 'Most Viewed Classes' A useful addition to this would be an 'Examples' folder, which presentes all categories containing the word 'Example' so that these are readily accessible at the top. cheers -ben ** Is it still called Category Pane, or with the recently announced important RPackage change is it now Package Pane ?

Oct. 19, 2013

Re: [Pharo-dev] Commit rights to Pharo30Inbox

by StÃ©phane Ducasse

tx! On Oct 18, 2013, at 10:26 PM, Attila Magyar <m.magyar3(a)gmail.com> wrote: > > Hi list, > I want to submit a SLICE to the pharo inbox, can you grant me commit rights? > > username: zeroflag > > thanks!

Oct. 19, 2013