matthieudartiailh / hqcmeas Goto Github PK

• support all the connection type supported by PyVisa (will have to wait an update of the driver system)
• support specifying a card adress (ex : GPIB0::1::INSTR)

The idea is that in some cases the user might want to know the current of an instrument when editing its measure and he should be able to do it without having to handle himself the authorization request (Even if I do not think it is a great idea to rely on the instrument state, as persistent measure become more tricky).
Road map :

• declare the standard editor to be an instrument user with an unreleasable policy.
• define a nice API in InstrTaskView to get an instrument knowing it might take some time to release it from it previous use.

The idea behind this is that as the number of user will increase, they will be likely to implement some custom tasks/pulse shapes/plugins or even drivers and that for various reason it would not make sense to embed them in the main project (because they are too specific).

Setuptools provide the notion of entry points that can be used to provide extension to a pluggable application. So each extension package would simply declare an entry point pointing to a callable returning one or several Enaml manifest. Each manifest will list all the extensions the new package provides to the program. This has the advantage to centralize everything in the application, furthermore as users are likely to need to contribute some basic UI writing a basic enaml file with their manifest should be easy.

The following parts of the program may be turned into packages :

• debugger : this is useful only to people developing driver which hopefully won't be everybody
• control : this is a kind of ghost anyway for the time being but as it might be quite heavy it would make sense to have it being external.
• pulses : because not everybody will need them

Implied changes :

• add a plugin 'extensions' who will have to iter over the package declaring the right entry point and register them. Possibly having it be able to install, uninstall packages using pip (conda perhaps also in long run) would be awesome. Offering the possibility to deactivate some installed packages might be interesting too.
• refactor the following plugins as elements must now be provided using an extension declared in a manifest (must define the form of the extensions):
  • task manager : tasks, interfaces, config and filters
  • instrument manager : driver_types, drivers, forms
  • pulses manager : shapes, sequences, contexts

The other plugins should behave nicely.

Refactoring (as a number of things will change including the name of the project we can take advantage of the situation to re-organize one or two things):

• create an app package in which we move the following plugins:
  • app
  • preferences
  • state
  • dependencies
  • extensions
  • log (minor: store log in string so that we can always display a full log in workspaces, currently messages emitted before the workspace starting are missing)
• create a tasks package in tasks and utils, logic, instr inside (task_logic, task_instr, ... is ugly and discouraged by PEP8)

New considerations:

• allowing user to contribute new stuff may mean they can override existing classes, do we allow that ?
• if we do how do we handle the overriding order (plugins may not always be loaded in the same order) ?
• if we don't do we let the user handle name conflict or try to do it ourselves ?
• how do we keep a clean mapping between task/interface and the instrument they can use ?

• Edition and transfert of pulse sequences
• selection of pulse sequence and running
• stop pulse sequence

This will be needed for AWG transfer task.

The idea would to duplicate all scalar inputs for all the value in the arrays (which should all have the same length).

Currently interface checks are run after the children checks in LoopTask which means that the children does not have access to the right iterable values when running their checks.