-
Notifications
You must be signed in to change notification settings - Fork 5
Jmafoster1/scenario #370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jmafoster1/scenario #370
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #370 +/- ##
==========================================
+ Coverage 96.64% 97.22% +0.58%
==========================================
Files 28 27 -1
Lines 1608 1551 -57
==========================================
- Hits 1554 1508 -46
+ Misses 54 43 -11
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
@jmafoster1 This is quite a big change, but it is something I raised several months ago. My main point was that the casual specification class is programmatically redundant (even more so now that you're suggesting removing the modelling scenario class). But, I now think that we need to stay loyal to the original idea of the framework to some degree. Probably best talking about this in our meeting tomorrow before making any more changes. |
Philosophically, I reject this on the basis that the framework has grown and changed so much from the original idea, but I think your point about the As a sidenote, is there a way to make running the tutorials part of the PR actions so they don't become out of date? |
|
Following on from our meeting this morning, I'll close this one in favour of #371, which is more modular and faithful to the original vision for the CTF. |
This PR removes the
Scenarioclass and merges what we need into theCausalSpecificationclass.I appreciate that this sounds drastic, but I realised that we weren't testing any of the
Scenarioclass methods. When I investigated, I realised that they were all just infrastructure for Z3, which we stripped out a while ago. Thus, it makes much more sense in my opinion to merge what we do actually need fromScenariointo theCausalSpecificationclass.