Fri 13 Dec 2013 12:20:09 PM UTC, comment #17:
It works for me as well, so I closed the bug.
|
Tue 10 Dec 2013 03:21:42 PM UTC, comment #16:
Seems to work fine. let us wait for wouter also to check it then I think we can close this post.
|
Tue 10 Dec 2013 03:12:43 PM UTC, comment #15:
In eb3557d, a parameter wait=True is added to utils.system.
editFile now calls utils.system with wait=False.
That should fix your problem. Please test.
Currently no stdout/stderr is got back if wait=False is used.
If needed we could read it like suggested in previous comment, but after waiting for the process to finish (so what is the
wait=False for then?).
|
Tue 10 Dec 2013 02:50:07 PM UTC, comment #14:
Indeed the process start at _init_ but then in run it waits for the output. If you have a look at the link I put, normally we should be able to call
self.stdout.read()
without waiting the process to end but it did not work for me.
That is why I thought we should keep the run method for further improvements output-related.
So I will not push the changements and wait for your rearrangements of the class.
|
Tue 10 Dec 2013 02:35:15 PM UTC, comment #13:
I think adding a wait=True parameter to Process is the best thing. But we should reorganize the Process class more. I thought that the process was only started when the communicate was called, but that does not seem to be true: the subprocess is directly started from the _init_ call. So our timeout function is not working properly: the process is already running when the timer is set. It works good now because we just use Process.__init__ and Process.run calls directly one after another.
And that is the only way it should be. So we can jusat as well merge run within _init_, and add timeout and wait as a parameter to Process.
|
Tue 10 Dec 2013 02:12:40 PM UTC, comment #12:
I checked online and I found some workaround for subprocess.Popen to avoid to wait the end of the process. the os.popen will substitute by subprocess.Popen so it is not a good strategy as wouter suggested.
I figure out a way to use xisting coding but I am not sure if it is clean enough. as wouter was suggesting and explained in this post ,
http://stackoverflow.com/questions/12965023/python-subprocess-popen-communicate-equivalent-to-popen-stdout-read
communicate will always wait the end of the process, so the trick is avoid to call the communicate and wait for the output I tried this way.
1 add a wait flag in Process.run()
2 modify the call of self.communicate in Process.run in this way
3 call in draw.editFile with wait=False
|
Tue 10 Dec 2013 01:11:53 PM UTC, comment #11:
'&' is a shell command, so it requires shell=True parameter in utils.system.
You can use a wrapper script as explained in https://savannah.nongnu.org/bugs/?40850#comment5
In the wrapper script you can add the '&'.
We might change the configuration of the editor to allow more complex commands, and possible make the shell=True parameter
also configurable, but I think the use of the wrapper script is the most general way and will work for now.
We still could add 'shell=True' in editFile.
|
Tue 10 Dec 2013 11:17:49 AM UTC, comment #10:
As far as I understand, that's because the P.run() from utils.system uses the subprocess.communicate(), which waits for the process to terminate. i could solve this by changing the cunction editFile in draw:
utils.system('%s %s' % (pf.cfg['editor'], fn))
replaced by
os.popen('%s %s &' % (pf.cfg['editor'], fn))
I don't think this is a nice solution though, since os.popen is deprecated.
The adding of the & in the existing utlis.system line does not give nice results, since another file, named '&' is opened then.
|
Mon 09 Dec 2013 11:20:40 PM UTC, comment #9:
I have just realized that wouter beat me for some minutes to get the issue, but still why the gui remains locked after the editor is open?
|
Mon 09 Dec 2013 11:07:30 PM UTC, comment #8:
Good work, Wouter. That is indeed the problem.
To solve it, I am not sure what to do however. The acceptance of unicode filenames was done so that we could open geometry files delivered by third parties using unicode filenames (not wise, but it happens). I would like to keep that.
On the other hand, I do not like the proliferation of testing everywhere for str or unicode. Even more so since in Python3 unicode does not exist anymore and str is a unicode string, so we will have to change everything again.
Furthermore I am afraid that in the current situation, a lot of things may break because of the unicode strings.
So to have a stable platform again, we should probably rollback the unicode support. But for the future, we should at least experiment with unicode strings. Therefore I think we need a configurable option (config file and/or command line) to select the unicode support. I am just not sure how to handle the config file with possibly unicode strings then. Maybe just convert them to str if unicode support is not selected. Or maybe not store unicode in the config.
|
Mon 09 Dec 2013 11:06:33 PM UTC, comment #7:
None of the below solution works. the problem is the that in
utils.Process in the init line 139 a check is made to evaluate if the type of cmd is a str, but actually it is a "unicode" instance. For this reason the split is not performed and the command fail to run. We can add these lines before that
But this raises another issue. The editor is started but the gui get stuck becuase it waits for the command to end. After closing the editor holding the script to edit, the gui is
unblock again.
How to avoid that?
|
Mon 09 Dec 2013 10:34:09 PM UTC, comment #6:
I have the same issue. The problem seems to be the type of some of the variables (curfile and workdir) in the configuration file. They are 'unicode' and not 'string'. Because of that, the cmd variable becomes of the type 'unicode' and not 'string'.
What happens now is that in the initialization of the system.utils.Process the
gets skipped because isinstance(cmd) is 'unicode', and not 'string'. So the subprocess.Popen.__init__(self,cmd,**kargs) fails and the Process initializer returns the 127 error.
What solves it for me is to remove the u from the curfile variable (so curvar = u'/my/file' --> '/my/file' in the configuration file. This is temporary however, as soon as I change to a different script, it becomes unicode again.
I guess to solve the issue we can
1. either add isinstance(cmd, unicode) to the check before the split in utils.Process:
This solution works for me.
2. make sure the paths are saved as strings and not unicode. I don't know why it gets formatted this way, no special characters are in my path for the current file or workdirectory.
|
Mon 09 Dec 2013 09:34:19 PM UTC, comment #5:
Have you tried with a pyformex started from a shell? Or is pyformex started from a GUI button? Desktop GUIs sometimes do not fully configure PATH variables (especially lately with dash instead of bash).
Next you can try by creating a script in a directory in your PATH (~/bin) that executes your editor:
Make sure your ~/bin is in your PATH and that the script is executable. Then configure that script as you editor in pyformex.
If that does not work, you can try the following: in pyformex/gui/draw.py change the editFile function, by adding 'shell=True' parameter:
|
Mon 09 Dec 2013 08:59:34 PM UTC, comment #4:
the command exist both as a shortcut or by giving the entire path and they work from shell. I never had problems with this or other editor I installed, that is why I was trying to understand what has changed in the latest version(s) to give this problem. I know that also Wouter had similar issues after the update. Any test I can perform?
|
Mon 09 Dec 2013 07:27:19 PM UTC, comment #3:
Status 127 is typical for a command not found.
Are you sure that the command /usr/bin/scite exists and is executable?
Try executing the command from a shell:
|
Mon 09 Dec 2013 06:19:17 PM UTC, comment #2:
I tried to checkout again, remove the old pyformex version and the old configuration file but the problem persist.
I tried to
1 use another file editor,
2 use the entire paths of the editors
if I use utils.last utils.lastCommandReport() I get
u'======== LAST COMMAND REPORT =====================\n cmd: /usr/bin/scite "/home/francio/phd2/cristallostudy/vesselpressuretest/vesselpressure.py"\n status: 127\n==================================================\n'
also using the verbose return this
Running command: /usr/bin/scite "/home/francio/phd2/cristallostudy/vesselpressuretest/vesselpressure.py"
The subprocess failed to start, probably because the executable does not exist or is not in your current PATH.
|
Mon 09 Dec 2013 04:42:27 PM UTC, comment #1:
1. The default config file (pyformex.conf in the source tree) should NEVER be changed. If it is, restore it (git co -- pyformex/pyformex.conf).
2. You user configuration file seems ok. I can open it with my editor (emacs :) and I can also start pyformex using it as the
user config file. Try to open with another editor.
3. There seems to be a bug setting the workdir on startup, or rather not displaying the correct workdir: it shows the home directory in the button, but when you click it, you may find yourself in another directory.
|
Mon 09 Dec 2013 01:43:08 PM UTC, original submission:
I have problems with the configuration files and I dont know how to fix it ads I could not get what pyormex read from what.
1 If I change the working directory, and then save preferences. the .config/pyformex/pyformex.conf file changes but when I reopen pyformex the workdir is reset to home directory
2 my default editor does not open the file anymore
How can this be fixed?
In attacmnent you can find the local and global config file.
|