Am Sonntag, 8. September 2013, 11:32:26 schrieb Francois Gouget:
On Thu, 5 Sep 2013, Wolfgang Walter wrote:
[...]
To see that my later patches are needed you must modify the test a little
bit:
- dlls/kernel32/tests/comm.c.old 2013-09-05 13:40:10.275757373 +0200
+++
On Thu, 5 Sep 2013, Wolfgang Walter wrote:
[...]
To see that my later patches are needed you must modify the test a little bit:
- dlls/kernel32/tests/comm.c.old 2013-09-05 13:40:10.275757373 +0200
+++ dlls/kernel32/tests/comm.c 2013-09-05 13:40:06.779074398 +0200
@@ -844,6 +844,8 @@
On Thursday 05 September 2013 10:37:22 you wrote:
Wolfgang Walter w...@stwm.de wrote:
+if (res || (!res GetLastError() == ERROR_IO_PENDING))
+/* if data has been sent: wait for termination */
+Sleep(timeout);
I don't see such a problem with real COM-port and
Wolfgang Walter w...@stwm.de wrote:
+if (res || (!res GetLastError() == ERROR_IO_PENDING))
+/* if data has been sent: wait for termination */
+Sleep(timeout);
I don't see such a problem with real COM-port and serial-USB cable
under Windows or Linux here and
Am Donnerstag, 5. September 2013, 17:54:58 schrieb Dmitry Timoshkov:
Wolfgang Walter w...@stwm.de wrote:
+if (res || (!res GetLastError() == ERROR_IO_PENDING))
+/* if data has been sent: wait for termination */
+Sleep(timeout);
I don't see such a problem
Wolfgang Walter w...@stwm.de wrote:
+if (res || (!res GetLastError() == ERROR_IO_PENDING))
+/* if data has been sent: wait for termination */
+Sleep(timeout);
I don't see such a problem with real COM-port and serial-USB cable
under Windows or Linux
Am Donnerstag, 5. September 2013, 18:55:55 schrieben Sie:
Wolfgang Walter w...@stwm.de wrote:
+if (res || (!res GetLastError() == ERROR_IO_PENDING))
+/* if data has been sent: wait for termination */
+Sleep(timeout);
I don't see such a problem
Wolfgang Walter w...@stwm.de wrote:
This is not a work around.
todo_wine will not magically undo sending the bytes.
Please explain why you think that there will be now pending
bytes in the tx buffer if the tests fails.
And why it does not make the next tests fail even if wine would
Am Donnerstag, 5. September 2013, 19:40:13 schrieb Dmitry Timoshkov:
Wolfgang Walter w...@stwm.de wrote:
This is not a work around.
todo_wine will not magically undo sending the bytes.
Please explain why you think that there will be now pending
bytes in the tx buffer if the tests
Wolfgang Walter w...@stwm.de wrote:
Does 'make test' pass without failures for you?
Without patch 1/2 and 2/2 I get for
$ ../../../tools/runtest -P wine -M kernel32.dll -T ../../.. -q -p
kernel32_test.exe.so comm.c
fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented
Am Donnerstag, 5. September 2013, 21:12:37 schrieb Dmitry Timoshkov:
Wolfgang Walter w...@stwm.de wrote:
Does 'make test' pass without failures for you?
Without patch 1/2 and 2/2 I get for
$ ../../../tools/runtest -P wine -M kernel32.dll -T ../../.. -q -p
kernel32_test.exe.so
Wolfgang Walter w...@stwm.de wrote:
With my patches 1/2 and 2/2 I get:
fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped
0x10ee8ec):
stub wine: configuration in '/home/walterw/.wine' has been updated.
fixme:comm:set_queue_size insize 1024 outsize 1024
Wolfgang Walter w...@stwm.de wrote:
With my patches 1/2 and 2/2 I get:
fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped 0x10ee8ec):
stub wine: configuration in '/home/walterw/.wine' has been updated.
fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented
On 05 Sep 2013, at 16:32, Dmitry Timoshkov wrote:
The tests must pass under Wine without any additional fixes as they do
currently under Windows. If you add some code to the tests which suddenly
makes them pass under Wine - that's not a fix, Wine implementation should
be fixed instead.
What
Wolfgang Walter w...@stwm.de wrote:
No, the source of the failures is still there.
What do you mean with that? The tests indeed do succeed now and there is a
reason they do: when you call WaitCommEvent() while the tx buffer is not
empty
yet the wine code will detect that
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
The tests must pass under Wine without any additional fixes as they do
currently under Windows. If you add some code to the tests which suddenly
makes them pass under Wine - that's not a fix, Wine implementation should
be fixed instead.
What
Am Donnerstag, 5. September 2013, 23:58:57 schrieb Dmitry Timoshkov:
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
The tests must pass under Wine without any additional fixes as they do
currently under Windows. If you add some code to the tests which
suddenly
makes them pass under Wine
Am Donnerstag, 5. September 2013, 23:32:00 schrieben Sie:
Wolfgang Walter w...@stwm.de wrote:
With my patches 1/2 and 2/2 I get:
fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped
0x10ee8ec):
stub wine: configuration in '/home/walterw/.wine' has been
On 05 Sep 2013, at 16:58, Dmitry Timoshkov wrote:
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
So either
* you add code in between that resets the state so that test2 can be run
independently of whether test1 failed (as Wolfgang proposes), or
* you put the tests in completely different
Wolfgang Walter w...@stwm.de wrote:
+if (res || (!res GetLastError() == ERROR_IO_PENDING))
+/* if data has been sent: wait for termination */
+Sleep(timeout);
I don't see such a problem with real COM-port and serial-USB cable
under Windows or Linux here and under testbot
20 matches
Mail list logo
