-
Can't you get the server fixed?.
2009-11-03 11:58:26 UTC in Tcl
-
The observed behaviour may not be due to the server prepending lines to the header in response, it may be due to improper encoding or decoding of preceding content, or by incorrect calculation of content length. This is to be suspected because the received text is reported to be \n and not \r\n (which is the normal form EOL for headers.)
If the error is in content, not header, then 'fixing'...
2009-10-09 21:46:22 UTC in Tcl
-
My apologies, I have completely misstated the case. ws2 is on the machine, I misunderstood the nature of my problem. I've closed the error.
2009-09-21 00:42:05 UTC in CeGCC - Cross development for Pocket PC
-
To use sockets I have to link against libws2.a, which creates a dependency on ws2.dll. This isn't available on my test winmob6.1, and prevents the compiled program from loading.
Is there an alternative available? There seems to be a wsp.dll which ms documentation suggests provides the winsock2 api. Is this the relevant target?
I'd not have posted this as a bug, but I noticed a call for...
2009-09-20 22:49:25 UTC in CeGCC - Cross development for Pocket PC
-
After 8 hours of running on the wiki I have no reports of any problems. I conclude that the fix is in!
Thanks Andreas.
2009-07-29 08:34:35 UTC in Tcl
-
Seems to have fixed it! I constructed a test which sends the header to Wub then pauses before attempting to send the rest of the entity.
Ran it on the unpatched tclsh, and the same eof error was evident. Ran it on the patched tclsh, and the entity was correctly received. So I would say the bug is resolved - at least, I'm going to install this on the running wiki and observe.
As a...
2009-07-29 01:50:26 UTC in Tcl
-
I have updated the wiki's version of tcl to 8.6 HEAD. When I run the wiki, it behaves the same way (essentially, it resets the connection when it's been given a lot of data to read - more than will fit into a buffer.) I haven't been able to debug it now, though, I would suppose this is because the generation of debug narrative slow the server down to the extent that network interactions are...
2009-07-29 00:40:03 UTC in Tcl
-
Clearly the test isn't a good test of what I'm observing. Please see enclosed Chan.tcl for the code which produces the events I observed.
Unlike the test, it includes a [watch] method, and it only forwards events to Tcl when tcl has registered interest in that event, and it nonetheless behaves exactly as the original test script behaves. Moreover, when the refchan is substituted for a...
2009-07-28 04:03:45 UTC in Tcl
-
The testRefchan.tcl script is not wild caught, it is crafted to illustrate and test for the problem I observed. My assertion that I am not posting an event pertains to the observed problem, which I have annotated in the other attachment, not to the test script, which was written after I'd reported this bug.
It seems to me that either there should never be a read invoked in non-blocking mode...
2009-07-27 21:28:10 UTC in Tcl
-
FWIW: I reviewed it, loaded it, compiled it, have run it with a simple test (open and close a bunch of files, observe that the filename changes as expected, and that the various std* files are still there.)
Looks fine, seems efficacious.
for {set i 1} {$i < 100} {incr i} {
set fd [open [info script] r]
puts "$fd [chan names]"
close $fd
}.
2009-07-26 00:03:16 UTC in Tcl
