profile
viewpoint
Eric Mertens glguy @GaloisInc Portland, Oregon

ekmett/lens 1693

Lenses, Folds, and Traversals - Join us on freenode #haskell-lens

ekmett/ad 301

Automatic Differentiation

ekmett/linear 162

Low-dimensional linear algebra primitives for Haskell.

ekmett/hask 159

Category theory for Haskell with a lens flavor (you need GHC 7.8.3, not 7.8.2 to build this!)

ekmett/free 128

free monads

ekmett/bound 99

Combinators for manipulating locally-nameless generalized de Bruijn terms

ekmett/gl 79

Complete raw OpenGL bindings for Haskell

ekmett/contravariant 70

Haskell 98 contravariant functors

ekmett/comonad 68

Haskell 98 comonads

ekmett/kan-extensions 62

Kan extensions, Kan lifts, the Yoneda lemma, and (co)monads generated by a functor

pull request commentge-high-assurance/RACK

Combine RACK workflow files

@langston-barrett Can you take a look at the test job's output? Especially https://github.com/ge-high-assurance/RACK/pull/239/checks?check_run_id=1488050269#step:11:119 which seems to show that a test failed, yet the test job itself still succeeded. Was the test supposed to fail but the test job still succeed?

tuxji

comment created time in a few seconds

push eventge-high-assurance/RACK

John Interrante

commit sha 03d2bd4bb392a15cca027ab9064785e8a0692ae0

Don't upgrade pip in lint job Was trying to make a pip warning go away, but got a pip error instead. ERROR: Cannot install -r cli/dev/requirements.txt (line 4) and pytest==6.0 because these package versions have conflicting dependencies. ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

view details

push time in an hour

PR opened ge-high-assurance/RACK

Combine RACK workflow files

Strictly speaking, we don't need separate workflow files for jobs that share the same trigger conditions. Such jobs can go in the same workflow file, so let's reduce the number of separate workflow files to only two (continuous.yml for continuous lint, test, and build jobs and release.yml for release build jobs).

+241 -247

0 comment

5 changed files

pr created time in an hour

create barnchge-high-assurance/RACK

branch : ji/combine-workflows

created branch time in an hour

push eventge-high-assurance/RACK

Valentin Robert

commit sha 6b86fbf9150038a2169a40a5fb1d2b0b4d1c10a2

ada: importing future must happen first

view details

push time in an hour

pull request commentekmett/lens

Allow bytestring-0.11

Yes, Cabal is patched. Cabal-3.4 will build with bytestring-0.11.

But the bounds are not relaxed as e.g. there is no text release. So there is a chain.

Bodigrim

comment created time in 2 hours

startedglguy/advent2020

started time in 3 hours

startedglguy/advent2019

started time in 4 hours

push eventge-high-assurance/RACK

Valentin Robert

commit sha b6c67963c44cac42ed4ef54e8121531321c7023d

ada: update format for github requirements

view details

push time in 4 hours

push eventge-high-assurance/RACK

Valentin Robert

commit sha 83d9ebb38b80d5e3368d461e7471b519a5bc3389

ada: add unit method to AdaNode typings

view details

Valentin Robert

commit sha 2ab1bd7d91d8e41ee089cae5f67ed47a70907cdb

ada: improve handling of filenames

view details

Valentin Robert

commit sha 07261b83dcd6d6b1fcf0b9b8f10a2898526c6f2b

ada: copyrights and docstrings

view details

push time in 4 hours

pull request commentekmett/lens

Allow bytestring-0.11

As far as I know, no, GHC-9.0.1 will ship bytestring-0.11.x.y.

I see. In that case, it's likely that I'll need to rebuild boot libraries anyway. The thing that tripped me up was actually a different library than what you mentioned: Cabal.

[ 17 of 242] Compiling Distribution.Utils.Structured ( Distribution/Utils/Structured.hs, dist/build/Distribution/Utils/Structured.o, dist/build/Distribution/Utils/Structured.dyn_o )

Distribution/Utils/Structured.hs:90:1: error:
    Could not load module ‘Data.ByteString.Lazy.Builder’
    It is a member of the hidden package ‘bytestring-0.10.10.0’.
    Perhaps you need to add ‘bytestring’ to the build-depends in your .cabal file.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
90 | import qualified Data.ByteString.Lazy.Builder as Builder
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Do you know if Cabal has been patched upstream to support bytestring-0.11? I noticed that the master branch of Cabal still has bytestring < 0.11 bounds, but perhaps I'm looking in the wrong place.

Bodigrim

comment created time in 6 hours

pull request commentekmett/lens

Allow bytestring-0.11

Speaking of which, is GHC 9.0.1 slated to include bytestring-0.11?

As far as I know, no, GHC-9.0.1 will ship bytestring-0.11.x.y. But I also assumed GHC-9.0 will be out in September, so don't trust me on that.

Bodigrim

comment created time in 6 hours

pull request commentekmett/lens

Allow bytestring-0.11

I ended up building my own local repository (url: file+noindex:///....) with patched packages, with e.g. text, hashable, attoparsec patches applied.

Ah, I was afraid that that might be the case. This is why I procrastinated on doing bytestring-related maintenance until there was a GHC (pre-)release that bundled bytestring-0.11. Speaking of which, is GHC 9.0 slated to include bytestring-0.11? If so, I might hold off on the task in https://github.com/ekmett/lens/pull/948#issuecomment-737173423 until that is out.

Bodigrim

comment created time in 7 hours

pull request commentekmett/lens

Allow bytestring-0.11

That said, We can have a policy that if dependency relaxation is not achievable without jumping through the hoops, we'll leave PRs / issues open until there are install plans.

Bodigrim

comment created time in 7 hours

pull request commentekmett/lens

Allow bytestring-0.11

I ended up building my own local repository (url: file+noindex:///....) with patched packages, with text, hashable, attoparsec patches applied. It's cumbersome (if you really want to test pre GHC-8.0 - no pattern synonym case).

Bodigrim

comment created time in 7 hours

pull request commentekmett/lens

Allow bytestring-0.11

To be clear, I trust @Bodigrim's judgment too! I'm mainly interested in learning how to do this so that I don't have to bug other people to figure out if my code is bytestring-0.11-compliant or not :)

Bodigrim

comment created time in 7 hours

pull request commentekmett/lens

Allow bytestring-0.11

I expect bytestring maintainer to know what they are doing, when they say upgrading is fine.

Bodigrim

comment created time in 7 hours

pull request commentekmett/lens

Allow bytestring-0.11

Thanks!

For future reference, how were you able to test this? The last time I tried building libraries with bytestring-0.11, I ran into several issues with boot libraries failing to compile. I'm interested in figuring this out since there is another restrictive upper version bound on bytestring in this repo that I'd like to lift:

https://github.com/ekmett/lens/blob/c83fc0e7a731db322de450cf981814ca7f0228ca/examples/lens-examples.cabal#L43

But I'd hate to just lift the bounds without having tested it myself first.

Bodigrim

comment created time in 7 hours

push eventekmett/lens

Bodigrim

commit sha 1debced4e9cb8b904b1f52c3ab10a551e40f3b2d

Allow bytestring-0.11

view details

Oleg Grenrus

commit sha c83fc0e7a731db322de450cf981814ca7f0228ca

Merge pull request #948 from Bodigrim/bytestring-0.11 Allow bytestring-0.11

view details

push time in 11 hours

PR merged ekmett/lens

Allow bytestring-0.11
+5 -1

0 comment

2 changed files

Bodigrim

pr closed time in 11 hours

issue commentge-high-assurance/RACK

perform sanity check of ontology model

Dave,

Here are my remaining comments:

[cid:image001.png@01D6C841.AC58D2A0] mitigates was changed to have a range for the property of HAZARD, rather than entity. What is the virtue in having this range restricted? As I said before, if a new entity type of FAILURE_CONDITION is created I could see wanting to identify the requirements that are mitigating that failure condition. This really is a comment that I would applies more generally. What are we gaining by having range restrictions in the base ontology that are more specific than ENTITY, ACTIVITY, or AGENT. While I could see some minor confusion that could stem from this openness when people first start using the tool, but eventually people while have to understand how to work with this as it will have to occur for ranges of some things. The tool in general is going to be much more useable in the long term the more flexibility that it has so anytime we are wanting to limit this flexibility we should have a clear and obvious reasons why. In my mind this applies to things such as cardinality as well. For example: [cid:image002.png@01D6C844.ADC860D0] The “givenText” on REQUIREMENT had a cardinality restriction add of at most 1 value, Why? I could see multiple “givenText” if you have more than one precondition. This is maybe not the strongest case because I wonder if these should be part of a TA specific ontology on not the core ontology. Even something like author for a REVIEW. I have participated in a many review where multiple people’s work where combined into a single review, why would we not support this? Things like dates, and statuses I absolutely agree can have cardinality restrictions, but just like the range we should be 100% confident that it is absolutely an error and I would argue it is better to error on the side of flexibility.

SystemComponent is being changed to SYSTEM in DevelopmentPlanData.sadl: [cid:image004.jpg@01D6C84A.D46B1150] SystemComponent was defined in the Turnstile extension of the ontology this should remain as is. COMPONENT was changed to SWCOMPONENT: [cid:image007.png@01D6C847.5EF0F050] This changes was not maintained for the Threads:bu[cid:image006.png@01D6C846.E0BDF660] But they were updated for the rules associated with this: [cid:image008.png@01D6C848.93A9AF20] This should just be made consistent, otherwise extracting the data will miss some relationships.

  • I don't think it is correct to change file:statisfies to Rq:satisfies, the domain for the property is FILE, so it should be using the file version. This might be a place where maybe we want to add a new fundamental relationship. Satisfies is a relationship that I could see having on many different classes. By defining it as a new fundamental relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can see that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES property that is defined for attaching it to REQUIREMENT instances. Again, I think that there's a major error in the modeling approach of being able to use any relationship from anywhere in the model to connect any entity instance types you might choose. By the way, file:satisfies has been removed.

The issue with this is that in SADL and the underlying OWL, “File has satisfies Req” is not interchange able with “Req has satisfies Req” the Domain for the first is File while in the later it is Req. If satisfies was removed from file this is likely not going to work as it will no longer show up in the nodes for SemTK and will likely cause an error on ingestion. To only have the property on Requirements you would have to have two properties a satisfies and satisfiedBy then you could write “Req has satisfiedBy File”.

The my final question for today is my the PROV primer describes derivation as “ When one entity's existence, content, characteristics and so on are at least partly due to another entity, then we say that the former was derived from the latter.” With this thing like “satisfies” would fall into that definition for derivation so why are we say that is not applicable. One of the big benefits for using the PROV base is to be able to with a very simple query, answer the question, “if I change this entity, what are the downstream entities that would now be suspect”. With these changes I am not sure we still be able to do those queries simply you would have to look at all the relationships and make a “uber-query” that looks at all the independent properties that are entity specific.

Since we are not going to try and squeeze this to the current release going forward maybe the best way to hash out these discussion is by having a pull request and putting comments as part of that. That way we can really look at each of the changes in context and have a pointed discussion that that.

Dan

From: Dave Archer notifications@github.com Sent: Monday, November 30, 2020 11:07 AM To: ge-high-assurance/RACK RACK@noreply.github.com Cc: Russell, Daniel (GE Aviation, US) Daniel.Russell@ge.com; Mention mention@noreply.github.com Subject: EXT: Re: [ge-high-assurance/RACK] perform sanity check of ontology model (#219)

Hi Dan,

On Wed, Nov 25, 2020 at 8:37 PM russell-d-e <notifications@github.commailto:notifications@github.com> wrote:

My Notes/Question,:

  • it seems that some of the changes are over specifying, for example "governs" for requirements being restricted to SYSTEM, COMPONENT, TEST, FILE, REVIEW. What about INTERFACE, it would be quite logical to define REQUIREMENTs for governing a INTERFACE. This over all is the issue with restricting the ranges on these class. It does not provide much if any benefit however it does restrict the possibilities on how things can be used.

already removed, because SemTK doesn't support these restrictions. You may not have the most recent version of this branch.

  • Changing mitigates to avoids, beyond that fact that you likely cannot avoid a hazard, mitigate is the common terminology that I have always heard in relation the Hazards why are we picking a new term. Again it seems adding the HAZARD restriction is not necessary. In the future I could see someone wanting to capture something like FAILURE_CONDITION that you may what to have mitigating REQUIREMENTS for.

Not sure where you're seeing avoids in the current branch? You might want to pull the branch again.

Note that mitigates is defined only for HAZARD. A separate relationship would be needed in FAILURE_CONDITION for it to be mitigated by a REQUIREMENT. I think that one of the problems with SADL is that it seems allowable to attach a relationship defined anywhere to whatever entity instance you choose - that's strictly disallowed in the E-R model. I think it would be worth revisiting the restriction issue with some of the tenets of E-R in mind?

  • *Why is SystemComponent being changed to SYSTEM, this was defined as part of the turnstile planning?

I'm not sure what file you're referring to here. I think that might be an error, since SystemComponent is a type of SYSTEM anyway.

  • Why did you not change ExecutiveThread, InputThread, and OutputThread to SYSTEM instead of SWCOMPONENT?

I made only changes to Turnstile that allow it to compile successfully, and where the semantics were clear to me. I'm not sure what kind of thing the "thread" abstraction is, or how it's intended to be used in assurance cases. Do we know what TA1's have in mind here?

  • I don't think it is correct to change file:statisfies to Rq:satisfies, the domain for the property is FILE, so it should be using the file version. This might be a place were maybe we want to add a new fundamental relationship. Satisfies is a relationship that I could see having on many different classes. By defining it as a new fundamental relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can see that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES property that is defined for attaching it to REQUIREMENT instances. Again, I think that there's a major error in the modeling approach of being able to use any relationship from anywhere in the model to connect any entity instance types you might choose. By the way, file:satisfies has been removed.

  • For DATA_DICTIONARY_TERM, providedBy and consumedBy are identified as two separate relationships as they show directionality of the relationship, for example in the turnstile example there are requirements that produce some data dictionary terms and consume other data dictionary terms. Directionality is something that can be very important if the data dictionary terms are being used do perform something like a data and control coupling analysis.

I don't think I changed these properties - only removed the statement that they were types of wasDerivedFrom, which is incorrect. At least that was my aim!

  • Why is Rv:governedBy changed to Rq:governedBy? governedBy is defined in the REVIEW.sadl?

governedBy was removed from REVIEW.sadl - you may not have the correct pull of the branch...

Hope this helps! Let me know if you have more questions!

/d

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-734069093, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJXTPZKM2P4DPD4X5VVJOTSRXLR7ANCNFSM4TKJZZWA .

-- Dave Archer, PhD https://galois.com/team/david-archer/ Principal Scientist Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300, Portland, OR 97204 email dwa@galois.commailto:dwa@galois.com SMS/phone +1(503)701-0235 (use Signal if possible) https://www.mypronouns.org/he-him

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ge-high-assurance/RACK/issues/219#issuecomment-735880140, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AO6MHPOFAHRT572ULSHXUWTSSO7JBANCNFSM4TKJZZWA.

kityansiu

comment created time in 12 hours

PR opened ekmett/lens

Allow bytestring-0.11
+5 -1

0 comment

2 changed files

pr created time in 18 hours

Pull request review commenthaskell/unix

GitHub Actions

+name: ci+on:+  push:+    branches:+      - master+      - 2.7+  pull_request: {}++defaults:+  run:+    shell: bash++jobs:+  build-old:+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: true+      matrix:+        os: [ubuntu-latest]+        ghc: ['7.8.4', '7.6.3', '7.4.2']+    steps:+    - uses: actions/checkout@v2+    - uses: actions/cache@v2+      name: Cache cabal stuff+      with:+        path: |+          ${{ steps.setup-haskell-cabal.outputs.cabal-store }}+          dist-newstyle+        key: ${{ runner.os }}-${{ matrix.ghc }}+    - name: Install GHC+      run: |+        sudo add-apt-repository ppa:hvr/ghc -y+        sudo apt-get update+        sudo apt-get install ghc-${{ matrix.ghc }}+    - name: Build+      run: |+        autoreconf -i+        cabal sdist -z -o .+        cabal get unix-*.tar.gz+        cd unix-*/+        cabal build -w /opt/ghc/bin/ghc-${{ matrix.ghc }} all+    - name: Haddock+      run: cabal haddock -w /opt/ghc/bin/ghc-${{ matrix.ghc }}++  build:+    needs: build-old+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: true+      matrix:+        os: [ubuntu-latest, macOS-latest]+        ghc: ['8.10', '8.8', '8.6', '8.4', '8.2', '8.0', '7.10']

approved

Bodigrim

comment created time in 20 hours

Pull request review commenthaskell/unix

GitHub Actions

+name: ci+on:+  push:+    branches:+      - master+      - 2.7+  pull_request: {}++defaults:+  run:+    shell: bash++jobs:+  build-old:+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: true+      matrix:+        os: [ubuntu-latest]+        ghc: ['7.8.4', '7.6.3', '7.4.2']+    steps:+    - uses: actions/checkout@v2+    - uses: actions/cache@v2+      name: Cache cabal stuff+      with:+        path: |+          ${{ steps.setup-haskell-cabal.outputs.cabal-store }}+          dist-newstyle+        key: ${{ runner.os }}-${{ matrix.ghc }}+    - name: Install GHC+      run: |+        sudo add-apt-repository ppa:hvr/ghc -y+        sudo apt-get update+        sudo apt-get install ghc-${{ matrix.ghc }}+    - name: Build+      run: |+        autoreconf -i+        cabal sdist -z -o .+        cabal get unix-*.tar.gz+        cd unix-*/+        cabal build -w /opt/ghc/bin/ghc-${{ matrix.ghc }} all+    - name: Haddock+      run: cabal haddock -w /opt/ghc/bin/ghc-${{ matrix.ghc }}++  build:+    needs: build-old+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: true+      matrix:+        os: [ubuntu-latest, macOS-latest]+        ghc: ['8.10', '8.8', '8.6', '8.4', '8.2', '8.0', '7.10']

build-old is for configurations unsupported by actions/setup-haskell (and underlying ghcup), which is GHC < 7.10.

Bodigrim

comment created time in 21 hours

Pull request review commenthaskell/unix

GitHub Actions

+name: ci+on:+  push:+    branches:+      - master+      - 2.7+  pull_request: {}++defaults:+  run:+    shell: bash++jobs:+  build-old:+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: true+      matrix:+        os: [ubuntu-latest]+        ghc: ['7.8.4', '7.6.3', '7.4.2']+    steps:+    - uses: actions/checkout@v2+    - uses: actions/cache@v2+      name: Cache cabal stuff+      with:+        path: |+          ${{ steps.setup-haskell-cabal.outputs.cabal-store }}+          dist-newstyle+        key: ${{ runner.os }}-${{ matrix.ghc }}+    - name: Install GHC+      run: |+        sudo add-apt-repository ppa:hvr/ghc -y+        sudo apt-get update+        sudo apt-get install ghc-${{ matrix.ghc }}+    - name: Build+      run: |+        autoreconf -i+        cabal sdist -z -o .+        cabal get unix-*.tar.gz+        cd unix-*/+        cabal build -w /opt/ghc/bin/ghc-${{ matrix.ghc }} all+    - name: Haddock+      run: cabal haddock -w /opt/ghc/bin/ghc-${{ matrix.ghc }}++  build:+    needs: build-old+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: true+      matrix:+        os: [ubuntu-latest, macOS-latest]+        ghc: ['8.10', '8.8', '8.6', '8.4', '8.2', '8.0', '7.10']

should 7.10 be in build-old?

Bodigrim

comment created time in 21 hours

pull request commenthaskell/unix

GitHub Actions

Updated after I learned more GitHub Actions tricks. @hvr ping CC @chessai

Bodigrim

comment created time in 21 hours

push eventge-high-assurance/RACK

John Interrante

commit sha fee08f6cb2da43a093f33f10ee9d6f56f917e62f

Update SemTK version to v2.3.0-20201201 Also fix minor typos and inconsistencies between workflows, that is, make test.yml more similar to rack-box-continuous.yml (once we test this push, then let's merge them together).

view details

push time in a day

issue commentge-high-assurance/RACK

perform sanity check of ontology model

John is in the process of making the pre-release; so please wait on pushing the changes to master.

kityansiu

comment created time in a day

issue commentge-high-assurance/RACK

perform sanity check of ontology model

On Wed, Nov 25, 2020 at 10:47 AM AbhaMoitra notifications@github.com wrote:

Couple of notes / questions:

we need a cardinality restriction on agentName

fixed to max 1

do I remember correctly that when we went over the changes last week that Eric verified that SemTK does not handle "H:source of HAZARD must be one of {HAZARD, sw:SWCOMPONENT, sys:SYSTEM}." and that is why it is commented out. However, I see "sw:performedBy of CODE_GEN must be one of {Ag:PERSON, Ag:ORGANIZATION}." etc.

commented out now

Why did we add unneeded "imports" to REQUIREMENTS.sadl, it makes the visualization less clear. Based on other changes in this file, you do need to now import HAZARD. Similar comment on other files.

Aside from imports of PROV-S, I've checked all imports and removed all but those that otherwise induce errors. The result is that SOFTWARE imports FILE and AGENTS REQUIREMENTS imports HAZARD HAZARD now imports only SYSTEM ANALYSIS now imports only DOCUMENT REVIEW now imports only DOCUMENT SYSTEM now imports only DOCUMENT

I'll push these changes shortly. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-733888444, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJXTP3VJUT466FSM2SK6ATSRVGNRANCNFSM4TKJZZWA .

-- Dave Archer, PhD https://galois.com/team/david-archer/ Principal Scientist Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300, Portland, OR 97204 email dwa@galois.com SMS/phone +1(503)701-0235 (use Signal if possible) https://www.mypronouns.org/he-him

kityansiu

comment created time in a day

GollumEvent
more