-
Notifications
You must be signed in to change notification settings - Fork 22
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adding the remainder of the wiki docs.
Significant editing remains. There are many broken links and plenty of editing and formatting needed. Rather than hold this up I will merge with the expectation that others will contribute to the clean up.
- Loading branch information
1 parent
1847b9b
commit baadb60
Showing
51 changed files
with
2,860 additions
and
287 deletions.
There are no files selected for viewing
105 changes: 105 additions & 0 deletions
105
docs/source/activity-command-expansion/create-an-expansion-set.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,105 @@ | ||
# Create An Expansion Set | ||
|
||
Think of an "expansion_set" as a way of grouping expansion logic to different versions of mission models | ||
or command dictionaries. | ||
|
||
For example, say you have a mission model and command dictionary version 1. You have written expansion | ||
logic that uses commands from the command dictionary. Later the command dictionary or mission model is | ||
updated to version 2. If your original expansion logic was created to only be compatible with the previous | ||
version of the command dictionary or mission model, you need to go through and rewrite/update your | ||
existing logic for all the activity_types. | ||
|
||
An alternative is that you can use the "expansion_set". This will allow you to copy over a set of expansion | ||
logic into a new "expansion_set" without manually changing anything in your code. Some expansion logic | ||
might not be valid anymore but the user can decide which expansion logic to copy over to the new set | ||
containing the updated command dictionary or mission model. | ||
|
||
A future feature will inform users of which expansion rules are compatible/incompatible for the selected | ||
mission model and command dictionary, | ||
making the migration of expansion_sets easier. | ||
|
||
The below GraphQL creates and expansion set for a given command dictionary and mission model which | ||
includes the provided expansions. | ||
|
||
``` | ||
mutation CreateExpansionSet( | ||
$commandDictionaryId: Int! | ||
$missionModelId: Int! | ||
$expansionIds: [Int!]! | ||
) { | ||
createExpansionSet( | ||
commandDictionaryId: $commandDictionaryId | ||
missionModelId: $missionModelId | ||
expansionIds: $expansionIds | ||
) { | ||
id | ||
} | ||
} | ||
``` | ||
|
||
**Ex. 1** | ||
|
||
That was a lot to take in. Let's create our own expansion set and tie everything together. Below is an | ||
example GraphGL to create an "expansion_set". With the 4 expansion logic defined we want to group them | ||
with command dictionary and mission model version 1. | ||
|
||
``` | ||
{ | ||
"commandDictionaryId": 1, | ||
"missionModelId": 1, | ||
"expansionIds": [1,2,4,9] | ||
} | ||
``` | ||
|
||
**Ex.2** | ||
|
||
Now let us say the mission model has changed and out of the 4 activity_types defined in the mission | ||
model we are dropping one of them. We will only copy over the expansion logic that is valid in this | ||
new set. | ||
|
||
``` | ||
{ | ||
"commandDictionaryId": 1, | ||
"missionModelId": 2, | ||
"expansionIds": [1,2,9] | ||
} | ||
``` | ||
|
||
## List Expansion Sets | ||
|
||
Below is a way to list the created expansion sets in GraphGL: | ||
|
||
``` | ||
query GetAllExpansionSets { | ||
expansion_set { | ||
id | ||
command_dictionary { | ||
version | ||
} | ||
mission_model { | ||
id | ||
} | ||
expansion_rules { | ||
activity_type | ||
id | ||
} | ||
} | ||
} | ||
``` | ||
|
||
Get all `expansion_set`'s for a particular `mission_model` or `command dictionary`: | ||
|
||
``` | ||
query GetSpecificExpansionSet( | ||
$commandDictionaryId: Int! | ||
$missionModelId: Int! | ||
) { | ||
expansion_set(where: {command_dictionary: {id: {_eq: $commandDictionaryId}}, mission_model_id: {_eq: $missionModelId}}) { | ||
id | ||
expansion_rules { | ||
activity_type | ||
id | ||
} | ||
} | ||
} | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
# Create A Sequence | ||
|
||
Sequence creations starts with declaring a new sequence on a simulation dataset. Because of the | ||
complexities with activities in the plans regenerating on simulation, sequences are tied to a | ||
specific simulation run rather than a plan (future work will explore addressing this). | ||
|
||
The API call to do this is a simple mutation | ||
|
||
``` | ||
mutation CreateSequence( | ||
$seqId: String! | ||
$simulationDatasetId: Int! | ||
) { | ||
insert_sequence_one(object: { | ||
simulation_dataset_id: $simulationDatasetId, | ||
seq_id: $seqId, | ||
metadata: {}, | ||
}) { | ||
seq_id | ||
} | ||
} | ||
``` | ||
|
||
Where the seqId is the id you want assigned to the sequence and simulationDatasetId is the id of | ||
the simulation dataset for the simulation you wish to create the sequence for. | ||
|
||
Note: You can only have one of any given seqId for a given simulationDataset |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
# Expand The Plan | ||
|
||
Now for the exciting part! We can finally expand the plan into commands. To do that, we'll need | ||
to set up a couple of things with your plan. | ||
|
||
1. Add an `activity_instances` to the plan which has expansion logic defined in the `expansion_set` | ||
2. Run a simulation on the plan | ||
|
||
### Prerequisite | ||
|
||
At this time you will have to use the Hasura Action API in order to expand the plan into commands. | ||
You will have to retrieve some information needed to expand via the API. The following two values | ||
are needed: | ||
|
||
* `expansionSetID` | ||
* `simulationDatasetId` | ||
|
||
Below is the query to retrieve an `expansionSetID`: | ||
|
||
``` | ||
query GetExpansionSet( | ||
$commandDictionaryId: Int! | ||
$missionModelId: Int! | ||
) { | ||
expansion_set(where: { mission_model_id: { _eq: $missionModelId }, command_dictionary: { id: { _eq: $commandDictionaryId} } }) { | ||
id | ||
} | ||
} | ||
# id : 1 | ||
``` | ||
|
||
Below is the query to retrieve the `simulationDatasetId`: | ||
|
||
``` | ||
query GetSimulationDatasetId( | ||
$planId: Int! | ||
) { | ||
simulation(where: { plan_id: { _eq: $planId } }, order_by: { dataset: { id: desc } }, limit: 1) { | ||
dataset { | ||
id | ||
} | ||
} | ||
} | ||
# id : 5 | ||
``` | ||
|
||
### Expanding | ||
|
||
Below is an example of the Hasura Action you can use to expand a plan: | ||
|
||
``` | ||
mutation ExpandPlan( | ||
$expansionSetId: Int! | ||
$simulationDatasetId: Int! | ||
) { | ||
expandAllActivities(expansionSetId: $expansionSetId, simulationDatasetId: $simulationDatasetId) { | ||
id | ||
expandedActivityInstances { | ||
commands { | ||
stem | ||
} | ||
errors { | ||
message | ||
} | ||
} | ||
} | ||
} | ||
``` |
54 changes: 54 additions & 0 deletions
54
docs/source/activity-command-expansion/expansion-authoring-ide-setup.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
# Expansion Authoring IDE Setup | ||
|
||
Now it is time to start writing the expansion logic for the activity type. The recommended IDE is Visual Studio Code as we are looking at embedding this IDE as a web editor as a future service. Another option is IntelliJ but you will need the paid Ultimate version to use the typescript plugin. | ||
|
||
## Recommended IDE: | ||
* Visual Studio Code: https://code.visualstudio.com/ | ||
* InteliJ: https://www.jetbrains.com/idea/ | ||
|
||
## Setup: | ||
|
||
1. Open a new project folder. You can create a new folder as your workspace | ||
|
||
<img width="1792" alt="Screen Shot 2022-03-14 at 1 31 14 PM" src="https://user-images.githubusercontent.com/70245883/158256230-026205a7-4a3a-4727-80cd-867133fc3740.png"> | ||
|
||
|
||
2. Drag you <activity_library>.ts and <command_library>.ts into you project | ||
|
||
|
||
<img width="1404" alt="Screen Shot 2022-03-14 at 1 35 00 PM" src="https://user-images.githubusercontent.com/70245883/158256720-02186497-83ef-4e83-9ea5-23f3103980e3.png"> | ||
|
||
|
||
3. Create an expansion logic file. You can name it whatever you like. `ex. BakeBananaBreadExpansionLogic.ts` | ||
4. Add the following below which is a boilerplate template | ||
|
||
```ts | ||
// This is the entry point for the expansion - name it whatever you want, it just has to be the default export | ||
export default function CommandExpansion( | ||
// Everything related to this activity | ||
props: { | ||
activityInstance: ActivityType; | ||
} | ||
): ExpansionReturn { | ||
// Commands are fully strongly typed, and intellisense in the authoring editor will | ||
// guide users to write correct expansions | ||
return [ | ||
// COMMAND_A(arg1) | ||
Subroutine(), | ||
// Commands without any arguments omit the () | ||
// COMMAND_C | ||
]; | ||
} | ||
|
||
// You can break it into smaller logical/reusable chunks to make comprehension easier | ||
function Subroutine() { | ||
return [ | ||
//COMMAND_B(arg1,arg2) | ||
]; | ||
} | ||
``` | ||
|
||
## Writing | ||
As you start typing in the editor, notice that each command is validated and type-checked. This means as you write out your logic, the editor will ensure all commands are valid, and that each argument meets the requirements. When you are happy with your logic save your works. | ||
|
||
<img width="1297" alt="Screen Shot 2022-03-29 at 8 47 47 AM" src="https://user-images.githubusercontent.com/70245883/160652341-3a2fde89-dc21-4a1f-be70-03b0549d9f9b.png"> |
70 changes: 70 additions & 0 deletions
70
docs/source/activity-command-expansion/expansion-logic-api.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
# Expansion Logic API | ||
|
||
Here is a list of APIs that AERIE provides to help you build your expansion logic. | ||
|
||
## Activity's Attributes | ||
|
||
You have access to the activity's attributes such as `start time,` `end time`, `duration`, etc | ||
|
||
```typescript | ||
C.ECHO(`Activity's Start Time: ${props.activityInstance.startTime}`), // YYYY-DDDThh:mm:ss | ||
C.ECHO(`Activity's End Time: ${props.activityInstance.endTime}`), // YYYY-DDDThh:mm:ss | ||
C.ECHO(`Activity's Start Offset: ${props.activityInstance.startOffset}`), // hh:mm:ss | ||
C.ECHO(`Activity's Duration: ${props.activityInstance.Duration}`), // hh:mm:ss | ||
|
||
``` | ||
|
||
## Computed Attributes | ||
|
||
You have access to the activity type's computed attributes. You can use these computed attributes in your expansion logic | ||
|
||
```ts | ||
export default function CommandExpansion(props: { | ||
activityInstance: ActivityType; | ||
}): ExpansionReturn { | ||
return [ | ||
PeelBanana(), | ||
C.PREHEAT_OVEN(350), | ||
C.PREPARE_LOAFF(1, false), | ||
C.BAKE_BREAD, | ||
]; | ||
|
||
function PeelBanana(): Command { | ||
if (props.activityInstance.attributes.computed < 2) { | ||
return C.PEEL_BANANA("fromStem"); | ||
} else { | ||
return C.ECHO("Already have enough Banana's peeled..."); | ||
} | ||
} | ||
} | ||
``` | ||
|
||
## Time | ||
|
||
You can specify a time argument for your commands. The time arguments supported are `absolute`, `relative`, and `epoch`. You will be using the Javascript Temporal Polyfill to represent time values. https://tc39.es/proposal-temporal/docs/ | ||
|
||
|
||
* Absolute Time ([Temporal.Instant](https://tc39.es/proposal-temporal/docs/instant.html)): YYYY-DDDThh:mm:ss | ||
* Relative Time ([Temporal.Duration](https://tc39.es/proposal-temporal/docs/duration.html)): hh:mm:ss | ||
* Epoch Time ([Temporal.Duration](https://tc39.es/proposal-temporal/docs/duration.html)): hh:mm:ss | ||
|
||
|
||
```typescript | ||
// Absolute examples | ||
A`2020-060T03:45:19`.ADD_WATER | ||
A(Temporal.Instant.from("2025-12-24T12:01:59Z")).ADD_WATER | ||
A("2020-060T03:45:19").ADD_WATER | ||
|
||
// Relative examples | ||
R`00:15:00`.EAT_BANANA | ||
R(Temporal.Duration.from({ minutes: 15 }).EAT_BANANA | ||
R('00:15:00').EAT_BANANA | ||
|
||
// Epoch examples | ||
E`00:15:30`.PREPARE_LOAF(1,true) | ||
E(Temporal.Duration.from({ minutes: 15, seconds: 30 }).PREPARE_LOAF(1,true) | ||
E('00:15:30').PREPARE_LOAF(1,true) | ||
|
||
// Command Complete examples | ||
C.BAKE_BREAD | ||
``` |
29 changes: 29 additions & 0 deletions
29
docs/source/activity-command-expansion/generate-activity-typescript-library.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
# Generate Activity TypeScript Library | ||
|
||
In order to write an author expansion logic, you will need to know which `activity_types` to use. These `activity_types` are defined in the mission model. | ||
|
||
Upon the selection of an `activity_type`, the command expansion service will generate a typescript library file containing all parameters that can be used when developing your logic. Below is the GraphQL request used to retrieve the library. | ||
|
||
1. Run the graphQL query below | ||
|
||
``` | ||
query GetActivityTypescript($activityTypeName: String!, $missionModelId: Int!) { | ||
getActivityTypeScript(activityTypeName: $activityTypeName, missionModelId: $missionModelId) { | ||
typescriptFiles { | ||
content | ||
filePath | ||
} | ||
reason | ||
status | ||
} | ||
} | ||
``` | ||
|
||
2. Save to a file <activity_type>_activity-types.ts ex. BakeBananaBread_activity-types.ts | ||
|
||
### Return Values | ||
|
||
* content - The typescript library for your activity_type | ||
* filepath - the filename of your library | ||
* reason - If any errors were thrown when generating this library file, the error message would be stored here. If there are no errors, you will get a `null` | ||
* status - server-status ex. 404, 500, 200 |
Oops, something went wrong.