Re: Rapid web app development tool for database
TurboGears has Catwalk. Have a look at that. It is a web UI that let's you manipulate the db. Have a look at the the TG Toolbox. -- http://mail.python.org/mailman/listinfo/python-list
Re: Recommended IDE for creating GUI?
http://wxglade.sourceforge.net/ - WxGlade is one option. It is quite helpful although somewhat unstable. http://wingware.com/ - is an IDE i dont remember if it has a UI builder. Probably worth checking anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interfacing with the command line
http://effbot.org/librarybook/os.htm scroll down about half a page to example 8. is that what you're looking for? PV -- http://mail.python.org/mailman/listinfo/python-list
Tackling setup.py - A bug??
Hi,
I've successfully compiled p4python with modified setup.py
the key to success was to split extra_compile_args's argument '-arch'
into 2 args.
below is fixed part:
[code]
ext_modules=[Extension("P4Client", [ "P4Clientmodule.cc"
],
include_dirs=[ os.path.join( p4_api_dir,
"include", "p4" ) ],
library_dirs=[ os.path.join( p4_api_dir,
"lib" ) ],
libraries=["client", "rpc", "supp"],#
P4API libs
extra_compile_args=["-DCASE_INSENSITIVE",
"-fpascal-strings",
"-isysroot",
"/Developer/SDKs/MacOSX10.4u.sdk",
"-DOS_MACOSX",
"-DOS_MACOSX104"
, "-arch", "ppc"
,"-D%s" % p4_api_ver],
extra_link_args=[
"-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk"
, "-arch", "ppc"
, "-framework", "System"
, "-framework", "CoreFoundation"
, "-framework", "Carbon"
],
)]
[/code]
hope it will help
--- Original Message: ---
And this followed by an setup.py install seemed to work just fine. Ok
so now I need to backport these options into setup.py. Here is what I
came up with..
elif os.name == "posix":
setup(name=NAME,
version=VERSION,
description=DESCRIPTION,
author=AUTHOR,
author_email=AUTHOR_EMAIL,
maintainer=MAINTAINER,
maintainer_email=MAINTAINER_EMAIL,
license=LICENSE,
url=URL,
keywords=KEYWORDS,
classifiers = filter(None, classifiers.split("\n")),
long_description = "\n".join(doclines[2:]),
py_modules=PY_MODULES,
ext_modules=[Extension("P4Client", ["P4Clientmodule.cc"],
include_dirs=[p4_api_dir],
library_dirs=[p4_api_dir],
libraries=["client", "rpc", "supp"],#
P4API libs
extra_compile_args=["-DCASE_INSENSITIVE",
"-fpascal-strings",
"-isysroot/Developer/
SDKs/MacOSX10.4u.sdk",
"-DOS_MACOSX", "-
DOS_MACOSX104",
"-DOS_MACOSXPPC", "-
DOS_MACOSX104PPC" ,"-D%s" % p4_api_ver],
extra_link_args=[ "-Wl,-syslibroot,/
Developer/SDKs/MacOSX10.4u.sdk", "-arch ppc", "-framework Carbon" ],
)])
But low and behold it didn't work... In the course of debugging I
found that the compile works. The linking appears to be a problem.
In the link stage I see the command which is being run looks very
similar to my command
g++ -bundle -undefined dynamic_lookup build/temp.macosx-10.3-ppc-2.5/
P4Clientmodule.o \
-Lp4api6.1 -lclient -lrpc -lsupp -o build/lib.macosx-10.3-ppc-2.5/
P4Client.so \
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -framework
Carbon
Not quite the same but close enough. HERE is where the bug shows
up
If I rerun this same EXACT command at the command line - followed by a
setup.py install it works.
Can someone with a larger python brain than mine please help me figure
this out? It's bugging the crap out fo me...
--
BR. Alexander 'zowers' Petrov.jabber:[EMAIL PROTECTED]icq:69694782
http://zowers.googlepages.com/mailto:[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Terry Reedy wrote: Luke Kenneth Casson Leighton wrote: i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue841454 Against 2.3, rejected due to dependence on SCons. Also appears to have been incomplete, needing more work. No it was complete but use SCons. Most of changes changes in code you will see again in 3871. http://bugs.python.org/issue3754 Open by Roumen Petrov, no review, see below. This is again request and the patch is for trunk. It share common idea with 841454:Cross building python for mingw32:Andreas Ames (yxcv):2003-11-13 14:31 1006238:Cross compile patch:Daniel Goertzen (goertzen):2004-08-09 22:05 1597850:Cross compiling patches for MINGW hanwen:2006-11-16 16:57 http://bugs.python.org/issue3871 Open, from same submitter, only (minor) review by you. Does this supercede 3754? No. It share common changes to code with 841454, 1006238, 1412448, 1597850. May be 1597850 and 3871 supercede 1412448. The issue3871 raise questions (and include solution/work around) related to: 2942 - mingw/cygwin do not accept asm file as extension source 2445 - Use The CygwinCCompiler Under Cygwin 1706863 - Failed to build Python 2.5.1 with sqlite3 Also issues related to LDFLAGS: 4010 - configure options don't trickle down to distutils 1628484 - Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [SNIP] -- http://mail.python.org/mailman/listinfo/python-list
Re: About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
anatoly techtonik wrote: On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov wrote: Against 2.3, rejected due to dependence on SCons. Also appears to have been incomplete, needing more work. No it was complete but use SCons. Most of changes changes in code you will see again in 3871. I would better use SCons for both unix and windows builds. In case of windows for both compilers - mingw and microsoft ones. To port curses extension to windows I need to know what gcc options mean, what are the rules to write Makefiles and how to repeat these rules as well as find options in visual studio interface. Not mentioning various platform-specific defines and warning fixes. Did you select one of existing curses library for windows ? Roumen -- http://mail.python.org/mailman/listinfo/python-list
cross-compilation
Hi list members, It seems to me that this is discussed many times in the past but without progress. As I understand in general there is no objections and preferred cross-compilation has to be based on distutils (scons was rejected). So I would like to cross-compile from linux(build system) to the mingw(host system) and note some(many) problems: - the configure script don't support cross-compilation: The first is lack of macro AC_CANONICAL_HOST. Next is AC_TRY_RUN with two arguments. - native mingw build isn't supported well: As example updated ifdefs from issue 1412448 aren't in the code. The posixmodule.c is required and I expect native build to fail. May be same for pwdmodule.c. - the build process may require python installed on build system and the "distutils" may be isn't aware that cross-compilation is requested. In general isn't possible to run on build platform executable just build for host platform. Linux plus emulator is an exception. What about to start to resolve issues step by step ? Roumen -- http://mail.python.org/mailman/listinfo/python-list
Re: cross-compilation
Martin v. Löwis wrote:
What about to start to resolve issues step by step ?
The first step surely should be to get the autoconf issue resolved.
I don't think distutils cross-compilation is going to work, instead,
people wishing to cross-compile should edit Modules/Setup.
Regards,
Martin
Please find attached file "python-2.5.2.patch-CROSS".
Note that this is "proof of concept" unified diff only for configure.in
to show only some changes required for cross-compilation:
- added macro AC_CANONICAL_HOST: this require files config.guess and
config.sub to be copied to top source directiory. The files can be
obtained from GNU automake distribution. In my test I use files from
automake 1.10.1.
- makefile conditional: the idea is to use in makefiles. It seems to me
that build for PGEN (Parser from Makefile.pre.in) has to be suppress in
case of cross-compilation as example (without related changes):
=
# Parser
@[EMAIL PROTECTED] Parser/pgen$(EXE)
=
- search for python in build system: usually in the cross environment
we cann't run just build python executable we may use existing
interpreter as example in Makefile.pre.in:
=
@[EMAIL PROTECTED] [EMAIL PROTECTED]@ @SYSPYTHON@
@[EMAIL PROTECTED] $(RUNSHARED) ./$(BUILDPYTHON)
=
- $ac_sys_system vs $host: the attached diff show how to detect host
system. The existing detection (variable $ac_sys_system) isn't suitable
for cross-environment.
- ar program : macro AC_CHECK_TOOLS replace AC_CHECK_PROGS. for more
details see autoconf texinfo page.
- detection of files: skip detection in cross-env. and by default assume
that file don't exists. This is minimal change and I think that we
has to use macro AC_CHECK_FILE and in cross-env. to warn user but this
require more changes.
- creation of files from configure script (note this is not related
directly to cross compilation): the script is changed to use macros
AC_CONFIG_COMMANDS{_PRE}, i.e. more autoconf friendly.
I would like to know what is acceptable for above changes ?
(note that changes for mingw are only to show idea how to get host
system and i will exclude from final patch ).
Also how to proceed ?
Must I open new issue and to mark that as example 1597850 depend from
new one ?
What is preferred patch: against trunk, release2.5 or both ?
Roumen
--- ./configure.in.CROSS2008-02-13 21:17:17.0 +0200
+++ ./configure.in 2008-08-19 03:11:48.0 +0300
@@ -8,6 +8,7 @@
AC_INIT(python, PYTHON_VERSION, http://www.python.org/python-bugs)
AC_CONFIG_SRCDIR([Include/object.h])
AC_CONFIG_HEADER(pyconfig.h)
+AC_CANONICAL_HOST
dnl This is for stuff that absolutely must end up in pyconfig.h.
dnl Please use pyport.h instead, if possible.
@@ -30,6 +31,36 @@
rm confdefs.h
mv confdefs.h.new confdefs.h
+dnl makefile conditional (for future use)
+if test "x$cross_compiling" = xyes; then
+ CROSS_ON=''
+ CROSS_OFF='#'
+else
+ CROSS_ON='#'
+ CROSS_OFF=''
+fi
+AC_SUBST(CROSS_ON)
+AC_SUBST(CROSS_OFF)
+
+if test "x$cross_compiling" = xyes; then
+ AC_MSG_NOTICE([cross-compilation is incomplete])
+
+ dnl in cross-compilation environment we need python from
+ dnl build system (for future use)
+ AC_PATH_PROG(SYSPYTHON, python, [none],
+[$PATH:/usr/local/bin]
+ )
+ if test "x$PYTHON" = xnone; then
+AC_MSG_ERROR([python program is required in cross-compilation environment])
+ fi
+
+ dnl HOST_OS is a variable to be used in makefiles to inform other
+ dnl tools for real host system if differ from build system
+ dnl (reserved for future use)
+ HOST_OS=$host_os
+fi
+AC_SUBST(HOST_OS)
+
AC_SUBST(VERSION)
VERSION=PYTHON_VERSION
@@ -585,6 +616,10 @@
*)
enable_shared="no";;
esac
+ case $host in
+ *-*-mingw*)
+enable_shared="yes";;
+ esac
fi
AC_MSG_RESULT($enable_shared)
@@ -593,11 +628,11 @@
AC_HELP_STRING(--enable-profiling, enable C-level code
profiling),
[ac_save_cc="$CC"
CC="$CC -pg"
- AC_TRY_RUN([int main() { return 0; }],
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[[int main() { return 0; }]])],
ac_enable_profiling="yes",
- ac_enable_profiling="no",
ac_enable_profiling="no")
- CC="$ac_save_cc"])
+ CC="$ac_save_cc"],
+ ac_enable_profiling="no")
AC_MSG_RESULT($ac_enable_profiling)
case "$ac_enable_profiling" in
@@ -675,6 +710,13 @@
RUNSHARED=DLL_PATH=`pwd`:${DLL_PATH:-/atheos/sys/libs:/atheos/autolnk/lib}
;;
esac
+ case $host in
+*-*-mingw*)
+ LDLIBRARY='libpython$(VERSION).dll.a'
+ DLLLIBRARY='libpython$(VERSION).dll'
+ BLDLIBRARY='-L. -lpython$(VERSION)'
+ ;;
+ esac
else # shared is disabled
case $ac_sys_system in
CYGWIN*)
@@ -682,13 +724,16 @@
LDLIBRARY='libpython$(VERSION).dll.a'
;;
esac
+ case $host in
+*-*-mingw*)
+ LDLIBRARY='libpython$(VERSION).dll.a';;
+ esac
fi
AC_MSG_RESULT($LDLIBRARY)
AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR,
How to correctly pass “pointer-to-pointer” into DLL via ctypes?
Hello.
I have a DLL that allocates memory and returns it. Function in DLL is like this:
void Foo( unsigned char** ppMem, int* pSize )
{
* pSize = 4;
* ppMem = malloc( * pSize );
for( int i = 0; i < * pSize; i ++ ) (* pMem)[ i ] = i;
}
Also, i have a python code that access this function from my DLL:
from ctypes import *
Foo = windll.mydll.Foo
Foo.argtypes = [ POINTER( POINTER( c_ubyte ) ), POINTER( c_int ) ]
mem = POINTER( c_ubyte )()
size = c_int( 0 )
Foo( byref( mem ), byref( size ) ]
print size, mem[ 0 ], mem[ 1 ], mem[ 2 ], mem[ 3 ]
I'm expecting that print will show "4 0 1 2 3" but it shows "4 221 221
221 221" O_O. Any hints what i'm doing wrong?
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to correctly pass “pointer-to-pointer” i nto DLL via ctypes?
Thank you a lot!
I have stripped down my production code to the sample - and it worked.
Bug was in another part of my code where free() was called for the
memory in question.
On Fri, Nov 19, 2010 at 3:39 PM, Diez B. Roggisch wrote:
> Grigory Petrov writes:
>
>> Hello.
>>
>> I have a DLL that allocates memory and returns it. Function in DLL is like
>> this:
>>
>> void Foo( unsigned char** ppMem, int* pSize )
>> {
>> * pSize = 4;
>> * ppMem = malloc( * pSize );
>> for( int i = 0; i < * pSize; i ++ ) (* pMem)[ i ] = i;
>> }
>>
>> Also, i have a python code that access this function from my DLL:
>>
>> from ctypes import *
>> Foo = windll.mydll.Foo
>> Foo.argtypes = [ POINTER( POINTER( c_ubyte ) ), POINTER( c_int ) ]
>> mem = POINTER( c_ubyte )()
>> size = c_int( 0 )
>> Foo( byref( mem ), byref( size ) ]
>> print size, mem[ 0 ], mem[ 1 ], mem[ 2 ], mem[ 3 ]
>>
>> I'm expecting that print will show "4 0 1 2 3" but it shows "4 221 221
>> 221 221" O_O. Any hints what i'm doing wrong?
>
> After correcting quite a few obvious errors in your code, it worked just
> fine for me. So I guess what you think you test is not what you test.
>
> --- test.py
> from ctypes import *
>
> foo =
> cdll.LoadLibrary("/Users/deets/projects/GH28/kinect/kinect/c/foo/libtest.dylib").foo
> foo.argtypes = [ POINTER( POINTER( c_ubyte ) ), POINTER( c_int ) ]
> mem = POINTER( c_ubyte )()
> size = c_int( 0 )
> foo( byref( mem ), byref( size ) )
> print size, mem[ 0 ], mem[ 1 ], mem[ 2 ], mem[ 3 ]
> ---
>
> --- test.c
> void foo( unsigned char** ppMem, int* pSize )
> {
> int i;
> * pSize = 4;
> * ppMem = malloc( * pSize );
> for( i = 0; i < * pSize; i ++ ) (* ppMem)[ i ] = i;
> }
> ---
>
> --- CMakeLists.txt
> cmake_minimum_required (VERSION 2.6)
> project (Test)
> add_library(test SHARED test.c)
> ---
>
> --
> Diez
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
