-
Notifications
You must be signed in to change notification settings - Fork 2
Description
ISISNeutronMuon/InstrumentScripts#60
As a developer I would recommend getting rid of populate. It can cause really weird effects if a block is the same name as a module e.g. time
Instead replace with a module which has a class member variable for each active block. On most beam lines this is imported as b.. b.block_name should return something that is interpreted as a string in scan(<motion> and cset and cget. Ideally it should update itself when the blocknames change.
Acceptance Criteria
- A decision is made on populate and the decision is recorder. (must be agreed in general between scientists)
- done they are happy to remove it if they can replace it with
b.
- done they are happy to remove it if they can replace it with
- Populate is removed
- Documentation is updated
- a blocks module is added that has a list of blocks variable in.
- Tests for any code change are added
Notes
-
This is a breaking change so maybe we just shouldn't
- we should because it is in the build_ins and can cause weird problems in the future
-
Its purpose is to create variables which can be used instead of block names so that scan can be written: scan(block, ... instead of scan("block", .... But it comes with caveats that when the user changes config they must remember to rerun populate to get new blocks and it is different to the recommended way of running g.cset i.e. cset("block", value). However I do not know the history and so would like to understand its motivation.
-
interpreted as a string: could mean just a return a string but maybe there is a way of returning a more complicated object that will evaluate to a string but have more complicated properties like units etc. This might eventually allow us to do
b.blockname.scan(-0.5, 0.5, 1)orb.blockname.cset(10)or evenb.blockname = 10.