- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Missing tests for FFI in CI

by ducasse

> On 21 Mar 2019, at 13:46, Tim Mackinnon <tim(a)testit.works> wrote: > > That is awesome - great work chasing all of that! > > Any idea of what kinds of things would have been impacted that we can all keep an eye out for or retest? > > Also, Is there anything useful we can add to our process to try and avoid this in the future? tests :) tests are the only way. >> On 21 Mar 2019, at 07:00, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> 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

[Pharo 8.0] Build #168: FAILURE

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

There is a new Pharo build available! The status of the build #168 was: FAILURE. Could not extract further issue information from commit message: Update stale.yml lower stale period for issues: one month is enough Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 21, 2019

[Pharo 8.0] Build #167: Remove flaky test

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

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

March 21, 2019

Re: [Pharo-dev] Missing tests for FFI in CI

by Tim Mackinnon

That is awesome - great work chasing all of that! Any idea of what kinds of things would have been impacted that we can all keep an eye out for or retest? Also, Is there anything useful we can add to our process to try and avoid this in the future? Tim Sent from my iPhone > On 21 Mar 2019, at 07:00, Stephan Eggermont <stephan(a)stack.nl> wrote: > > 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] About a better filedialog

by ducasse

> On 21 Mar 2019, at 10:14, Hilaire <hilaire(a)drgeo.eu> wrote: > > Peter's FileDialog looks so much better than FileList :) :) Stef > > 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

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