1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
title: architecture of skdb
main concepts:
- packages:
- metadata:
- each package has a dependency set, a list of other packages that must be downloaded in order to make the package work
- in the metadata the dependency set is not a list but rather a hierarchical boolean tree
- source or catalog data
- CAD files
- dependencies:
types:
build:
description:
if Y must be used to make the part X
then X has a build dependency on Y
#note not all dependencies are parts (but they must be a package)
examples:
- a screw has a build dependency on a lathe
assembly: comes after the build process; integrates component parts into an assembly part
disassembly: undoes the steps in assembly process; decomposes assembly part into components
use: &use
description:
if part X is unusuable when without Y
then X has a use dependency on Y
examples:
- a screw requires a nut in order to fasten something else
run: *use
software:
description:
if the skdb representation of X is unusuable without the skdb representation of Y
then X has a software dependency on Y
examples:
- library header files required for compiling support into another program
- precompiled object or shared library for link time (i.e., package X requires a shared library from Y if you compile package X)
- precompiled object or shared library for software run time (i.e., package X loads up the lib.so file (not compiled in))
dependency sets:
each package has at least one dependency set that must be satisfied (in special cases that one set can be null)
without satisfaction of a dependency set, the package is probably useless (a broken install)
a package with multiple dependency sets allows there to be unique buildtime, runtime and software dependencies for different situations
for instance, certain buildtime dependencies might demand certain runtime dependencies
- instructions:
description:
sequences of steps for humans and machines for any of the different scenarios (build, run etc.)
usually generated by running instruction generation code from each of the dependencies
wishlist:
- zoomable text detail: see doug engelbart or code folding
- 3D animation:
description: see 'parameterized action representation' papers for neat diagrams
url: http://adl.serveftp.org/papers/instructions/Virtual%20humans%20for%20validating%20maintenance%20procedures.pdf.1.png
- 2D: see lego instructions
- sentence planner: &spud
- generate different sentences that say the same thing given the same input #for disambiguation
- English grammar
- other natural languages
- tree-adjoining grammars: xtag
- virtual human actors to verify and demonstrate instructions
- virtual non-human agents to verify and simulate actions (robots, machinery)
concepts:
- Agent:
- such as a cnc machine, human, computer, something else
- its methods are actions that build scripts can select from
- is a lathe a Part or an Agent?
- Tree:
- top-to-bottom
- root state is at the bottom
- root is the last visited or last added state
- if you were to make a pie, the root node of the recipe tree would be a State with a Pie in it
- when you make a pie you need merge the root state (node) from two trees:
crust making tree:
apple slicing tree:
- State:
- a node in the tree
- contains a list of various objects, maybe a Pie, maybe a Part, etc.
- has an __iter__ method
- Action:
- an edge in the tree
- defined as a method of a particular actor
- no specific sequence of actions unless necessary; step-by-step
instructions are just a particular (optimal) serialization of action dependency tree
questions: #and answers, if you're lucky
- where are steps (in instructions) written down in skdb?
- how do you translate from an action to machine code:
- CAM has a "post processor" which tailors the generic instructions for the individual machine tool/language
- or natural language: *spud
- how do instructions from other packages contribute to instructions for dependent packages?
external references: see f16 maintenance manuals (internal fuel tank vent)
|
