| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
longer a whitespace, but for Tcl it still is.
"NEL/Next Line" (U+0085) should have been a Unicode whitespace, but never was in Tcl. This is corrected in Tcl 8.6, but for legacy reasons not in Tcl 8.5.
Update documentation accordingly, and extend test-cases for Unicode 7 compliance.
|
|
|
|
|
| |
to the Tcl_*SetVar*() family of routines to cover the missing case where
the flags value of TCL_APPEND_VALUE is passed in alone.
*** POTENTIAL INCOMAPTIBILITY***
|
| |
|
| |
|
|
|
| |
a nonblocking channel is blocked.
|
| |
|
| |
|
|
|
|
|
| |
schedules cause a ForwardingResult to remain on the forwardList after
it has been processed (IORChan is the origin of the code in IORTrans).
|
|
|
|
|
|
|
| |
get it right on the next pass, don't forget the TCL_UTF_MAX padding
demanded by Tcl_ExternalToUtf(). (Thanks for finding that, aku!)
Fix the factorPtr management. It was just totaly wrong. The factor should
be a ratio of the record of bytes read to the record of chars read.
With those fixes, new test io-12.6 covers the "too many chars" code.
|
|
|
|
|
| |
which is its only caller. We need to discard the curOutPtr buffer as well,
and not count on another pass through the loop to attempt to flush it
(and raise the same failure again?).
|
|\ |
|
| |
| |
| |
| | |
Several socket-14.* tests failing there, and those that pass are very slow
about it. Firewall or poor networking configuration may be playing a role.
|
| |
| |
| | |
a whole raft of test failures. WIP.
|
| |\
| | |
| | |
| | | |
PipeWatchProc(). When we are interested in both readable and writable events of a command pipeline channel, we only want the readable from the read end of the pipe, and the writable from the write end of the pipe.
|
| |/
|/|
| |
| |
| | |
PipeWatchProc(). When we are interested in both readable and writable
events of a command pipeline channel, we only want the readable from
the read end of the pipe, and the writable from the write end of the pipe.
|
| |\
| |/
|/|
| | |
the flag BUFFER_READY.
|
| |\
| | |
| | |
| | |
| | | |
platforms into the trunk. For details see the merged revision and its
ancestor.
|
| | | |
|
| | | | |
| | \ | |
| |\ \ \
| | | | |
| | | | |
| | | | | |
particular not allowing them to leak between multiple layers of a stacked channel. Much common code refactored into ChanRead().
|
| | | | | |
|
| | | | |
| | | | |
| | | | | |
direct clearing of CHANNEL_EOF flag.
|
| | | | | |
|
| | | | | |
|
| | |\ \ \ |
|
| | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
began repairing some of the logic about them. Tests iogt-2.* now fail because
they've been crafted as experiments recording the fine detail of reflected
channel driver calls, and fixing the management of channel flags is changing
that. zlib-8.5 also needed adjustment to reflect that an EOF set must come
with an empty string read when flags are functioning properly.
|
| |\ \ \ \ \ \
| | |_|_|/ / /
| |/| | | | |
| | | | | | | |
***POTENTIAL INCOMPATIBILITY***
Changes results of both [lsearch -integer] and [lsort -integer].
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
"lsearch -sorted -integer" on 64bit system
|
| |\ \ \ \ \ \
| | |_|/ / / /
| |/| | | | | |
|
| | |/ / / /
| |/| | | |
| | | | | | |
passed to the read method of the channel transformation command. Save a copy.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
of a chain of compileable ensembles.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
segfault trying to use a deleted interp. Fixed.
|
| | \ \ \ \ \ | |
| | \ \ \ \ \ | |
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Large overhaul of I/O read operations
- Protects integer overflow of buffers, reusing append machinery
- Forces -buffersize changes to take place when commanded
- Uses assertions to simplify code in "can't happen" situations
- Eliminated duplication of -translation processing
- Fixes bugs io-35.18b and io-35.20
|
| | |\ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | | |
|
| | | | | | | | | |
|
| | |\ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Back in 2011, Bugs 3384654 and 3393276 first noticed troubles with
ChannelBuffer sharing, but the magnitude of the problem wasn't truly
grasped. A fix was applied that turned out to be more of a band-aid
workaround. Now that the real fix is in place, the band-aid is actually
preventing it working properly in thie case. Rip it off!
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
memory leaks.
|
| | |\ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | | |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This is not the proper final answer. ChannelBuffer management in
FlushChannel is simply not robustly correct yet.
|
| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
it was in 8.6.0/8.6.1.
|
| | | | |\ \ \ \ \ \ \
| | |_|_|/ / / / / / /
| |/| | | | | | | | | |
|
| | | | |\ \ \ \ \ \ \ |
|
| | | | |\ \ \ \ \ \ \ \ |
|
| | | | |\ \ \ \ \ \ \ \ \ |
|
| | | | |\ \ \ \ \ \ \ \ \ \ |
|
| | | | |\ \ \ \ \ \ \ \ \ \ \ |
|