On Wed, May 21, 2008 at 5:12 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
>> Trent Nelson wrote:
>> | Gah. I just went and visited the Berkeley DB download site as
>> | I was preparing my commit message so I could refer to the
>> | exact .tar.gz being imported, only to notice that the latest
>> | v
> Trent Nelson wrote:
> | Gah. I just went and visited the Berkeley DB download site as
> | I was preparing my commit message so I could refer to the
> | exact .tar.gz being imported, only to notice that the latest
> | version is now 4.7.25. Jesus, can we use this version?
>
> Err No.
>
> It
Alex Martelli wrote:
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Putting this functionality in 2.6/3.0 would provide a really
nice incentive to update from Py2.5. It would be a sad
lost opportunity if this module had to wait another couple years.
I feel essen
Martin v. Löwis wrote:
IIRC, it chokes on the attempt to compile assembler code that
has C preprocessor macros in it (can't test it right now).
Could the build process be modified to run the C preprocessor
over the assembly language first?
--
Greg
__
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> This thread has diverged a bit from the original topic.
>
> I suggest going ahead and adding pyprocessing to the library.
> IMO, its functionality is going to be an essential capability as
> more and more computers ship
> The "csvn" subversion bindings use "ctypesgen" to grovel header files:
> http://code.google.com/p/ctypesgen/
Thanks for the pointer. Looks nice. I've used ctypeslib before, but
it takes a bit of infrastructure building (gcc-xml) before it works.
Bill
__
This thread has diverged a bit from the original topic.
I suggest going ahead and adding pyprocessing to the library.
IMO, its functionality is going to be an essential capability as
more and more computers ship with multiple processors.
At this point, the basic API for pyprocessing seems well
t
On May 21, 2008, at 3:58 PM, Jean-Paul Calderone wrote:
Plus, even if ctypes works, the code might be incorrect, because they
had been assuming structure layouts and symbolic constants that have
just a different definition on some other platform, causing the
extension module to crash.
Writing p
On Wed, 21 May 2008 20:57:33 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
As said before, PyOpenGL is an example of an extension that moved from C
code to Python/ctypes, luckily we don't use it, but what if the
maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
Having
> So maybe Python just doesn't run on Solaris with the Sun C compiler.
> Certainly doesn't build out of the box.
Hmmm, when I look at http://www.sun.com/software/solaris/freeware/, I
see that Python is listed as "included with Solaris 10" as
"Sun-supported software". But the version installed on
Martin v. Löwis schrieb:
>> As said before, PyOpenGL is an example of an extension that moved from C
>> code to Python/ctypes, luckily we don't use it, but what if the
>> maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
>> Having the ctypes extension in the stdlib doesn't imply it
Thomas Heller schrieb:
> A.M. Kuchling schrieb:
> > On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> >> Myself I would rather spend my energy to make ctypes more portable, within
> >> my
> >> skills and the platforms I have access to.
> >
> > Someone could run Solaris x86 inside a
> In any case, what would be the procedure to update the buildbot
> infraestructure?.
You need to import the sources into the Python subversion repository;
I understand Trent was about to do that.
Then you need to adjust Tools/msi/external.bat to have the slaves export
the new version.
Regards,
> As said before, PyOpenGL is an example of an extension that moved from C
> code to Python/ctypes, luckily we don't use it, but what if the
> maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
> Having the ctypes extension in the stdlib doesn't imply it runs on any
> platform where
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trent Nelson wrote:
| Gah. I just went and visited the Berkeley DB download site as
| I was preparing my commit message so I could refer to the
| exact .tar.gz being imported, only to notice that the latest
| version is now 4.7.25. Jesus, can we use
[EMAIL PROTECTED] wrote:
Skip> Maybe the presence of a functioning ctypes (can|might|should|will)
Skip> become the operational definition of "Python runs on platform X".
Michael> And what about platforms like the JVM or CLR?
Sorry, allow me to rephrase:
Maybe the presence of a
Gah. I just went and visited the Berkeley DB download site as I was preparing
my commit message so I could refer to the exact .tar.gz being imported, only to
notice that the latest version is now 4.7.25. Jesus, can we use this version?
Trent.
From:
Ulrich Berning schrieb:
>
> If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using
> vendor compilers) would be an easy job, I'm sure it would have been done
> already. If more and more essential packages depend on ctypes, we should
> make a clear statement, that Python isn't suppo
A.M. Kuchling schrieb:
> On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
>> Myself I would rather spend my energy to make ctypes more portable, within my
>> skills and the platforms I have access to.
>
> Someone could run Solaris x86 inside a hosted virtual machine and make
> it ava
Bill Janssen schrieb:
> What happens on those platforms where ctypes doesn't work? Does the
> module fail to import, either because it isn't present, or because it
> can't load the libffi library? Or does it fail silently in some way?
It doesn't compile, and Python's setup.py script removes if a
Michael Foord schrieb:
> James Y Knight wrote:
>>
>> On May 21, 2008, at 11:26 AM, Michael Foord wrote:
>>
>>> And what about platforms like the JVM or CLR?
>>>
>>> Incidentally there were a small but vocal group of Pythonistas who
>>> were (are?) certain that IronPython is not Python because it d
Skip> Maybe the presence of a functioning ctypes (can|might|should|will)
Skip> become the operational definition of "Python runs on platform X".
Michael> And what about platforms like the JVM or CLR?
Sorry, allow me to rephrase:
Maybe the presence of a functioning ctypes (can|mi
On May 21, 2008, at 11:26 AM, Michael Foord wrote:
And what about platforms like the JVM or CLR?
Incidentally there were a small but vocal group of Pythonistas who
were (are?) certain that IronPython is not Python because it doesn't
have [all of...] the C extensions.
It seems likely to b
James Y Knight wrote:
On May 21, 2008, at 11:26 AM, Michael Foord wrote:
And what about platforms like the JVM or CLR?
Incidentally there were a small but vocal group of Pythonistas who
were (are?) certain that IronPython is not Python because it doesn't
have [all of...] the C extensions.
[EMAIL PROTECTED] wrote:
Ulrich> Having the ctypes extension in the stdlib doesn't imply it runs
Ulrich> on any platform where python runs.
Maybe the presence of a functioning ctypes (can|might|should|will) become
the operational definition of "Python runs on platform X".
And what
On Wed, May 21, 2008 at 10:11:05AM -0500, [EMAIL PROTECTED] wrote:
> Maybe the presence of a functioning ctypes (can|might|should|will) become
> the operational definition of "Python runs on platform X".
It is not black-or-white, runs or doesn't. PythonD, e.g., runs on DOS,
can use sockets (fro
On Tue, Apr 22, 2008 at 7:04 PM, Steven Bethard <[EMAIL PROTECTED]>
wrote:
> > The callable takes the src directory + its content as a list, and
> > returns filter eligible for exclusion
>
> FWIW, that looks better to me.
>
> > That makes me wonder, like Alexander said on the bug tracker:
> >
Ulrich> Having the ctypes extension in the stdlib doesn't imply it runs
Ulrich> on any platform where python runs.
Maybe the presence of a functioning ctypes (can|might|should|will) become
the operational definition of "Python runs on platform X".
Skip
__
Fred Drake wrote:
On May 21, 2008, at 5:41 AM, Nick Coghlan wrote:
While a proxy class written in C would no doubt be faster than one
written in Python, one of the things I'm hoping to achieve is for the
stdlib generic proxy to serve as an example for people writing their
own new-style proxy c
On May 21, 2008, at 5:41 AM, Nick Coghlan wrote:
While a proxy class written in C would no doubt be faster than one
written in Python, one of the things I'm hoping to achieve is for
the stdlib generic proxy to serve as an example for people writing
their own new-style proxy classes in additi
Fred Drake wrote:
Nick Coghlan wrote:
So what do people think of including a ProxyBase implementation in 2.6
and 3.0 that explicitly delegates all of the C-level slots to a
designated target instance?
On May 20, 2008, at 7:55 PM, Greg Ewing wrote:
Sounds good to me.
Same here. There's an
Hi Martin,
On Tue, May 20, 2008 at 10:22:37AM +0200, "Martin v. Löwis" wrote:
> In particular, setting this environment variable would also disable
> the detection of whether stdout is a terminal.
In this case, it seems to me that existing programs that start python as
a non-interactive subproces
Brett Cannon wrote:
On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
Gregory P. Smith wrote:
On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
As long as the ctypes extension doesn't build on major Un*x platforms
(AIX,
HP-UX)
Martin v. Löwis schrieb:
I can neither find recvfd in my man pages nor in my header files in
/usr/include on Linux (Ubuntu 8.04 i686). I assume recvfd and sendfd
aren't syscalls but the proposed names for the functions.
Yes (and no). The system call is sendmsg, with a cmsg_type of
SCM_RIGHTS. I
34 matches
Mail list logo
