FRCVLabMLSA_future < Main

<span style="color: #7a4707; font-family: 'Courier New', courier, monaco, monospace; white-space: pre;">&lt;meta name="robots" content="noindex" /&gt;</span>

---++ Future Work

- Handling other ways of calling Python

<ul>

     <li>PyAPI_FUNC(int) PyRun_AnyFileExFlags(FILE *fp, const char *filename, int, PyCompilerFlags *);</li>
     <ul>
          <li>Also PyRun_AnyFile or PyRun_AnyFileEx or PyRun_AnyFileFlags</li>
          <li>if FP is associated with an interactive device, return PyRun_InteractiveLoop(); else return the result of PyRun_SimpleFile().</li>
          <li>IF filename is NULL, the function uses &quot;???&quot; as the filename</li>
     </ul>

     <li>PyAPI_FUNC(int) PyRun_SimpleStringFlags(const char * command, PyCompilerFlags *);</li>
     <ul>
          <li> also PyRun_SimpleString</li>
          <li>"command" is the python command(s) to be executed. The function will create a __main__ function to add and run what is defined in "command"</li>      
          <ul>
               <li>the string can be filtered to find default Python functions</li>
               <li>using a default name for this kind of python call to represent it in the graph (numbered default name to differ calls)</li>
          </ul>
     </ul>

     <li>PyAPI_FUNC(int) PyRun_InteractiveOneFlags(FILE *fp, const char *filename, PyCompilerFlags *);</li>
     <ul>
               <li>also PyRun_InteractiveOne</li>
               <li> fp is an interactive device (console, terminal) and filename is the name of the file</li>
               <ul>
                    <li>executes only ONE statement from "filename"</li>
               </ul>
</ul>

     <li>PyAPI_FUNC(int) PyRun_InteractiveLoopFlags(FILE *fp, const char *filename, PyCompilerFlags *);</li>
     <ul>
          <li>Also PyRun_InteractiveLoop</li>
          <li>fp is an interactive device (console, terminal) and filename is the name of the file</li>
          <ul>
               <li>executes statements from "filename"</li>
          </ul>
     </ul>

     <li>PyAPI_FUNC(PyObject *) PyRun_StringFlags(const char *str, int start, PyObject *globals, PyObject *locals, PyCompilerFlags *);</li>
     <ul>
          <li>Also PyRun_String</li>
          <li>runs "str" in the context specified by "globals" and "locals"</li>
          <ul>
               <li>create a default function name for this kind of call, then use it as nodes in the graph</li>
          </ul>
     </ul>

     <li>PyAPI_FUNC(PyObject *) PyRun_FileExFlags(FILE *, const char *, int, PyObject *, PyObject *, int, PyCompilerFlags *);</li>
     <ul>
          <li>Also PyRun_File or PyRun_FileExFlags or PyRun_FileExFlags</li>
          <li>Python source code is read from fp, and filename is the name of the file.</li>
     </ul>

All these methods use a string as identifier to modules or commands. It should not be difficult to identify functions and analyze them. They are also similar to "PyRun_SimpleFile", which is already implemented .

     <li>Pure Embedding (most safe and complete way of calling python)</li>
     <ul>
          <li>see for the original code: https://docs.python.org/3/extending/embedding.html</li>
          <li>Process:</li>
          <ul>
               <li>pModule = PyImport_Import(PyObject *pName);</li>
               <ul>
                    <li>pName comes from converting C string to Python Object using Python.h interface. It is the name of the module(file) to open.</li>
               </ul>

               <li>pFunc = PyObject_GetAttrString(PyObject *pModule, const char *func);</li>
               <ul>
                    <li>func is the name of the function inside the module.</li>
               </ul>

               <li>pValue = PyObject_CallObject(PyObject *pFunc, PyObject *pArgs);</li>
               <ul>
                    <li>pArgs is the list of arguments. pValue is the return value of the function. It must be converted to a C type</li>
               </ul>

          </ul>
     </ul>


The problem with this approach is that there are multiple conversions and attributions before getting the reference to the function. A Reaching Definition Analysis is necessary to find the intermediate values.


There is a pattern for the steps to be performed, and it also gives more information about the function and the module. So it will make it easier to resolve scoping issues.

</ul>


---++ Permissions

   * Persons/group who can view/change the page:

   * Set ALLOWTOPICCHANGE = FRCVRoboticsGroup

-- (c) Fordham University Robotics and Computer Vision
This topic: Main > WebHome > FordhamRoboticsAndComputerVisionLaboratory > FRCVPublicProject > FRCVLabMLSA > FRCVLabMLSA_future
Topic revision: r1 - 2016-07-28 - BrunoVieiro