Rocky Bernstein wrote:
> As a hobby I've been writing a debugger. One of the
> commands,"restart", works by calling an execv(). You may need to do
> this when
> the program you are debugging is threaded or when one needs to ensure
> that all program state is reinitialized.
>
> Recently, I added re
On Sat, Jan 31, 2009 at 4:55 PM, Rocky Bernstein wrote:
> As a hobby I've been writing a debugger. One of the
> commands,"restart", works by calling an execv(). You may need to do
> this when
> the program you are debugging is threaded or when one needs to ensure
> that all program state is reinit
Ludvig Ericson wrote:
> Begin forwarded message:
>> From: Ludvig Ericson
>> Or even
>>
>> … = partial.skip
>> split_one = partial(str.split, …, 1)
That won't work:
>>> ... = 1
File "", line 1
SyntaxError: can't assign to Ellipsis
Like None/True/False, "..." is a constant that can't be modifie
As a hobby I've been writing a debugger. One of the
commands,"restart", works by calling an execv(). You may need to do
this when
the program you are debugging is threaded or when one needs to ensure
that all program state is reinitialized.
Recently, I added remote debugging via TCP sockets and no
> _ssl.c does indeed use int or long in various places. I'm not sure how
> far it can go with Py_ssize_t -- is OpenSSL 64-bit clean?
That's irrelevant for the issue at hand (PY_SSIZE_T_CLEAN). What matters
is that s# etc converters output Py_ssize_t (unless in deprecated
compatibility mode); if y
> Weird. regardless, this is presumably not related to your subversion
> upgrade. I don't think I've done any commits from these hosts since I
> got IPv6 connectivity, only updates.
I got some messages in kern.log which might be relevant
Jan 31 23:55:36 dinsdale kernel: IPv6: sending pkt_too_bi
> fwiw, I just turned off IPv6 and it worked fine. That makes no sense to
> me given that the ssh connection worked fine either way. Does svn
> itself try and log source addresses somehow when using svn+ssh and balk
> on IPv6 addrs?
No. subversion ignores the network layer.
> Weird. regardless
fwiw, I just turned off IPv6 and it worked fine. That makes no sense to me
given that the ssh connection worked fine either way. Does svn itself try
and log source addresses somehow when using svn+ssh and balk on IPv6 addrs?
Weird. regardless, this is presumably not related to your subversion
u
I'm just trying to commit the following to trunk:
SendingLib/test/test_socket.py
SendingMisc/NEWS
SendingModules/socketmodule.c
Transmitting file data ...
I have another svn commit attempt which appesrs to be hanging and destined
to timeout running right now.
ssh -v pytho
Bill Janssen parc.com> writes:
>
> is OpenSSL 64-bit clean?
I'm afraid I'm completely incompetent on this subject...!
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
> >
> > > Any thoughts? My own opinion is that it really doesn't matter
> > > that much if the slot is left in; it's just a little annoying to have
> > > such backwards-compatibility baggage already present in
> > > the shiny new 3.
> any ideas?
Assuming you reported this right after it happened - sorry, no.
I can't find anything relevant in the log files (although a
precise time of failure would have helped).
Does a plain "ssh python...@svn.python.org" still work?
What path did you try to check into?
Regards,
Martin
_
> Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long
> in various places instead of Py_ssize_t.
That's probably still the case.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Martin v. Löwis v.loewis.de> writes:
>
> > Any thoughts? My own opinion is that it really doesn't matter
> > that much if the slot is left in; it's just a little annoying to have
> > such backwards-compatibility baggage already present in
> > the shiny new 3.0 series. A little like finding a b
I'm seeing the following when trying to svn commit:
Transmitting file data ...Read from remote host svn.python.org: Operation
timed out
svn: Commit failed (details follow):
svn: Connection closed unexpectedly
...
That was with subversion 1.4.4; copying my changes to a different host with
subversi
> (1) Is it desirable to remove tp_compare entirely, instead of
> just renaming it?
No.
> (2) If so, for which Python version should that removal take place?
> 3.0.1? 3.1.0? 4.0?
If it is removed, it definitely shouldn't be removed in 3.0.1; that
would be a binary-incompatible change.
> (3) I
On Sat, Jan 31, 2009 at 3:07 PM, Mark Dickinson wrote:
> Once the cmp removal is complete, the type object's tp_compare
> slot will no longer be used. The current plan is to rename it to
> tp_reserved, change its type to (void *), and raise TypeError when
> initializing any type that attempts to
Here's a question (actually, three questions) for python-dev that
came up in the issue 1717 (removing cmp) discussion.
Once the cmp removal is complete, the type object's tp_compare
slot will no longer be used. The current plan is to rename it to
tp_reserved, change its type to (void *), and rais
> How about Friday February 13?
Fine with me (although next Friday (Feb 6) would work slightly better)
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman wrote:
> I am just replying to the end of this thread to throw in a reminder
> about my partial.skip patch, which allows the following usage:
>
> split_one = partial(str.split, partial.skip, 1)
>
> Not looking to say "mine is better", but if the ide
Guido van Rossum schrieb:
> Frankly, I don't really believe the users for whom those rules were
> created are using 3.0 yet. Instead, I expect there to be two types of
> users: people in the educational business who don't have a lot of
> bridges to burn and are eager to use the new features; and d
a Mercurial "super client" http://blog.red-bean.com/sussman/?p=116
Figured I would link to this for the people doing the HG investigation
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
2009/1/31 "Martin v. Löwis" :
>> Can you point me at specifics (bug reports or test cases)? I could see
>> if I can help in fixing things.
>
> See r69098.
Thanks. So 3.0.1 and later will be fine - my apologies, I hadn't quite
understood what you said.
Paul.
___
Begin forwarded message:
From: Ludvig Ericson
Date: January 31, 2009 16:43:50 GMT+01:00
To: Alexander Belopolsky
Subject: Re: [Python-Dev] Partial function application 'from the
right'
On Jan 31, 2009, at 04:02, Alexander Belopolsky wrote:
On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou
I have now upgraded subversion to 1.5.1 on svn.python.org.
Please let me know if you encounter problems.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 3:07 PM, Benjamin Peterson wrote:
On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon
wrote:
Great! Then should we start planning for 3.0.1 in terms of release
dates and what to have in the release so we can get this out the door
qu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 1:56 PM, Brett Cannon wrote:
On Fri, Jan 30, 2009 at 08:03, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote:
1. Barry, who is the release manager for 3.0.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 11:50 AM, Mark Dickinson wrote:
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw
wrote:
To clarify: cruft that should have been removed 3.0 is fine to
remove for
3.0.1, for some definition of "should have been".
Just to doubl
> Can you point me at specifics (bug reports or test cases)? I could see
> if I can help in fixing things.
See r69098.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
Martin v. Löwis wrote:
>> I can see how "svn resolved ." gets it right (now that I understand how
>> the conflict is being produced and then fixed automatically by svnmerge,
>> but not actually marked as resolved).
>>
>> I still don't understand how "svn revert ." can avoid losing the
>> metadata c
2009/1/31 "Martin v. Löwis" :
> Notice that bdist_wininst doesn't really work in 3.0. So you likely
> won't see many packages until 3.0.1 is released.
Ah, that might be an issue :-)
Can you point me at specifics (bug reports or test cases)? I could see
if I can help in fixing things.
Paul.
_
Just my 2 eurocents:
I think version numbers communicate a couple of things. One thing the
communicate is that if you go from x.y.0 to x.y.1 (or from x.y.34 to
x.y.35 for that matter) you signify that this is a bug fix release,
and that the risk of any of your stuff breaking is close to zero,
unle
32 matches
Mail list logo
