I don't understand, this patch doesn't cause any regressions on my machine using the latest git (none of them do). The patch[6/10] is (nearly) identical to the patch I submitted earlier (which did not cause regressions). The only difference is in the hash. The next patch[7/10] changes zero functionality because the function that is implemented in [7/10] is unused at this point in time and patch [7/10] passes the conformance tests.
scott@SocialSycotic:~/programming/wine/wine/patch$ diff 9.7.2/0006-Implements-sock_close_handle.txt 9-4.7/0006-Implements-sock_close_handle.txt 1c1 < From 40ae4098b66df1cb30dc77368ccfc1c495bb0b68 Mon Sep 17 00:00:00 2001 ---
From d1e0353beb8490bbd9b8818523c6d79daae510ff Mon Sep 17 00:00:00 2001
scott@SocialSycotic:~/programming/wine/wine/patch$
Using only patches [1/10 - 6/10] (The patches applied by patchwatcher when it displays the failure):
../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so stream.c && touch stream.ok
As for the conformance test. I will look into how I have to change the sock.c test loop.
~Scott
On Sun, Sep 7, 2008 at 9:14 AM, Dan Kegel dank@kegel.com wrote:
This is interesting. It does seem like that patch changed an error code and added a new failure to urlmon:protocol.c. Was this just a case of "I should have combined two of the patches in the series"?
BTW, if you end up resending the patch series again, you might send the test case first (with todo_wine's), and then after the errors are fixed, remove the todo_wine's.
On Sat, Sep 6, 2008 at 4:42 PM, Patchwatcher patchwatcher@kegel.com wrote:
Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "[6/10 AcceptEx] Implements sock_close_handle" Result: the patch failed regression tests.
You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/1162.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/1162.txt See http://kegel.com/wine/patchwatcher/results for more info.
With regards to the info with patch [7/10] I see that it still fails on patchwatcher, but patchwatcher ignores those. Does this mean that it was causing this regression on patchwatcher before and that i never noticed them because of a different regression? They still don't cause regressions on my system however.
~Scott
On Sun, Sep 7, 2008 at 3:49 PM, Scott Lindeneau slindeneau@gmail.com wrote:
I don't understand, this patch doesn't cause any regressions on my machine using the latest git (none of them do). The patch[6/10] is (nearly) identical to the patch I submitted earlier (which did not cause regressions). The only difference is in the hash. The next patch[7/10] changes zero functionality because the function that is implemented in [7/10] is unused at this point in time and patch [7/10] passes the conformance tests.
scott@SocialSycotic:~/programming/wine/wine/patch$ diff 9.7.2/0006-Implements-sock_close_handle.txt 9-4.7/0006-Implements-sock_close_handle.txt 1c1
< From 40ae4098b66df1cb30dc77368ccfc1c495bb0b68 Mon Sep 17 00:00:00 2001
From d1e0353beb8490bbd9b8818523c6d79daae510ff Mon Sep 17 00:00:00 2001
scott@SocialSycotic:~/programming/wine/wine/patch$
Using only patches [1/10 - 6/10] (The patches applied by patchwatcher when it displays the failure):
../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so stream.c && touch stream.ok
As for the conformance test. I will look into how I have to change the sock.c test loop.
~Scott
On Sun, Sep 7, 2008 at 9:14 AM, Dan Kegel dank@kegel.com wrote:
This is interesting. It does seem like that patch changed an error code and added a new failure to urlmon:protocol.c. Was this just a case of "I should have combined two of the patches in the series"?
BTW, if you end up resending the patch series again, you might send the test case first (with todo_wine's), and then after the errors are fixed, remove the todo_wine's.
On Sat, Sep 6, 2008 at 4:42 PM, Patchwatcher patchwatcher@kegel.com wrote:
Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "[6/10 AcceptEx] Implements sock_close_handle" Result: the patch failed regression tests.
You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/1162.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/1162.txt See http://kegel.com/wine/patchwatcher/results for more info.
That test almost always fails, but you managed to get it to fail in two new ways. patchwatcher has a novelty filter, and ignores known failure messages. Since your code triggered new,different failure messages, it got flagged. It's possible that the new failure mode is semirare, so you might have to run the test over and over again in a loop for a while to catch it. - Dan
On Sun, Sep 7, 2008 at 12:04 AM, Scott Lindeneau slindeneau@gmail.com wrote:
With regards to the info with patch [7/10] I see that it still fails on patchwatcher, but patchwatcher ignores those. Does this mean that it was causing this regression on patchwatcher before and that i never noticed them because of a different regression? They still don't cause regressions on my system however.
~Scott
On Sun, Sep 7, 2008 at 3:49 PM, Scott Lindeneau slindeneau@gmail.com wrote:
I don't understand, this patch doesn't cause any regressions on my machine using the latest git (none of them do). The patch[6/10] is (nearly) identical to the patch I submitted earlier (which did not cause regressions). The only difference is in the hash. The next patch[7/10] changes zero functionality because the function that is implemented in [7/10] is unused at this point in time and patch [7/10] passes the conformance tests.
scott@SocialSycotic:~/programming/wine/wine/patch$ diff 9.7.2/0006-Implements-sock_close_handle.txt 9-4.7/0006-Implements-sock_close_handle.txt 1c1
< From 40ae4098b66df1cb30dc77368ccfc1c495bb0b68 Mon Sep 17 00:00:00 2001
From d1e0353beb8490bbd9b8818523c6d79daae510ff Mon Sep 17 00:00:00 2001
scott@SocialSycotic:~/programming/wine/wine/patch$
Using only patches [1/10 - 6/10] (The patches applied by patchwatcher when it displays the failure):
../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB fixme:wininet:InternetLockRequestFile STUB ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so stream.c && touch stream.ok
As for the conformance test. I will look into how I have to change the sock.c test loop.
~Scott
On Sun, Sep 7, 2008 at 9:14 AM, Dan Kegel dank@kegel.com wrote:
This is interesting. It does seem like that patch changed an error code and added a new failure to urlmon:protocol.c. Was this just a case of "I should have combined two of the patches in the series"?
BTW, if you end up resending the patch series again, you might send the test case first (with todo_wine's), and then after the errors are fixed, remove the todo_wine's.
On Sat, Sep 6, 2008 at 4:42 PM, Patchwatcher patchwatcher@kegel.com wrote:
Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "[6/10 AcceptEx] Implements sock_close_handle" Result: the patch failed regression tests.
You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/1162.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/1162.txt See http://kegel.com/wine/patchwatcher/results for more info.
-
Dan Kegel -
Scott Lindeneau