ctypes-devel Mailing List for ctypes (Page 3)
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: <pan...@ya...> - 2006-12-25 13:54:49
|
cty...@li...様へ、招待期限になりましたのでご確認下さい。 至急、下記の招待カードからアクセスしていただき、 準備したおります専用スペースへ入室お願いします。 >>> 招待カード :::: 明日期限 :::: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://www.now-on-site.com/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ずべて無料の自由恋愛コミュニティは、健全セフレの募集板です。 |
ctypes-devel様 お世話になっております。 私どもは自由恋愛促進を目的に、条件にあったセフレのペアリング、 大人の恋愛のきっかけをサポート中です。 貴方様を招待します、【No.20024】瑞穂様の紹介スペースは ご覧頂いているでしょうか。 今回は20-25歳カテゴリーにて同地区エリアの方だけの対象で、 優先的にご依頼人から貴方様へのご招待となりました。 瑞穂様の希望としまして、自己紹介やメールでの連絡をした後に、 お近くのカフェで待ち合わせを希望しています。 スケジュールのほうはいかがでしょうか。 お互いの休日や夜の予定などは、お互いでご相談頂けますか。 こちらがあらためまして紹介カードです。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://takumi.vicp.cc/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
From: <pan...@ya...> - 2006-12-14 17:19:35
|
ctypes-devel様 >>> 招待カード セフレ促進、自由恋愛コミュニティから大人のつながる 招待カードをお届けしました。 無料掲示板での近所検索により貴方様が 該当しましてご依頼人からのご招待となりました。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 【No.20024】瑞穂様から ┌──┐ │＼／│ ご招待カードを開封する http://takumi.vicp.cc/acfree/20024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
From: Thomas H. <th...@py...> - 2006-10-05 18:16:24
|
Peter Hansen schrieb: > Victor Stinner wrote: >> Question: would it be possible to change object lifetime, tell that the >> function keep a referrence of the object, or something like that? Or should I >> keep a copy of "mycallback = callback_t(mine)" somewhere? > > I'm pretty sure you must keep a reference in Python, or it will be (via > reference counting) freed up immediately. I'm also (slightly less, but > still fairly) sure that the documentation on callbacks points something > like this out... maybe double-check there again? > Peter is completely right. You need to keep the callback object alive *in Python* until it is no longer used by any C code. If ctypes would keep it alive forever automatically, we would have a memory leak. Thomas |
|
From: Peter H. <pe...@en...> - 2006-10-05 17:23:59
|
Victor Stinner wrote: > Question: would it be possible to change object lifetime, tell that the > function keep a referrence of the object, or something like that? Or should I > keep a copy of "mycallback = callback_t(mine)" somewhere? I'm pretty sure you must keep a reference in Python, or it will be (via reference counting) freed up immediately. I'm also (slightly less, but still fairly) sure that the documentation on callbacks points something like this out... maybe double-check there again? -Peter |
|
From: Victor S. <vic...@in...> - 2006-10-05 14:03:24
|
Hi,
I wrote a Python binding for libnetfilter_conntrack using ctypes. Ctypes=20
library is really great! It's so easy to write the binding and then to use=
=20
it!
But during tests, I was victim of a crash. After long analys, I understood=
=20
that the problem comes from callback. Here is a little example of the crash:
=2D-- C code ---
typedef int (*callback_t) (int *arg);
callback_t global_callback =3D NULL;
void set_callback(callback_t callback)
{
global_callback =3D callback;
}
void read_table()
{
int i;
static int arg =3D 10;
if (!global_callback) return;
for (i=3D0; i<10; i++)
{
if (global_callback(&arg) !=3D 0) return;
}
}
=2D-- Python code ---
lib =3D cdll.LoadLibrary("libbug_callback.so")
def mine(number_ptr):
return 0
callback_t =3D CFUNCTYPE(c_int, POINTER(c_int))
for subloop in xrange(10000):
lib.set_callback( callback_t(mine) ) # <~~~ here it is
lib.read_table()
=2D--
=46ull example is attached to this email (crash_ctypes.tar.bz2).
Or another version of Python code to better understand the bug:
=3D=3D=3D
#=A0using same function and callback type
for subloop in xrange(10000):
mycallback =3D callback_t(mine)
lib.set_callback(mycallback)
del mycallback # <~~~ without this, it doesn't crash
lib.read_table()
=3D=3D=3D
On my mind, the problem is about object destruction and referrence counting=
=2E=20
It's not really a problem of ctypes, more a problem of object lifetime.
=AB lib.set_callback( callback_t(mine) ) =BB create a temporary object of t=
ype=20
callback_t which is used during the call of lib.set_callback. But after thi=
s=20
call, the object is destroyed. The problem is that the C library stores a=20
pointer to this (destroyed) object. And so it will quickly crash...
Question: would it be possible to change object lifetime, tell that the=20
function keep a referrence of the object, or something like that? Or should=
I=20
keep a copy of "mycallback =3D callback_t(mine)" somewhere?
Bye,
Victor Stinner
http://www.inl.fr/
|
|
From: <sg...@ho...> - 2006-06-20 17:02:31
|
今年はまあまあですね。無料サイトのお陰です。 http://plustwo.info/taiken/ 出会い体験談=== hag...@ya... |
|
From: <dv...@ho...> - 2006-05-11 18:57:37
|
ラブホの出来た経緯と現代の役割 なんちゃって・・・。 http://biz-station.org/go/ 問） pi...@ey... |
|
From: <ge...@ho...> - 2006-04-30 18:22:41
|
出会いのチャンス到来 http://solo-s.com/sefsef/ 問） xi...@wa... |
|
From: <ao...@ho...> - 2006-03-20 13:16:05
|
彼女の髪が風で少し揺れた時、胸が熱くなった。。。 これが始まりだった。 http://carmastorra.com/demo/ 真面目な出会いを求める方へ http://carmastorra.com/demo/ 問） faf...@16... |
|
From: <sa...@ya...> - 2006-03-11 01:17:48
|
【マドモアゼルアンアン】 人妻さんの濡れ所とは？？？？ http://manpee-g.biz/chikak/ 問） faf...@16... |
|
From: Randy <kz...@ey...> - 2006-01-20 03:28:37
|
To cty...@li...: Bullet-Proof server: Fresh IPs 1024MB RAM PIV CPU 80 GB Hard Disk Dedicated 100M fiber Unlimited Data Transfer In China $599.00 monthly May use the server for: Mass web Hosting Direct Mailing We also provide email list according to your order and sending out your message for you. Waiting for your answer. Cheers! Randy Server Dept Mar...@21... NotAgain for cty...@li...: Go...@ao... |
|
From: <con...@uu...> - 2006-01-13 22:13:22
|
$B5.J}MM$H2q$$$?$$$H$$$&=w@-2q0wMM$,$*$j$^$9!#(B $B"'$*JV;v$3$A$i$+$i"'(B http://311.send-mail.info/kanzen_muryo.php?id=35q76jhfgd8gl7yjs $B$$$D$b$4MxMQD:$$$F@?$KM-Fq$&8f:B$$$^$9!#(B $B%5%$%H%j%K%e!<%"%k$KH<$$!":FEPO?<jB3$-$,I,MW$G$9!#(B $B$^$?!"#1#0#0#0#01_J,$NL5NA%]%$%s%H$b$4MQ0U$7$F$*$j$^$9$N$G$<$R:FEPO?<jB3$-$r:Q$^$;$F$/$@$5$$!#(B http://311.send-mail.info/kanzen_muryo.php?id=i479fgd8glfgh75kwhg $B"(%o%s%/%j%C%/!&ITEv@A5aEy$G$O$"$j$^$;$s$N$G!"0B?4$7$F$4MxMQ$/$@$5$$!#(B $B:FEPO?$,I,MW$N$J$$J}$O(B con...@uu... |
|
From: Thomas H. <th...@py...> - 2005-11-22 18:24:32
|
Sean Jensen-Grey <se...@xy...> writes: > I was using OpenGL-ctypes and notice that ctypes-cvs-head had a better > util.py than branch_1_0 specifically when attempting to load libgle. > > The head version correctly finds libgle.so.3 while branch_1_0 assumes > libgle.so > > Please review the attached util.py, it exports the same find_library > function as the orginal. Thanks, I will probably commit it into the branch_1_0. Can you also supply some test cases? Thomas |
|
From: William <kz...@ey...> - 2005-11-22 00:23:24
|
Dear cty...@li...: We specialized in Email Marketing. 1. Targeted e-mail list We may provide targeted e-mail list. We can customize the list as you need. 2. Send out Targeted e-mail Marketing for you We may send your e-mail message to your target clients! We will customize your e-mail list and send out your message for you. * We offer BP Hosting & mail server. Regards! William Service Team kez...@ye... |
|
From: Sean Jensen-G. <se...@xy...> - 2005-11-18 23:11:03
|
I was using OpenGL-ctypes and notice that ctypes-cvs-head had a better util.py than branch_1_0 specifically when attempting to load libgle. The head version correctly finds libgle.so.3 while branch_1_0 assumes libgle.so Please review the attached util.py, it exports the same find_library function as the orginal. Sean |
|
From: Eyal L. <eya...@gm...> - 2005-10-21 11:40:28
|
On 10/21/05, Thomas Heller <th...@py...> wrote: > I've only looked briefly at the code, so I don't have detailed comments. > One disadvantage I see so far is that cinvoke would only work when > compiled with gcc on an x86 system - correct? Well, it has a bit of inline asm to call arbitrary function pointers with arbitrary stacks. But that is a trivial piece of inline assembly, and only that needs to be ported to various architectures. > Then: ctypes is used to call functions in dlls/shared libraries, without > the need to write a Python extension. It seems (but I can only guess > here, you have to provide use cases, rationales, and code examples), > that cinvoke is compiled into a C application, and allows to call > functions in that program from another process. So, is this to allow to > script applications? Nope. It is mainly used to test C libraries and programs. Though scripting C programs with it is also much easier than embedding a Python interpreter, and more powerful. > And, let me ask: What's your real use case, and why can't you use > ctypes for that? Because I cannot use ctypes to control a C program that has its own mainloop and cannot be embedded as loadable library. Because if I use ctypes, my C program is must run in the context of the Python interpreter process, and testing it becomes less representative, in terms of its memory management, signal handlers it installs, etc. With cinvoke, the C program can live in its "natural" environment. Because I cannot use ctypes to control multiple C processes that communicate with each other, especially when those C processes need to sit on separate computers. I have already needed this to test complex C programs. > There are several Python modules to allow access and manipulate C > compatible data structures, the standard struct module, higher level > wrappers around the struct module, and ctypes-lookalike type module (Bob > Ippolito has 'ptypes', iirc). Personally, I don't have a large need to > manipulate these structures without beeing able to pass them to > C-functions, so for me it makes no sense to separate them. But the idea is to use the same data type library to represent C data, AND to use those data variables to pass them to functions. This is what cinvoke does. I did this in cinvoke because I wanted to be able to directly access the data symbols of remote processes and manipulate them without having to create duplicate data type declarations for function calls and for data manipulation and representation. Note that the data library within cinvoke is generically more powerful than existing struct modules and such, for at least some purposes. It allows "attaching" of a data-type to an arbitrary "space" object, and defining pointer dereference semantics by assigning an "address_space" attribute into pointers. This "space" object can be the actual address space of a remote cinvoke server, or just a portion of a file. This allows to "map" data types into files, dereference pointers in files or in the address space via the same parsing code, and so on. This data manipulation, by the way, is also very useful for testing. Especially as with cinvoke, you can have multiple cinvoke servers running on multiple computers, and then you can use: # Get a symbol from aprocess's address space: a_symbol =3D a.symbol(MyBigStruct, 'some_symbolname') # Call a function in bprocess's address space with a pointer to a's symbol: b.call.modify_given_ptr(node_ptr(a_symbol)) And this will transparently copy a_symbol into the context of bprocess, run the function, and then transparently copy the data back into a_symbol in the context of aprocess. Also, if I want to test a C function's data corruption handling, I can use: a_symbol.nodes.some_data_member.value =3D Corrupted_value assert TYPE_OF_FAILURE =3D=3D a.call.some_api(node_ptr(a_symbol)) > Finally, function pointers are also C data types, so the separation > between the type library and the 'call' module is not so clear. And, > nowadays ctypes is portable to quite a lot of systems (with the help of > libffi, of course). Well, cinvoke is portable to a lot of architectures in the same way that Linux is, except there is only one trivial asm function to port. Function Pointers are the only C data type that is only useful when calling, so it makes sense for this data type to be tightly coupled to ctypes/cinvoke. However, it does not make sense to define the same structs, unions and enums multiple times in order to call functions with it and in order to parse/build/manipulate data with it. |
|
From: Thomas H. <th...@py...> - 2005-10-21 11:21:08
|
Eyal Lotem <eya...@gm...> writes: > Hi. I am working to create a project similar in scope to ctypes, but > with a different implementation. > > I would like to get your opinions and feedback about what advantages > or disadvantages you think it has compared to ctypes. I've only looked briefly at the code, so I don't have detailed comments. One disadvantage I see so far is that cinvoke would only work when compiled with gcc on an x86 system - correct? Then: ctypes is used to call functions in dlls/shared libraries, without the need to write a Python extension. It seems (but I can only guess here, you have to provide use cases, rationales, and code examples), that cinvoke is compiled into a C application, and allows to call functions in that program from another process. So, is this to allow to script applications? And, let me ask: What's your real use case, and why can't you use ctypes for that? > Also wondering why ctypes does not have a separate type library, a > generic one, just for describing types, and a separate component to > use those types to call functions. There are several Python modules to allow access and manipulate C compatible data structures, the standard struct module, higher level wrappers around the struct module, and ctypes-lookalike type module (Bob Ippolito has 'ptypes', iirc). Personally, I don't have a large need to manipulate these structures without beeing able to pass them to C-functions, so for me it makes no sense to separate them. Finally, function pointers are also C data types, so the separation between the type library and the 'call' module is not so clear. And, nowadays ctypes is portable to quite a lot of systems (with the help of libffi, of course). Thomas |
|
From: Eyal L. <eya...@gm...> - 2005-10-21 01:06:08
|
Hi. I am working to create a project similar in scope to ctypes, but with a different implementation. I would like to get your opinions and feedback about what advantages or disadvantages you think it has compared to ctypes. Also wondering why ctypes does not have a separate type library, a generic one, just for describing types, and a separate component to use those types to call functions. The URL for cinvoke: http://pybuild.sf.net/cinvoke.html |
|
From: Neateye <nit...@ao...> - 2005-09-11 21:34:23
|
Call out Gouranga be happy!!! Gouranga Gouranga Gouranga .... That which brings the highest happiness!! |
|
From: Tim F. <tf...@co...> - 2005-07-20 02:34:00
|
Hello,
The following is a possible bug report.
Gccxml 0.7.0 doesn't like the following:
#if defined( __GNUC__ )
# define GCC_PACK __attribute__ ((aligned (1),packed))
#endif
typedef struct AStruct {
// some stuff here
} GCC_PACK AStruct;
and errors out with:
error: syntax error before `__attribute__'
even though __attribute__ has been around in GCC for a long time.
I tested out adding _pack_ = 1 to the generated python code but found out
that it doesn't work unless it is added _before_ fields is defined. My
expectation was that it was order independent.
OK, since I have lots and lots of these structs, I was determined to add a
command line option for global packing to xml2py, which I did. Let me
know if you'd like it. I commented out all of the assertions for size and
offset as I am using another method to verify everything.
Please reply via email as I haven't subscribed.
Regards,
Tim
|
|
From: Shane H. (IEEE) <sha...@ie...> - 2005-05-23 18:02:02
|
Thomas Heller wrote:
> Shane, thanks for the patch. I have my own version of this patch, but
> yours is probably better. My own one only supports a single outgoing
> interface, but yours looks like it supports more of them. As a bonus,
> my version actually supports to 'fire' the events, and even from
> different threads. I'll try to merge both and check them into CVS. The
> approach to fire the events is quite simple, here it is (I hope
> thunderbird doesn't destroy the formatting):
<snip>
Ok, I tried to implement the fireEvent in what I have, but I keep
getting an exception that says::
TypeError: function takes at most 3 arguments (9 given)
For sink.Invoke(). It obviously takes 9 parameters, but I can't seem to
convince the system of that. ;) Any thoughts? ::
def fireEvent(*args):
for sink in self._iterConnectionPointSinks():
params = DISPPARAMS()
params.cArgs = len(args)
rgvarg = params.rgvarg = (VARIANT * len(args))()
for i, a in enumerate(args):
rgvarg[i].value = a
Invoke = dict(sink._methods_)['Invoke']
Invoke(
sink, dispid,
byref(GUID()), 0, # lcid
DISPATCH_METHOD, # wFlags
byref(params),
None, # pVarResult
None, # pExcepInfo
None) # puArgError
The patch of my attempt is attached.
Thanks,
-Shane
|
|
From: Thomas H. <th...@st...> - 2005-05-20 08:08:29
|
(Hope this gets through, there are some problems with the SF mailing lists currently) Shane Holloway (IEEE) schrieb: > Thomas, > > I wasn't sure if you had the time to look at it, but I got a minimal > implementation[1] of server connection points implemented. The only > issue I ran into was calling event through _dispmethod_? Can you > suggest the approach for this? > > .. [1]: > http://sourceforge.net/tracker/index.php?func=detail&aid=1203889&group_id=71702&atid=532156 > > Shane, thanks for the patch. I have my own version of this patch, but yours is probably better. My own one only supports a single outgoing interface, but yours looks like it supports more of them. As a bonus, my version actually supports to 'fire' the events, and even from different threads. I'll try to merge both and check them into CVS. The approach to fire the events is quite simple, here it is (I hope thunderbird doesn't destroy the formatting): def Fire_Event(self, name, *args, **kw): # call this method to notify the active advise connections # we could cache the memids... from ctypes.com.git import GetInterfaceFromGlobal memid = c_int() self._typeinfo.GetIDsOfNames(byref(c_wchar_p(name)), 1, byref(memid)) for p in self._connections.values(): if self._multi_threading: p = GetInterfaceFromGlobal(p, self._sink_interface) params = DISPPARAMS() params.cArgs = len(args) rgvarg = params.rgvarg = (VARIANT * len(args))() for i, a in enumerate(args): rgvarg[i].value = a p.Invoke(memid.value, byref(GUID()), 0, # lcid DISPATCH_METHOD, # wFlags byref(params), None, # pVarResult None, # pExcepInfo None) # puArgError return S_OK > > Secondly, I was wondering if there is a wiki/page summarizing your > vision for comtypes? Not yet, only code. There are some pages in the 'py2exe and ctypes' wiki, but the ctypes.com stuff is quite old and not up to date. > I've been lamenting the state of COM in python for a while now. I'm > not a big COM fan (or developer) anymore, but every once in a while a > client needs us to interface with COM, and I'd like to help make that > more pleasant for me *and* everyone else. ;) I know you learned > quite a bit from ctypes.com, and that knowledge is going into > comtypes. How do you see other developers helping you in comtypes? > We'll see. For COM, I have received a small patch here and there, but not more. > Thanks, > -Shane Holloway > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Ctypes-devel mailing list > Cty...@li... > https://lists.sourceforge.net/lists/listinfo/ctypes-devel |
|
From: Shane H. (IEEE) <sha...@ie...> - 2005-05-18 20:57:21
|
Thomas, I wasn't sure if you had the time to look at it, but I got a minimal implementation[1] of server connection points implemented. The only issue I ran into was calling event through _dispmethod_? Can you suggest the approach for this? .. [1]: http://sourceforge.net/tracker/index.php?func=detail&aid=1203889&group_id=71702&atid=532156 Secondly, I was wondering if there is a wiki/page summarizing your vision for comtypes? I've been lamenting the state of COM in python for a while now. I'm not a big COM fan (or developer) anymore, but every once in a while a client needs us to interface with COM, and I'd like to help make that more pleasant for me *and* everyone else. ;) I know you learned quite a bit from ctypes.com, and that knowledge is going into comtypes. How do you see other developers helping you in comtypes? Thanks, -Shane Holloway |
|
From: Thomas H. <tho...@gm...> - 2004-12-27 20:15:11
|
Wrong list, Scott? On Mon, 27 Dec 2004 10:11:17 -0800, Scott David Daniels <Sco...@ac...> wrote: > 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... > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Ctypes-devel mailing list > Cty...@li... > https://lists.sourceforge.net/lists/listinfo/ctypes-devel > |
295 messages has been excluded from this view by a project administrator.
