Feature: proxy attributes of remote parameters

[alexcjohnson]

Per discussion in https://github.com/qdev-dk/Qcodes/pull/139#issuecomment-227121328

Changes proposed in this pull request:

• Rather than copying attributes of parameters and other RemoteComponents from the server to the remote, proxy them (get/set/del). This means that:
  • if your parameter changes on the server, like when you change a mode parameter and some other parameter gets new units etc, the remote will reflect this properly
  • you can also change attributes manually by eg parameter.units = new_units, without worrying about whether the parameter is remote or not.
• Note that I did NOT allow arbitrary attributes to be set from the server, only the ones the parameter originally had after instantiation. Not quite sure the use case (turning a simple parameter into a multi-valued one? That would be weird...) but it would be possible to relax this constraint.
• Some testing: speed up instrument tests with smarter setUp vs setUpClass etc - cuts off another ~7 secs while completing coverage of the new features as well as the rest of remote.py

@MerlinSmiles @spauka @giulioungaretti

[damazter]

@alexcjohnson
Would this also mean that if the instruments adds parameters to itself after the init they would be connected to the remote instrument? (see #99)

[alexcjohnson]

Would this also mean that if the instruments adds parameters to itself after the init they would be connected to the remote instrument?

No, this PR doesn't do that. It would be fairly easy to add functionality to a RemoteInstrument to check for new or altered components and update itself; the challenge is how the InstrumentServer would know that a change has occurred in one of its instruments, so that it can tell the RemoteInstrument about it.

So to be concrete, update like this would be easy:

# first some method/parameter/function that changes the parameters in the real instrument
ins.reconfigure(...)
# but the RemoteInstrument is unaware until you tell it to go look for changes
ins.update()
# now the RemoteInstrument is back in sync with the server copy

But to have ins.reconfigure(...) by itself cause the RemoteInstrument to update automatically, that would be more challenging. The instrument on the server doesn't even know it's on a server, it just knows that its reconfigure() method was called, and it returns whatever it returns. That problem we could solve - we could use events on the server ala #92, or we could mark in the RemoteInstrument which components, when accessed, should cause an update.

But one problem I don't see any real solution to is if multiple processes connect to the instrument server, for example, main and a loop, maybe also a meta-instrument server. Only the one that initiated the change would have any way to know it should update the components.

Anyway I'm happy to make an update method, that will be required no matter what else we do.

[damazter]

I would be more tha nhappy to call update manually. It is only needed in rare cases. I don't feel the urgent need to have an automated method.

[alexcjohnson]

@damazter I added RemoteInstrument.update(), it works as described above.

Any other comments?

[damazter]

thanks

[giulioungaretti]

I think it makes no sense to wait to merge 💃 for me !

[giulioungaretti]

On a second look, docs is missing. See in line commets :D

[giulioungaretti]

Missing Returns:

[alexcjohnson]

@giulioungaretti thanks for checking the docs. OK now?

[giulioungaretti]

@alexcjohnson awesome! 💃