BerkeleyDB 4.6.19 is a buggy release, the DB_HASH access method databases
can lockup the process. This is why several of the bleeding edge distro
buildbots are timing out while running test_bsddb3. I've created a simple C
test case and made sleepycat^Woracle aware of the problem.
I have a change
Sorry for the late response. As always, I have a lot of other stuff
going on at the moment, but I'm very interested in this subject.
On 6 Sep, 06:15 pm, [EMAIL PROTECTED] wrote:
>>PyOpenSSL, in particular, is both a popular de-facto
>>standard *and* almost completely unmaintained; python's stand
> (a)What's the "preferred" style in python extension modules
> of parsing a number from python into a C type, where the
> C type size may change on different platforms?
> Is my method of guessing what the largest common size
> will be (long, unsigned long, ...
The weekly summaries from the new bug tracker are disappearing somewhere
between the tracker and python-dev. My attempt to post one by hand was
rejected by python-dev-owner (Barry Warsaw?) without explanation. Perhaps he
has bounced the others; emails to python-dev-owner result in an automated
mess
I'm looking for suggestions for other SSL module tests.
Here's the result of running my (not yet checked-in) test_ssl.py
module in verbose mode. I'm pretty happy with the codebase right now,
and barring other tests, I'm ready to check it in and start on the 3.x
patch (or perhaps the 2.3 package
Hi folks.
While working on an in-house application that uses the curses
module, we noticed that it didn't work as expected on an AIX system
(powerpc 64-bit big-endian LP64), using python 2.3.5.
On a hunch, I took a look through the _cursesmodule.c code and
noticed the use of PyArg_ParseTuple()'s
> > "test_tcl" fails on me (OS X 10.4.10 on an Intel Mac, remotely logged
> > in via SSH and X Windows):
>
> That's no surprise, I would say: it seems you link against TkAqua
> (not X11 Tk); for that to work, you need a reference to WindowServer,
> which won't be available when logged in through S
> > There are some functions in _ssl.c for gathering randomness from a
> > daemon, and adding that randomness to the pseudo-random number
> > generator in SSL, before using SSL. There's a note there saying that
> > "on some platform" this is necessary. Anyone know which platforms?
>
> In general
> I'd like to ask some help where i should start checking the code to fix the
> error.
Python searches possible candidate locations of the standard library for
a landmark, see getpath.c; currently, the landmark is os.py.
If it doesn't find the landmark, it complains.
Regards,
Martin
Hi!
I've tried to port Python (2.3.6 and 2.5.1) to my own OS. The compilation of
the python library is done after a few hours of work. When i try to run the
compiled executable i got an error shown on the following screenshot:
http://giszo.lame.hu/jshot/screens/screen31.png
After a little while o
> "test_tcl" fails on me (OS X 10.4.10 on an Intel Mac, remotely logged
> in via SSH and X Windows):
>
> % test_tcl
> 2007-09-08 17:00:22.629 python.exe[4163] CFLog (0): CFMessagePort:
> bootstrap_register(): failed 1100 (0x44c), port = 0x3a03, name =
> 'Processes-0.58327041'
> See /usr/include/
> There are some functions in _ssl.c for gathering randomness from a
> daemon, and adding that randomness to the pseudo-random number
> generator in SSL, before using SSL. There's a note there saying that
> "on some platform" this is necessary. Anyone know which platforms?
In general, anything t
12 matches
Mail list logo
