We Keep Coding

Intel Vtune cannot find python source file

This is an old problem as is demonstrated as in https://community.intel.com/t5/Analyzers/Unable-to-view-source-code-when-analyzing-results/td-p/1153210. I have tried all the listed methods, none of them works, and I cannot find any more solutions on the internet. Basically vtune cannot find the custom python source file no matter what is tried. I am using the most recently version as of speaking. Please let me whether there is a solution.
For example, if you run the following program.
def myfunc(*args):
# Do a lot of things.
if __name__ = '__main__':
# Do something and call myfunc
Call this script main.py. Now use the newest vtune version (I have using Ubuntu 18.04), run the vtune-gui and basic hotspot analysis. You will not found any information on this file. However, a huge pile of information on Python and its other codes are found (related to your python environment). In theory, you should be able to find the source of main.py as well as cost on each line in that script. However, that is simply not happening.
Desired behavior: I would really like to find the source file and function in the top-down manual (or any really). Any advice is welcome.

VTune offer full support for profiling python code and the tool should be able to display the source code in your python file as you expected. Could you please check if the function you are expecting to see in the VTune results, ran long enough?
Just to confirm that everything is working fine, I wrote a matrix multiplication code as shown below (don't worry about the accuracy of the code itself):
def matrix_mul(X, Y):
result_matrix = [ [ 1 for i in range(len(X)) ] for j in range(len(Y[0])) ]
# iterate through rows of X
for i in range(len(X)):
# iterate through columns of Y
for j in range(len(Y[0])):
# iterate through rows of Y
for k in range(len(Y)):
result_matrix[i][j] += X[i][k] * Y[k][j]
return result_matrix
Then I called this function (matrix_mul) on my Ubuntu machine with large enough matrices so that the overall execution time was in the order of few seconds.
I used the below command to start profiling (you can also see the VTune version I used):
/opt/intel/oneapi/vtune/2021.1.1/bin64/vtune -collect hotspots -knob enable-stack-collection=true -data-limit=500 -ring-buffer=10 -app-working-dir /usr/bin -- python3 /home/johnypau/MyIntel/temp/Python_matrix_mul/mat_mul_method.py
Now open the VTune results in the GUI and under the bottom-up tab, order by "Module / Function / Call-stack" (or whatever preferred grouping is).
You should be able to see the the module (mat_mul_method.py in my case) and the function "matrix_mul". If you double click, VTune should be able to load the sources too.

Is there any way to print it in python(python bridging on prolog)?

I am trying to run the prolog queries from the python program by using pyswip.
Suppose i have a program like this,
from pyswip import Prolog
p = Prolog()
p.retractall('rule1(_,_)')
p.retractall('rule2(_,_)')
p.retractall('rule3(_,_)')
p.assertz('rule2(X):- writeln(\'in rule2\': X)')
p.assertz('rule1(X,Y):- rule2(X), writeln(\'rule2 exectued\'),rule3(Y)')
p.assertz('rule3(Y):- writeln(\'in rule3\': Y)')
print(list(p.query('rule1(1,2)')))
now what i want is that all those writeln rules which will print in prolog, i want that to be printed in the python terminal.is there any way to do it ?

For me this behaves as follows:
>>> print(list(p.query('rule1(1,2)')))
in rule2:1
rule2 exectued
in rule3:2
[{}]
Your writeln statements are executed as expected, the output is printed to the Python terminal. Is the output different for you? Do you want it to be different?
Edit (see comments below): When Python is not run directly in a terminal but rather in a Jupyter notebook or similar, the Prolog output can get lost. In that case, the Prolog query can be wrapped in with_output_to(atom(PrologOutput), ...), which will capture the Prolog code's output in an atom (a Python string):
>>> print(list(p.query('with_output_to(atom(PrologOutput), rule1(1,2))')))
[{'PrologOutput': 'in rule2:1\nrule2 exectued\nin rule3:2\n'}]

How to execute python function as whole in VSCode (it splits and sends just the first line to an interpreter)

I'm getting used to VSCode in my daily Data Science remote workflow due to LiveShare feature.
So, upon executing functions it just executes the first line of code; if I mark the whole region then it does work, but it's cumbersome way of dealing with the issue.
I tried number of extensions, but none of them seem to solve the problem.
def gini_normalized(test, pred):
"""Simple normalized Gini based on Scikit-Learn's roc_auc_score"""
gini = lambda a, p: 2 * roc_auc_score(a, p) - 1
return gini(test, pred)
Executing the beginning of the function results in error:
def gini_normalized(test, pred):...
File "", line 1
def gini_normalized(test, pred):
^
SyntaxError: unexpected EOF while parsing
There's a solution for PyCharm: Python Smart Execute - https://plugins.jetbrains.com/plugin/11945-python-smart-execute. Also Atom's Hydrogen doesn't have such issue either.
Any ideas regarding VSCode?
Thanks!

I'm a developer on the VSCode DataScience features. Just to make sure that I'm understanding correctly. You would like the shift-enter command to send the entire function to the Interactive Window if you run it on the definition of the function?
If so, then yes, we don't currently support that. Shift-enter can run line by line or run a section of code that you manually highlight. If you want, you can use #%% lines in your code to put functions into code cells. Then when you are in a cell shift-enter will run that entire cell, might be the best current approach for you.
That smart execute does look interesting, if you would like to file that as a suggestion you can use our GitHub here to get it on our backlog to look at.
https://github.com/Microsoft/vscode-python

Hi you could click the symbol before each line and turn it into > (the indented codes of the function was hidden now). Then if you select the whole line and the next line, shift+enter could run them together.
enter image description here

Pythondialog: Unable to retrieve the version of the dialog-like backend

Minimal code example, run on OSX and Python 3:
#! /usr/bin/env python3
from dialog import Dialog
d = Dialog(dialog="dialog")
sel = d.menu("Test",
choices=[ ("FooTag", "Foo", False, "FooHelp"),
("BarTag", "Bar", True, "BarHelp")]
)
I get the error message:
Traceback (most recent call last):
File "./test.py", line 5, in <module>
d = Dialog(dialog="dialog")
File "/usr/local/lib/python3.3/site-packages/dialog.py", line 1371, in __init__
self.backend_version())
File "/usr/local/lib/python3.3/site-packages/dialog.py", line 2012, in backend_version
"{1!r}".format(self._dialog_prg, output))
dialog.UnableToRetrieveBackendVersion: Unable to retrieve the version of the dialog-like backend: unable to parse the output of '/usr/local/bin/dialog --print-version': ''
However, dialog reports correctly:
> dialog --print-version
Version: 1.1-20100428
>
Nothing changes, if I use the absolut path /usr/local/bin/dialog. I guess, it is an install problem, but I've no clue.

As you have found yourself, the problem is caused by the fact that your dialog program prints its version on stdout whereas more recent versions print it on stderr. So, the string pythondialog tries to parse as a version number is empty in such a case.
pythondialog 3.2.2rc1 (latest release at the time of this writing) detects this situation and automatically reruns dialog --stdout --print-version, making sure this time to read from dialog's stdout stream. Since this is only done once at Dialog instance creation (the backend version being cached), the impact of this workaround is minimal.
It is better than your solution (passing use_stdout=True to the Dialog constructor), because it allows the rest of pythondialog to use dialog's stderr stream normally: the use of --stdout is only limited to retrieving the version of dialog. On the contrary, the solution you found will pass --stdout to all dialog calls which, according to the dialog(1) manual page, may fail "depending on the platform and your environment".
Had you reported this problem on the pythondialog issue tracker or mailing list, the workaround I mentioned here would certainly have been implemented earlier...

Your example with little fixes for on my computer (i changed False to 'False'). Your issue is that version is not matched against regex. This is code from pythondialog:
mo = self._print_version_cre.match(output)
if mo:
return mo.group("version")
else:
raise UnableToRetrieveBackendVersion(
"unable to parse the output of '{0} --print-version': "
"{1!r}".format(self._dialog_prg, output))
#this is located upper
_print_version_cre = re.compile(r"^Version:[ \t]+(?P<version>.+?)[ \t]*$", re.MULTILINE)
I've tested your version with this regexp and it matched on my computer, but I guess you have other version of pythondialog. So check _print_version_cre in your dialog.py and try to much with dialog version.

I found the solution myself:
dialog in OSX reports to stdout, not stderr.
By using
d = Dialog(dialog="dialog", use_stdout=True)
I get the expected result.

Loading a document on OpenOffice using an external Python program

I'm trying to create a python program (using pyUNO ) to make some changes on a OpenOffice calc sheet.
I've launched previously OpenOffice on "accept" mode to be able to connect from an external program. Apparently, should be as easy as:
import uno
# get the uno component context from the PyUNO runtime
localContext = uno.getComponentContext()
# create the UnoUrlResolver
resolver = localContext.ServiceManager.createInstanceWithContext(
"com.sun.star.bridge.UnoUrlResolver", localContext)
# connect to the running office
ctx = resolver.resolve("uno:socket,host=localhost,port=2002;"
"urp;StarOffice.ComponentContext")
smgr = ctx.ServiceManager
# get the central desktop object
DESKTOP =smgr.createInstanceWithContext("com.sun.star.frame.Desktop", ctx)
#The calling it's not exactly this way, just to simplify the code
DESKTOP.loadComponentFromURL('file.ods')
But I get an AttributeError when I try to access loadComponentFromURL. If I make a dir(DESKTOP), I've see only the following attributes/methods:
['ActiveFrame', 'DispatchRecorderSupplier', 'ImplementationId', 'ImplementationName',
'IsPlugged', 'PropertySetInfo', 'SupportedServiceNames', 'SuspendQuickstartVeto',
'Title', 'Types', 'addEventListener', 'addPropertyChangeListener',
'addVetoableChangeListener', 'dispose', 'disposing', 'getImplementationId',
'getImplementationName', 'getPropertySetInfo', 'getPropertyValue',
'getSupportedServiceNames', 'getTypes', 'handle', 'queryInterface',
'removeEventListener', 'removePropertyChangeListener', 'removeVetoableChangeListener',
'setPropertyValue', 'supportsService']
I've read that there are where a bug doing the same, but on OpenOffice 3.0 (I'm using OpenOffice 3.1 over Red Hat5.3). I've tried to use the workaround stated here, but they don't seems to be working.
Any ideas?

It has been a long time since I did anything with PyUNO, but looking at the code that worked last time I ran it back in '06, I did my load document like this:
def urlify(path):
return uno.systemPathToFileUrl(os.path.realpath(path))
desktop.loadComponentFromURL(
urlify(tempfilename), "_blank", 0, ())
Your example is a simplified version, and I'm not sure if you've removed the extra arguments intentionally or not intentionally.
If loadComponentFromURL isn't there, then the API has changed or there's something else wrong, I've read through your code and it looks like you're doing all the same things I have.
I don't believe that the dir() of the methods on the desktop object will be useful, as I think there's a __getattr__ method being used to proxy through the requests, and all the methods you've printed out are utility methods used for the stand-in object for the com.sun.star.frame.Desktop.
I think perhaps the failure could be that there's no method named loadComponentFromURL that has exactly 1 argument. Perhaps giving the 4 argument version will result in the method being found and used. This could simply be an impedance mismatch between Python and Java, where Java has call-signature method overloading.

This looks like issue 90701: http://www.openoffice.org/issues/show_bug.cgi?id=90701
See also http://piiis.blogspot.com/2008/10/pyuno-broken-in-ooo-30-with-system.html and http://udk.openoffice.org/python/python-bridge.html