- Masking out SBCommandReturnObject::Printf() from the Python layer because SWIG...
authorEnrico Granata <egranata@apple.com>
Mon, 25 Mar 2013 17:37:39 +0000 (17:37 +0000)
committerEnrico Granata <egranata@apple.com>
Mon, 25 Mar 2013 17:37:39 +0000 (17:37 +0000)
It is replaced by a Print("str") call which is equivalent to Printf("%s","str")
- Providing file-like behavior for SBStream with appropriate extension write() and flush() calls, plus documenting that these are only meant and only exist for Python
Documenting the file-like behavior on our website

llvm-svn: 177877

lldb/scripts/Python/interface/SBCommandReturnObject.i
lldb/scripts/Python/python-extensions.swig
lldb/www/python-reference.html

index e5f062c..e72c1e2 100644 (file)
@@ -86,8 +86,14 @@ public:
        void
        PutCString(const char* string, int len = -1);
 
-       size_t
-       Printf(const char* format, ...);
+    // wrapping the variadic Printf() with a plain Print()
+    // because it is hard to support varargs in SWIG bridgings
+    %extend {
+        void Print (const char* str)
+        {
+            self->Printf("%s", str);
+        }
+    }
 
 };
 
index 84c719c..29eae6d 100644 (file)
                 else
                     return PyString_FromString("");
         }
+        
+        /* the write() and flush() calls are not part of the SB API proper, and are solely for Python usage
+        they are meant to make an SBCommandReturnObject into a file-like object so that instructions of the sort
+        print >>sb_command_return_object, "something"
+        will work correctly */
+
         void lldb::SBCommandReturnObject::write (const char* str)
         {
             if (str)
                     return PyString_FromString("");
         }
 }
+%extend lldb::SBStream {
+        /* the write() and flush() calls are not part of the SB API proper, and are solely for Python usage
+        they are meant to make an SBStream into a file-like object so that instructions of the sort
+        print >>sb_stream, "something"
+        will work correctly */
+
+        void lldb::SBStream::write (const char* str)
+        {
+            if (str)
+                $self->Printf("%s",str);
+        }
+        void lldb::SBStream::flush ()
+        {}
+}
 %extend lldb::SBSymbol {
         PyObject *lldb::SBSymbol::__str__ (){
                 lldb::SBStream description;
index 86edbc5..daf0b98 100755 (executable)
@@ -368,10 +368,9 @@ Enter your Python command(s). Type 'DONE' to end.
                 <b>lldb.SBCommandReturnObject</b>\r
             </td>\r
             <td class="content">\r
-                A return object where you can indicate the success or failure of your command. You can also\r
-                provide information for the command result by printing data into it. You can also just print\r
-                data as you normally would in a python script and the output will show up; this is useful for\r
-                logging, but the real output for your command should go in the result object.\r
+                A return object which encapsulates success/failure information for the command and output text\r
+                that needs to be printed as a result of the command. The plain Python "print" command also works but\r
+                text won't go in the result by default (it is useful as a temporary logging facility).\r
             </td>\r
         </tr>\r
         <tr>\r
@@ -387,6 +386,9 @@ Enter your Python command(s). Type 'DONE' to end.
             </td>\r
         </tr>\r
         </table>\r
+        <p>As a convenience, you can treat the result object as a Python file object, and say\r
+        print >>result, "my command does lots of cool stuff". SBCommandReturnObject and SBStream\r
+        both support this file-like behavior by providing write() and flush() calls at the Python layer.</p>\r
         <p>One other handy convenience when defining lldb command-line commands is the command\r
           <b>command script import</b> which will import a module specified by file path - so you\r
           don't have to change your PYTHONPATH for temporary scripts.  It also has another convenience\r