March 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Issue Tracker] installed some robots

by Marcus Denker

They seem to all work. The âStaleâ plugin somehow marked two already merged PRs as staleâ¦ which is odd. But else it seems to work. > On 21 Mar 2019, at 10:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > I have added some robots to the github account https://github.com/pharo-project <https://github.com/pharo-project> > > For for main repository https://github.com/pharo-project/pharo <https://github.com/pharo-project/pharo> I have enabled by adding the required configs to .github/ : > > > Work In Progress: Prevent merging of Pull Requests with "WIP" in the title > https://github.com/marketplace/wip <https://github.com/marketplace/wip> > > No Response: Closes Issues where the author hasn't responded to a request for more information > > If the tag more-information-needed is set and no answer provided, issue is closed in 14 days. > > https://probot.github.io/apps/no-response/ <https://probot.github.io/apps/no-response/> > > Request Info: Requests more info on issues and pull requests with the default title or an empty body. > it sets the more-information-needed flag. > https://probot.github.io/apps/request-info/ <https://probot.github.io/apps/request-info/> > > > Stale: Close stale Issues and Pull Requests > > https://github.com/probot/stale <https://github.com/probot/stale> > Issues: daysUntilStale: 240, daysUntilClose: 60 > Pulls: daysUntilStale: 20, daysUntilClose: 10 > > >

March 21, 2019

Re: [Pharo-dev] Questions about DebugSession>>isContextPostMortem:

by Max Leske

On 21 Mar 2019, at 11:06, Thomas Dupriez wrote: Hi Thomas, > Hello, > > While looking at the DebugSession>>isContextPostMortem: method (code > below), I got three questions: > > 1) There is a check for whether the suspendedContext (top context) of > the process is nil. Does it even make sense for a process not to have > any top context? Yes, only suspended processes have a suspendedContext. Also, the process might have been terminated already. > > 2) It seems that all the last 3 lines are doing is to check whether > selectedContext is in the context chain of the process. Could they be > rewritten into this simpler one-liner? Â `|^ (suspendedContext > hasContext: selectedContext) not`| Yes, I think that would work. > > 3) Overall, this method says that a context C is "post mortem" if the > process controlled by the DebugSession has a top context and C is not > in its context chain. That's the practical definition. Could someone > shed some light on the high-level definition of "post mortem"? Because > "post mortem" is like "after death", but the death of what? A context > that merely belongs to another context chain would be considered "post > mortem" by the practical definition, but there's no death in this > case... > || > You can create a copy of a process' stack. That stack will behave like a process in the debugger but it can't run, as the VM doesn't have a process to which the context are attached, hence it's considered post-mortem. > > ``` > > |DebugSession>>isContextPostMortem: selectedContext "return whether > we're inspecting a frozen exception without a process attached" | > suspendedContext | suspendedContext := interruptedProcess > suspendedContext. suspendedContext ifNil: [ ^ false ]. > (suspendedContext == selectedContext) ifTrue: [ ^ false ]. ^ > (suspendedContext findContextSuchThat: [:c | c sender == > selectedContext]) isNil ``` | > > Does someone know the answer to some (or all) of these questions? > > Thomas Hope that helps. Max

March 21, 2019

[Pharo 8.0] Build #166: FAILURE

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

There is a new Pharo build available! The status of the build #166 was: FAILURE. Could not extract further issue information from commit message: add config for https://github.com/probot/stale Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 21, 2019

Questions about DebugSession>>isContextPostMortem:

by Thomas Dupriez

Hello, While looking at the DebugSession>>isContextPostMortem: method (code below), I got three questions: 1) There is a check for whether the suspendedContext (top context) of the process is nil. Does it even make sense for a process not to have any top context? 2) It seems that all the last 3 lines are doing is to check whether selectedContext is in the context chain of the process. Could they be rewritten into this simpler one-liner? Â `|^ (suspendedContext hasContext: selectedContext) not`| 3) Overall, this method says that a context C is "post mortem" if the process controlled by the DebugSession has a top context and C is not in its context chain. That's the practical definition. Could someone shed some light on the high-level definition of "post mortem"? Because "post mortem" is like "after death", but the death of what? A context that merely belongs to another context chain would be considered "post mortem" by the practical definition, but there's no death in this case... || ``` |DebugSession>>isContextPostMortem: selectedContext "return whether we're inspecting a frozen exception without a process attached" | suspendedContext | suspendedContext := interruptedProcess suspendedContext. suspendedContext ifNil: [ ^ false ]. (suspendedContext == selectedContext) ifTrue: [ ^ false ]. ^ (suspendedContext findContextSuchThat: [:c | c sender == selectedContext]) isNil ``` | Does someone know the answer to some (or all) of these questions? Thomas

March 21, 2019

[Issue Tracker] installed some robots

by Marcus Denker

Hi, I have added some robots to the github account https://github.com/pharo-project <https://github.com/pharo-project> For for main repository https://github.com/pharo-project/pharo <https://github.com/pharo-project/pharo> I have enabled by adding the required configs to .github/ : Work In Progress: Prevent merging of Pull Requests with "WIP" in the title https://github.com/marketplace/wip No Response: Closes Issues where the author hasn't responded to a request for more information If the tag more-information-needed is set and no answer provided, issue is closed in 14 days. https://probot.github.io/apps/no-response/ Request Info: Requests more info on issues and pull requests with the default title or an empty body. it sets the more-information-needed flag. https://probot.github.io/apps/request-info/ Stale: Close stale Issues and Pull Requests https://github.com/probot/stale Issues: daysUntilStale: 240, daysUntilClose: 60 Pulls: daysUntilStale: 20, daysUntilClose: 10

March 21, 2019

[Pharo 8.0] Build #165: 2929-Move-method-comment-parsing-from-Behaviour-to-CompiledMethod

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

There is a new Pharo build available! The status of the build #165 was: FAILURE. The Pull Request #2930 was integrated: "2929-Move-method-comment-parsing-from-Behaviour-to-CompiledMethod" Pull request url: https://github.com/pharo-project/pharo/pull/2930 Issue Url: https://pharo.fogbugz.com/f/cases/2929 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 21, 2019

Re: [Pharo-dev] About a better filedialog

by Hilaire

Peter's FileDialog looks so much better than FileList :) Le 20/03/2019 Ã 20:09, ducasse a Ã©critÂ : > I was thinking the FileList. > Now I will look at the FileDialogWindow :) > > Stef -- Dr. Geo http://drgeo.eu

March 21, 2019

Missing tests for FFI in CI

by Stephan Eggermont

Yesterday, we tracked down a serious issue in 64 bit FFI. After giving up with our own code, we made a fresh start with the latest base image and OSWindows. We were finally able to figure out what went wrong with two simple tests that were failing in 64 bit that worked correctly in 32 bit. FFIConstantHandleType externalType is the wrong size After confirming that and making it work, we were told that a number of FFI fixes were done by Nicolas and Eliot in Squeak that did not get integrated in Pharo. Applying the changes from the latest Squeak FFI resolved the problem, and a few that we were unaware of. Stephan

March 21, 2019

Re: [Pharo-dev] Why everybody could have an impact?

by Tim Mackinnon

Yes, I got to do it (so he could help in a small way) - https://github.com/pharo-project/pharo/issues/2939 And I annotated it. Tim Sent from my iPhone > On 20 Mar 2019, at 20:08, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi tim > > Can you report it precisely because right now it is not actionable. > And yes doing something is a challenge. Doing nothing is much more confortable because nothing breaks, and you die relaxed. > > Stef > >> On 20 Mar 2019, at 20:17, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Ironically - one of my Exercism testers hit an issue with extract method about when you typed this... itâs seems there has a difference between âSuggestions | Extract methodâ and âSource Code | Extract methodâ sigh... the former gives a walk back ... and itâs due to a strange misspelled variable âpreviousSelectionHighligthâ not being initialised. >> >> So yeah - this all needs testing and fixing. >> >> Tim >> >> Sent from my iPhone >> >>> On 20 Mar 2019, at 17:16, ducasse <stepharo(a)netcourrier.com> wrote: >>> >>> Hi >>> >>> to relax I was going over RB code because we will start to improve the refactoring. >>> And I started to add tests (yes the dummy little things that everybody can write but >>> that most people prefer to think they do and talk about). >>> And writing such super super stupid tests >>> >>> testCheckInvalidMethodName >>> "Usually used to validate input." >>> >>> self deny: (RBCondition checkMethodName: 'fofo fo'). >>> self deny: (RBCondition checkMethodName: '123fofo'). >>> "self deny: (RBCondition checkMethodName: 'foo::')." >>> "self deny: (RBCondition checkMethodName: 'agr:goo:aa').â >>> >>> >>> checkMethodName: aString >>> "Return whether the argument aName is can represent a selector" >>> >>> ^ aString isString and: [ RBScanner isSelector: aString ] >>> >>> >>> I found that RBScanner reports that >>> >>> #foo:: or 'agr:goo:aaâ is a valid selector :( >>> >>> So if you **really** want to help pharo this is not that difficult. >>> >>> Now this is a matter of will. >>> >>> Stef >>> >> >> > > >

March 20, 2019

Re: [Pharo-dev] Why everybody could have an impact?

by ducasse

Hi tim Can you report it precisely because right now it is not actionable. And yes doing something is a challenge. Doing nothing is much more confortable because nothing breaks, and you die relaxed. Stef > On 20 Mar 2019, at 20:17, Tim Mackinnon <tim(a)testit.works> wrote: > > Ironically - one of my Exercism testers hit an issue with extract method about when you typed this... itâs seems there has a difference between âSuggestions | Extract methodâ and âSource Code | Extract methodâ sigh... the former gives a walk back ... and itâs due to a strange misspelled variable âpreviousSelectionHighligthâ not being initialised. > > So yeah - this all needs testing and fixing. > > Tim > > Sent from my iPhone > >> On 20 Mar 2019, at 17:16, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Hi >> >> to relax I was going over RB code because we will start to improve the refactoring. >> And I started to add tests (yes the dummy little things that everybody can write but >> that most people prefer to think they do and talk about). >> And writing such super super stupid tests >> >> testCheckInvalidMethodName >> "Usually used to validate input." >> >> self deny: (RBCondition checkMethodName: 'fofo fo'). >> self deny: (RBCondition checkMethodName: '123fofo'). >> "self deny: (RBCondition checkMethodName: 'foo::')." >> "self deny: (RBCondition checkMethodName: 'agr:goo:aa').â >> >> >> checkMethodName: aString >> "Return whether the argument aName is can represent a selector" >> >> ^ aString isString and: [ RBScanner isSelector: aString ] >> >> >> I found that RBScanner reports that >> >> #foo:: or 'agr:goo:aaâ is a valid selector :( >> >> So if you **really** want to help pharo this is not that difficult. >> >> Now this is a matter of will. >> >> Stef >> > >

March 20, 2019