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()"