andreas_kupries committed patchset 3153 of module tcllib to the tcllib CVS repository, changing 4 files.
2012-05-28 13:30:32 PDT in tcllib
Thank you.
2012-05-22 09:12:15 PDT in Tcl
Don, attached is a possible fix for the issue, protecting the thread specific parts of ChanPostEventObjCmd() against use when building without threads.
2012-05-22 08:46:41 PDT in Tcl
Committed change to branch bug-3525907, rev. 5ffc93920daf1775e96132f6fd826e735d84028b and descendants.
2012-05-17 14:47:42 PDT in Tcl
The attached patch seems to fix the issues, and passes the testsuite for me. Please test.
2012-05-17 14:31:13 PDT in Tcl
Moving the chan configure $chan -flush sync before the puts of the first message (still after the zlib transform is pushed) gets us both messages on the receiver side. I.e. no loss of bytes anymore. It still receives them only when the channel is closed. I suspect that the "-flush sync" (is intended to) activate(s) the special zlib flush code forcing out the data buffered...
2012-05-16 11:21:30 PDT in Tcl
Reading through the patch is the priorPtr dance required ? Given that esPtr->nextr was saved to "esNextPtr" in the patch, could we not simply use this saved pointer get to the next element of the list ? I.e. use esPtr = esNextPtr in the for (....) clause ? Hm ... Reading more of the comments you are saying that not only esPtr might have been freed, leaving its pointers...
2012-05-16 10:19:24 PDT in Expect
andreas_kupries committed patchset 3152 of module tcllib to the tcllib CVS repository, changing 7 files.
2012-05-11 14:45:30 PDT in tcllib
andreas_kupries committed patchset 3151 of module tcllib to the tcllib CVS repository, changing 4 files.
2012-05-11 13:54:46 PDT in tcllib
22:28:42 [360eb75e01] *CURRENT* Undone part of change [32d93a8414], keeping [chan postevent] synchronous for owner == handler. (user: andreask tags: trunk)
2012-05-09 15:29:02 PDT in Tcl