User feedback

[lneuhaus]

What is most useful?

• few well-documented use-cases including notebook/code to reproduce (incl. API)
• improved / facilitating documentation
• easier locking procedure

[lneuhaus]

have possibility to run pyrpl on redpitaya

[SamuelDeleglise]

Since we have worked quite hard to make the whole interface fully compatible with notebook integation, I think it makes sense to keep some notebook examples. Moreover, I have struggled a bit lately because unittests didn't include running some code embedded in a notebook.

For this reason, I have written a test_ipython_notebook unittest, that will automatically make sure that no exceptions are raised by the tested notebooks. The test looks for notebooks;:

• In the default tutorial notebook directory: docs\example-notebooks
• In the test_ipython_notebook_folder for more "private" tests. (For instance, one test makes sure that the Ipython kernel that's being tested is the same python version as the unittest)

Since passing the IP address of the test redpitaya might look a bit cryptic for a new user that is reading the tutorial, I have added a trick: every cell that begins with #define-hostname will be replaced by HOSTNAME = 'currently-used-IP'. Similarly, the magic comment #no-test will skip the entire cell during the unittest. This is useful for cells that propose to perform some pip install for instance.

So I have put back the tutorial into docs\example-notebooks. It passes the unittest, however, the IIR section is obviously not working as expected. Maybe you can have a look? Also, we never wrote the Lockbox part for the notebook.

Regarding your initial question. I think it makes sense to have a basic tutorial notebook, but then several more advanced notebooks on specific topics. The nice thing is that they will be tested during unittests.

[lneuhaus]

Ok, all this sounds good. I will have a look at the notebook sections. We should as also make links to them on the website.

Regarding the hostname: why does the unittest have to define an IP? Can we not simply rely on the environment variable for the unittest, and keep the hostname argument out of the tutorial? The behavior is that, if no environment variable or argument with hostname is available, the startup widget will ask for the ip. At the next execution, the hostname should already be in the config file.

[SamuelDeleglise]

OK, I was mechanically trying to adapt the unittest to the old notebook without really thinking that changing the notebook itself might be a solution. However, thinking about it twice, I find that during unittests, you want at worst to have one single IP selection window at the beginning that defines the IP address for all tests (or to define the REDPITAYA_HOSTNAME once and for all). If you rely on config_files such as 'tutorial.yml' to store the IP address, you will run into troubles when you want to run the unittests on a different Redpitaya (that happens quite often for me): namely, you need to remember to change the IP address in the environment variable, but also, in the various config_files... Anyways, we need some black magic to skip the execution of some cells, so it's not a big deal to also add the IP propagation black magic.

On the other hand, I have changed the default IP address to "" in the tutorial, such that the IP selection window opens up by default...

[lneuhaus]

Another way to deal with the IP address mess is to modify the setup_all method of all test cases (the one which also creates the Pyrpl object) such that it removes the hostfile entry from the config file that is used before the pyrpl object is created (which is known to setup_all since it is used to create the pyrpl object).

[SamuelDeleglise]

I'm not sure to follow what you are suggesting: keep in mind that in a tutorial notebook, the pyrpl instance is typically not created using a TestPyrpl construct, and the config file would ideally have a special name such as 'tutorial'.