August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] allUnimplementedCalls removed

by stepharo

On 14/8/14 16:21, Marcus Denker wrote: > On 10 Aug 2014, at 08:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi Marcus, >> >> was it appropriate to remove allUnimplementedCalls from the >> SystemNavigation? We lost an important message to check the image >> health. Is there any replacement? >> > I removed it mostly because the Code Critique tool has the same functionalityâ¦ > but maybe it is good to have this for the Kernel without needed the Code critique loaded? +1 > We can add it backâ¦ > > Marcus >

Aug. 14, 2014

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Marcus Denker

On 14 Aug 2014, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: > Thanks gain Marcus - I think this is what Ben or Sean were referring to. > > I donât think Iâve fully understood the role of the cache - again maybe another beer at Esug might set me straight. God knows - maybe I might be able to figure out how to fix it? > Yes, we can try :-) > Does clearing your cache let it then compare properly Yes! > - or is it more complicated than thatt > At the moment - I feel blind in all my changes, and Iâm really not sure what Iâm committing to remote - repos which is worrying. It could be that its a workflow thing - and maybe someone can show me a better workflow. > Marcus

Aug. 14, 2014

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Tim Mackinnon

Thanks gain Marcus - I think this is what Ben or Sean were referring to. I donât think Iâve fully understood the role of the cache - again maybe another beer at Esug might set me straight. God knows - maybe I might be able to figure out how to fix it? Does clearing your cache let it then compare properly - or is it more complicated than that? At the moment - I feel blind in all my changes, and Iâm really not sure what Iâm committing to remote - repos which is worrying. It could be that its a workflow thing - and maybe someone can show me a better workflow. Tim On 14 Aug 2014, at 15:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 10 Aug 2014, at 23:44, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi Stef - I went back and opened that image again (I save it in that state) - it was 4.0-40162 build. And it still says no changes? Itâs possible that my changes were incorporated now - or possibly Iâve done something wrong (although Iâm not quite sure what). Possibly my .changes file would show my steps? >> > > I think there is a bugâ¦ > > I even added an issue entry long time ago: > > https://pharo.fogbugz.com/f/cases/6964/Changes-in-Monticello-seems-to-compa… > > The problem seems to be that even if you ask for âshow me the change to *that* repositoryâ, it actually looks in the cache and finds > the already changed one. > > Marcus

Aug. 14, 2014

Re: [Pharo-dev] Does image build process check for halts?

by Tim Mackinnon

Gosh - this would be a great talk at a conferenceâ¦ ;) Maybe at Esug someone can show me some of what is going onâ¦ I donât really understand how you are building things, but it should be possible to come up with some pragmatic things that maybe we can help with. Certainly self halt. should be a simple one to detect and get in place. In my Esug, talk I was going to show my simple (and naive) script that builds the OU image and regexâs the transcript that I pump out to the file system. It sounds like the Pharo build is much more clever - but maybe that technique might work too? Tim On 14 Aug 2014, at 15:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 08 Aug 2014, at 17:29, Tim Mackinnon <tim(a)testit.works> wrote: > >> Maybe this is a good moment to review what checks are run on every build and ensure that they are working? >> >> Itâs easy to leave in something like self halt - it would be nice to have the CI system do its stuff and send you an email that you forget (this is where CI is awesome). >> > > Yesâ¦ but nothing happens by itself. > >> Iâm also assuming in the CI process we check logs for âundefinedâ and âerrorâ msgs that would appear in the transcript right? >> > no, it does not. It fails on Error, though. And Undeclareds are checked by the test #testUndeclared of the ReleaseTest class that is run on > the final result of the build. > > Marcus

Aug. 14, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40170 Home: https://github.com/pharo-project/pharo-core

Aug. 14, 2014

[pharo-project/pharo-core] 5885f8: 40170

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 5885f80d244f774084114751148f34f5e6dfecf2 https://github.com/pharo-project/pharo-core/commit/5885f80d244f774084114751… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-14 (Thu, 14 Aug 2014) Changed paths: M Kernel.package/Object.class/instance/error handling/explicitRequirement.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script169.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40169.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tests.package/TraitTest.class/instance/testing/testExplicitRequirementWithSuperclassImplementatiosAlwaysReturnsTheCorrectValue.st Log Message: ----------- 40170 http://files.pharo.org/image/40/40170.zip

Aug. 14, 2014

Re: [Pharo-dev] allUnimplementedCalls removed

by Marcus Denker

On 10 Aug 2014, at 08:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Marcus, > > was it appropriate to remove allUnimplementedCalls from the > SystemNavigation? We lost an important message to check the image > health. Is there any replacement? > I removed it mostly because the Code Critique tool has the same functionalityâ¦ but maybe it is good to have this for the Kernel without needed the Code critique loaded? We can add it backâ¦ Marcus

Aug. 14, 2014

Re: [Pharo-dev] Does image build process check for halts?

by Marcus Denker

On 08 Aug 2014, at 17:29, Tim Mackinnon <tim(a)testit.works> wrote: > Maybe this is a good moment to review what checks are run on every build and ensure that they are working? > > Itâs easy to leave in something like self halt - it would be nice to have the CI system do its stuff and send you an email that you forget (this is where CI is awesome). > Yesâ¦ but nothing happens by itself. > Iâm also assuming in the CI process we check logs for âundefinedâ and âerrorâ msgs that would appear in the transcript right? > no, it does not. It fails on Error, though. And Undeclareds are checked by the test #testUndeclared of the ReleaseTest class that is run on the final result of the build. Marcus

Aug. 14, 2014

Re: [Pharo-dev] Does image build process check for halts?

by Marcus Denker

On 08 Aug 2014, at 09:50, Tim Mackinnon <tim(a)testit.works> wrote: > Guys - I noticed that the pharo build 40152 - has a halt when you press ALT-Tab (I assume this was accidentally left in by someone?). > > But this got me thinking - doesnât the CI process check for this and just fail the build? Maybe legitimate halts should be tagged specially somehow so they pass through - but accidental ones get noted? > > What there is right now is a automatic checker (âthe monkeyâ), that runs a) all tests and b) a selection of code-critique rules on the submitted slices. (But keep in mind that there is a bug right now that makes is not really working: https://pharo.fogbugz.com/f/cases/13393/Monkey-failing-with-a-problem-in-se… ) We do not yet run globally the rulesâ¦ we should start. The problem is that there are *a lot* (and that means: *a lot*) of problems that the code critique tells aboutâ¦ so we need to do it rule-by-rule. (e.g. turn on only âtemp var not referencedâ, then fix all bugs, then the next). Marcus

Aug. 14, 2014

Re: [Pharo-dev] Submitted Improved Pharo Help (Case 13811) - but couldn't compare it?

by Marcus Denker

On 10 Aug 2014, at 23:44, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Stef - I went back and opened that image again (I save it in that state) - it was 4.0-40162 build. And it still says no changes? Itâs possible that my changes were incorporated now - or possibly Iâve done something wrong (although Iâm not quite sure what). Possibly my .changes file would show my steps? > I think there is a bugâ¦ I even added an issue entry long time ago: https://pharo.fogbugz.com/f/cases/6964/Changes-in-Monticello-seems-to-compa… The problem seems to be that even if you ask for âshow me the change to *that* repositoryâ, it actually looks in the cache and finds the already changed one. Marcus

Aug. 14, 2014