August 2007 - Wine-Devel - list.winehq.org

Re: [patch] Garbage code in text string display

by James Hawkins

On 8/19/07, Guan Xin <guanx.bac(a)gmail.com> wrote: > I have submitted no patch after looking at Windows source code. > The original submission certainly introduced to WINE nothing but a bug. > I was later forced to prove this bug is necessary. > It doesn't matter when you looked at the code versus when you submitted the patch. You prove a 'bug' is necessary by writing test cases. Also, please bottom-post in this mailing list. -- James Hawkins

Aug. 20, 2007

Re: [Winetest RFI] What do you want out of the test suite?

by Paul Vriens

Paul Vriens wrote: > Wagner Ferenc wrote: >> Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >> >>> I've been playing a bit with have the 'todo_<platform>' on the page. >>> In theory >>> it's possible that there are todo_<platform>'s that why I don't refer >>> to todo_wine. >>> >>> On http://www.xs4all.nl/~pvriens/200708181000_orig/ you can see the >>> current >>> situation for some random test results. >>> >>> On http://www.xs4all.nl/~pvriens/200708181000_with_todo/ I've added a >>> column >>> with todo's if one or more tests have a todo_item. This todo columns >>> will only >>> be present in the main summary and shows the maximum number of todo's >>> for that >>> test for that platform. >>> >>> I've tried adding the todo information to the current table cells but >>> didn't >>> find a satisfactory (that is nice looking) way. This is especially >>> true for >>> tests that also have a skip. >> >> Hi Paul, >> >> Why not introduce something like >> >> .todo_pass { >> background-color: #60ff60; >> border-right-style: solid; >> border-left-style: solid; >> border-width: thick; >> border-left-color: #ffffff; >> border-right-color: #60ff60; >> } >> >> That way todo_wine needn't be special in any way, and this notation >> also carries over for the individual test results (which should be the >> same, but some more visualization can't hurt). In the group overview >> the tooltip could also be extended by this information. >> >> Unless you can use some clever inheritance (cascading), you'll >> have to introduce all of .todo_skip_pass, .todo_mixed, etc. but that's >> manageable. >> >> I chose white border color in the above example, as I couldn't come up >> with anything better. Besides clashing with the textual fields (., >> crash, timeout, etc.) it's not bad in my opinion. We could as well >> live with it. > > Hi Feri, > > It will not clash btw as failed/crash/timeout tests will not have todo's > (they are catched already in gather). > > It will probably boil down to what people prefer. I'll have a go at your > idea (I've played already with the same idea as said, but didn't liked > the results then) and post another link. Then it will come down to > voting :-) > > Cheers, > > Paul. > OK, I gave it a try. http://www.xs4all.nl/~pvriens/200708181000_with_todo_white_border/ shows a white border on the left side but can hardly be noticed I think. http://www.xs4all.nl/~pvriens/200708181000_with_todo_yellow_border/ shows a yellow border on the left which is a bit better (again I think). http://www.xs4all.nl/~pvriens/200708181000_with_todo_yellow_border_and_grou… is the same but also shows that are are todo's for a group in the summary. (The yellow border will clash with the mixed results). Let me know your thoughts on this. Cheers, Paul.

Aug. 20, 2007

Re: [Winetest RFI] What do you want out of the test suite?

by Paul Vriens

Wagner Ferenc wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> I've been playing a bit with have the 'todo_<platform>' on the page. In theory >> it's possible that there are todo_<platform>'s that why I don't refer to todo_wine. >> >> On http://www.xs4all.nl/~pvriens/200708181000_orig/ you can see the current >> situation for some random test results. >> >> On http://www.xs4all.nl/~pvriens/200708181000_with_todo/ I've added a column >> with todo's if one or more tests have a todo_item. This todo columns will only >> be present in the main summary and shows the maximum number of todo's for that >> test for that platform. >> >> I've tried adding the todo information to the current table cells but didn't >> find a satisfactory (that is nice looking) way. This is especially true for >> tests that also have a skip. > > Hi Paul, > > Why not introduce something like > > .todo_pass { > background-color: #60ff60; > border-right-style: solid; > border-left-style: solid; > border-width: thick; > border-left-color: #ffffff; > border-right-color: #60ff60; > } > > That way todo_wine needn't be special in any way, and this notation > also carries over for the individual test results (which should be the > same, but some more visualization can't hurt). In the group overview > the tooltip could also be extended by this information. > > Unless you can use some clever inheritance (cascading), you'll > have to introduce all of .todo_skip_pass, .todo_mixed, etc. but that's > manageable. > > I chose white border color in the above example, as I couldn't come up > with anything better. Besides clashing with the textual fields (., > crash, timeout, etc.) it's not bad in my opinion. We could as well > live with it. Hi Feri, It will not clash btw as failed/crash/timeout tests will not have todo's (they are catched already in gather). It will probably boil down to what people prefer. I'll have a go at your idea (I've played already with the same idea as said, but didn't liked the results then) and post another link. Then it will come down to voting :-) Cheers, Paul.

Aug. 20, 2007

Re: Dyne:bolic binary module

by Robert Shearman

Robert Shoemaker wrote: > I was wondering what the steps would be to put my binary build for the > i686 Dyne:bolic distro on the releases page, it was no small task > getting it to compile. Since the code hasn't been reviewed yet, I think this should be a developer only thing. If the performance improvement is big enough then you should get enough of a userbase to fix/document compile issues. -- Rob Shearman

Aug. 20, 2007

Re: [Winetest RFI] What do you want out of the test suite?

by Wagner Ferenc

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > I've been playing a bit with have the 'todo_<platform>' on the page. In theory > it's possible that there are todo_<platform>'s that why I don't refer to todo_wine. > > On http://www.xs4all.nl/~pvriens/200708181000_orig/ you can see the current > situation for some random test results. > > On http://www.xs4all.nl/~pvriens/200708181000_with_todo/ I've added a column > with todo's if one or more tests have a todo_item. This todo columns will only > be present in the main summary and shows the maximum number of todo's for that > test for that platform. > > I've tried adding the todo information to the current table cells but didn't > find a satisfactory (that is nice looking) way. This is especially true for > tests that also have a skip. Hi Paul, Why not introduce something like .todo_pass { background-color: #60ff60; border-right-style: solid; border-left-style: solid; border-width: thick; border-left-color: #ffffff; border-right-color: #60ff60; } That way todo_wine needn't be special in any way, and this notation also carries over for the individual test results (which should be the same, but some more visualization can't hurt). In the group overview the tooltip could also be extended by this information. Unless you can use some clever inheritance (cascading), you'll have to introduce all of .todo_skip_pass, .todo_mixed, etc. but that's manageable. I chose white border color in the above example, as I couldn't come up with anything better. Besides clashing with the textual fields (., crash, timeout, etc.) it's not bad in my opinion. We could as well live with it. -- Cheers, Feri.

Aug. 20, 2007

Re: [PATCH try2 2/5] wininet: Free handle structs in WININET_Release.

by Robert Shearman

Misha Koshelev wrote: > This is necessary so that we send the INTERNET_STATUS_HANDLE_CLOSING before, for example > INTERNET_STATUS_CLOSE_CONNECTION gets sent from HTTP_CloseConnection in HTTP_CloseHTTPRequestHandle. > This can be tested on native/with native wininet on wine because although we do not send > INTERNET_STATUS_CLOSE_CONNECTION correctly when the data is finished reading on wine as native > does, if we simply don't read all the data (or any data, changing the while TRUE's to while FALSE's > in the InternetReadFiel_test for example in wininet/tests/http.c) then these do in fact get sent > as a response to InternetCloseHandle like they do on wine, and INTERNET_STATUS_HANDLE_CLOSING > always gets sent afterwards (last). > It seems like it would be better to add a close_connection method to go along with destroy, instead of leaving the handle in a half-destroyed state. Either that, or to not use INTERNET_SendCallback to send the callback in this case so that you don't have to have a WININETHANDLEHEADER object still around. -- Rob Shearman

Aug. 20, 2007

Re: Direct3D 10 design considerations

by Chris Howe

For what it's worth, although the idea of not starting with a clean state has its advantages (not in the least being able to support D3D10 software in a short time frame) I think that the clean slate argument wins out for me overall. Yes, it's more work in the short term, but I can't help thinking of a situation down the line where something gets done with the D3D10 framework - some as yet unknown extension or iteration to D3D11 or whatever - that took the library down a path that code based on Wine's current implementation couldn't follow, necessitating a restart from scratch later on anyway. Worst case scenario, perhaps, but a painful one that's probably worth thinking about. It'd be a shame if it did happen that way and D3D10 compatibility went backwards while it got restarted, plus there'd be a load of D3D10 cruft in the D3D9 library that would need to get culled... -- Chris

Aug. 20, 2007

Re: [Winetest RFI] What do you want out of the test suite?

by Paul Vriens

Stefan Leichter wrote: > Am Monday 13 August 2007 13:28 schrieb Paul Vriens: >> Stefan Leichter wrote: >>> Am Friday 10 August 2007 12:15 schrieb Paul Vriens: >>>> Hi, >>>> >>>> I just want to get people's opinion(s) about the >>>> needs/requirements/whishes for both the conformance tests themselves >>>> (including winetest) as well as the webpages. >>>> >>>> I'll collect the information and will put it on the wiki. >>>> >>>> Cheers, >>>> >>>> Paul. >>> What about marking the "todo_wine" on the web page somehow? >>> >>> Bye Stefan >> Hi Stefan, >> >> todo_wine will only be present on a Wine testrun. Results for each test are >> available (including todo) when you hover over the single results. >> >> We can of course use a general 'todo' visualization but who do you like to >> see that? >> >> Or was you're idea to show todo_wine's in Windows results !? >> >> Cheers, >> >> Paul. > Some days ago i had an issue with an installer. I remembered that i had this > long time ago and that i wrote a test to document the difference and a patch > to fix the issue. Only the test was accepted not the patch. > > Having the todo_wine on the test result page might have saved me some time > digging through the ChangeLog files. > > Also it someone is locking for something todo, he can look to the test results > and see the known issues. I don't thing all issues are all documented in > bugzilla. > > Bye Stefan > Hi Stefan, I've been playing a bit with have the 'todo_<platform>' on the page. In theory it's possible that there are todo_<platform>'s that why I don't refer to todo_wine. On http://www.xs4all.nl/~pvriens/200708181000_orig/ you can see the current situation for some random test results. On http://www.xs4all.nl/~pvriens/200708181000_with_todo/ I've added a column with todo's if one or more tests have a todo_item. This todo columns will only be present in the main summary and shows the maximum number of todo's for that test for that platform. I've tried adding the todo information to the current table cells but didn't find a satisfactory (that is nice looking) way. This is especially true for tests that also have a skip. As said before in theory we could have todo's for several platforms and different todo results per test. In practice we will only have todo_wine's and the number of todo's per test will be the same. Needless to say that for this to work we need people to run tests on Wine and have the reports sent in. Let me know what you think of it. (the patch to 'gather' is attached). Cheers, Paul.

Aug. 20, 2007

Re: [patch] Garbage code in text string display

by Guan Xin

I have submitted no patch after looking at Windows source code. The original submission certainly introduced to WINE nothing but a bug. I was later forced to prove this bug is necessary. On 8/20/07, James Hawkins <truiken(a)gmail.com> wrote: > > No patches will be accepted from you for the Wine project because > you've looked at Windows source code. > > -- > James Hawkins >

Aug. 20, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Maarten Lankhorst

Vitaliy Margolen schreef: > Maarten Lankhorst wrote: >> Vitaliy Margolen schreef: >>> That didn't work all that well: >>> >>> err:wave:DSDB_MapBuffer Please run winecfg, open "Audio" page and set >>> "Hardware Acceleration" to "Emulation". >>> wine: Unhandled page fault on read access to 0x00000030 at address >>> 0x7edf2cf8 (thread 0011), starting debugger... >>> >>> This is with OSS and full acceleration. >> Just sent-in patch to dsound fixes that, even then it is no reason not >> to accept this patch as it would have happened already with the current >> code. >> > Doesn't help: To fix it I need a more usable backtrace then that, one that has all dsound calls too. Maarten

Aug. 20, 2007