The labscript Python library provides a translation from simple Python code to complex hardware instructions. The library is used to construct a "connection table" containing information about what hardware is being used and how it is interconnected. Devices described in this connection table can then have their outputs set by using a range of functions, including arbitrary ramps.
I've been wondering whether we should have the user explicitly call labscript_init(shot_file) in labscript code, and have the only magical thing runmanger does be inserting that shot_file varialble into the namespace, kinda like how lyse does it.
This would make it once again symmetric between compiling shots standalone and from runmanager, and would define which module gets the globals if we do this in Issue #11 - calling labscript_init() puts globals in your global namespace.
The advantage of this is that it gives us more power to do things independently of runmanager if we want to. It is also less magical - even though we're still populating the namespace with globals, the user knows what line that happens on, and the only magic is us giving them a filepath which they can check for the existence of and do something different if it doesn't exist. This is precisely the same as lyse, and I like that consistency.
As an example, one could import runmanager, programatically create a shot file by making runmanager API calls (runmanger.make_run_file_from_globals_files() comes to mind), and then call labscript_init() on the resulting file. Connection table code could then follow, and thus you've compiled a connection table without the GUI programs.
I mean, that's not the way we should do that - I'll file another issue to BLACS about making that easier, but still.
This would be backward incompatible, but if a Device was instantiated without calling labscript_init() it would throw an exception saying "please call labscript_init()"
Original report (archived issue) by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
I've been wondering whether we should have the user explicitly call
labscript_init(shot_file)in labscript code, and have the only magical thing runmanger does be inserting thatshot_filevarialble into the namespace, kinda like how lyse does it.This would make it once again symmetric between compiling shots standalone and from runmanager, and would define which module gets the globals if we do this in Issue #11 - calling
labscript_init()puts globals in your global namespace.The advantage of this is that it gives us more power to do things independently of runmanager if we want to. It is also less magical - even though we're still populating the namespace with globals, the user knows what line that happens on, and the only magic is us giving them a filepath which they can check for the existence of and do something different if it doesn't exist. This is precisely the same as lyse, and I like that consistency.
As an example, one could import runmanager, programatically create a shot file by making runmanager API calls (
runmanger.make_run_file_from_globals_files()comes to mind), and then calllabscript_init()on the resulting file. Connection table code could then follow, and thus you've compiled a connection table without the GUI programs.I mean, that's not the way we should do that - I'll file another issue to BLACS about making that easier, but still.
This would be backward incompatible, but if a
Devicewas instantiated without callinglabscript_init()it would throw an exception saying "please calllabscript_init()"