- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1044: 22122-Categorize-methods-in-AthensCairoPatternSurfacePaint
by ci-pharo-ci-jenkins2＠inria.fr June 12, 2018

June 12, 2018

There is a new Pharo build available! The status of the build #1044 was: FAILURE. The Pull Request #1526 was integrated: "22122-Categorize-methods-in-AthensCairoPatternSurfacePaint" Pull request url: https://github.com/pharo-project/pharo/pull/1526 Issue Url: https://pharo.fogbugz.com/f/cases/22122 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1043: 22119-transforming-depreaction-for-addAndClassifySelectorwithMethodinProtocolnotifying
by ci-pharo-ci-jenkins2＠inria.fr June 12, 2018

June 12, 2018

There is a new Pharo build available! The status of the build #1043 was: FAILURE. The Pull Request #1525 was integrated: "22119-transforming-depreaction-for-addAndClassifySelectorwithMethodinProtocolnotifying" Pull request url: https://github.com/pharo-project/pharo/pull/1525 Issue Url: https://pharo.fogbugz.com/f/cases/22119 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Window groups and Calypso Browser
by Torsten Bergmann June 12, 2018

June 12, 2018

Hi Denis, when I open a Pharo window (like Playground) and select "Create window group" I can drag and drop other windows onto it. So one can group several windows into one, each one shown with an own tab. This works for most of the Pharo windows (Playground, Iceberg, ...) in latest Pharo 7 - but not for the Calypso browser. I can drag a system browser into the window group - but when I drag it out again it is just a gray window and the content is not usable anymore. I guess this is a bug in Calypso - so I opened https://github.com/pharo-ide/Calypso/issues/287 Thx T.

2 1

[Pharo 7.0-dev] Build #1042: 20212-SyntaxErrorDebugger-GUI-glitching-when-compiler-is-fed-incorrect-input
by ci-pharo-ci-jenkins2＠inria.fr June 12, 2018

June 12, 2018

There is a new Pharo build available! The status of the build #1042 was: SUCCESS. The Pull Request #1520 was integrated: "20212-SyntaxErrorDebugger-GUI-glitching-when-compiler-is-fed-incorrect-input" Pull request url: https://github.com/pharo-project/pharo/pull/1520 Issue Url: https://pharo.fogbugz.com/f/cases/20212 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1041: 21949 not possible to save settings
by ci-pharo-ci-jenkins2＠inria.fr June 12, 2018

June 12, 2018

There is a new Pharo build available! The status of the build #1041 was: SUCCESS. The Pull Request #1524 was integrated: "21949 not possible to save settings" Pull request url: https://github.com/pharo-project/pharo/pull/1524 Issue Url: https://pharo.fogbugz.com/f/cases/21949 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1040: 22120-Integrate-Iceberg-v110
by ci-pharo-ci-jenkins2＠inria.fr June 11, 2018

June 11, 2018

There is a new Pharo build available! The status of the build #1040 was: SUCCESS. The Pull Request #1523 was integrated: "22120-Integrate-Iceberg-v110" Pull request url: https://github.com/pharo-project/pharo/pull/1523 Issue Url: https://pharo.fogbugz.com/f/cases/22120 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1039: 22111 font chooser package should be fonts chooser
by ci-pharo-ci-jenkins2＠inria.fr June 11, 2018

June 11, 2018

There is a new Pharo build available! The status of the build #1039 was: SUCCESS. The Pull Request #1517 was integrated: "22111 font chooser package should be fonts chooser" Pull request url: https://github.com/pharo-project/pharo/pull/1517 Issue Url: https://pharo.fogbugz.com/f/cases/22111 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1038: 22107-DockingBarMorph-should-have-its-own-entry-in-the-theme-to-define-the-border-width
by ci-pharo-ci-jenkins2＠inria.fr June 11, 2018

June 11, 2018

There is a new Pharo build available! The status of the build #1038 was: FAILURE. The Pull Request #1514 was integrated: "22107-DockingBarMorph-should-have-its-own-entry-in-the-theme-to-define-the-border-width" Pull request url: https://github.com/pharo-project/pharo/pull/1514 Issue Url: https://pharo.fogbugz.com/f/cases/22107 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

About infinite debuggers in tests (https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger)
by Steven Costiou June 11, 2018

June 11, 2018

Hi, Is that normal that in the following method we do "EX PASS" (at the end)? runCaseForDebug: aTestCase [ aTestCase announce: TestCaseStarted withResult: self. aTestCase runCaseManaged. aTestCase announce: TestCaseEnded withResult: self. "To not affect performance of big test suites following logic is not inside addPass: method" errors remove: aTestCase ifAbsent: [ ]. failures remove: aTestCase ifAbsent: [ ]. self addPass: aTestCase ] on: self class failure , self class skip , self class warning , self class error do: [ :ex | ex sunitAnnounce: aTestCase toResult: self. EX PASS ] I think it is the source of the infinite crazy debugger bug (maybe i'm wrong) https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger Doing "ex debug" solves the problem but i do not know the impact (pharo 5 - 6 - 7, but not previous versions). For what i understand, it happens because : - when you got an error in a test, it goes through the ex pass - but when you got a doesNotUnderstand, it first goes into: doesNotUnderstand: aMessage <debuggerCompleteToSender> | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. RESUMEVALUE := EXCEPTION SIGNAL. ^exception reachedDefaultHandler ifTrue: [AMESSAGE SENTTO: SELF] ifFalse: [resumeValue] In normal cases (class of the receiver is not a test case), when you step in the debugger the EXCEPTION SIGNAL blocks the execution right away. In subclasses of TESTCASE, it does EX PASS each time you signal the exception and so it continues in the doesNotUnderstand. Then it enters the AMESSAGE SENTTO: SELF in the doesNotUnderstand, which is still not understood and goes again into the "ex pass", then you can wait a long time... I'm not really sure though why it does not open another debugger and why it gets stuck. Maybe that is the real bug: it should open another debugger and not loop and pop one million debugging windows after a user interruption. Another side effect is that the watchdog of the TestExecutionEnvironment also gets stuck and stops counting for the timeout, because a debugging session was open and never closed (because its looping). See TestExecutionEnvironment>>watchDogLoopFor:. Replacing EX PASS by EX DEBUG seems to work and reproduce the standard behavior of the debugger for classes that are not subclasses of TestCase. But i do not know if the "pass" was explicitly intended and if there will be side effects... Steven.

2 1

[Pharo 7.0-dev] Build #1037: 22108 Cleanup Text-Scanning
by ci-pharo-ci-jenkins2＠inria.fr June 11, 2018

June 11, 2018

There is a new Pharo build available! The status of the build #1037 was: SUCCESS. The Pull Request #1515 was integrated: "22108 Cleanup Text-Scanning" Pull request url: https://github.com/pharo-project/pharo/pull/1515 Issue Url: https://pharo.fogbugz.com/f/cases/22108 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0