alma/pyalma
1
0
Fork 0
Code Issues 5 Pull Requests Releases Wiki Activity

docs python code blocks

Browse Source
This commit is contained in:
Tom Krüger
2020-12-19 02:15:52 +01:00
parent a64fb38c39
commit 1ba7fd5025
2 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@@ -44,7 +44,7 @@ The experiment description in `example.experiment` roughly translates to: Perfor
###### `example.py` ###### `example.py`
```python3 ```python
def run(instance, save_callback, state): def run(instance, save_callback, state):
# do some stuff on "instance" # do some stuff on "instance"
``` ```
@@ -53,7 +53,7 @@ The `run` function is where the magic happens. For every file in our batch the
Now that we have specified everything, we can start executing our experiment. Now that we have specified everything, we can start executing our experiment.
```python3 ```python
>>> import alma.experiment >>> import alma.experiment
>>> dispatcher = alma.experiment.load("example.experiment") >>> dispatcher = alma.experiment.load("example.experiment")
@@ -62,13 +62,13 @@ Now that we have specified everything, we can start executing our experiment.
The line `dispatcher.start()` starts the concurrent non blocking execution of our experiment. This means the dispatcher stays responsive and we can pause/stop the execution at any given time. The line `dispatcher.start()` starts the concurrent non blocking execution of our experiment. This means the dispatcher stays responsive and we can pause/stop the execution at any given time.
```python3 ```python
>>> dispatcher.stop() >>> dispatcher.stop()
``` ```
During the execution the `dispatcher` continuously keeps track of which files he still needs to call `run(...)` on and how many iterations he has left. He does so by saving the current state of the execution in a file. Loading an experiment (`alma.experiment.load(...)`) the framework first looks for such a save file and if one exists, the execution will pick up at the point we've called `dispatcher.stop()`. To pick up the experiment we can perform: During the execution the `dispatcher` continuously keeps track of which files he still needs to call `run(...)` on and how many iterations he has left. He does so by saving the current state of the execution in a file. Loading an experiment (`alma.experiment.load(...)`) the framework first looks for such a save file and if one exists, the execution will pick up at the point we've called `dispatcher.stop()`. To pick up the experiment we can perform:
```python3 ```python
>>> dispatcher = alma.experiment.load("example.experiment") >>> dispatcher = alma.experiment.load("example.experiment")
>>> dispatcher.start() >>> dispatcher.start()
``` ```

2
docs/run_module.md
View File

@@ -2,7 +2,7 @@
The run module is arguably the most important part of the *alma* interface. It is here where the actual experiment/task has to be implemented. For *pyalma* the run module is merely a python file implementing a specified interface so that *pyalma* can load and execute it. Let's have a look at a short but yet extensive example. The run module is arguably the most important part of the *alma* interface. It is here where the actual experiment/task has to be implemented. For *pyalma* the run module is merely a python file implementing a specified interface so that *pyalma* can load and execute it. Let's have a look at a short but yet extensive example.
```python3 ```python
import random import random
def run(instance, save, state): def run(instance, save, state):