January 2003 - Wine-Devel - list.winehq.org

Re: wine/ library/debug.c include/wine/library.h i ...

by Dan Kegel

Dimitrie O. Paun wrote: >>Hmm. I don't see a problem with WINE_TRACE myself. It seems short enough, >>and the source code gets read a lot more often than it gets written, >>so the extra clarity is good. > > Maybe I'm in my I_just_don't_get_it_mode, but I really don't! What clarity? > Why is it important that the debug API is a Wine thing? Why not look at it > as a 3rd party debugging API? Would you still call it WINE_TRACE? No, of > course not, it would be silly. Why expose this implementation detail (that > this is really implemented inside of Wine) in the interface? What possible > benefit do you get out of it? Quite the contrary, it will just obfuscate > the source. People think that very_long_identifiers_for_everything are > a Good Thing. They are not. What about: WINE_SUPPORT_DEBUG_API_TRACE? > Do we gain anything from knowing all that? I don't think so. It doesn't have to be long, it just has to be unique, and have a prefix that implies that it comes from Wine. That way nobody is likely to be confused about whose TRACE macro it is. It's important when visually scanning source code that it be fairly obvious what package each identifier comes from, IMHO. _W might be enough of a unique and common prefix... - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dan Kegel

Dimitrie O. Paun wrote: > Bottom line, I don't really care what we export. I do care what we use > internally. A great deal. In fact, if we export long symbols, I don't > think it matters how long they are, people will just invent short synonyms. > But why can't we invent short synonyms for Wine itself? :) I'd argue that for clarity's sake, we should discourage people from concocting short synonyms for WINE_TRACE... so if we pick something too long for Dimitrie, we're in for a heap of arguments. How about _WTRACE? It gets zero hits on google... -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Re: Francois's winsock.h patch

by Dimitrie O. Paun

On January 3, 2003 08:18 pm, Alexandre Julliard wrote: > My impression was that it was not ready yet. Francois? FWIW, it does work for me just fine. -- Dimi.

Jan. 4, 2003

Problem in dlls/ddraw/dsufrace/main.c

by Sylvain Petreolle

Trying to run Revolt Demo, the program halts saying DDERR_NOTFOUND in Main_DirectDrawSurface_GetAttachedSurface Looking in the source, we see that : found=NULL; for (surf = This->attached; surf != NULL; surf = surf->next_attached){ ... // surf is not modified into that if (...) found=surf; } if (found == NULL) { TRACE("Did not find any valid surface\n"); return DDERR_NOTFOUND; } Looks like the only possible return value of this is DDERR_NOTFOUND, because of the for(...; surf !=NULL ; ...) Or am I writing complete bullshit ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 4, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dan Kegel

Dimitrie O. Paun wrote: > But this is besides the point. What I'm arguing against is using the long > names internally. This makes little sense, since I am virtually sure nobody > else will. So we will loose clarity, neatness, and convenience for the very > purpose of uniformity with some Winelib apps, that's not going to be there > in the first place since they are not gonna use the long names, and are going > to invent their own anyhow. Hmm. I don't see a problem with WINE_TRACE myself. It seems short enough, and the source code gets read a lot more often than it gets written, so the extra clarity is good. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Francois's winsock.h patch

by Dimitrie O. Paun

Alexandre, Are you going to apply Francois's winsock.h patch that fixes the Winelib problems that I encountered on wxWindows? -- Dimi.

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dan Kegel

Dimitrie O. Paun wrote: > WINE_TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", wine_dbgstr_rect(lprc), > wine_dbgstr_point(lppt), nSize); > > There is so many stuff in there... it's way too verbose, you don't know > what's going on there anymore. Contrast with this: > > TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", dbgstr_rect(lprc), dbgstr_point(lppt), nSize); Yes, but consider the poor sod who has already used the identifier TRACE (precisely because it's a convenient name, as you point out) and is trying to build with winelib. Sure, we could have some switch to turn on and off the short names, but that gets hard to read... - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dimitrie O. Paun

On January 3, 2003 07:48 pm, Dan Kegel wrote: > It doesn't have to be long, it just has to be unique, and have a prefix > that implies that it comes from Wine. That way nobody is likely to > be confused about whose TRACE macro it is. It's important when visually > scanning source code that it be fairly obvious what package each identifier > comes from, IMHO. And it's even more important that visually scanning source code does not hurt the eye. For me, it's a sine qua non condition -- I simply do not work (unless paid, of course :)) on ugly stuff. There is no reason to support apps that do _WTRACE, _TTRACE, _XTRACE, etc. There is also no reason to show at source level that the trace statement from Wine is used. None. This is like having .sh, or .py extensions to scripts. They just expose implementation details that are better kept hidden. So no, _WTRACE is a lot worse than WINE_TRACE since it's so ugly. Dan, don't tell me you want people to use that as is :) -- Dimi.

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dimitrie O. Paun

On January 3, 2003 07:08 pm, Dan Kegel wrote: > Hmm. I don't see a problem with WINE_TRACE myself. It seems short enough, > and the source code gets read a lot more often than it gets written, > so the extra clarity is good. Maybe I'm in my I_just_don't_get_it_mode, but I really don't! What clarity? Why is it important that the debug API is a Wine thing? Why not look at it as a 3rd party debugging API? Would you still call it WINE_TRACE? No, of course not, it would be silly. Why expose this implementation detail (that this is really implemented inside of Wine) in the interface? What possible benefit do you get out of it? Quite the contrary, it will just obfuscate the source. People think that very_long_identifiers_for_everything are a Good Thing. They are not. What about: WINE_SUPPORT_DEBUG_API_TRACE? Do we gain anything from knowing all that? I don't think so. But we don't seem to reach a consensus on this one. So I will state this for the record: -- I think using WINE_TRACE instead of TRACE inside of Wine makes little sense, and it will uglify everything. I strongly oppose it. Making the sources ugly is something we should not do lightly. People work on Wine for pleasure, and that definitely diminishes it. Making the most common thing more tedious falls into the same category. -- Let's think of the debugging API on it's own terms, not as part of wine. In fact, wine_ should not be part of the name at all. I suggested dbg_, even though Alexandre is right that it might cause problems. I'd like to remark that debugging APIs are special in that they are used orders of magnitude more often than any other API. In all natural languages, very common words often form exceptions to the rules of the language for shortness sake. Witness the verb "to be" in most languages. For this reasons, I don't think it's a mistake to treat it a bit differently. I suggest that we export symbols with the dbg_ prefix by default, but we allow an easy way for the user to change that, maybe like so: #define WINE_DEBUG_API_PREFIX(s) d_##s #include <wine/debug.h> Bottom line, I don't really care what we export. I do care what we use internally. A great deal. In fact, if we export long symbols, I don't think it matters how long they are, people will just invent short synonyms. But why can't we invent short synonyms for Wine itself? :) -- Dimi.

Jan. 3, 2003

RESENT: running confirmance tests, question

by Sylvain Petreolle

===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 3, 2003