March 2001 - Wine-Devel - list.winehq.org

Re: for loop fixes

by Andreas Mohr

On Sat, Mar 03, 2001 at 07:17:41PM -0800, Francois Gouget wrote: > On Sat, 3 Mar 2001, Andreas Mohr wrote: > [...] > > - changed all terminating ";" of isolated for loops to " ;" to indicate the > > loop's isolation. > > IMHO, for such loops the following would be much clearer: > > <init_expression>; > while (<test_condition>) { > <update_expression>; > } > > (ok, you can also put '{' on the next line) Right. > > Please do the same for these for loops in the future. > > ??? Well, I just meant that they should always use " ;" instead of ";". But your proposal is probably much better. > > Somebody might want to write a Wine coding guidelines article... > > $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l > 96 > > (wg is my recursive source grep script) > > Maybe we should ask people to put the for and the instruction it > applies to on separate lines. Combined with the suggestion above this > would make it easier to check for this kind of bug. Correct. > > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > > too ;-) > > Yep, I should have done that myself (if you find a generic bug, > always check for other similar bugs). I always do that when someone spots a generic bug :-) Andreas Mohr

March 4, 2001

Re: [RESEND] Re: faster 8bpp to 24 bit depth conversion in SetImageBits_8

by Vedran Rodic

Sorry. I guess I still have to get used to this mutt program:) Vedran

March 4, 2001

[RESEND] Re: faster 8bpp to 24 bit depth conversion in SetImageBits_8

by Vedran Rodic

On Sun, Mar 04, 2001 at 01:51:16PM +0100, Ove Kaaven wrote: > > > Since this is a 32-bit move (movl), you should use %%eax, not %%ax. The > assembler doesn't complain about this now, but technically it should, and > might someday. > > Since you're converting to 32bpp, not 16bpp, you should multiply "left" by > 4, not by 2, or strange things may happen in some apps. Thanks. Fixed patch attached. I did change left multiplicator from 2 to 4 in my earlier patches, but I forgot to include it in my final patch being 3 AM and so... I'll try to be more careful next time. Vedran

March 4, 2001

Re: for loop fixes

by David D. Hagood

(hope I don't set off a flame war like last time I posted to the list... ;^) I'd like to suggest that rather than using the " ;" as a null statement, Wine should either use "{}" or { } My reasons are as follows: 1) I get suspicious if I see a naked semicolon on a line. I wonder if somebody has accidentally pressed return where they didn't mean to. A pair of braces is a lot more deliberate. 2) I usually find myself needing to put something in the loop later. If there's already braces, that simplifies throwing a TRACE or something in the loop, and removing it later.

March 4, 2001

RFC: client side implementation of async I/O

by Michael McCormack

Hi all, This patch moves responsibility for asynchronous I/O to the client process. i'm posting it to wine-devel because i want to know what other developers here think about the technique i've used to make this work... i've relaxed some of the assumptions wineserver makes about client processes. i think this implementation is more efficient, as it makes fewer server calls and duplicates fewer file descriptors, while maintaining correctness. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

March 4, 2001

Re: for loop fixes

by David Elliott

Andreas Mohr wrote: > On Sat, Mar 03, 2001 at 07:17:41PM -0800, Francois Gouget wrote: > > On Sat, 3 Mar 2001, Andreas Mohr wrote: > > [...] > > > - changed all terminating ";" of isolated for loops to " ;" to indicate the > > > loop's isolation. > > > > IMHO, for such loops the following would be much clearer: > > > > <init_expression>; > > while (<test_condition>) { > > <update_expression>; > > } > > > > (ok, you can also put '{' on the next line) > Right. > Why, what's wrong with a for loop? So far we have these choices: for(init,test,update); /* original */ for(init,test,update) ; /* with space */ init; while(test) { update; } What about simply: for(init,test,update) ; Putting the semicolon on the next line indented makes sense IMHO. Solves the problem of confusing it with a for loop accidently having a semicolon at the end and these kind that intentionally have one and is visible to a human at a very very quick glance. The only expense is ONE line. > > > > Please do the same for these for loops in the future. > > > > ??? > Well, I just meant that they should always use " ;" instead of ";". > But your proposal is probably much better. > I dunno, I like mine but shit we are gonna start a really bad coding-style war here if we continue with this. > > > > Somebody might want to write a Wine coding guidelines article... > > > > $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l > > 96 > > > > (wg is my recursive source grep script) > > > > Maybe we should ask people to put the for and the instruction it > > applies to on separate lines. Combined with the suggestion above this > > would make it easier to check for this kind of bug. > Correct. Just don't specify an indentation style, lest we be stuck with 2 or 3 spaces for an indent instead of a nice single 8-space tab (am I the only one here who prefers tabs to spaces?) As far as specifying using while instead of for, I am not such a big fan of that either. Personally I feel whoever is writing the code should decide. Requiring a space between the ) and ; or requiring the semicolon on the next line indented once more is probably the best way to go. Even an either-or approach on this would be acceptable. > > > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > > > too ;-) > > > > Yep, I should have done that myself (if you find a generic bug, > > always check for other similar bugs). > I always do that when someone spots a generic bug :-) > Surprised there was only one of these that was for real incorrect. I have accidently put that semicolon there on several late-night programming sessions. Usually you catch it pretty quick though since when you run the code it does some really strange shit. -Dave

March 4, 2001

Re: for loop fixes

by Francois Gouget

On Sat, 3 Mar 2001, Andreas Mohr wrote: [...] > - changed all terminating ";" of isolated for loops to " ;" to indicate the > loop's isolation. IMHO, for such loops the following would be much clearer: <init_expression>; while (<test_condition>) { <update_expression>; } (ok, you can also put '{' on the next line) > Please do the same for these for loops in the future. ??? > Somebody might want to write a Wine coding guidelines article... $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l 96 (wg is my recursive source grep script) Maybe we should ask people to put the for and the instruction it applies to on separate lines. Combined with the suggestion above this would make it easier to check for this kind of bug. > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > too ;-) Yep, I should have done that myself (if you find a generic bug, always check for other similar bugs). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

March 4, 2001

Re: Add explicit WM_CLOSE processing in the edit control

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Since handler of WM_CLOSE in DefWindowProc calls DestroyWindow, > which eventually sends WM_DESTROY, EDITSTATE gets destroyed before > call to EDIT_UnlockBuffer in the end of processing of WM_CLOSE, > therefore EDIT_UnlockBuffer gets confused. This is not specific to WM_CLOSE, it can happen with other messages too; any time we transfer control back to the application the window can be destroyed. I think it would be better to either unlock the buffer before calling DefWindowProc, or make EDIT_UnlockBuffer cope with a destroyed window. -- Alexandre Julliard julliard(a)winehq.com

March 4, 2001

Re: erase bkgnd on page scroller control

by Alexandre Julliard

Susan Farley <susan(a)codeweavers.com> writes: > @@ -720,7 +721,8 @@ > PAGER_INFO *infoPtr; > DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); > > - dwStyle |= WS_CLIPCHILDREN; > + /* background color of the child should be the same as the pager */ > + dwStyle &= ~WS_CLIPCHILDREN; Shouldn't we simply leave WS_CLIPCHILDREN alone and use whatever the app specified when creating the window, instead of forcing it one way or another? -- Alexandre Julliard julliard(a)winehq.com

March 4, 2001

Re: ListView fix

by Eric Pouech

> for (i = nFirst; i <= nLast; i++); ^ | +- !!!!!!! > { > + TRACE("i=%d\n",i); > LISTVIEW_SetItemState(hwnd,i,&item); > } A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

March 3, 2001