Renaming of Variables

[lneuhaus]

Some variables have unintuitive names. Let's collect them here and do a collective renaming some day in the future, when everybody is aware that issues might arise.

• asg.scale should be asg.amplitude

[lneuhaus]

• input names:
  • adc1/2 should be in1/2
  • dac1/2 should be out1/2

[SamuelDeleglise]

I also find it weird that iq are numbered starting from 0 whereas asgs are numbered starting from 1.

[lneuhaus]

That one has historical/implementation reasons. What is more natural? Starting from 0 or from 1?

[SamuelDeleglise]

Not sure, à possibility would be start at 0 and eventually use 0 for
internal use such as network analyser. On the other hand some (mostly
matlab users) would argue that starting at 1 is more intuitive

Le 7 nov. 2016 8:38 PM, "lneuhaus" notifications@github.com a écrit :

That one has historical/implementation reasons. What is more natural?
Starting from 0 or from 1?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#40 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACqnOAvUdDacf58g9ZjMiCp0F_Fm0I_wks5q734ggaJpZM4JC9Lo
.

[lneuhaus]

for me its more intuitive to consistently start at 0. but we would have to be consequent and name scope channels by 0 and 1, too, for example. the "internal usage" of network analyzer reminds me that we have not discussed the issue of "blocking a hardware module" recently, I hope you did not forget it in your changes. That is, if you want to avoid conflicts you must implement some access permission system for the hardware modules imo. i think the list system where you pop and append the available modules is not so bad..

[SamuelDeleglise]

OK, concerning the 0 or 1 indexing, I think if we include the scope channels in there, it would be much less error prompt to start at 1 (I don't know any scope that indexes its channels starting from 0)....

Concerning the device stack, I have been thinking about it since your message, and in this case, it should be clear also in the gui that the resource is unavailable. Actually, I still find it useful for debugging and understanding what's going on behind the scene to be able to see the values. What I suggest:

• To disable the widget (becomes grey) and change its title to for example "iq1 (network_analyzer)" when it becomes a slave
• Hence, BaseModule would have a static function pop_slave_module(module_name) that returns the first available instance of the requested type (iq, asg...), and a (non-static) function release(self) to make the slave module available again (self is the slave module in this case).
• I also thought about using the same system for scope and spectrum_analyzer (the second becoming the owner of the first when in use). We could integrate as a generic mechanism inside the pop/release functions to save/restore the slave module parameters. Then, when a module is slaved by a higher-level module, the automatic continuous saving of its attributes (formerly registers) would be disabled (it is then the responsibility of the higher level module to save the relevant parameters).
• If we go in this direction, then probably we want to have an object rp.available_modules (or maybe to make it shorter, they could be directly under rp) for the user to access the remaining available modules for debugging purposes, and we want to "hide" the full module list for instance in rp.hardware_modules
• Finally, in the initializer of rp, we could decide which modules we want to have displayed in the gui, by default, all modules, but for a high-level lockbox, maybe the user wants to have only the pyrpl_control widget and scope visible...

[lneuhaus]

contained in #83
renaming completed