This is only a small part of the problem. You would have to massively alter the behaviour of the runpy module to be able to keep the namespace of the script alive (http://docs.python.org/2/library/runpy.html). Or alternatively you would need to write a complete replacement for the runpy module. Note that in earlier relax versions, scripts were run using the execfile() function call, but this was removed due to security concerns (http://article.gmane.org/gmane.science.nmr.relax.scm/11269/match=r11830). There is also another alternative of using the module importing mechanisms (http://www.python.org/dev/peps/pep-0302/). If the script is imported as a module, then you will have access to the script as a module object. I have tried this before but gave up because of fatal sys.path and GUI support issues. Feel free to play around with this if you wish, but it may not be worth the effort. Most of what is done in a user script will be stored in the relax data store. And if you need to store special objects for only the lifetime of the program execution, look at the status object. If you need longer term storage, i.e. stored in the save state, then you have the relax data store (but all objects must be able to be converted to XML and back again to be able to use this).
Regards, Edward On 14 February 2014 11:05, Troels Emtekær Linnet <[email protected]> wrote: > I guess it is these lines which prevent the name space to be local? > > # Execute the module. > try: > # Reverse the system path so that the script path is first. > sys.path.reverse() > > # Execute the script as a module. > if dep_check.runpy_module: > runpy.run_module(module, globals) > > > 2014-02-14 10:54 GMT+01:00 Troels Emtekær Linnet <[email protected]>: > >> Dear Edward. >> >> I am trying with this code: >> if script_file and status.prompt: >> #return run_script(intro=self.__intro_string, local=locals(), >> script_file=script_file, show_script=self.__show_script, >> raise_relax_error=self.__raise_relax_error) >> run_script(intro=self.__intro_string, local=locals(), >> script_file=script_file, show_script=self.__show_script, >> raise_relax_error=self.__raise_relax_error) >> prompt(intro=self.__intro_string, local=locals()) >> >> >> If I add the "return" command, relax quits after execution of the code. >> >> Without adding the return code, I will get relax running the code, but the >> variable in the script is not available. ? >> >> >> ---------------------------------------------------------------------------------------------------------------- >> [tlinnet@tomat relax_trunk]$ ./relax -p test.py >> >> >> >> relax repository checkout rNone >> None >> >> Molecular dynamics by NMR data analysis >> >> Copyright (C) 2001-2006 Edward d'Auvergne >> Copyright (C) 2006-2014 the relax development >> team >> >> This is free software which you are welcome to modify and redistribute >> under the conditions of the >> GNU General Public License (GPL). This program, including all modules, is >> licensed under the GPL >> and comes with absolutely no warranty. For details type 'GPL' within the >> relax prompt. >> >> Assistance in using the relax prompt and scripting interface can be >> accessed by typing 'help' within >> the prompt. >> >> Processor fabric: Uni-processor. >> >> script = 'test.py' >> >> ---------------------------------------------------------------------------------------------------- >> a = 10 >> print "helo" >> >> ---------------------------------------------------------------------------------------------------- >> helo >> >> >> >> >> relax repository checkout rNone >> None >> >> Molecular dynamics by NMR data analysis >> >> Copyright (C) 2001-2006 Edward d'Auvergne >> Copyright (C) 2006-2014 the relax development >> team >> >> This is free software which you are welcome to modify and redistribute >> under the conditions of the >> GNU General Public License (GPL). This program, including all modules, is >> licensed under the GPL >> and comes with absolutely no warranty. For details type 'GPL' within the >> relax prompt. >> >> Assistance in using the relax prompt and scripting interface can be >> accessed by typing 'help' within >> the prompt. >> >> Processor fabric: Uni-processor. >> >> relax> print a >> Traceback (most recent call last): >> File "<console>", line 1, in <module> >> NameError: name 'a' is not defined >> relax> print test.a >> Traceback (most recent call last): >> File "<console>", line 1, in <module> >> NameError: name 'test' is not defined >> >> >> >> >> >> 2014-02-14 10:46 GMT+01:00 Edward d'Auvergne <[email protected]>: >> >>> Hi, >>> >>> This is rather simple: >>> >>> - First execute the run_script() function to have the script execute >>> prior to reaching the prompt. >>> >>> - Then execute the prompt() function. >>> >>> Without the prompt() function call, the Python execution will just run >>> to the end of the relax.py file and terminate. The prompt() function >>> call prevents this by jumping into the interpreter mode. The >>> interpreter mode is then exited with the special objects 'q', 'quit', >>> 'exit', and 'bye' and [Ctrl-D]. These commands cause the prompt() >>> function to be exited, allowing the Python execution to run to the end >>> of the relax.py file and quit. As an aside, if you look you'll see >>> that this implementation (the _Exit class/object) is not ideal as it >>> uses sys.exit(), which really should never be used - this is simply >>> ancient code which should one day be updated. >>> >>> So what you need is that when a script is supplied together with the >>> --prompt argument, then you just run both of these, one after the >>> other. That's what the pseudo-code I suggested does >>> (http://thread.gmane.org/gmane.science.nmr.relax.devel/5000/focus=5008). >>> I quickly tested running one function after the other and it works. >>> You don't need to worry about returning the status from the >>> run_script() function, as that's not used in relax yet. But >>> eventually to allow for proper terminal behaviour, relax will one day >>> return a status value to the terminal. The user combinations for >>> running relax would be: >>> >>> - No arguments: Run prompt(), >>> - Only the -p, --prompt arguments: Run prompt(), >>> - Only a script file: Run run_script(), >>> - Both the -p, --prompt arguments and a script file: Run run_script() >>> then prompt(). >>> >>> I hope this is now clearer. >>> >>> Regards, >>> >>> Edward >>> >>> >>> On 14 February 2014 10:14, Troels Emtekær Linnet <[email protected]> >>> wrote: >>> > Hi Edward. >>> > >>> > Thank you for the suggestions, which I will implement. >>> > >>> > I wonder about the pseudo code. >>> > >>> > My problem is that I don't know how to parse the script to the prompt? >>> > Does the prompt needs to be modified to run the given script? >>> > >>> > Best >>> > Troels >>> > >>> > >>> > 2014-02-13 18:03 GMT+01:00 Edward d'Auvergne <[email protected]>: >>> > >>> >> Hi, >>> >> >>> >> The idea in the patch looks ok. It's worth discussing on the list the >>> >> idea though, rather than relying on reading the patch itself. The >>> >> --pedantic flag activates this feature that Chris MacRaild added to >>> >> relax back in 2006. So I gather that the suggestion is to change the >>> >> argument: >>> >> >>> >> -p, --pedantic, escalate all warnings to errors >>> >> >>> >> to: >>> >> >>> >> -e, --escalate, escalate all warnings to errors >>> >> >>> >> I guess this is reasonable. I suggest committing just that change as >>> >> one commit yourself. The current patch also includes the argument: >>> >> >>> >> -p, --prompt, 'Execute the given script and continue into the prompt >>> >> mode to allow for interactive inspection' >>> >> >>> >> This should be in a separate commit. Also, the first letter of the >>> >> help text should be in lowercase to match the rest of the help system. >>> >> There is also a problem with the logic of the if-else statement in >>> >> the run() method. I would suggest the pseudo-code: >>> >> >>> >> if script: >>> >> script_status = run_script() >>> >> if not script or (script and status.prompt): >>> >> prompt() >>> >> >>> >> So essentially two commits, the first renaming --pedantic, the second >>> >> adding the --prompt argument and logic. What do you think? >>> >> >>> >> Regards, >>> >> >>> >> Edward >>> >> >>> >> >>> >> >>> >> >>> >> On 13 February 2014 17:48, Troels E. Linnet >>> >> <[email protected]> wrote: >>> >> > Follow-up Comment #1, sr #3117 (project relax): >>> >> > >>> >> > This follows the discussion at: >>> >> > http://thread.gmane.org/gmane.science.nmr.relax.devel/5000 >>> >> > >>> >> > The next step would be to figure out to run the code and stay in the >>> >> > interpreter. >>> >> > Is it necessary to write a new function? >>> >> > >>> >> > Initial pathc applied. >>> >> > >>> >> > (file #20034) >>> >> > _______________________________________________________ >>> >> > >>> >> > Additional Item Attachment: >>> >> > >>> >> > File name: first.patch Size:5 KB >>> >> > >>> >> > >>> >> > _______________________________________________________ >>> >> > >>> >> > Reply to this item at: >>> >> > >>> >> > <http://gna.org/support/?3117> >>> >> > >>> >> > _______________________________________________ >>> >> > Message sent via/by Gna! >>> >> > http://gna.org/ >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > relax (http://www.nmr-relax.com) >>> >> > >>> >> > This is the relax-devel mailing list >>> >> > [email protected] >>> >> > >>> >> > To unsubscribe from this list, get a password >>> >> > reminder, or change your subscription options, >>> >> > visit the list information page at >>> >> > https://mail.gna.org/listinfo/relax-devel >>> > >>> > >> >> > _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
