| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
simpler if we use fgetpos and fsetpos, rather than trying to mess with
platform-specific TELL64 alternatives.
Of course, this hasn't been tested on a 64-bit platform, so I may have
to withdraw this -- but I'm hopeful, and Trent Mick supports this
patch!
|
|
|
|
|
|
|
|
| |
faster than the other. Should be faster for Mark Favas's 254-character
mail log lines, and *is* 3-4% quicker for my test case with much shorter
lines (but they're typical of *my* text files, and I'm tired of optimizing
for everyone else at my expense <wink> -- in fact, the only one who loses
here is Guido ...).
|
|
|
|
| |
platforms. See NEWS for details.
|
|
|
|
| |
the xreadlines module and lets it do its thing.)
|
|
|
|
| |
a fallback for TELL64. Fixes SF Bug #128119.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Tim discovered another "bug" in my get_line() code: while the comments
said that n<0 was invalid, it was in fact still called with n<0 (when
PyFile_GetLine() was called with n<0). In that case fortunately
executed the same code as for n==0.
Changed the comment to admit this fact, and changed Tim's MS speed
hack code to use 'n <= 0' as the criteria for the speed hack.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
code duplication is to let us get away without a realloc whenever possible;
boosted the init buf size (the cutoff at which we *can* get away without
a realloc) from 100 to 200 so that more files can enjoy this boost; and
allowed other threads to run in all cases. The last two cost something,
but not significantly: in my fat test case, less than a 1% slowdown total.
Since my test case has a great many short lines, that's probably the worst
slowdown, too. While the logic barely changed, there were lots of edits.
This also gets rid of the reference to fp->_cnt, so the last platform
assumption being made here is that fgets doesn't overwrite bytes
capriciously (== beyond the terminating null byte it must write).
|
|
|
|
|
|
| |
variant that never needs to "search from the right".
Also fixed unlikely memory leak in get_line, if string size overflows INTMAX.
Also new std test test_bufio to make sure .readline() works.
|
|
|
|
|
|
| |
realized that this behavior is already present in PyFile_GetLine(),
which is the only place that needs it. A little refactoring of that
function made get_line_raw() redundant.
|
|
|
|
|
|
|
| |
- The raw_input() functionality is moved to a separate function.
- Drop GNU getline() in favor of getc_unlocked(), which exists on more
platforms (and is even a tad faster on my system).
|
|
|
|
| |
in one place.
|
|
|
|
| |
using GNU libc's getline()
|
| |
|
| |
|
|
|
|
|
| |
hack for TELL64()... Sounds like there's something else going on
really. Does anybody have a clue I can buy?
|
|
|
|
|
|
| |
Changes to error messages to increase consistency & clarity.
This (mostly) closes SourceForge patch #101839.
|
|
|
|
|
|
|
| |
Fix large file support for BeOS.
This closes SourceForge patch #101773. Refer to the patch discussion for
information on possible alternate fixes.
|
|
|
|
|
|
|
|
| |
Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.
This closes SourceForge patch #101659 and bug #115323.
|
|
|
|
|
| |
According to Justin Pettit, this also works on OpenBSD, so I've added
that symbol as well.
|
|
|
|
| |
This should match the situation in the 1.6b1 tree.
|
|
|
|
|
|
| |
Remove some of GCC's warning in -Wstrict-prototypes mode.
This closes SourceForge patch #101342.
|
| |
|
|
|
|
|
|
|
| |
file.writelines() now tries to emulate the behaviour of file.write()
as closely as possible. Due to the problems with releasing the
interpreter lock the solution isn't exactly optimal, but still better
than not supporting the file.write() semantics at all.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
change to regrtest.py to allow optional running of test_largefile ('cause it's
slow on Win64).
This closes patches:
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100510&group_id=5470
and
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100511&group_id=5470
|
|
|
|
| |
or .fileno() method
|
| |
|
| |
|
|
|
|
|
|
|
| |
Full_Name: Bastian Kleineidam
Version: 2.0b1 CVS 5.7.2000
OS: Debian Linux 2.2
Submission from: earth.cs.uni-sb.de (134.96.252.92)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The common technique for printing out a pointer has been to cast to a long
and use the "%lx" printf modifier. This is incorrect on Win64 where casting
to a long truncates the pointer. The "%p" formatter should be used instead.
The problem as stated by Tim:
> Unfortunately, the C committee refused to define what %p conversion "looks
> like" -- they explicitly allowed it to be implementation-defined. Older
> versions of Microsoft C even stuck a colon in the middle of the address (in
> the days of segment+offset addressing)!
The result is that the hex value of a pointer will maybe/maybe not have a 0x
prepended to it.
Notes on the patch:
There are two main classes of changes:
- in the various repr() functions that print out pointers
- debugging printf's in the various thread_*.h files (these are why the
patch is large)
Closes SourceForge patch #100505.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
|
|
|
|
|
|
| |
This (1) avoids thread unsafety whereby another thread could zap the
list while we were using it, and (2) now supports writing arbitrary
sequences of strings.
|
| |
|
|
|
|
| |
PyArg_ParseTuple() format string arguments as possible.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(This also redoes my previous patch, but better.)
|
|
|
|
|
| |
calls was used instead of a single PyArg_ParseTuple call with an
optional argument.
|
|
|
|
|
|
|
| |
buffer increment, and sometimes the new buffer size. Make it do what
its name says, and fix the one place where this matters to the caller.
Also add a comment explaining why we call lseek() and then ftell().
|
|
|
|
|
| |
was used so it's reflected in the IOError. Call
PyErr_SetFromErrnoWithFilename().
|
| |
|
|
|
|
| |
(Jack)
|
| |
|