- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #480: Put a NotFoundError into Deprecated80 for compatibility

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

There is a new Pharo build available! The status of the build #480 was: FAILURE. The Pull Request #3899 was integrated: "Put a NotFoundError into Deprecated80 for compatibility" Pull request url: https://github.com/pharo-project/pharo/pull/3899 Issue Url: https://github.com/pharo-project/pharo/issues/3898 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 12, 2019

[Pharo 8.0] Build #479: 3847-TestRunner-code-coverage-does-not-need-to-use-method-reference-wrapping

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

There is a new Pharo build available! The status of the build #479 was: FAILURE. The Pull Request #3849 was integrated: "3847-TestRunner-code-coverage-does-not-need-to-use-method-reference-wrapping" Pull request url: https://github.com/pharo-project/pharo/pull/3849 Issue Url: https://github.com/pharo-project/pharo/issues/3847 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 12, 2019

[Pharo 8.0] Build #478: 3895-improve-RGMethodDefinitionprintOn-and-name

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

There is a new Pharo build available! The status of the build #478 was: FAILURE. The Pull Request #3896 was integrated: "3895-improve-RGMethodDefinitionprintOn-and-name" Pull request url: https://github.com/pharo-project/pharo/pull/3896 Issue Url: https://github.com/pharo-project/pharo/issues/3895 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 12, 2019

[Pharo 8.0] Build #477: Consistency in how compilerOptions are represented

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

There is a new Pharo build available! The status of the build #477 was: FAILURE. The Pull Request #3893 was integrated: "Consistency in how compilerOptions are represented" Pull request url: https://github.com/pharo-project/pharo/pull/3893 Issue Url: https://github.com/pharo-project/pharo/issues/compilerOptions Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 12, 2019

[Pharo 8.0] Build #476: 3471-SmallIntegers-comment-is-out-of-date (fixes #3471)

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

There is a new Pharo build available! The status of the build #476 was: FAILURE. The Pull Request #3888 was integrated: "3471-SmallIntegers-comment-is-out-of-date (fixes #3471)" Pull request url: https://github.com/pharo-project/pharo/pull/3888 Issue Url: https://github.com/pharo-project/pharo/issues/3471 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 12, 2019

[Pharo 8.0] Build #475: Cleanup ASTCache

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

There is a new Pharo build available! The status of the build #475 was: FAILURE. The Pull Request #3878 was integrated: "Cleanup ASTCache" Pull request url: https://github.com/pharo-project/pharo/pull/3878 Issue Url: https://github.com/pharo-project/pharo/issues/3877 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 12, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Ben Coman

On Thu, 11 Jul 2019 at 22:30, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi Cyril, > > > > I had a particular use-case in Sentry Logger (adopted from old ShoreLine reporter) that added a "Report" button to the pre-debugger (via a PreDebugAction subclass). Not having the button is fine for me (automated reporting is always better), just wanted to mention it. > > > > What I am wondering more is whether eliminating the pre-debugger would make it much harder to add something like "Production pre-debug window" that contains alternative content that doesn't scare non-technical people. > > > > Not all users of Pharo are Pharo developers, so dropping on them the full debugger is not good. > > Would it be cleaner to enable by default the Always Open Full Debugger, and then it can be toggled off when building production images? > > > > Or did you have some other alternatives in mind? > > > > Hi Peter, > > With changes introduced with the GTDebbuger it is possible to register > alternative debuggers. They have a priority and know if they need to > open depending on the context. > > We discussed with Steven and Thomas from the RMoD team and we think > this is cool like that we can register alternative debuggers. That would be cool - especially if it comes with a good Settings UI to make it more discoverable and good in-Image Help on how to create such an alternative debugger ;) cheers -ben

July 12, 2019

Re: [Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

by Mariano Martinez Peck

Hi Christophe, First of all, THANK YOU a lot for putting together this great work. This was long overdue and I never had the available time for doing it. We can discuss implementation details of OSSubprocess as much as we want, but I was personally quite satisfied with the API. So if you could come up with a similar API for Windows, I very much welcome that. And you can see even in OSSubprocess github issues that it has been asked a few times. As for the pipes...one short term solution you may want to try is to use files. If you see the whole API of OSSubprocess is polymorphic to the type of the underlying streams used for standard streams. So, for stdout, stderr, stdin etc... you can choose to either use pipes or ... regular files. In fact, in the tests, you can see 2 subclasses...one that tests all the tests with pipes and the other one with files. Finally, it explained here the differences: https://github.com/pharo-contributions/OSSubprocess#regular-files-vs-pipes Anyway, just thought I could throw my 2 cents. Congratulations, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

July 11, 2019

[Pharo 8.0] Build #474: 3891-Rename-method-refactoring-does-not-work-anymore

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

There is a new Pharo build available! The status of the build #474 was: FAILURE. The Pull Request #3892 was integrated: "3891-Rename-method-refactoring-does-not-work-anymore" Pull request url: https://github.com/pharo-project/pharo/pull/3892 Issue Url: https://github.com/pharo-project/pharo/issues/3891 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Peter Uhnak

Hi Cyril, thanks for the info! Being able to specify a top priority production debugger is definitely a better solution (instead of me trying to hack around pre-debugger :)). Thanks! Peter On Thu, Jul 11, 2019 at 4:30 PM Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi Cyril, > > > > I had a particular use-case in Sentry Logger (adopted from old ShoreLine > reporter) that added a "Report" button to the pre-debugger (via a > PreDebugAction subclass). Not having the button is fine for me (automated > reporting is always better), just wanted to mention it. > > > > What I am wondering more is whether eliminating the pre-debugger would > make it much harder to add something like "Production pre-debug window" > that contains alternative content that doesn't scare non-technical people. > > > > Not all users of Pharo are Pharo developers, so dropping on them the > full debugger is not good. > > Would it be cleaner to enable by default the Always Open Full Debugger, > and then it can be toggled off when building production images? > > > > Or did you have some other alternatives in mind? > > > > Hi Peter, > > With changes introduced with the GTDebbuger it is possible to register > alternative debuggers. They have a priority and know if they need to > open depending on the context. > > We discussed with Steven and Thomas from the RMoD team and we think > this is cool like that we can register alternative debuggers. > > On top of that, we would like to add the concept of fallback in case > there is a problem. > > Currently, when the debugger bug, the emergency evaluator is open. We > would like to open the next available debugger instead of the > emergency evaluator. Then the emergency evaluator would be the last in > the list. > > Also, an another subject, the button report can still be added to the > full debugger. > > > Peter > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > >

July 11, 2019