Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't
On 19/05/2019 04:58, DL Neil wrote: > last time I used the term "bomb", I'm guessing that "abend" wouldn't > pass muster either... Gosh, I haven't seen a reference to abend in 20 years. I'd almost managed to erase the memory... :-) -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't
Stephen, On 16/05/19 12:16 AM, Stephen P. Molnar wrote: I am writing scripts to semi-automate some of my Quantum Chemistry software and have encountered a problem that has me baffled. The two scripts have the same form, the only difference being the commands. One script works, the other bombs. Blast from the past! I thought I'd finished with nerve agents, receptors, and ligands back in 1990-1. The memories have not improved with age! Taking the first question, ie 'two scripts which appear identical but are not':- Nothing 'popped' during a quick visual scan. Linux (which it is assumed you are using) has two basic built-in commands/pgms: diff and cmp (difference and compare). For occasions when I want to compare directories first, and probably contained-files thereafter, I use "Meld". As to the second: +1 to removing the extra moving-parts, like Spyder, and running directly from the cmdLN (simplify, simplify). Even though accuracy and precision are important, this is the Tutor list, so don't worry too much about the terminology. Most of us, young or old will have recognised what you meant. Whilst I can't recall the last time I used the term "bomb", I'm guessing that "abend" wouldn't pass muster either... -- Regards =dn ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't
Thanks for your reply. I am most appreciative of your detailed response. Please see below for my comments. On 05/15/2019 08:12 PM, Steven D'Aprano wrote: Hi Stephen, My responses are interleaved with your comments below. Please excuse the length of my post, but your problem is a complicated one. On Wed, May 15, 2019 at 08:16:02AM -0400, Stephen P. Molnar wrote: I am writing scripts to semi-automate some of my Quantum Chemistry software and have encountered a problem that has me baffled. The two scripts have the same form, the only difference being the commands. One script works, the other bombs. A note on terminology: to programmers, the terminology "bombs" usually refers to a fatal application crash detected by the operating system: https://en.wikipedia.org/wiki/Bomb_%28icon%29 whereas what you are experiencing is merely an exception with a traceback displayed. The difference is that a "bomb" (or a "crash") is a serious bug in the application (Python), while an exception is actually a sign that Python is working correctly. The bottom line is that there's not much you can do about a bomb except stop running the script, whereas an exception means there's a bug in your code you can fix. My use of computers in my scientific work goes back to the early 1960's as a graduate student when I took an introductory course in FORTRAN II. I am a Chemist and not a professional programmer, although I occasionally write a FORTRAN program, thanks to Linux and gfortran. Although retired, I am still maintaining a computational chemistry research program. So, substitute 'bug' for 'bomb' in this thread. The script that works is: [...] Thanks for the careful and detailed samples of your code, but in general unless you are paying a consultant to to the work for you, it is best to try to narrow down the samples to the smallest amount that demonstrates the problem. We're volunteers, donating our time for free, and often with very limited time to offer. Every extra line of code you present us with discourages us a little more from tackling your problem, so the smaller the amount of code, the more likely we are to help. For a better explanation, you might like to read this: http://www.sscce.org/ It is written for Java programmers but applies to any language. #!/usr/bin/env python This line tells a Unix system to run the script using "python", which is probably going to be Python 2. But I see from your code below that you are actually running Python 3 code. So this is a potential problem. I cannot tell if it is *actually* a problem right now, or will only become one in the future. You could try replacing the word "python" with "python3", but you should run these commands at the Unix shell first: env python env python3 and see what they say. Another problem is that both of your scripts call out to an external script `pythonsh` which we cannot see, so there's no way of knowing what that is doing. Pythonsh is a bash script, a part of MGL_Tools (http://mgltools.scripps.edu/) which is the source of prepare_ligand4.py and prepare_dpf4.py which I am attempting to implement in my two scripts. MGL_Tools is a gui for AutoDock which, in turn I have been using for at least 25 years now. (Both MGL_Tools and AutoDock are open source and have been widely used.) The function of pythonsh is to establish an environment for the use of python2 and to set a number of paths.. If I invoke pythonsh in a bash shell I get: comp@AbNormal:/sdc1/Apps/Models/1-NerveAgents/Scripts$ ./pythonsh setting PYTHONHOME environment Python 2.5.6 (r256:88840, Nov 6 2012, 15:29:26) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> The second script refers to yet another Python script `prepare_pdf4.py` but the output says this file doesn't exist: can't open file './prepare_pdf4.py': [Errno 2] No such file or directory So that's a problem you need to fix. I have no idea if that will fix everything, or just part of the issue. The problem may not be the invocation of prepare_dpf4.py, because: comp@AbNormal:/sdc1/Apps/Models/1-NerveAgents/Ligands$ ./pythonsh ./prepare_dpf4.py prepare_dpf4.py: ligand and receptor filenames must be specified. Usage: prepare_dpf4.py -l pdbqt_file -r pdbqt_file -l ligand_filename -r receptor_filename Optional parameters: [-o output dpf_filename] [-i template dpf_filename] [-x flexres_filename] [-p parameter_name=new_value] [-k list of parameters to write] [-e write epdb dpf ] [-v] verbose output [-L] use local search parameters [-S] use simulated annealing search parameters [-s] seed population using ligand's present conformation Prepare a docking parameter file (DPF) for AutoDock4. The DPF will by default be _.dpf. This may be overridden using the -o flag. Then: /sdc1/Apps/Models/1-NerveAgents/Ligands$ ./pythonsh
Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't
Probably not applicable, but before deleting the original post, I distinctly remember seeing in amongst the text of the post, ".pfd" as part of a larger string of text, and as distinct from ".pdf". I wondered then if the OP's problem might be a typographical error? I am a student not a tutor - this is wild speculation! Best Regards, John Collins. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't
Hi Stephen,
My responses are interleaved with your comments below. Please excuse the
length of my post, but your problem is a complicated one.
On Wed, May 15, 2019 at 08:16:02AM -0400, Stephen P. Molnar wrote:
> I am writing scripts to semi-automate some of my Quantum Chemistry
> software and have encountered a problem that has me baffled. The two
> scripts have the same form, the only difference being the commands. One
> script works, the other bombs.
A note on terminology: to programmers, the terminology "bombs" usually
refers to a fatal application crash detected by the operating system:
https://en.wikipedia.org/wiki/Bomb_%28icon%29
whereas what you are experiencing is merely an exception with a
traceback displayed. The difference is that a "bomb" (or a "crash") is a
serious bug in the application (Python), while an exception is actually
a sign that Python is working correctly.
The bottom line is that there's not much you can do about a bomb except
stop running the script, whereas an exception means there's a bug in
your code you can fix.
> The script that works is:
[...]
Thanks for the careful and detailed samples of your code, but in general
unless you are paying a consultant to to the work for you, it is best to
try to narrow down the samples to the smallest amount that demonstrates
the problem. We're volunteers, donating our time for free, and often
with very limited time to offer. Every extra line of code you present us
with discourages us a little more from tackling your problem, so the
smaller the amount of code, the more likely we are to help.
For a better explanation, you might like to read this:
http://www.sscce.org/
It is written for Java programmers but applies to any language.
> #!/usr/bin/env python
This line tells a Unix system to run the script using "python", which is
probably going to be Python 2. But I see from your code below that you
are actually running Python 3 code. So this is a potential problem. I
cannot tell if it is *actually* a problem right now, or will only become
one in the future.
You could try replacing the word "python" with "python3", but you should
run these commands at the Unix shell first:
env python
env python3
and see what they say.
Another problem is that both of your scripts call out to an external
script `pythonsh` which we cannot see, so there's no way of knowing what
that is doing.
The second script refers to yet another Python script
`prepare_pdf4.py` but the output says this file doesn't exist:
can't open file
'./prepare_pdf4.py': [Errno 2] No such file or directory
So that's a problem you need to fix. I have no idea if that will fix
everything, or just part of the issue.
> while the script that bombs is:
[...]
> Traceback (most recent call last):
>
> File "", line 1, in
> runfile('/home/comp/Apps/Models/1-NerveAgents/Ligands/calc_pdf.py',
> wdir='/home/comp/Apps/Models/1-NerveAgents/Ligands')
>
> File
> "/home/comp/Apps/miniconda3/lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py",
>
> line 824, in runfile
> execfile(filename, namespace)
This tells me that you are running your code via the Spyder IDE. That
means you have *at least* five and maybe six components involved:
- the Python interpreter
- which runs the Spyder IDE
- which runs your script
- which runs the mystery file pythonsh;
- which does something (runs it?) with the prepare_ligands4.py
file or the (missing) prepare_pdf4.py file;
- which does who knows what.
When having problems debugging this code, it helps to simplify the
problem by cutting Spyder out of the chain. If you run your script
directly, using a command like
python3 path/to/the/script.py
does the error go away? I suspect not, but you can keep that in mind for
future debugging.
> File
> "/home/comp/Apps/miniconda3/lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py",
>
> line 110, in execfile
> exec(compile(f.read(), filename, 'exec'), namespace)
>
> File "/home/comp/Apps/Models/1-NerveAgents/Ligands/calc_pdf.py", line
> 23, in
> print ('Subprocess FAILED:', proc.command)
>
> AttributeError: 'Popen' object has no attribute 'command'
That error message is completely correct: Popen objects don't have an
attribute called "command".
You are tring to print your own error message, referring to
"proc.command" but there is no such thing. What are you trying to do?
You need to find another way to do it.
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't
On 15May2019 08:16, Stephen P. Molnar wrote:
I am writing scripts to semi-automate some of my Quantum Chemistry
software and have encountered a problem that has me baffled. The two
scripts have the same form, the only difference being the commands.
As you say, the scripts are the same but for that tiny difference. So
let's look:
for nvar in ligand:
command = ["./pythonsh", "./prepare_ligand4.py",
[...]
command = ["./pythonsh", "./prepare_pdf4.py",
[...]
The errors are:
runfile('/home/comp/Apps/Models/1-NerveAgents/Ligands/calc_pdf.py',
wdir='/home/comp/Apps/Models/1-NerveAgents/Ligands')
b''
None
/sdc1/Apps/MGLTools2-1.1/bin/python: can't open file
'./prepare_pdf4.py': [Errno 2] No such file or directory
So: first issue: your prepare_pdf4.py file is missing. Is it really
missing or are you in the wrong working directory? Might its filename be
mistyped?
BTW, you shouldn't need the leading "./" on the .py filenames: harmless
but also useless. If you copied that usage from the "./pythonsh"
incantation, the circumstances are different. You probably need the
"./pythonsh" to execute it directly from the current directory, which is
not in your $PATH (and indeed it should not be - that way lies
subversion). The .py files are just data and do not need this.
Then, the second part. This is a totally separate error from your
script. Jumping to the bottom...
Traceback (most recent call last):
[...]
File "/home/comp/Apps/Models/1-NerveAgents/Ligands/calc_pdf.py",
line 23, in
print ('Subprocess FAILED:', proc.command)
AttributeError: 'Popen' object has no attribute 'command'
Because the prepare_pdf.py file is missing, for whatever reason, your
"if proc.returncode" fire. And in that code you access "proc.command",
which isn't defined. In the former script it doesn't try to execute this
line because pythonsh succeeded.
Looking at the subprocess docs, I think that is spelled "cmd", not
"command".
I have attached the two scripts that are called and a test input file.
This is a text only list. Attachments are dropped before your message
goes out. Fortunately you have enough information in the main body of
the message.
Googling has not helped me to find a solution [...]
1: I recommend duckduckgo instead of Google for privacy/tracking
reasons.
2: When I search, I tend to find people with the same problem, not
necessarily people with answers. But this question might be hard to get
good hits on because the problem lies in a spelling error, which others
may not have made that way.
Cheers,
Cameron Simpson
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
