Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's some Python code to translate floats to hex strings and back, in
case it's useful.
Added file: http://bugs.python.org/file10780/hex_float.py
___
Python tracker <[EMAI
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10729/hex_float.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an updated Python version of toHex and fromHex; fixes a bug in the
previous version of fromHex for hex floats starting with an upper case hex
digit. I'm not sure how useful this is, but I thought I might as well
p
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
...and the tests for hex_float.py
Added file: http://bugs.python.org/file10786/test_hex_float.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10780/hex_float.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I agree that if the type of the 2nd arg isn't int or long it should be
> rejected. That should not slow down the common path (two ints).
I'm having second thoughts about this; it doesn't seem worth adding an
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I can reproduce this with the Apple-supplied Python, but I'm having
trouble reproducing it with anything from python.org. I tried checking
out revision 54863 and doing
./configure --enable-framework MACOSX_DEPLOYMENT_TARGET=1
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: georg.brandl -> marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
I know it is almost certainly too late, but I think a lot of people will
be confused by str.decode() and bytes.encode() (or was that the other
way around)?
Calling the methods str.tobytes() and bytes.tostr() (or nicer,
str.to_bytes
Changes by Mark Summerfield <[EMAIL PROTECTED]>:
--
type: -> behavior
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3000>
___
___
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Well, I can't find anything more to fuss about here. :-)
Reclosing.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The g4 buildbot still isn't happy, either. See:
http://www.python.org/dev/buildbot/trunk.stable/g4%20osx.4%20trunk/builds/
3645/step-test/0
(This was a run of revision 64663, I think.)
___
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> The G4 buildbot is green right now.
Sure. But it looks like test_multiprocessing hung on build 3645, which
as far as I can tell included all the recent fixes.
My machine's behaving the same way: when doing 'ma
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an interesting snippet from the my most recent attempt to run
'make test'. I got a failed assertion:
[...]
test_multibytecodec_support
test_multifile
test_multiprocessing
Assertion failed: (bp != NULL), fun
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> What platform mark?
OS X 10.5.4/Intel Core 2 Duo. (It's a 2007 Macbook Pro.)
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Mark, can you try commenting out _TestCondition and seeing if you can
> still get it to hang?;
I removed the _TestCondition class entirely from test_multiprocessing,
and did make test again. It didn't hang! :-) I
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay. I just got about 5 perfect runs of the test suite, followed by:
Macintosh-3:trunk dickinsm$ ./python.exe -m test.regrtest
[...]
test_multiprocessing
Assertion failed: (bp != NULL), function PyObject_Malloc, file
Objects/obma
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Are you sure that's right?
Not at all. :-)
> That traceback has no mention of
> PyObject_Malloc or obmalloc.c. Try checking the date. Also, if you
> use "gdb ./python.exe " to start gdb it should
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a new traceback (a different error again, this time: a negative
refcount in Objects/tupleobject.c.)
Added file: http://bugs.python.org/file10796/traceback2.txt
___
Python tracker <[E
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Are you sure that's right? That traceback has no mention of
> PyObject_Malloc or obmalloc.c.
So now I think that the traceback was right. There was no mention of
PyObject_Malloc or obmalloc.c because the traceback only
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm working on it. I expect to have something ready by the end of this
weekend.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sure. What about non-C99 machines? I thought Python code was only
allowed to assume ANSI C.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
In the interests of getting early feedback, here's half a patch,
containing an implementation of from.fromhex and tests.
Still to come: float.hex and documentation.
I'll ask on python-dev about C99 and %a.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> containing an implementation of from.fromhex and tests.
That should be 'float.fromhex', not 'from.fromhex'.
I should also have said that this patch is against the trunk; only minor
change
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The float.as_integer_ratio method needs to be documented somewhere other
than whatsnew/2.6.rst.
--
assignee: georg.brandl
components: Documentation
messages: 69277
nosy: georg.brandl, marketdickinson
severity: normal
status
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an updated patch, complete with both float methods and
documentation.
Added file: http://bugs.python.org/file10815/hex_float2.patch
___
Python tracker <[EMAIL PROTECTED]>
<ht
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Add updated patch with expanded documentation.
Added file: http://bugs.python.org/file10816/hex_float2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10815/hex_float2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Checked in, r64729.
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Jean. I've checked in your workaround in r64735.
Leaving this open for now as a reminder about finite/is_finite.
--
resolution: -> fixed
___
Python tracker <[EMAIL
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> There is another, perhaps related issue on Solaris. The compiler warns
> that function finite is implicitly defined.
>
> Commenting out this line in pyconfig.h as
>
> /* #define HAVE_FINITE 1 */
>
> make t
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Tim]
> If you think using 16 (when possible) will stop complaints, think again
> ;-) For example, ...
Aha! But using *15* digits would be enough to eliminate all 1, 2, 3, 4,
..., 15 digit 'surprises', wouldn
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's the 'proof' that 15 digits should be enough:
Suppose that x is a positive (for simplicity) real number that's exactly
representable as a decimal with <= 15 digits. We'd like to know that
'%
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
For what it's worth, I'm -0.1 (or should that be -0.10001?) on
this change. It seems better to leave the problems caused by binary
floating-point out in the open than try to partially hide them, and the
prop
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm pretty much out of ideas here. Skip, if you have any time to figure
out where the math.log call is going wrong, I'd appreciate it. On Jean's
machine, the problem was that the call log(-inf) to the C librar
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Some other possibilities to try. This page:
http://www.redhat.com/docs/wp/solaris_port/x99.html
seems to suggest that linking with -lieee, and possibly also adding the -
ffast-math gcc option, migh
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a slightly more polished version of the previous patch; no
behaviour changes.
Let me know if there's anything I can do to help get this in before next
week's beta. Anybody want to trade patch revie
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Minor modifications to the previous patch, mostly to the docs.
Setting priority to critical, since this really needs to go in before the
next beta if it's going to get into 2.6/3.0.
--
priority: -> critical
Ad
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Mildly off-topic: it seems that currently eval(repr(x)) == x isn't
always true, anyway. On OS X 10.5.4/Intel, I get:
>>> x = (2**52-1)*2.**(-1074)
>>> x
2.2250738585072009e-308
>>> y = eval(repr(x
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an updated patch that makes the trailing 'p123' exponent optional
in fromhex. (This matches the behaviour of C99's strtod and sscanf; in
contrast, Java always requires the exponent.)
I'm begi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
In the spirit of being "liberal in what you accept, but strict in what you
emit", here's a version that makes both the leading '0x' and the trailing
'p...' exponent optional on input. Both of these
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Some final tinkering:
- docstrings and docs expanded slightly; docs mention interoperability
with C and Java.
- in float.hex(), there's always a sign included in the exponent (e.g.
"0x1p+0" instead of "0x1p0
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3008>
___
___
Python-bugs-list mailing list
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an updated patch that addresses Raymond's concerns.
> The patch looks good. I would coded hex_from_char() using a lookup
> into "0123456789abcdef" which uses no unpredicatable branches.
> L
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is not a bug (though it's commonly reported as such :-) ). Given
that not all real numbers can be represented as floats, math.pi is
necessarily an approximation to true Pi, and you're
printing that approximation out t
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I get the same behavior in the trunk (on OS X 10.5), though it's not a
problem in the py3k branch.
I agree that this is undesirable behaviour, and I think it should be
fixed. For me, the crossover seems to occur
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Committed, r64974
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> userland. On these systems, the behavior I described does not exist:
Not even with really large values? What happens on 64-bit with
>>> x = 08.0
? (that's 20 zeros between the
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Does this also apply to 2.6?
--
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> >>> x = 08.0
Urk. That should be:
>>> x = 010.0
The problem is in the parsenumber function in Python/ast.c. The
solution seems to be very simple: just remove the enti
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Now I just have to figure out where to add tests for this.
Found it. Tests in test_compile.py.
Fixed in the trunk in r65005. This should probably also be backported to
2.5.
Thanks for the report, Richard!
--
r
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed in the 2.5 branch, r65007.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Does this also apply to 2.6?
Looks like it doesn't. :-).
The patch needs to touch the newly arrived
comparison with "infinity", as well as the
"inf" and "nan" comparisons.
__
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3369>
___
_
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In _TestZZZNumberOfObjects in test_multiprocessing.py, at around line 1040
(this is r65075 on the trunk), there's a line:
print self.manager._debugInfo()
Should this be
print self.manager._debug_info(
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
As of revision 65077 of the trunk, I'm getting errors in
test_multiprocessing that seem to point to memory corruption in object
allocation/deallocation. The failures are intermittent, and of a
similar nature to the errors I
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
And one more:
Failure 4:
test_make_pool (__main__.WithManagerTestPool) ... Assertion failed: (bp !=
NULL), function PyObject_Malloc, file Objects/obmalloc.c, line 746.
___
Python tracker &
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
And another:
Failure 5:
test_notify (__main__.WithManagerTestCondition) ... Assertion failed:
(usable_arenas->freepools == NULL), function PyObject_Malloc, file
Objects/obmalloc.c, line 8
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
LD_LIBRARY_PATH isn't set. gcc is the system gcc from Apple:
Macintosh-3:trunk dickinsm$ echo $LD_LIBRARY_PATH
Macintosh-3:trunk dickinsm$ which gcc
/usr/bin/gcc
Macintosh-3:trunk dickinsm$ gcc -v
Using built-in specs.
Target:
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay: I just tried the following:
(1) clean svn checkout
(2) ./configure && make
(3) 100 runs of test_multiprocessing, via the shell command:
for ((i=0;i<100;i+=1)); do ./python.exe
Lib/test/test_multiprocessing.py; sleep
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I should add to the previous message that this was revision 65090, and
that it was a non-debug build.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It looks like this isn't just me. See the buildbot output at:
http://www.python.org/dev/buildbot/all/x86%20osx.5%20trunk/builds/33/ste
p-test/0
which shows:
test_multiprocessing
Assertion failed: (bp != NULL), function PyOb
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue756093>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for the patch! I probably won't get to this properly until after
2.6 final, but it won't get lost. It seems like there's pretty good
support for adding these functions.
By the way, there's already a s
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I still think this is the wrong solution, and should be fixed before 2.6;
long(float('nan')) should raise ValueError. As Alexander points out,
this fits much better with the IEEE 754 standard, and also with the C99
standar
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Assigning to me; I'd like to check in the new fix for 2.6/3.0, but I'll
give it a couple of weeks for any objections to surface first.
--
assignee: -> marketdickinson
versions: +Python 2.6, Pyt
Mark Harrison <[EMAIL PROTECTED]> added the comment:
There's a one-line change necessary in BaseHTTPServer.py.
s/socketserver/SocketServer/ on this line:
+socketserver.StreamRequestHandler.__init__(self, request,
client_address, parent)
+SocketServer.StreamReq
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed in r65179. I modified the patch slightly to include the "infinity"
check, and to change "if(s_buffer)" to the slightly more explicit "if
(s_buffer != NULL)".
Thanks!
--
resoluti
Changes by Mark Summerfield <[EMAIL PROTECTED]>:
--
nosy: +mark
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2834>
___
___
Python
Changes by Mark Summerfield <[EMAIL PROTECTED]>:
--
nosy: +mark
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3394>
___
___
Python
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I'm +1 on making gamma() be the true gamma function and not carrying
> over this brain-damage to Python.
+1 from me, too.
___
Python tracker <[EMAIL PROTECTED]>
<http:/
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The IBM General Decimal Arithmetic Specification, on which the decimal
module is based, has recently been updated to version 1.68; the
testcases from IBM have also been updated.
The comments in the decimal module clearly state th
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
One change from v1.66 to v1.68 of the spec:
"""The normalize operation has been renamed reduce to avoid confusion with
normal numbers."""
The decimal module is not under any obligation to use the same na
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Looks like the changes needed here are even more minor than I thought.
The decimal module already does the right thing with respect to
the new specification and the new tests. So all that needs doing is
to replace the old tests with t
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file10987/issue3449.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sadly, this is not the only problem with math.sum on x86 hardware right
now. I'd guess that this is another problem related to double-rounding
and the use of 80-bit floating-point registers on x86. Raymond and I
are sti
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See also issue 2819 for ongoing discussion, and issue 2937, which is the
likely root cause of the current difficulties with math.sum.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch giving an alternative implementation of math.fsum; it's
based on Tim Peter's suggestions, works mostly with integer arithmetic,
and so bypasses problems with double rounding and extended precision
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks. Those are the results I'd expect on x86. So here's the puzzle:
On lines 658-9 of Lib/test/test_math.py, in revision 65248 of the py3k
branch, there's a pair of lines that looks like:
if 1e16
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'd also be interested in having _PyLong_NumBits exposed to Python in some
way or another. It's something I've needed many times before, and it's
used in the decimal module, for example.
My favorite workaround u
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Would there be any interest in porting these algorithms to C and using
> them in the standard Python long implementation?
Yes, definitely! Though it depends a little bit how much complication
is involved.
A subquadratic a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed, r65257.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Tests related to overflow, special-values, intermediate overflow, and
results at or near the boundary of the floating-point range have been
removed in r65258.
___
Python tracker <[EMAIL PROTECTE
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See r65292 for more updates to the test-suite: I've replaced the Python
version of msum by a version based on lsum in the original ASPN recipe.
___
Python tracker <[EMAIL PRO
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Minor code cleanups, and fixes to special-value handling in r65299
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Renamed math.sum to math.fsum (as previously discussed) in r65308.
I think all that's left now is to add a note to the docs about the
problems on x86.
___
Python tracker <[EMAIL PRO
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Added documentation note about x86 problems in r65315.
Jean, Raymond: is it okay to close this issue now?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here (fsum8.patch) is a clean version of the alternative fsum algorithm.
I'd like to push for using this in place of the existing algorithm.
Added file: http://bugs.python.org/file11008/
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Tim]
> if you're concerned about speed, it would probably pay to eliminate all
> library calls except one to frexp().
Indeed it would! Here's a revised patch that avoids use of fmod. Speed is
comparable with the c
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Timings on x86/Linux are similar: the lsum-based version is around
10% slower on average, 25% slower in the worst case, and significantly
faster for the msum worst cases.
There's probably still some snot left to optimize out, th
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Toned down note in docs (at Raymond's request) in r65366.
While I'd really like to see an lsum-based version go in instead, I
think it's too close to the release to make this change right now.
There was also orig
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I finally found some more time to look at this. I cut down the test-suite
to try to find a minimal failing example. I can fairly reliably make a
debug build of the trunk crash using the following nine lines
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> This is wrong (the GIL must be held when using the PyMem_* and
> PyObject_* functions), and is probably the cause of the failed
assertion.
This sounds quite likely.
I just managed (using the low-tech method of setting a sta
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch that fixes the problem for me. It releases the GIL around
the calls to _conn_sendall within conn_send_string, instead of releasing
the GIL for the whole call to conn_send_string.
--
keywords: +patch
Added
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Amaury! How's this?
I have no access to a Windows machine, so this patch is untested on
Windows.
Added file: http://bugs.python.org/file11028/issue3399_2.patch
___
Python trac
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm also seeing the incref error occasionally, on OS X 10.5.4:
==
ERROR: test_remote (__main__.WithManagerTestRe
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
For the connection refused error, the following script fails for me
(again, on OS X 10.5.4) with the message:
errno: [Errno 61] Connection refused
on most runs. (If xrange(10) is replaced by a smaller range like
xrange(4) then the
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Looks like something in semaphore.c needs fixing, but I've no idea what.
I take that back. It's nothing to do with semaphore.c. I'll keep trying.
___
Python tracker &
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Question: I see "math module patch committed, r63542" in May 22. But in
> 3.0b2, there is no math.fsum and math.sum seems to be a wrapper for
> builtin sum. Has this not been forward ported (merged) yet?
I'
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Are you looking at the conn refused or the incref error?
The connection refused error.
The attached patch fixes the problem, for me. On my machine, the
connection refused error code was 61 rather than 10061. With this patch
1501 - 1600 of 12223 matches
Mail list logo
