[PATCH] python3 support for /usr/bin/dtrace

[PATCH] python3 support for /usr/bin/dtrace

[Nathan Scott]

Hi all,

Came across a few syntax issues when building PCP with static
probes enabled on a system where python3 was default.  Patch
below gets me to a working build again.

cheers.

--
Nathan


Use python syntax in dtrace.in that works for python v3 also

A series of syntax errors result if /usr/bin/dtrace is run on
a python3 system, such as:

  File "/usr/bin/dtrace", line 190
    except ParseException, err:
                         ^
SyntaxError: invalid syntax

The downside to this change is that python versions before 2.6
may no longer work, but that seems to be a fairly common minimum
python version these days.

diff --git a/dtrace.in b/dtrace.in
index aa51d57..564cf0a 100644
--- a/dtrace.in
+++ b/dtrace.in
@@ -187,12 +187,12 @@ class _PypProvider(_HeaderCreator):
             except TypeError:
                 # pyparsing-1.5.0 does not support parseAll
                 self.ast = self.bnf.parseFile(provider).asList()
-        except ParseException, err:
+        except ParseException as err:
             if len(self.current_probe):
-                print "Warning: %s:%s:%d: syntax error near:\nprobe %s\n" % (sys.argv[0],provider, self.current_lineno, self.current_probe)
+                print("Warning: %s:%s:%d: syntax error near:\nprobe %s\n" % (sys.argv[0],provider, self.current_lineno, self.current_probe))
             else:
-                print "Warning: %s:%s:%d syntax error near:\n%s\n" % (sys.argv[0],provider,err.lineno, err.line)
-            raise ParseException, err
+                print("Warning: %s:%s:%d syntax error near:\n%s\n" % (sys.argv[0],provider,err.lineno, err.line))
+            raise(ParseException, err)
   
         probes_def = ""
         for asti in self.ast:
@@ -275,19 +275,19 @@ class _ReProvider(_HeaderCreator):
 
 
 def usage():
-    print "Usage " + sys.argv[0] + " [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]"
+    print("Usage " + sys.argv[0] + " [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]")
 
 
 def dtrace_help():
     usage()
-    print "Where -h builds a systemtap header file from the .d file"
-    print "      -C when used with -h, also run cpp preprocessor"
-    print "      -o specifies an explicit output file name,"
-    print "         the default for -G is file.o and -h is file.h"
-    print "      -I when running cpp pass through this -I include Path"
-    print "      -s specifies the name of the .d input file"
-    print "      -G builds a stub file.o from file.d,"
-    print "         which is required by some packages that use dtrace."
+    print("Where -h builds a systemtap header file from the .d file")
+    print("      -C when used with -h, also run cpp preprocessor")
+    print("      -o specifies an explicit output file name,")
+    print("         the default for -G is file.o and -h is file.h")
+    print("      -I when running cpp pass through this -I include Path")
+    print("      -s specifies the name of the .d input file")
+    print("      -G builds a stub file.o from file.d,")
+    print("         which is required by some packages that use dtrace.")
     sys.exit(1)
 
 
@@ -338,7 +338,7 @@ def main():
         elif sys.argv[i] == "--no-pyparsing":
             HAVE_PYP = False
         elif sys.argv[i] == "--types":
-            print sys.argv[0] + ": note: obsolete option --types used"
+            print(sys.argv[0] + ": note: obsolete option --types used")
         elif sys.argv[i] in ignore_options:
             pass                # dtrace users sometimes pass these flags
         elif sys.argv[i] in ignore_options2:
@@ -347,7 +347,7 @@ def main():
         elif sys.argv[i] == "--help":
             dtrace_help()
         elif sys.argv[i][0] == "-":
-            print sys.argv[0], "invalid option", sys.argv[i]
+            print(sys.argv[0], "invalid option", sys.argv[i])
             usage()
             return 1
         i += 1
@@ -360,7 +360,7 @@ def main():
         cpp = os.environ.get("CPP", "cpp")
         retcode = call(split(cpp) + includes + defines + [s_filename, fname])
         if retcode != 0:
-            print "\"cpp includes s_filename\" failed"
+            print("\"cpp includes s_filename\" failed")
             usage()
             return 1
         s_filename = fname
@@ -386,8 +386,8 @@ def main():
             # complex C declarations can fool the pyparsing grammar.  
             # we could increase the complexity of the grammar
             # instead we fall back to string pattern matching
-            except ParseException, err:
-                print "Warning: Proceeding as if --no-pyparsing was given.\n"
+            except ParseException as err:
+                print("Warning: Proceeding as if --no-pyparsing was given.\n")
                 providers = _ReProvider()
     elif build_source:
         if HAVE_PYP:
@@ -399,13 +399,13 @@ def main():
             try:
                 providers.probe_write(s_filename, fname)
                 break;
-            except ParseException, err:
-                print "Warning: Proceeding as if --no-pyparsing was given.\n"
+            except ParseException as err:
+                print("Warning: Proceeding as if --no-pyparsing was given.\n")
                 providers = _ReProvider()
         if not keep_temps:
             os.remove(fname)
         else:
-            print "header: " + fname
+            print("header: " + fname)
 
         (ignore, fname) = mkstemp(suffix=".c")
         fdesc = open(fname, mode='w')
@@ -417,19 +417,19 @@ def main():
              ["-fPIC", "-I.", "-I@prefix@/include", "-c", fname, "-o",
               filename + suffix], shell=False)
         if retcode != 0:
-            print "\"gcc " + fname + "\" failed"
+            print("\"gcc " + fname + "\" failed")
             usage()
             return 1
         if not keep_temps:
             os.remove(fname)
         else:
-            print "source: " + fname
+            print("source: " + fname)
 
     if use_cpp:
         if not keep_temps:
             os.remove(s_filename)
         else:
-            print "cpp: " + s_filename
+            print("cpp: " + s_filename)
 
     return 0
 

Re: [PATCH] python3 support for /usr/bin/dtrace

[Frank Ch. Eigler]

Hi -

> Came across a few syntax issues when building PCP with static
> probes enabled on a system where python3 was default.  [...]

By default, meaning /usr/bin/python mapping to python3?  Or do you
mean just that /usr/bin/python may be missing, so we should consider
hash-banging /usr/bin/python3 instead?


> [...]  The downside to this change is that python versions before
> 2.6 may no longer work, but that seems to be a fairly common minimum
> python version these days.

RHEL5 ships with python 2.4.*.  Is there a solution that lets that
work too?


- FChE

Re: [PATCH] python3 support for /usr/bin/dtrace

[Nathan Scott]

----- Original Message -----
> > [...] 
> > Came across a few syntax issues when building PCP with static
> > probes enabled on a system where python3 was default.  [...]
> 
> By default, meaning /usr/bin/python mapping to python3?

Yes, by "a system where python3 was default" I meant:

$ /usr/bin/python --version
Python 3.3.2

cheers.

--
Nathan

Re: [PATCH] python3 support for /usr/bin/dtrace

[Frank Ch. Eigler]

Hi -

> Yes, by "a system where python3 was default" I meant:
> $ /usr/bin/python --version
> Python 3.3.2

What distro is doing or planning to do this?  AIUI, it is contrary to
python3 adoption plans for the major ones.


- FChE

Re: [PATCH] python3 support for /usr/bin/dtrace

[Nathan Scott]

----- Original Message ----
> > Yes, by "a system where python3 was default" I meant:
> > $ /usr/bin/python --version
> > Python 3.3.2
> 
> What distro is doing or planning to do this?

The only distro I know of that has switched completely is:
https://www.archlinux.org/news/python-is-now-python-3/

But others (like f23) plan to have the option of having only
python3 installed, by default.  And of course, its alot less
patching if everything except the hashbang line of the script
supports both major versions (which is what we'll be doing in
PCP for the time being, FWLIW).

*shrug* - do with the patch as you see fit; just figured I'd
share the problem & one potential fix you could use.

cheers.

--
Nathan

Re: [PATCH] python3 support for /usr/bin/dtrace

[Frank Ch. Eigler]

Hi -

> The only distro I know of that has switched completely is:
> https://www.archlinux.org/news/python-is-now-python-3/

Right.

> But others (like f23) plan to have the option of having only
> python3 installed, by default.  

Yeah, that's different though (/usr/bin/python3 installed, not
/usr/bin/python redirected).


> And of course, its alot less patching if everything except the
> hashbang line of the script supports both major versions (which is
> what we'll be doing in PCP for the time being, FWLIW).

Understood.  If there were no downside (compatibility down to
older supported OS's like RHEL5), there's be no problem.


> *shrug* - do with the patch as you see fit; just figured I'd
> share the problem & one potential fix you could use.

Another fix to the archlinux problem is to "#! /usr/bin/python2".


- FChE

Re: [PATCH] python3 support for /usr/bin/dtrace

[David Smith]

On 02/21/2015 02:31 PM, Frank Ch. Eigler wrote:
> 
> Hi -
> 
>> Came across a few syntax issues when building PCP with static
>> probes enabled on a system where python3 was default.  [...]
> 
> By default, meaning /usr/bin/python mapping to python3?  Or do you
> mean just that /usr/bin/python may be missing, so we should consider
> hash-banging /usr/bin/python3 instead?
> 
> 
>> [...]  The downside to this change is that python versions before
>> 2.6 may no longer work, but that seems to be a fairly common minimum
>> python version these days.
> 
> RHEL5 ships with python 2.4.*.  Is there a solution that lets that
> work too?

I tested this patch and found it didn't work on python 2.4. I took out
the failing part (the new exception handling) and checked in the rest as
commit d576100.

I think I may have an idea of how to fix the exception handling to
handle python 2.4+.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: [PATCH] python3 support for /usr/bin/dtrace

[Frank Ch. Eigler]

> [...]
>> RHEL5 ships with python 2.4.*.  Is there a solution that lets that
>> work too?

Yes, there is; a hack from http://python3porting.com/noconv.html makes
exception catching work on rhel5's python2.4 and python3.  A new
commit does this, and a the dtrace.exp test case checks that the
python script runs fully on both python2 & python3.

- FChE

Re: [PATCH] python3 support for /usr/bin/dtrace

[Nathan Scott]

----- Original Message -----
> [...]
> I tested this patch and found it didn't work on python 2.4. I took out
> the failing part (the new exception handling) and checked in the rest as
> commit d576100.
> 
> I think I may have an idea of how to fix the exception handling to
> handle python 2.4+.
> 

Nice - thanks David!

cheers.

--
Nathan