You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Implement stateless components.
* Ruff
* More ruff.
* Rework components, pipelines, drivers again.
* Ruff
* chore: ty
* chore: more ty
* chore: ty the third
* docs: update part 1
* Modify workflow to pin ruff version.
* fix failing tests
* fix failing lint
* Another change to ruff stuff and other workflow version stuff.
* Fix out of order execution, again.
* docs: rejig & update
* debug prints in pytest
Copy file name to clipboardExpand all lines: docs/source/quickstart.rst
+37-20Lines changed: 37 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,45 +29,63 @@ Where *appdir* is ``/home/kraus/.config/tomato/1.0a1/``. A custom *appdir* can b
29
29
30
30
**tomato** program flowchart
31
31
````````````````````````````
32
-
**tomato** currently contains two command line user-facing utilities/executables:
32
+
**tomato** currently contains three command line user-facing utilities/executables:
33
33
34
-
- :mod:`~tomato.tomato`, responsible for management of the daemon process, and
35
-
- :mod:`~tomato.ketchup`, responsible for job submission and management.
34
+
- :mod:`~tomato.tomato`, responsible for management of the daemon process,
35
+
- :mod:`~tomato.ketchup`, responsible for job submission and management, and
36
+
- :mod:`~tomato.passata`, providing an interface to the hardware via drivers and components.
36
37
37
-
These two executables then internally spawn other processes, including the state daemon process ``tomato-daemon``, a ``tomato-job`` process for every running job, and a ``tomato-driver`` process for each driver type, managing all devices of a that type.
38
+
These executables then internally spawn other processes, including the state daemon process ``tomato-daemon``, a ``tomato-job`` process for every running job, and a ``tomato-driver`` process for each driver type, managing all devices of a that type.
38
39
39
40
.. mermaid::
40
41
41
42
flowchart TB
42
43
subgraph daemon[tomato-daemon]
43
-
cmd{{port:cmd}} ==> st[(state)]
44
-
st --> jm([job manager])
45
-
st --> dm([driver manager])
46
-
st <--> io[state io]
47
-
end
44
+
cmd{{port:cmd}} <==> cfg[(config)]
45
+
cfg --> jm([job manager])
46
+
cfg --> pm([pip manager])
47
+
cfg --> dm([driver manager])
48
48
49
-
subgraph driver[tomato-driver]
50
-
dcmd{{port:cmd}} ==> dst[(state)]
51
49
end
52
50
53
-
dst o-.-o h1[hardware]
51
+
jm -.-> job
54
52
55
53
subgraph job[tomato-job]
56
54
mp([main loop]) --> tp>task process]
57
55
end
58
56
59
-
cmd ==> db[(job db\nsqlite)]
60
-
jm -.-> db
61
-
mp -.-> db
57
+
jm <-.-> jobdb[(job db\nsqlite)]
58
+
mp -.-> jobdb
59
+
60
+
jm <-.-> pipdb[(pip db\nsqlite)]
61
+
pm <-.-> pipdb
62
+
mp -.-> pipdb
63
+
64
+
dm <-.-> drvdb[(drv db\nsqlite)]
65
+
drvdb <-.-> dst
66
+
67
+
setf[settings file\ndevices file] ---> cfg
62
68
63
69
t>tomato] -.-> cmd
64
70
k>ketchup] -.-> cmd
65
71
66
-
jm -.-> job
67
72
dst -.-> driver
68
73
dm -..-> driver
69
74
tp -.-> dcmd
70
75
76
+
subgraph driver[tomato-driver]
77
+
dcmd{{port:cmd}} ==> dst[(state)]
78
+
end
79
+
80
+
dst o-.-o h1[hardware]
81
+
82
+
p>passata] -.-> cmd
83
+
p -.-> dcmd
84
+
85
+
.. note::
86
+
87
+
Note that the :mod:`tomato.daemon` process is stateless, only responsible for reading of the configuration files and spawning the *job*, *driver* and *pipeline*--management threads. All configuration and state information that should be persistently stored (i.e. survive restart of the components) is stored in a :mod:`sqlite3` database.
88
+
71
89
.. _concepts:
72
90
73
91
**tomato** concepts flowchart
@@ -141,6 +159,7 @@ The following concepts are used in **tomato**:
141
159
142
160
pip3[pipeline 3] -.-> c3
143
161
162
+
.. _settings-file:
144
163
145
164
Settings file
146
165
`````````````
@@ -212,6 +231,8 @@ Additional, *driver*-specific settings may be provided in this section. Each *dr
212
231
213
232
Further *driver*-specific settings, such as ``dllpath`` or ``calibration``, can be specified here. All of these *driver*-specific settings are passed to each *driver* when its process is launched and the :class:`DriverInterface` is initialised, and can therefore contain paths to various libraries or other files necessary for the *driver* to function.
214
233
234
+
.. _devices-file:
235
+
215
236
Devices file
216
237
````````````
217
238
This ``yaml``-formatted file contains information about each *device*, corresponding to an individual piece of hardware managed by **tomato**, as well as information about the organisation of the individually-addressable *components* of those *devices* into *pipelines*.
@@ -341,7 +362,3 @@ As of ``tomato-2.0``, the :obj:`task_params` specified in the *payload* are vali
Copy file name to clipboardExpand all lines: docs/source/usage.rst
-8Lines changed: 0 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -216,11 +216,3 @@ While the *job* is running, access to an up-to-date snapshot of the data is prov
216
216
>>> ketchup snapshot <jobid>
217
217
218
218
This will create an up-to-date ``snapshot.<jobid>.nc`` file in the current working dir. The files are overwritten on subsequent invocations of ``ketchup snapshot``. An automated, periodic snapshotting stored in a custom location can be further configured within the *payload* of the *job*.
0 commit comments