Is it possible to write a gnumeric python plugin for the file_opener and file_saver service?
It seems implemented in the python-loader plugin, there are corresponding sections in the Gnome documentation.
But the example plugin gnome-glossary, which is python file_saver plugin, raises an error ImportError: No module named gsf and I can't write in the output object given by the API:
def so_file_save(wb, output):
output.props.write("toto")
produces the error :
Exception Python (<type 'exceptions.AttributeError'> : 'gobject.GProps' object has no attribute 'write')
And this gobject.GProps object claim to be of __gtype__ : GsfOutputStdio
The python bindings for 'libgsf' are unsupported since a long time ago. As you can read in the old README-python:
I wrote these bindings in 2002, and they haven't been updated since.
They were never part of a standard build, but it was possible to build
them by following the instructions below. It will probably take some
work to make them work with current versions of autotools and
pygobject. Bindings would have to be revalidated, and extended to
match the current API of libgsf.
I do not plan to do further work on these bindings. If anybody wants
to pick them up, please feel free.
Jon K Hellan [...] 2006-02-24
That explaines why gnome-glossary fails. Also, it seems to be a problem with the parameter output, which is shown as a GObject, but not as GsfOutputStdio (you only can see the properties, but you do not have access to any method.
This is not the solution you are looking for, but an attempt of explanation of what you are seeing.
Related
I'm trying to implement Manipulating the zone identifier to specify where a file was download from – The Old New Thing - MSDN blogs in Python.
At CoCreateInstance:
pythoncom.CoCreateInstance(
pywintypes.IID('{0968e258-16c7-4dba-aa86-462dd61e31a3}'), #CLSID_PersistentZoneIdentifier
None,pythoncom.CLSCTX_ALL,
pywintypes.IID('{cd45f185-1b21-48e2-967b-ead743a8914e}')) #IID_IZoneIdentifier
I get an error:
TypeError: There is no interface object registered that supports this IID
(No stacktrace as this is an extension function)
If I replace the IZoneIdentifier IID with pythoncom.IID_IUnknown or pythoncom.IID_IPersistFile, it works, but a QueryInterface with the right IID fails with the same error.
Indeed, in HKCR\Interface, I see nothing like IZoneIdentifier but do see an IPersistFile.
Having disassembled urlmon.dll, I see that it indeed implements the interface, but doesn't register it in its DllRegisterServer. Searching further, I see that IPersistFile is being registered by ole32.dll - but not IZoneIdentifier.
MSDN documents this interface to be available since IE6. But it's not there in either IE7 or IE8. Since this is XP (and with all the updates allegedly), I've nothing else to try.
Likewise, the interface is present in Windows SDK 7.0 in the urlmon.h file mentioned in the MSDN article.
The questions are:
Was this interface silently dropped in favour of something else without MSDN reflecting that or something? Alternatively, is this a known issue? Is it available in later versions of IE?
What components do ole32.dll and urlmon.dll pertain to (so I can try (un)installing updates for them)?
There's nothing wrong with IZoneIdentifier. The original C++ program runs just fine. As #IgorTandetnik pointed out, not every interface an object implements is going to be registered in the registry, only those that support marshalling.
The error comes from pythoncom itself (a hint is that it's a TypeError, not pythoncom.com_error, and the error message is always in English rather than the system's UI language).
The cause is that pythoncom indeed requires IDispatch support by the interface - or it wouldn't be able to deduce how to work with the interface's functions and values they accept/return.
The only exception is a number of IUnknown-based interfaces support for which is compiled in (IPersistFile is one of them; the full list is in pythoncom.InterfaceNames apparently).
Support for other IUnknown-based interfaces can be added with a "pythoncom extension" module. Some (very scarce) documentation on them can be found in pywin32 docs in the Python and COM - Implementation Details article.
I've got the excelRTDserver.py up and running in Excel 2010 (32bit) by changing the EXCEL_TLB_MINOR value to 7. I can see the server in the add-ins list and if I enter =RTD("Python.RTD.TimeServer","","seconds","5") into a cell, I get the current time. But it never updates. If I change the "5" to another number, I get an update but after the initial change it never changes again.
How do I get it to update? I found someone else with a similar problem here, but no solution.
UPDATE: I've got a little further - there is an exception raised within ServerStart when casting the PyIDispatch callback object into a IRTDUpdateEvent callback object. Using this method to capture the error message, I get "Cannot create a file when that file already exists.". If I follow the suggestion here and use win32com.client.CastTo(CallbackObject,'IRTDUpdateEvent') I get "This COM object can not automate the makepy process - please run makepy manually for this object", but I have already run makepy for Microsoft Excel 12.0 Object Library (1.6).
Any help would be greatly appreciated.
To work around this problem I've created a new project on github for pythoncom excel types:
https://github.com/pyxll/exceltypes
This includes a slightly modified version of excelRTDServer.py that uses the new type PyIRTDUpdateEvent instead of the win32com makepy wrapper, and so it now works in Excel 2010 (look for the comments 'EXCELTYPES_MODIFICATION' in exceltypes/demos/excelRTDServer.py).
To build the project you will need visual studio installed (it won't build with gcc) and you can build it using the setup.py included in the project as follows:
python setup.py install
If you need to force it to use visual studio instead of gcc use the "--compiler=msvc" option, if you're using anaconda for example.
If you want to use Visual Studio 2012 instead of the default 2010 add the following lines to setup.py:
from distutils import msvc9compiler
msvc9compiler.VERSION = 11
I think you may be out of luck.
According to the author of excelRTDServer.py in a recent python-win32 thread:
The message that this is in response to describes your exact problem, and it's recent, so maybe you already got this info directly, but in case you didn't...
I fear that things with IRTDUpdateEvent have changed with recent versions
of excel (since Excel 2007? I guess that's not so 'recent' anymore...).
While hunting around for news of interface changes, I came across this
thread in a java forum:
http://www.nevaobject.com/phpbb3/viewtopic.php?t=516
The part that worries me is this comment:
"Apparently in Excel 12 (Excel 2007) the RTD callback object that
implements dual IRTDUpdateEvent interface throws exception (generic COM
exception 0x80020009) when is called via IDispatch. If you use v-table
binding the call to UpdateNotify succeeds. I don't really know whether it
is a bug in Excel 12 or a feature."
So far I haven't been able to confirm this against the MSDN information...
But if this is true, it does explain the problem being seen. Many older
examples on the web, and pywin32+makepy treat this interface as IDispatch,
and wrap it accordingly.
I don't think we can fix this with pywin32 as it is right now. My
understanding is that it relies on IDispatch support. May need to look at
comtypes (http://starship.python.net/crew/theller/comtypes/) to wrap the
(new?) IRTDUpdateEvent objects, or maybe a C extension. :(
Python:
I get "This COM object can not automate the makepy process - please run makepy manually for this object", but I have already run makepy for Microsoft Excel 12.0 Object Library (1.6).
Yesterday at work after a while reading your question, I forgot that is python and not java :)).. Well, the only thing I think now is that seems you need to run the PIA for office 2010.
Edit later: if you steel have problems after what i told you., please comment and not downvote, because this issue is uncommon.
JAVA:
This happen because is missing the option to generate v-tables.
You need to modify ServerStart method and also IRTDServer interface and IRTDServer_Impl class., so CallbackObject is COMIUnknown. Then you need to generate IRTDServer_Skel class by runing the IBuilder.
Now you can generate a new java wrapper for IRTDUpdateEvent to request v-table:
That error message sometimes is raised when u put it in something like 'for'-loop,here is a hackly solution 4u:import time,and use 'sleep()' in your loop
The IRTDUpdateEvent problem (throwing exception) as described in here should be fixed in the latest Office 365 version.
"Apparently in Excel 12 (Excel 2007) the RTD callback object that implements dual IRTDUpdateEvent interface throws exception (generic COM exception 0x80020009) when is called via IDispatch. If you use v-table binding the call to UpdateNotify succeeds. I don't really know whether it is a bug in Excel 12 or a feature."
Therefore excelRTDserver.py should work fine with the latest version of Office. In other words, =RTD("Python.RTD.TimeServer","","seconds","5") should continuously get updated as expected.
My end goal is to query NVAPI for gpu usage and other statistics in python. See http://developer.nvidia.com/nvapi
from ctypes import WinDLL
nvapi = WinDLL("nvapi.dll")
print nvapi# <WinDLL 'nvapi.dll', handle 718a0000 at 27c0050>
print nvapi.nvapi_QueryInterface# <_FuncPtr object at 0x026D8E40>
print nvapi.nvapi_QueryInterface()# returns 0
print nvapi.NvAPI_Initialize# AttributeError: function 'NvAPI_Initialize' not found
print nvapi.NvAPI_SYS_GetChipSetInfo# AttributeError: function 'NvAPI_SYS_GetChipSetInfo' not found
Here is a copy of the header file available for download from the link above: http://paste.pound-python.org/show/7337/
At this point, I am just trying to familiarize myself with the api... so what am I doing wrong? I can't figure out how to call any of the functions listed in the header file.
Are you sure it's a WinDLL? From the header file, it looks like a standard C calling convention to me. Have you tried CDLL instead?
EDIT:
I see now. The header you pointed to isn't actually the interface for nvapi.dll--it is a wrapper around it that must be statically linked.
From the docs downloaded from NVIDIA's developer site:
Use a Static Link with Applications
NvAPI cannot be dynamically linked to applications. You must create a static link to the library and then call NvAPI_Initialize(), which loads nvapi.dll dynamically.
If the NVIDIA drivers are not installed on the system or nvapi.dll is not present when the application calls NvAPI_Initialize(), the call just returns an error. The application will still load.
I would guess that the actual calls in nvapi.dll are completely different than the ones exposed in this wrapper library. I can't seem to find any documentation on those though. Perhaps they are internal and change between systems.
If you want to use this interface, I'm not really sure what the best solution is. It's a static library and not a dynamic one, so ctypes wouldn't handle it unless you wrapped it in another DLL. I'm not an expert at native code with Python, so maybe someone else will have an easy fix. Sorry.
Taken from your comment:
NvAPI_Initialize call still fails.
saying the function is not found.
NvAPI_Initialize is not exported from the dynamic library nvapi.dll. It is a symbol contained in nvapi.lib, the static library shipped with the NVIDIA SDK, thus it's no wonder you are unable to call it using Python.
Honestly, the easiest route here is to create a small wrapper DLL in C, statically linking to nvapi.lib and exposing a friendly interface to Python.
In default installation of cedet-1.0 completion can only track global scope symbols in current file. This is not much differs from built-in completion functions (dabbrev-expand or hippie-expand).
It can complete symbols from neither imported modules, nor class properties.
Not saying it cannot handle 'self'.
Is it possible to tweak semantic to do the things?
P.S.
ECB code browser sucesfully sees all imports/base classess and stuff.
It is symbol completion workd incorrectly, or not properly set up.
CEDET support for each language is slightly different. In the case of python, the 1.0 release for CEDET hadn't been configured to convert a python import into a file-name. In addition, 'self' is similar to 'this' in c++, which needs to be added by completion logic since it isn't declared. These two features were added to the bzr repository in January of this year. I am not a python programmer, but I recall reports that this fixed a range of the most basic features of smart completion so that symbols from imported libraries works. There was also new code in bzr for python system paths.
Thus, I recommend downloading CEDET from bzr to get these features to see if it now does what you would expect for smart completion.
How do I, at run-time (no LD_PRELOAD), intercept/hook a C function like fopen() on Linux, a la Detours for Windows? I'd like to do this from Python (hence, I'm assuming that the program is already running a CPython VM) and also reroute to Python code. I'm fine with just hooking shared library functions. I'd also like to do this without having to change the way the program is run.
One idea is to roll my own tool based on ptrace(), or on rewriting code found with dlsym() or in the PLT, and targeting ctypes-generated C-callable functions, but I thought I'd ask here first. Thanks.
You'll find from one of ltrace developer a way to do this. See this post, which includes a full patch in order to catch dynamically loaded library. In order to call it from python, you'll probably need to make a C module.
google-perftools has their own implementation of Detour under src/windows/preamble_patcher* . This is windows-only at the moment, but I don't see any reason it wouldn't work on any x86 machine except for the fact that it uses win32 functions to look up symbol addresses.
A quick scan of the code and I see these win32 functions used, all of which have linux versions:
GetModuleHandle/GetProcAddress : get the function address. dlsym can do this.
VirtualProtect : to allow modification of the assembly. mprotect.
GetCurrentProcess: getpid
FlushInstructionCache (apparently a nop according to the comments)
It doesn't seem too hard to get this compiled and linked into python, but I'd send a message to the perftools devs and see what they think.