bugpyFormex - Bugs: bug #40850, Configuration issues

 
 

bug #40850: Configuration issues

Submitted by:  francesco <francio>
Submitted on:  Mon 09 Dec 2013 01:43:08 PM UTC  
 
Category: CoreSeverity: 4 - Important
Item Group: Functionality errorStatus: Fixed
Privacy: PublicAssigned to: Benedict Verhegghe <bverheg>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 13 Dec 2013 12:20:09 PM UTC, comment #17:

It works for me as well, so I closed the bug.

Wouter Devriendt <whdvrien>
Project Member
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.

francesco <francio>
Project Member
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?).

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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.

francesco <francio>
Project Member
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.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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

francesco <francio>
Project Member
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.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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.

Wouter Devriendt <whdvrien>
Project Member
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?

francesco <francio>
Project Member
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.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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?

francesco <francio>
Project Member
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.

Wouter Devriendt <whdvrien>
Project Member
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:

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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?

francesco <francio>
Project Member
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:

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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.

francesco <francio>
Project Member
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.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
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.

francesco <francio>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #29817:  pyformex.conf added by francio (4KiB - application/octet-stream)
file #29818:  pyformex.conf added by francio (12KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by whdvrien (Posted a comment)
  • -unavailable- added by bverheg (Posted a comment)
  • -unavailable- added by francio (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 13 Dec 2013 12:20:09 PM UTCwhdvrienOpen/ClosedOpen=>Closed
    Tue 10 Dec 2013 03:21:42 PM UTCfrancioStatusReady For Test=>Fixed
    Tue 10 Dec 2013 02:12:40 PM UTCfrancioStatusWorks For Me=>Ready For Test
    Mon 09 Dec 2013 11:07:30 PM UTCbverhegStatusWont Fix=>Works For Me
    Mon 09 Dec 2013 11:06:33 PM UTCfrancioStatusWorks For Me=>Wont Fix
    Mon 09 Dec 2013 04:42:27 PM UTCbverhegStatusNone=>Works For Me
      Assigned toNone=>bverheg
    Mon 09 Dec 2013 01:43:08 PM UTCfrancioAttached File-=>Added pyformex.conf, #29817
      Attached File-=>Added pyformex.conf, #29818

    Back to the top


    Powered by Savane 3.1-cleanup1