| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
M PyShell.py
M rpc.py
M run.py
|
| |
|
| |
|
|
|
|
| |
having it there causes the line to wrap.
|
| |
|
|
|
|
|
|
|
|
| |
on Windows. The test_sequence() ERROR is easily repaired if we're
willing to add an os.unlink() line to mhlib's updateline(). The
test_listfolders FAIL I gave up on -- I don't remember enough about Unix
link esoterica to recall why a link count of 2 is something a well-
written program should be keenly interested in <wink>.
|
| |
|
| |
|
| |
|
|
|
|
| |
You'll still have to manually edit it, though...
|
| |
|
|
|
|
|
|
|
|
| |
Builder carbon NIB files from Python. As-is, I may need to twiddle a few
things as he donated this long ago.
Donovan is now one of the four people in the world who know how to drive
bgen!
|
|
|
|
|
|
|
| |
- steer people away from installing with sudo
- warn that fink-installed software may cause trouble
- explain why you might want a framework build and point people to
Mac/OSX/README.
|
|
|
|
| |
people may have (fink, gnu).
|
|
|
|
| |
see sf #506436
|
|
|
|
| |
be longer than the old string.
|
| |
|
|
|
|
| |
this was trying to assert, but the name it referenced didn't exist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly when no comparison function is specified. This saves a layer
of function call on every compare then. Measured speedups:
i 2**i *sort \sort /sort 3sort +sort %sort ~sort =sort !sort
15 32768 12.5% 0.0% 0.0% 100.0% 0.0% 50.0% 100.0% 100.0% -50.0%
16 65536 8.7% 0.0% 0.0% 0.0% 0.0% 0.0% 12.5% 0.0% 0.0%
17 131072 8.0% 25.0% 0.0% 25.0% 0.0% 14.3% 5.9% 0.0% 0.0%
18 262144 6.3% -10.0% 12.5% 11.1% 0.0% 6.3% 5.6% 12.5% 0.0%
19 524288 5.3% 5.9% 0.0% 5.6% 0.0% 5.9% 5.4% 0.0% 2.9%
20 1048576 5.3% 2.9% 2.9% 5.1% 2.8% 1.3% 5.9% 2.9% 4.2%
The best indicators are those that take significant time (larger i), and
where sort doesn't do very few compares (so *sort and ~sort benefit most
reliably). The large numbers are due to roundoff noise combined with
platform variability; e.g., the 14.3% speedup for %sort at i=17 reflects
a printed elapsed time of 0.18 seconds falling to 0.17, but a change in
the last digit isn't really meaningful (indeed, if it really took 0.175
seconds, one electron having a lazy nanosecond could shift it to either
value <wink>). Similarly the 25% at 3sort i=17 was a meaningless change
from 0.05 to 0.04. However, almost all the "meaningless changes" were
in the same direction, which is good. The before-and-after times for
*sort are clearest:
before after
0.18 0.16
0.25 0.23
0.54 0.50
1.18 1.11
2.57 2.44
5.58 5.30
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
2.2 bugfix candidate (may cause RuntimeError for applications that
currently work fine).
|
| |
|
|
|
|
|
| |
Piers obviously couldn't have passed on any platform. Fiddling it so it
works (for a meaning of "works" no stronger than "doesn't fail" <wink>).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the parser and compiler to use PyMalloc.
Only the files implementing processes that will request memory
allocations small enough for PyMalloc to be a win have been
changed, which are:-
- Python/compile.c
- Parser/acceler.c
- Parser/node.c
- Parser/parsetok.c
This augments the aggressive overallocation strategy implemented by
Tim Peters in PyNode_AddChild() [Parser/node.c], in reducing the
impact of platform malloc()/realloc()/free() corner case behaviour.
Such corner cases are known to be triggered by test_longexp and
test_import.
Jeremy Hylton, in accepting this patch, recommended this as a
bugfix candidate for 2.2. While the changes to Python/compile.c
and Parser/node.c backport easily (and could go in), the changes
to Parser/acceler.c and Parser/parsetok.c require other not
insignificant changes as a result of the differences in the memory
APIs between 2.3 and 2.2, which I'm not in a position to work
through at the moment. This is a pity, as the Parser/parsetok.c
changes are the most important after the Parser/node.c changes, due
to the size of the memory requests involved and their frequency.
|
|
|
|
| |
- implement viable library search routine for EMX
|
| |
|
| |
|
|
|
|
| |
Fixes #589429.
|
| |
|
|
|
|
| |
elements.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
[ 589427 ] standard include paths on command line
_ssl still got /usr/include on the command line.
|
| |
|
|
|
|
|
| |
currently-smallest value, and add item, in one gulp. See the second
N-Best algorithm in the test suite for a natural use.
|
|
|
|
|
|
|
|
|
|
|
|
| |
substantially fewer array-element compares. This is best practice as of
Kntuh Volume 3 Ed 2, and the code is actually simpler this way (although
the key idea may be counter-intuitive at first glance! breaking out of
a loop early loses when it costs more to try to get out early than getting
out early saves).
Also added a comment block explaining the difference and giving some real
counts; demonstrating that heapify() is more efficient than repeated
heappush(); and emphasizing the obvious point thatlist.sort() is more
efficient if what you really want to do is sort.
|
|
|
|
| |
The PyArg_ParseTuple() error string still said "msort". Changed to "sort".
|
| |
|
|
|
|
|
| |
in the test file. I have docs for heapq.heapify ready to check in, but
Jack appears to have left behind a stale lock in the Doc/lib directory.
|
| |
|
| |
|
| |
|