I don't know whether anybody has done this before,
but I just tried to run cvs2svn on the Python repository.
The conversion took 7 hours, and the result is now
available at
http://www.dcl.hpi.uni-potsdam.de/python/branches/
Because of the load that the conversion produces on
the machine, I cannot r
On 06 March 2005, "Martin v. Löwis" said:
> - It has imported the CVSROOT directory as well. I don't
> know whether this is deliberate/useful.
This is just an artifact of how SourceForge CVS repositories are
organized. When I converted Optik's CVS to Subversion, I just did this:
cvs2svn -s /
Tim Peters wrote:
Florent's DeadlockDebugger in turn builds on an external C threadframe
module:
http://www.majid.info/mylos/stories/2004/06/10/threadframe.html
Folding the functionality of that (or similar functionality) into the
core would, IMO, be a valuable addition for 2.5, and would mak
I've LaTeX'ified the proposed documentation for __new__() and uploaded
the patch to SF:
http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=124422&aid=1156412
Someone who really understands new-style classes should give this a
look. (Guido?) I've tested that Python
Anyone else seeing test failures on the 2.4 branch right now? I started
seeing this failure:
test_warnings
test test_warnings failed -- Traceback (most recent call last):
File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in
test_warn_specific_category
warnings.warn
Greg Ward wrote:
Anyone else seeing test failures on the 2.4 branch right now? I started
seeing this failure:
Both are passing for me on OS X 10.3.8 w/ a fresh cvs up as of 15:41 PT. But I
am getting failures for test_socket (ignoring the usual test__locale failure on
OS X):
==
On 06 March 2005, I said:
> Anyone else seeing test failures on the 2.4 branch right now? I started
> seeing this failure:
>
> test_warnings
> test test_warnings failed -- Traceback (most recent call last):
> File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in
> test_wa
On 06 March 2005, I said:
> OK, I've narrowed it down: test_warnings fails when run after
> test_descr:
Raymond Hettinger, step right up! You're the next contestant on The
Tests Are Failing! Your recent checkins include...
working file: Lib/test/test_descr.py; sticky tag: release24-maint
re
Greg Ward wrote:
[SNIP]
A-ha! I get it. There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters. This patch fixes both:
"""
--- Lib/test/test_descr.py 4 Mar 2005 04:47:04 - 1.202.2.2
+++ Lib/test/test_descr.py
Brett C. wrote:
Greg Ward wrote:
[SNIP]
A-ha! I get it. There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters. This patch fixes both:
"""
--- Lib/test/test_descr.py 4 Mar 2005 04:47:04 - 1.202.2.2
+++ Lib/test
On 06 March 2005, I said:
> I'll check this in and merge to the trunk once I see all tests passing.
Checked in on 2.4 branch. Not merged to trunk since Raymond hasn't
merged his stuff to the trunk yet.
Greg
--
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I r
Somewhat slower, but here are two more threads from me (email is mostly a
weekday thing for me, and the last few days were full of sun, wine, food and
jazz. Well, and work. But working with sun, wine, food and jazz, so it's
hard to complain too much). Feedback will not be ignored :)
---
At 02:42 PM 3/6/05 -0800, Fazal Majid wrote:
I suspect integrating this feature (let's call it sys._current_frames()
for the sake of argument, although it probably belongs in the threads
module) in the core is not going to be quite as trivial as you say, as
there are potential memory leaks. If t
> I am not expecting the candidates for taking of the Summaries
> to write stuff for this one (although I wouldn't mind it =).
In penance for being late with the other ones, here are a summaries for a
couple of skipped threads for this period:
---
Slow unit t
[Phillip J. Eby]
> What would you suggest calling it? sys._current_frames(), returning a
> dictionary?
I don't fight about names -- anything that doesn't make Guido puke
works . I channel that sys._current_frames() would be fine. A
dict mapping thread id to current thread frame would be lovely!
[Fazal Majid]
> Since I started this, I might as well finish it. I do have some Python
> developer experience (hey, I even voted for comp.lang.python back
> when...) but not in the core interpreter itself.
Cool! WRT your current module, it would need changes to follow
Python's C coding style, to
Greg,
Um, unless I misread this, you added new attributes to the ossaudiodev objects
in the 2.4 branch. Please don't do this - this is a new feature, and suddenly
people who want to use those new attributes have to either test for version
>= 2.4.1, or else do a hasattr test. Please see the bugfix
17 matches
Mail list logo
