Lawrence Oluyede | 1 Aug 2006 12:14
Picon
Gravatar

Re: newbie help

> Now, I've tried what you describe.  When I try to implement, I get an error
> that says something to the effect of "can't resolve argument 2...."

Can you paste the lines generating the error and the full traceback?

--

-- 
Lawrence
http://www.oluyede.org/blog

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Lawrence Oluyede | 1 Aug 2006 14:18
Picon
Gravatar

Re: newbie help

On 8/1/06, Todd Dahling <dahlingt <at> gmail.com> wrote:
> PythonWin 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
> win32.
> Portions Copyright 1994-2004 Mark Hammond (mhammond <at> skippinet.com.au) - see
> 'Help/About PythonWin' for further copyright information.
> >>> from ctypes import *
> >>> inDLL=CDLL("c:\\indll.dll")
> >>> fcn=inDLL.fcn
> >>> session = c_int(0)
> >>> MAX = 255
> >>> addList = c_long*MAX
>  >>> listSize = c_int(MAX)
> >>> numFound = POINTER(c_int)
> >>> rsrc = c_char*MAX
> >>> rsrcLen = c_int(MAX)
> >>> fcn(session, addList, listSize, numFound, rsrc, rsrcLen)
>  Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ArgumentError: argument 2: exceptions.TypeError: Don't know how to convert
> parameter 2

First: you should reply to "all" not only to me. Use reply all not "reply".

Second: there's some mistakes up there:

addList = c_long * MAX it's a type declaration not a variable. You are
declaring addList as an array of MAX length. Function expects an
array, not its type. I specified this in my first email.

addList_type = c_long * MAX
(Continue reading)

Todd Dahling | 2 Aug 2006 13:01
Picon

Re: newbie help

OK, so here is what I do:
 
>>> inDLL = CDLL(....)
>>> FCN = inDLL.fcn
>>> session = c_int(0)
>>> MAX = 255
>>> addList_type = c_long*MAX
>>> addList = addList_type()
>>> listSize = c_long(MAX)
>>> numFound = c_long()
>>> rsrc_type = c_char*MAX
>>> rsrc = rsrc_type()
>>> rsrcLen = c_long(MAX)
>>> hpe1432_find(session, addList, listSize, byref(numFound), rsrc, rsrcLen)
 
with the result:
 
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
ValueError: Procedure called with not enough arguments (24 bytes missing) or wrong calling convention
 
Now, it's interesting that "addList[0]" is 13 (it should be), rest zeros.  numFound is c_long(1), meaning it found 1 item.  rsrc[0:16] has the correct string in it.  so, it's finding all the hardware like it should, but still returns an error
 
The function should return a 0 or 1 status too.  I dont know exactly what is happening, but I think it's because the function is declared with zero-length arrays, like this:
 
Status FCN(Int32, Int32 addList[], Int32 listSize, &numFound, char rsrc[], Int32 rsrcLen);
 
(Int32 addList[] AND char rsrc[])
 
any further thoughts are appreciated
Thanks 
 
On 8/1/06, Lawrence Oluyede <l.oluyede <at> gmail.com> wrote:
On 8/1/06, Todd Dahling <dahlingt <at> gmail.com> wrote:
> PythonWin 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
> win32.
> Portions Copyright 1994-2004 Mark Hammond (mhammond <at> skippinet.com.au) - see
> 'Help/About PythonWin' for further copyright information.
> >>> from ctypes import *
> >>> inDLL=CDLL("c:\\indll.dll")
> >>> fcn=inDLL.fcn
> >>> session = c_int(0)
> >>> MAX = 255
> >>> addList = c_long*MAX
>  >>> listSize = c_int(MAX)
> >>> numFound = POINTER(c_int)
> >>> rsrc = c_char*MAX
> >>> rsrcLen = c_int(MAX)
> >>> fcn(session, addList, listSize, numFound, rsrc, rsrcLen)
>  Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ArgumentError: argument 2: exceptions.TypeError: Don't know how to convert
> parameter 2

First: you should reply to "all" not only to me. Use reply all not "reply".

Second: there's some mistakes up there:

addList = c_long * MAX it's a type declaration not a variable. You are
declaring addList as an array of MAX length. Function expects an
array, not its type. I specified this in my first email.

addList_type = c_long * MAX
addList = addList_type()

The same for rsrc

numFound is a POINTER to an int (int * in C) which is a type, not a
variable of that type. numFound should be declared as a plain c_int
and passed by reference this way:

function(foo, byref(numFound), baz)


--
Lawrence
http://www.oluyede.org/blog

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ctypes-users mailing list
ctypes-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ctypes-users
Thomas Heller | 2 Aug 2006 13:26
Favicon

Re: newbie help

Todd Dahling schrieb:
> OK, so here is what I do:
> 
>>>> inDLL = CDLL(....)
>>>> FCN = inDLL.fcn
>>>> session = c_int(0)
>>>> MAX = 255
>>>> addList_type = c_long*MAX
>>>> addList = addList_type()
>>>> listSize = c_long(MAX)
>>>> numFound = c_long()
>>>> rsrc_type = c_char*MAX
>>>> rsrc = rsrc_type()
>>>> rsrcLen = c_long(MAX)
>>>> hpe1432_find(session, addList, listSize, byref(numFound), rsrc, rsrcLen)
> 
> with the result:
> 
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ValueError: Procedure called with not enough arguments (24 bytes missing) or
> wrong calling convention
> 

As the error message says, it could also be that you are using the wrong
calling convention.  You have to look into the documentation for the function
that you want to call, or into the header file to really find out.
If the function uses the 'stdcall' calling convention, you should load the
library with WinDLL(...) not CDLL(...).

Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Todd Dahling | 3 Aug 2006 12:02
Picon

Re: newbie help

that's got it!
 
Thanks everybody for your help
 
TD

 
On 8/2/06, Thomas Heller <theller <at> python.net> wrote:
Todd Dahling schrieb:
> OK, so here is what I do:
>
>>>> inDLL = CDLL(....)
>>>> FCN = inDLL.fcn
>>>> session = c_int(0)
>>>> MAX = 255
>>>> addList_type = c_long*MAX
>>>> addList = addList_type()
>>>> listSize = c_long(MAX)
>>>> numFound = c_long()
>>>> rsrc_type = c_char*MAX
>>>> rsrc = rsrc_type()
>>>> rsrcLen = c_long(MAX)
>>>> hpe1432_find(session, addList, listSize, byref(numFound), rsrc, rsrcLen)
>
> with the result:
>
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ValueError: Procedure called with not enough arguments (24 bytes missing) or
> wrong calling convention
>

As the error message says, it could also be that you are using the wrong
calling convention.  You have to look into the documentation for the function
that you want to call, or into the header file to really find out.
If the function uses the 'stdcall' calling convention, you should load the
library with WinDLL(...) not CDLL(...).

Thomas


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ctypes-users mailing list
ctypes-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ctypes-users
Thomas Heller | 4 Aug 2006 10:44
Favicon

Re: Changing value of a null pointer

Lenard Lindstrom schrieb:
> On 23 Jul 2006 at 11:59, Bob Ippolito wrote:
> 
>> 
>> On Jul 23, 2006, at 10:56 AM, Lenard Lindstrom wrote:
>> 
>> > How is one to change the value of a null pointer?
>> 
>> Make a new one. That's like asking "how can I change the value of an  
>> int" -- you don't.
>> 
>> > Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]
>> > on win32
>> > Type "help", "copyright", "credits" or "license" for more
>> > information.
>> >>>> from ctypes import __version__, c_int, POINTER
>> >>>> __version__
>> > '0.9.9.9'
>> >>>> INT_P = POINTER(c_int)
>> >>>> int_p = INT_P(c_int(1))
>> >>>> int_p[0]
>> > 1
>> >>>> int_p[0] = 2
>> >>>> int_p[0]
>> > 2
>> >>>> null_int_p = INT_P()
>> >>>> null_int_p[0]
>> > Traceback (most recent call last):
>> >   File "<stdin>", line 1, in ?
>> > ValueError: NULL pointer access
>> >>>> null_int_p[0] = 2
>> > Traceback (most recent call last):
>> >   File "<stdin>", line 1, in ?
>> > ValueError: NULL pointer access
>> >
>> > And shouldn't a dereferenced null pointer return None?
>> 
>> No, why should it? Dereferencing a NULL pointer is an error.
>>
> You're right. I am confusing the address pointed to with the value at 
> that address. In C it is easy to keep them straight. In ctypes 
> another level of indirection is added.
> 
> So then I should say that p.contents should accept None to make a 
> pointer NULL and return None for a NULL pointer, since p.contents 
> accesses the pointer's value.

Is this just for consistency, or do you have a use case?  I'm wondering
if it is worth to change this (I would not have a problem with changing
the standalone ctypes package to support this, but I'm unsure about the
version bundled with Python 2.5 which is in feature freeze).

Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Thomas Heller | 4 Aug 2006 18:18
Favicon

ctypes 1.0.0 released

To celebrate this event, I've even updated the web pages!

ctypes 1.0.0 released - August 4, 2006
======================================

Overview

    ctypes is an advanced ffi (Foreign Function Interface) package for
    Python 2.3 and higher.

    ctypes allows to call functions exposed from dlls/shared libraries
    and has extensive facilities to create, access and manipulate
    simple and complicated C data types in Python - in other words:
    wrap libraries in pure Python.  It is even possible to implement C
    callback functions in pure Python.

    ctypes runs on Windows, Windows CE, MacOS X, Linux, Solaris,
    FreeBSD, OpenBSD. It may also run on other systems, provided that
    libffi supports this platform.

Changes in 1.0.0

    Better support for comtypes.  More target platforms for OpenBSD.
    Several small bugfixes.

    This is exactly the same version as included in Python 2.5b3,
    which was recently released.

Changes in 0.9.9.9

    Index checking on 1-sized arrays was reintroduced, so they can no
    longer be used as variable sized data.

    Assigning None to pointer type structure fields possible overwrote
    wrong fields.

    Fixed a segfault when ctypes.wintypes were imported on non-Windows
    machines.

    Accept any integer or long value in the ctypes.c_void_p
    constructor.

    It is now possible to use custom objects in the ctypes foreign
    function argtypes sequence as long as they provide a from_param
    method, no longer is it required that the object is a ctypes type.

    ctypes can now be built with MingW on Windows, but it will not
    catch access violations then since MingW does no structured
    exception handling.

    Sync the darwin/x86 port libffi with the copy in PyObjC. This
    fixes a number of bugs in that port. The most annoying ones were
    due to some subtle differences between the document ABI and the
    actual implementation :-(

    Release the GIL during COM method calls, to avoid deadlocks in
    Python coded COM objects.

Changes in 0.9.9.7

    Fixes for 64-bit big endian machines.

    It is now possible to read and write any index of pointer
    instances (up to 0.9.9.6, reading was allowed for any index, but
    writing only for index zero).

    Support for unnamed (anonymous) structure fields has been added,
    the field names must be listed in the '_anonymous_' class
    variable.  Fields of unnamed structure fields can be accessed
    directly from the parent structure.

    Enabled darwin/x86 support for libffi (Bob Ippolito and Ronald
    Oussuren).

    Added support for variable sized data structures: array
    types with exactly 1  element don't do  bounds checking any  more,
    and  a resize  function can resize  the internal  memory buffer of
    ctypes instances.

    Fixed a bug with certain array or structure types that contained
    more than 256 elements.

Changes in 0.9.9.6

    The most important change is that the old way to load libraries
    has been restored: cdll.LoadLibrary(path), and CDLL(path) work
    again.  For details see the changelog in CVS and in the source
    distribution.

    It was a mistake to change that in the 0.9.9.3 release - I
    apologize for any confusion and additional work this has caused or
    will cause.

    New module ctypes.util which contains a cross-platform
    find_library function.

    Sized integer types (c_int8, c_int16, and so on) have been added
    by integrating a patch from Joe Wreschnig.  Also c_size_t, which
    corresonds to the 'size_t' C type has been added.

    Two long standing bugs with pointers have been fixed.  Thanks to
    Axel Seibert for pushing me to the first, and thanks to Armin Rigo
    for finding the second one.

    The ctypes.decorator module has been removed completely, so the
    'cdecl' and 'stdcall' symbols are no longer available.
    The code generator has been removed completely.  It will probably
    be made available as a separate project later.

    The samples directory has been removed because it was completely
    out-of-date.

    The .zip and .tar.gz source distributions no longer contain
    different file sets.

    The development in CVS now takes place in the HEAD again, the
    'branch_1_0' branch is no longer used.

Changes in 0.9.9.3

    Windows

        The ctypes.com package is no longer included and supported.
        It is replaced by the comtypes package which will be released
        separately.

	ctypes has been ported to Windows CE by Luke Dunstan.

    Other platforms

        Hye-Shik Chang has written a new build system for libffi
        which should remove possible licensing issues.

    All platforms

        The library loading code has been rewritten by Andreas Degert,
        there are now sophisticated methods to find shared libraries.
	On OS X, this uses files from Bob Ippolito's macholib.
        See the manual for details.

        Finally I started to write the manual, it is available online:

            http://tinyurl.com/7bpg4

	New 'errcheck' protocol to check the return values of foreign
	functions, suggested by Mike Fletcher.

	Lots of bug fixes, especially for 64-bit platforms. Improved
	performance when creating ctypes instances.

	Subclasses of simple types (c_int, c_void_p, and so on) now
	behave as expected - they are not automatically converted into
	native Python types any longer.

	Support for explicit byte ordering in structures has been
	added (BigEndianStructure, LittleEndianStructure base
	classes).

	call byref() automatically, if needed, for POINTER types in
	argtypes.

	Lots of improvements to the code generator.

Download

    Downloads are available in the sourceforge files section
    <http://sourceforge.net/project/showfiles.php?group_id=71702>

    Binary windows installers, which contain compiled extension
    modules, are also available, be sure to download the correct one
    for the Python version you are using.

Homepage

    <http://starship.python.net/crew/theller/ctypes/>

Enjoy,

Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Thomas Heller | 4 Aug 2006 21:59
Favicon

Re: Memory leak problem in using comtypes

Sumeet Sobti schrieb:
>> > 
>> > (2) There's one case in which memory still leaks. This is when I
>> call a
>> > method on a COM object, and the COM object returns an answer like
>> this:
>> > 
>> > (((127900.0, None, 2620), (127875.0, None, 2335), (127675.0, 1071,
>> > None)), 127800.0)
>> > 
>> > That is, when tuples are nested 3 levels deep.
>> > 
>> > There is *no* memory leakage when the answer is of the form:
>> > 
>> > ((128000.0, None, 2576), (127975.0, None, 1923), (127950.0, None,
>> > 1734))
>> > 
>> > That is, when tuples are nested only 2 levels deep.
>> 
>> Can you post the IDL of these COM methods?
>> 
> 
> Both of these cases are from the same method of a COM object. The
> output depends on the input argument I supply to the method. The IDL
> entry is this:
> 
>         [id(0x00000008), propget, helpstring("property Get")]
>         HRESULT Get(
>                         [in] VARIANT vKey,
>                         [out, retval] VARIANT* pVal);
> 
> The input is a string describing what I want to get out of it. In the
> first case, I ask for 2 items, and it returns a tuple containing the
> two items. In the second case, I ask for only 1 item, and it returns
> just that item.
> 
> The entry in the comtypes generated python file looks like this:
> 
>     COMMETHOD([dispid(8), helpstring(u'property Get'), 'propget'],
> HRESULT, 'Get',
>               ( ['in'], VARIANT, 'vKey' ),
>               ( ['retval', 'out'], POINTER(VARIANT), 'pVal' )),
> 

It seems there is no quick fix for those, but I'm looking into it.
So far, I have added testcases only that show the problem ;-)

Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Thomas Heller | 4 Aug 2006 22:05
Favicon

Re: third section to the docs

RayS schrieb:
>  > Thomas post-scripted:
>  > PS: It may be a good idea to add a third section to the docs (in > addition
>  > to the 'tutorial' and the 'reference'), maybe something like a 'cookbook',
>  > which contains extended examples how to use ctypes.
> 
> I like it; I live by usage examples.
> Will this be wiki-like, or should we post our usage examples to this 
> list? (easier, of course)

Whatever you like.

Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Lawrence Oluyede | 4 Aug 2006 22:40
Picon
Gravatar

Re: third section to the docs

> I like it; I live by usage examples.
> Will this be wiki-like, or should we post our usage examples to this
> list? (easier, of course)

I think wiki's better. It can be commented and edited in real time

--

-- 
Lawrence
http://www.oluyede.org/blog

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Gmane