ctypes-devel Mailing List for ctypes (Page 4)
Brought to you by:
theller
Menu
▾
▴
ctypes-devel — Discussion forum for ctypes developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(4) |
Dec
(2) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(6) |
| 2007 |
Jan
(3) |
Feb
(11) |
Mar
(17) |
Apr
(46) |
May
(52) |
Jun
(77) |
Jul
(105) |
Aug
(23) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Scott D. D. <Sco...@Ac...> - 2004-12-27 18:30:17
|
I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg is starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? -- Scott David Daniels Sco...@Ac... |
|
From: Thomas H. <th...@py...> - 2004-09-21 14:22:53
|
=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?= <jp...@pl...> writes: > There is a typo in the __init__.py file. > > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python-ctypes-typo.patch?rev=1.1 > > -- > Regards, > Jakub Piotr CÅapa Fixed in CVS now, thanks! Thomas |
|
From: <jp...@pl...> - 2004-09-21 01:53:18
|
There is a typo in the __init__.py file. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python-ctypes-typo.patch?= rev=3D1.1 --=20 Regards, Jakub Piotr C=C5=82apa |
|
From: <ben...@id...> - 2004-05-22 13:15:28
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Peter P. <pa...@cs...> - 2004-01-10 16:44:50
|
Hi,
I'm trying to get a wrapper using ctypes working around the windows MIDI
streaming functions. The relevant structures in C are the following:
typedef struct midihdr_tag {
LPSTR lpData; /* pointer to locked data block */
DWORD dwBufferLength; /* length of data in data block */
DWORD dwBytesRecorded; /* used for input only */
DWORD_PTR dwUser; /* for client's use */
DWORD dwFlags; /* assorted flags (see defines) */
struct midihdr_tag far *lpNext; /* reserved for driver */
DWORD_PTR reserved; /* reserved for driver */
#if (WINVER >= 0x0400)
DWORD dwOffset; /* Callback offset into buffer */
DWORD_PTR dwReserved[8]; /* Reserved for MMSYSTEM */
#endif
} MIDIHDR, *PMIDIHDR, NEAR *NPMIDIHDR, FAR *LPMIDIHDR;
typedef struct midievent_tag
{
DWORD dwDeltaTime; /* Ticks since last event */
DWORD dwStreamID; /* Reserved; must be zero */
DWORD dwEvent; /* Event type and parameters */
DWORD dwParms[1]; /* Parameters if this is a long
event */
} MIDIEVENT;
I've interpreted these in Python using ctypes as:
class MIDIEVENT(Structure):
_fields_ = [("dwDeltaTime", c_ulong),
("dwStreamID", c_ulong),
("dwEvent", c_ulong),
("dwParams", c_ulong * 1)]
lpMidiHdr = POINTER("MIDIHDR")
class MIDIHDR(Structure):
_fields_ = [("lpData", c_char_p),
("dwBufferLength", c_ulong),
("dwBytesRecorded", c_ulong),
("dwUser", POINTER(c_ulong)),
("dwFlags", c_ulong),
("lpNext", lpMidiHdr),
("reserved", POINTER(c_ulong)),
("dwOffset", c_ulong),
("dwReserved", POINTER(c_ulong * 8))]
The problem I'm having is with the lpData field in the MIDIHDR
structure. It expects an array of MIDIEVENT structures, but ctypes
doesn't like it if I just do the following:
# create a header object
header = MIDIHDR()
# create an event and put it into the header
event = MIDIEVENT()
event.dwEvent = MidiOutMsg(0x90, 0, 69, 127)
header.lpData = pointer(event)
Is it possible to assign an event or array of events to the lpData field
as a pointer to char? As an alternative, I see that I might have to
ditch the event structure altogether, and just build the lpData string
from scratch. How could I go about doing that? Should I use c_buffer,
and, if so, how do you represent its type in the structure?
I'm not sure where to go from here, so any help will be appreciated.
Pete
|
|
From: Thomas H. <th...@py...> - 2003-12-17 07:58:00
|
Thomas Heller <th...@py...> writes: > Mulot Gérard <g....@fr...> writes: > >> Exporting Managed code as Unmanaged : >> http://www.csharphelp.com/archives3/archive500.html >> >> the following c# code is exported as an unmanaged dll with ILDASM from Net >> Framework SDK >> >> // HelloWorldDll.cs >> using System; >> >> namespace HelloWorldDll >> { >> public class HelloWorldClass >> { >> public static string SayHello(string name) >> { >> return ("Hello " + name); >> } >> } >> } >>>>> from ctypes import * >>>>> x = windll.HelloWorldDll >>>>> x.SayHello('Gerard') >> 1465528 >>>>> >> >> I can't return the string Hello Gerard > Ok, I've downloaded and extracted the dll from the rar file in the above url, and - no problems here (except that winzip doesn't handle rar files): >>> from ctypes import * >>> windll.HelloWorldDll <WinDLL 'HelloWorldDll', handle 860000 at 982800> >>> windll.HelloWorldDll.SayHello <ctypes._StdcallFuncPtr object at 0x009248C8> >>> windll.HelloWorldDll.SayHello() Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: Procedure probably called with not enough arguments (4 bytes missing) >>> windll.HelloWorldDll.SayHello("Thomas") 1547976 >>> windll.HelloWorldDll.SayHello.restype = c_char_p >>> windll.HelloWorldDll.SayHello("Thomas") 'Hello Thomas' >>> ^Z Thomas PS: I noticed you used the ctypes-devel list for this msg, ctypes-users would be the 'correct' list to use ;-). |
|
From: Thomas H. <th...@py...> - 2003-12-16 21:14:24
|
Mulot Gérard <g....@fr...> writes: > Exporting Managed code as Unmanaged : > http://www.csharphelp.com/archives3/archive500.html > > the following c# code is exported as an unmanaged dll with ILDASM from Net > Framework SDK > > // HelloWorldDll.cs > using System; > > namespace HelloWorldDll > { > public class HelloWorldClass > { > public static string SayHello(string name) > { > return ("Hello " + name); > } > } > } >>>> from ctypes import * >>>> x = windll.HelloWorldDll >>>> x.SayHello('Gerard') > 1465528 >>>> > > I can't return the string Hello Gerard If you mail me the dll I can try - no time to build this myself. Thomas |
|
From: <g....@fr...> - 2003-12-14 21:17:41
|
Exporting Managed code as Unmanaged : http://www.csharphelp.com/archives3/archive500.html the following c# code is exported as an unmanaged dll with ILDASM from Net Framework SDK // HelloWorldDll.cs using System; namespace HelloWorldDll { public class HelloWorldClass { public static string SayHello(string name) { return ("Hello " + name); } } } >>> from ctypes import * >>> x = windll.HelloWorldDll >>> x.SayHello('Gerard') 1465528 >>> I can't return the string Hello Gerard Gerard |
|
From: Bud P. B. <bu...@co...> - 2003-12-10 09:56:55
|
I confess that I know nothing about C, so I'm aware that this is going to be a dumb question. Hope someone can help me out anyhow. I would like to call the following C function from python: DWORD function1(BYTE* pbtData, DWORD& dwDataLen); where #define DWORD unsigned long #define BYTE unsigned char The return value seems to be some error code (0 for success) and both pbtData and dwDataLen are expected to be set by the function (i.e., are output) I better don't tell you what I tried... many thanks in advance -bud ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. bu...@co... Servizio Elaborazione Dati 0564-488 577 (voice) Comune di Grosseto 0564- 21139 (fax) Via Ginori, 43 58100 Grosseto Collaborazione Comuni per la CIE http://www.comune.grosseto.it/cie/ |
|
From: Thomas H. <th...@py...> - 2003-11-14 20:03:23
|
aaron <aa...@ya...> writes:
> The structure with size less than 4 is correct.
> but once it oven 4, it will always round up to next
> multiple of 4.
Not true, this prints '5':
"""
from ctypes import *
class X(Structure):
_fields_ = [("a", c_char),
("b", c_char),
("c", c_char),
("d", c_char),
("e", c_char)]
print sizeof(X)
"""
But, as soon as there is an integer in the structure, the alignment
requirements are set to the alignment of the integer, and this also
rounds the size to the next sizeof(int) multiple, so this prints '8':
"""
from ctypes import *
class X(Structure):
_fields_ = [("a", c_int),
("b", c_char)]
print sizeof(X)
"""
This *may* not be exactly the same as in C (I'm not sure), depending on
the C compiler, but IIRC it is required internally to allow using arrays
of Structures.
If it is wrong for you, you can always use custom packing, and this
prints '5' again:
"""
from ctypes import *
class X(Structure):
_pack_ = 1
_fields_ = [("a", c_int),
("b", c_char)]
print sizeof(X)
"""
Thomas
|
|
From: aaron <aa...@ya...> - 2003-11-13 09:04:01
|
The structure with size less than 4 is correct. but once it oven 4, it will always round up to next multiple of 4. aaron |
|
From: Bradley S. <br...@gr...> - 2003-08-05 23:21:19
|
Ctypes-java is now in CVS in the ctypes sourceforge project. Ctypes-java is a foreign call interface for java to call C level code, similar to Microsoft JDirect, or C# PInvoke. It is still very much a work in progress, with many of ctypes-python's features still unimplemented. That said it is being used for useful and non trivial tasks. Preliminary code to present ctypes-python's API to jython is included. -- Bradley Schatz <br...@gr...> |
|
From: Thomas H. <th...@py...> - 2003-07-31 07:51:31
|
FYI. admin@m.gmane.org (Gmane Administrator) writes: [...] > > Gmane is a mail-to-news portal that never expires its messages. It > therefore also functions as a mailing list archive. It's a > bi-directional gateway, but Gmane verifies that its users' email > addresses are valid before passing the messages through the > news-to-mail gateway. (Groups can also be made "read-only", which > means that Gmane won't forward any messages at all to the mailing > list.) > [...] > > The following parameters are set for this mailing list: > > * Newsgroup name: gmane.comp.python.ctypes.devel > * Mailing list address: cty...@li... > * The gateway is bi-directional * Address encryption is on > * Spam detection is on > * The list is described as: > "Python ctypes development" > * News URL: news://news.gmane.org/gmane.comp.python.ctypes.devel > * Web URL: http://news.gmane.org/thread.php?group=gmane.comp.python.ctypes.devel > > This newsgroup will be created when the first message from the > mailing list arrives. > > For more information about the Gmane project, go to > <URL: http://gmane.org/>. > > This request was handled by > Lars Magne Ingebrigtsen <la...@gn...>. |
|
From: Thomas H. <th...@py...> - 2003-07-30 13:03:52
|
Bradley Schatz <br...@gr...> writes: >> > I have been toying with porting the engine of your code to java, and have >> > had a measure of success. I am successfully calling non-trivial DLL >> > functions using all C Types, including structs. My next goal is >> > callbacks. >> > >> > My intention is to keep this java implementation aligned as close as >> > possible with the python version, so that a jython implementation that is >> > compatible with the CPython version can be layered on top. [me] >> >> Would it be possible to reverse this layering? In other words, it ctypes >> would be implemented in pure Python, would this be usable in jython, and >> that could be used from java? I have never used jython, so I have no >> idea. >> > > Could you really implement CTypes in pure python? Where would the > trampolines come from ? ctypes is really two parts: The first is the 'call foreign function, and implement callbacks' part, which cannot be implemented in pure Python, the other part are the base types like c_int, Structure, and so on. The latter is the most complicated one, and could be done in pure Python. Maybe with the help of a few C implemented objects. > IMHO You cant really reverse the layering. Here is how my implementation > works. > > Layer 1: > The ctypes "C" kernel: a high level interface (scripting/java) to low > level types and functions. We are always going to need C in there > somewhere to generate trampolines, convert args between the high level > lang and C. > > I expect that with a little refactoring we should be able to share this > kernel quite well. > > Layer 2: > Java CTypes objects corresponding all of the varieties of C later > objects - CInt, CULong, CPointer, etc. Note here that this layer is > strongly typed as it is java. Note that some of the semantics that you > are using in the python layer arent supported by java, notably > metaclasses (I lie, we can do this but not cleanly), functions and loose > typing. > > Layer 3: > Implement your python API on top of the Java object layer. JYthon > objects can inherit from Java objects, so this will be really easy. The > main function here will be to support the loose tying artifacts that you > use. > > Layer 4: > Is where I am really interested. The com framework stuff. If my later 3 > tracks your core ctypes interface, and as much of the dirty work is done > in python then I can use it in java. > > >> The reason I ask is that the pypy project (Python in Python) would >> probably also be interested in a ctypes implementation were more code is >> written in Python instead of C. >> > > Could you really make ctypes use _less_ C. It looks pretty lean to me > for the functionality it gives. Do you have any examples of ways that > you think that you could make it leaner? I don't know if it would become leaner, but it would become more portable probably, and less implementation details would differ between the versions. And maybe it would also become easier to understand and/or maintain. Maybe it's time to sketch the structure of ctypes' types? Unfortunately I don't have too much time right now. Thanks, Thomas |
|
From: Thomas H. <th...@py...> - 2003-07-30 12:52:42
|
Bradley Schatz <br...@gr...> writes: > On Wed, 2003-07-30 at 04:27, Thomas Heller wrote: >> Bradley, further comments below. >> >> > Hi Thomas, >> > >> > Firstly let me thank you for ctypes for python - I was using it for some >> > Flash/Python work recently and found it a great alternative to Mark H's >> > work. >> > >> > I have been toying with porting the engine of your code to java, and have >> > had a measure of success. I am successfully calling non-trivial DLL >> > functions using all C Types, including structs. My next goal is >> > callbacks. >> > >> > My intention is to keep this java implementation aligned as close as >> > possible with the python version, so that a jython implementation that is >> > compatible with the CPython version can be layered on top. >> >> Would it be possible to reverse this layering? In other words, it ctypes >> would be implemented in pure Python, would this be usable in jython, and >> that could be used from java? I have never used jython, so I have no >> idea. >> > > Could you really implement CTypes in pure python? Where would the > trampolines come from ? > > IMHO You cant really reverse the layering. Here is how my implementation > works. > > Layer 1: > The ctypes "C" kernel: a high level interface (scripting/java) to low > level types and functions. We are always going to need C in there > somewhere to generate trampolines, convert args between the high level > lang and C. > > I expect that with a little refactoring we should be able to share this > kernel quite well. > > Layer 2: > Java CTypes objects corresponding all of the varieties of C later > objects - CInt, CULong, CPointer, etc. Note here that this layer is > strongly typed as it is java. Note that some of the semantics that you > are using in the python layer arent supported by java, notably > metaclasses (I lie, we can do this but not cleanly), functions and loose > typing. > > Layer 3: > Implement your python API on top of the Java object layer. JYthon > objects can inherit from Java objects, so this will be really easy. The > main function here will be to support the loose tying artifacts that you > use. > > Layer 4: > Is where I am really interested. The com framework stuff. If my later 3 > tracks your core ctypes interface, and as much of the dirty work is done > in python then I can use it in java. > > >> The reason I ask is that the pypy project (Python in Python) would >> probably also be interested in a ctypes implementation were more code is >> written in Python instead of C. >> > > Could you really make ctypes use _less_ C. It looks pretty lean to me > for the functionality it gives. Do you have any examples of ways that > you think that you could make it leaner? > >> > Now I am ready to go public with what I have done so far, so I thought I >> > would take this opportunity to find out your preferences for what forum >> > you would prefer me to release this in. Would you prefer me to release >> > this as a seperate sourceforge project, or as a subproject of yours? Are >> > you happy for this to use the ctypes name? >> > >> > My feeling is that this port would benefit greatly from closer >> > collaboration - I am still unclear on numerous issues surrounding windows >> > error handling and the com support. Would the ctypes (python) mailing >> > list be a good forum to ask these questions? >> >> Will ctypes for java be able to use the ctypes.com package as it is >> (with maybe minor adjustments)? If so, it would be a good idea to >> separate it from the ctypes module, and we would have ctypes for Python, >> ctypes for java, ctypes.com and maybe more. >> > > Sounds good, I like the sound of a small ctypes.posix as well (python > has this, I know, but java is a little lacking around the edges) > > Why dont I create a ctypes.java project on SF so that I can release this > ASAP, and you can get a feel for just what we are talking about. > > With that project in place, we can aim for integration over the next few > weeks, so that my code migrates into your project. We will then use the > ctypes.java project as a pointer. > > And lets create the ctypes-devel list asap so that we can start > discussing this in the open. > > One other thing I would like you to consider. I havent put a license on > my code yet, and I see that yours is BSD license. Would you consider > shifting to GPL? I ask this because I believe that GPL encourages > sharing of code, and I am more comfortable with it. > > Best regards, > > Bradley > > > > > > > >> Thomas > -- > Bradley Schatz <br...@gr...> |
295 messages has been excluded from this view by a project administrator.
