-
Notifications
You must be signed in to change notification settings - Fork 25
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
Add scope, motivation, and software review information to generated software-READMEs #3248
base: main
Are you sure you want to change the base?
Changes from 16 commits
316318c
ba4d31a
973da48
571c4ac
1c91a7c
87045e6
489d3c1
7136b17
7353304
1ef62c8
5d8f5e3
c33bfcc
e61d585
593e688
093493c
335268a
1355c24
f4adbb9
9881278
ad0fce2
5512a58
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -49,6 +49,12 @@ data CodeSpec where | |
purpose :: Purpose, | ||
-- | Example Background. | ||
background :: Background, | ||
-- | Example Scope. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why are these all Futhermore, are we now requiring all this information for all codes? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My guess is that these were meant to specify that it is the purpose, etc., of the example itself, but I think this is a bit redundant There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe |
||
scope :: Scope, | ||
-- | Example Software Review. | ||
sftwr_rev :: SoftwareReview, | ||
-- | Example Motivation. | ||
motivation :: Motivation, | ||
-- | All inputs. | ||
inputs :: [Input], | ||
-- | Explicit inputs (values to be supplied by a file). | ||
|
@@ -100,6 +106,9 @@ codeSpec SI {_sys = sys | |
, _authors = as | ||
, _purpose = ps | ||
, _background = bk | ||
, _scope = scp | ||
, _sftwr_rev = sfrv | ||
, _motivation = mtvtn | ||
, _instModels = ims | ||
, _datadefs = ddefs | ||
, _configFiles = cfp | ||
|
@@ -125,6 +134,9 @@ codeSpec SI {_sys = sys | |
authors = as, | ||
purpose = ps, | ||
background = bk, | ||
scope = scp, | ||
sftwr_rev = sfrv, | ||
motivation = mtvtn, | ||
inputs = allInputs, | ||
extInputs = inputs', | ||
derivedInputs = derived, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -104,6 +104,9 @@ si = SI { | |
_authors = [naveen], | ||
_purpose = [], | ||
_background = [], | ||
_motivation = [], | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reviewing multiple examples in a row that all set these 3 things to be empty. This really does start to feel like a hack. If we're going to implement a feature, shouldn't we be using it in all the examples? Just using it in Projectile does not convince me that this is a feature that is implemented at the right level. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We do have a form of this information that we write for the SRS documents, as we just recently did for #3777. It would be nice if we could share them with a chunk that defines what the purpose, background, and motivation of each case study, respectively, is. This is also related to #3773. The specific purpose, background, and motivation of each case study are just instances of the generic concepts of purpose, background, and motivation. In other words, for our current design, these might just be unique There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, actually, would it be nice to share the same SRS discussion of the purp., back., and moti. in the generated READMEs? I'm not sure anymore. We might want a longer version of that in the SRS, and a shorter one here. @smiths do you have any thoughts on this? Do you think we can share them? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @balacij I think for every example we should be able (if we haven't already) to write a one sentence purpose. This one sentence purpose would fit nicely in the README. It should also be usable in the SRS. As @NoahCardoso recently did, we can reuse the purpose in the Introduction to the SRS. Although we haven't done it yet, I could see us wanting to have a longer version of the purpose for the SRS. For instance, our one sentence purpose could be something like: The software library provides a multi-domain Lattice Boltzmann solver. (I'm working on a project with a colleague in mechanical engineering that could be described with that sentence.) The problem with this one sentence purpose is that it introduces at least two concepts that not everyone will be familiar with. This could be fine in a README file, but in the SRS, a description of what multi-domain means and what Lattice Boltzmann means would be in order. Following #3773, we could say that the purpose is an idea definition that includes two other idea definitions. In the README we might not generate the text for the definitions of the sub-ideas, but for the SRS, this would be a natural thing to do. We could go through a similar conversation for Motivation and Scope. I think Motivation would be fairly simple, but Scope does get more involved. There are different views of Scope. There is a simple "high level" view, and then there is the view that decomposes the Scope into Scope Decisions (things that are entirely left out) and Assumptions. The Scope can also include typical values and examples. |
||
_scope = [], | ||
_sftwr_rev = [], | ||
_quants = symbolsAll, | ||
_concepts = [] :: [DefinedQuantityDict], | ||
_datadefs = dataDefinitions, | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this information that is quite specific to the
README
has really gotten too large to fit inLanguage.Drasil.Code.Imperative.GOOL.ClassInterface
. This should be split out into its own file.It doesn't even belong to
Language.Drasil.Code.Imperative
, as it is quite independent of that. Finding a better home needs a design.