srenblad
/
artiq
forked from M-Labs/artiq
1
0
Fork 0
Code Pull Requests Activity

doc/tutorial: add missing type annotation in LED example. Closes #356

This commit is contained in:
Sebastien Bourdeauducq 2016-03-29 14:53:52 +08:00
parent 3c09577ed0
commit 1a513634ff
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/manual/getting_started_core.rst
View File

@ -43,8 +43,8 @@ A method or function running on the core device (which we call a "kernel") may c
Modify the code as follows: :: Modify the code as follows: ::
def input_led_state(): def input_led_state() -> TBool:
return int(input("Enter desired LED state: ")) return bool(input("Enter desired LED state: "))
class LED(EnvExperiment): class LED(EnvExperiment):
def build(self): def build(self):
@ -70,6 +70,8 @@ You can then turn the LED off and on by entering 0 or 1 at the prompt that appea
What happens is the ARTIQ compiler notices that the ``input_led_state`` function does not have a ``@kernel`` decorator and thus must be executed on the host. When the core device calls it, it sends a request to the host to execute it. The host displays the prompt, collects user input, and sends the result back to the core device, which sets the LED state accordingly. What happens is the ARTIQ compiler notices that the ``input_led_state`` function does not have a ``@kernel`` decorator and thus must be executed on the host. When the core device calls it, it sends a request to the host to execute it. The host displays the prompt, collects user input, and sends the result back to the core device, which sets the LED state accordingly.
RPC functions must always return a value of the same type. When they return a non-``None`` value, the compiler should be informed in advance of the type of the value, which is what the ``-> TBool`` annotation is for.
The ``break_realtime`` call is necessary to waive the real-time requirements of the LED state change (as the ``input_led_state`` function can take an arbitrarily long time). This will become clearer later as we explain timing control. The ``break_realtime`` call is necessary to waive the real-time requirements of the LED state change (as the ``input_led_state`` function can take an arbitrarily long time). This will become clearer later as we explain timing control.
Algorithmic features Algorithmic features