June 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1082: 21701-Add-primitive-to-change-the-window-icon

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1082 was: FAILURE. The Pull Request #1198 was integrated: "21701-Add-primitive-to-change-the-window-icon" Pull request url: https://github.com/pharo-project/pharo/pull/1198 Issue Url: https://pharo.fogbugz.com/f/cases/21701 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 22, 2018

Re: [Pharo-dev] Fuel Error in Latest Launcher

by Max Leske

Thanks Sean. On 21 Jun 2018, at 18:08, Sean P. DeNigris wrote: > Max Leske wrote >>> Where should this bug be reported? >>> https://github.com/theseion/Fuel/issues ? >> >> Yes, please. > > https://github.com/theseion/Fuel/issues/234 > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 22, 2018

Re: [Pharo-dev] strange debugging

by Ben Coman

>> On 15 Jun 2018, at 01:07, Ben Coman <btc(a)openinworld.com> wrote: >> >> Not sure if this is intended behaviour... >> >> in a brand new build 71053, open a browser GTGenericStackDebuggerTest >> testBasic >> >> right-click and choose "Debug" >> >> the debugger opens about on the third statement. >> Clicking <Restart> doesn't improve things, >> and then clicking <Into> shows the stack on MetaLink>>uninstall. >> >> cheers -ben > > On 15 Jun 2018, at 12:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Thanks, I made a note and will look (I hope next week) > On 21 June 2018 at 22:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > The reason seems to be that the mechanism uses a âonceâ breakpoint which > is for now implemented by > removing the breakpoint at runtime. This leads to the debugger getting > text/bytecode offset wrong > as we install a different method. > > runTest: testSelector of: testClass > > | breakpoint | > breakpoint := Breakpoint new > node: (testClass lookupSelector: testSelector) ast; > once; > install. > [super runTest: testSelector of: testClass] ensure: [ breakpoint > remove ] > Thanks for the update. > > I am thinking of implementing the once breakpoints using a condition > instead (so that the byte code is unchanged). > The other nice effect is that one can more easily re-enable those > breakpoints (like haltOnce). > That sounds like a good idea. Will that change the semantics at all? IIRC, prior to metalinks the Halt-once was a global reset only, and post metalinks it was reset by a method save. So will the condition-state be global or per method? And then mild curiousity about the implementation - how would that state be stored? > > As workaround, we can remove the âonceââ¦ as we remove the breakpoint in > the ensure:, it should be removed and > not stay around causing problems. (but it is there in case you would run > the test again, that is why a once break is nicer). cheers -ben

June 22, 2018

Re: [Pharo-dev] Fuel Error in Latest Launcher

by Sean P. DeNigris

Max Leske wrote >> Where should this bug be reported? >> https://github.com/theseion/Fuel/issues ? > > Yes, please. https://github.com/theseion/Fuel/issues/234 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 21, 2018

[Pharo 7.0-dev] Build #1081: 22102-RBBasicLintRuleTest-contains-dead-code-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1081 was: SUCCESS. The Pull Request #1577 was integrated: "22102-RBBasicLintRuleTest-contains-dead-code-" Pull request url: https://github.com/pharo-project/pharo/pull/1577 Issue Url: https://pharo.fogbugz.com/f/cases/22102 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 21, 2018

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

by Tim Mackinnon

Actually - it looks like a caching thing - as in a clean image, if I use my reduced baseline (without the Tests) it loads (albeit with a deprecation warning). Does anyone know what you have to clear to get it to honour the baseline code you actually have in your image - as its a faff to have to use a clean image? (This is a constant frustration in Smalltalk - caches are useful and all, but there isnât a consistent way to reset frameworks - I really long for a pragma for reset, and a menu item somewhere that shows you a reset menu for all the frameworks you have loaded, so its easy to clear things and get to a consistent stateâ¦) Tim > On 21 Jun 2018, at 14:58, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi guys - how did you load Seaside into Pharo 7 as part of a baseline? Iâve hit a similar same problem and am getting a walkback error when trying to load a baseline for a project I wanted to try on P7 which uses seaside. > > I get: MetacelloNameNotDefinedError: project group, or package named: 'Seaside-Pharo-Development' not found when used in requires: or includes: field of package: 'Seaside-Tests-Pharo-Development' for version: baseline of BaselineOfSeaside3. > > My baseline has the following: > > setUpDependencies: spec > > spec > baseline: 'Seaside3' > with: [ spec > repository: 'github://SeasideSt/Seaside:master/repository'; > loads: #('Seaside-Environment') ]. > > > If did have (copied from a Willow example) - and Iâm wondering if something is getting cached and that its not actually using the above - but Iâm not clear on how to ensure any caches are cleared? > > spec > baseline: 'Seaside3' > with: [ spec > repository: 'github://SeasideSt/Seaside:v3.2.4/repository'; > loads: #('Seaside-Environment' 'JQuery' 'Zinc') ]; > project: 'Seaside3-Tests' copyFrom: 'Seaside3' with: [ spec loads: #('Seaside-Tests-Core') ]. > > Any tips gratefully received. > > Tim > >> On 24 May 2018, at 16:02, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi Torsten, >> >> Thanks for taking care. >> >> I can confirm, from a quick test, that Seaside loads/works fine in the latest Pharo 7. >> >> I had trouble opening the Seaside Control Panel, 10s of deprecation warnings opening for the icon base64 decoding, I had to comment out the #deprecated: message send in #mimeDecodeToBytes: >> >> I don't understand why the Grease stream tests are failing since they seem to be testing ReadWriteStream, a class that was not changed, at all. >> >> Sven >> >>> On 22 May 2018, at 22:01, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Just as an info: after fixing the #mimeDecodeToBytes: issue with recent image 70934 and later it is possible >>> to load Seaside again from GitHub using >>> >>> Metacello new >>> baseline:'Seaside3'; >>> repository: 'github://SeasideSt/Seaside:master/repository'; >>> load >>> >>> >>> into a recent Pharo 7.0 (load instruction as recommended on https://github.com/SeasideSt/Seaside) >>> >>> For the deprecated warnings you either "Proceed" or disable them for the time being. >>> >>> 799 of 806 Seaside tests passes >>> 470 of 457 Grease tests passes >>> >>> primarily failing to to non-compatible streams. Seaside and Grease tests seem to test >>> some ANSI related things - who fail now. >>> >>> _______________________________________________ >>> seaside-dev mailing list >>> seaside-dev(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >> >> > >

June 21, 2018

Re: [Pharo-dev] strange debugging

by Marcus Denker

Hello, The reason seems to be that the mechanism uses a âonceâ breakpoint which is for now implemented by removing the breakpoint at runtime. This leads to the debugger getting text/bytecode offset wrong as we install a different method. runTest: testSelector of: testClass | breakpoint | breakpoint := Breakpoint new node: (testClass lookupSelector: testSelector) ast; once; install. [super runTest: testSelector of: testClass] ensure: [ breakpoint remove ] I am thinking of implementing the once breakpoints using a condition instead (so that the byte code is unchanged). The other nice effect is that one can more easily re-enable those breakpoints (like haltOnce). As workaround, we can remove the âonceââ¦ as we remove the breakpoint in the ensure:, it should be removed and not stay around causing problems. (but it is there in case you would run the test again, that is why a once break is nicer). Marcus > On 15 Jun 2018, at 12:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Thanks, I made a note and will look (I hope next week) > >> On 15 Jun 2018, at 01:07, Ben Coman <btc(a)openinworld.com> wrote: >> >> Not sure if this is intended behaviour... >> >> in a brand new build 71053, open a browser GTGenericStackDebuggerTest >> testBasic >> >> right-click and choose "Debug" >> >> the debugger opens about on the third statement. >> Clicking <Restart> doesn't improve things, >> and then clicking <Into> shows the stack on MetaLink>>uninstall. >> >> cheers -ben >

June 21, 2018

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

by Tim Mackinnon

Hi guys - how did you load Seaside into Pharo 7 as part of a baseline? Iâve hit a similar same problem and am getting a walkback error when trying to load a baseline for a project I wanted to try on P7 which uses seaside. I get: MetacelloNameNotDefinedError: project group, or package named: 'Seaside-Pharo-Development' not found when used in requires: or includes: field of package: 'Seaside-Tests-Pharo-Development' for version: baseline of BaselineOfSeaside3. My baseline has the following: setUpDependencies: spec spec baseline: 'Seaside3' with: [ spec repository: 'github://SeasideSt/Seaside:master/repository'; loads: #('Seaside-Environment') ]. If did have (copied from a Willow example) - and Iâm wondering if something is getting cached and that its not actually using the above - but Iâm not clear on how to ensure any caches are cleared? spec baseline: 'Seaside3' with: [ spec repository: 'github://SeasideSt/Seaside:v3.2.4/repository'; loads: #('Seaside-Environment' 'JQuery' 'Zinc') ]; project: 'Seaside3-Tests' copyFrom: 'Seaside3' with: [ spec loads: #('Seaside-Tests-Core') ]. Any tips gratefully received. Tim > On 24 May 2018, at 16:02, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Torsten, > > Thanks for taking care. > > I can confirm, from a quick test, that Seaside loads/works fine in the latest Pharo 7. > > I had trouble opening the Seaside Control Panel, 10s of deprecation warnings opening for the icon base64 decoding, I had to comment out the #deprecated: message send in #mimeDecodeToBytes: > > I don't understand why the Grease stream tests are failing since they seem to be testing ReadWriteStream, a class that was not changed, at all. > > Sven > >> On 22 May 2018, at 22:01, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Just as an info: after fixing the #mimeDecodeToBytes: issue with recent image 70934 and later it is possible >> to load Seaside again from GitHub using >> >> Metacello new >> baseline:'Seaside3'; >> repository: 'github://SeasideSt/Seaside:master/repository'; >> load >> >> >> into a recent Pharo 7.0 (load instruction as recommended on https://github.com/SeasideSt/Seaside) >> >> For the deprecated warnings you either "Proceed" or disable them for the time being. >> >> 799 of 806 Seaside tests passes >> 470 of 457 Grease tests passes >> >> primarily failing to to non-compatible streams. Seaside and Grease tests seem to test >> some ANSI related things - who fail now. >> >> _______________________________________________ >> seaside-dev mailing list >> seaside-dev(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > >

June 21, 2018

Re: [Pharo-dev] Fuel Error in Latest Launcher

by Max Leske

On 21 Jun 2018, at 15:34, Sean P. DeNigris wrote: > Eliot Miranda-2 wrote >> Looks like the bug is that Fuel isâ¦ > > Ah, glad we identified it! > > Where should this bug be reported? > https://github.com/theseion/Fuel/issues ? Yes, please. > > > > ----- > Cheers, > Sean > -- > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 21, 2018

[ANN] Next Pharo Sprint: Jun 29

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Jun 29, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote SprintL Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2789583

June 21, 2018