Re: [Wine] Call for help with Wine 1.0 testing
On Thu, May 15, 2008 at 4:52 PM, Jeremy White <[EMAIL PROTECTED]> wrote: >> Say, who maintains that web site? It'd be handy to have an option to >> suppress rows that have neither crashes nor failures; right now you have >> to scroll vertically a whole lot to see all the failures. > > I'm not sure. The source is in this git tree: > http://source.winehq.org/git/tools.git I wrote a postprocessor to do it. It's at http://kegel.com/wine/skipgood.pl.txt An example of its output is at http://kegel.com/wine/failing.html It really does make it easier to see all the failures.
Re: Right way to cope with user error in make test?
"Jeremy White" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > So...turns out that in this flood of new reporting, that one of the errors > only happened to me, and it further turns out to be entirely user error; > I didn't have libxslt. > > So, the obvious first solution is for me to actually read my configure > results and deal with it. > > But I think I serve nicely as an example of the sort of incompetent user > for whom it would still be nice to have make test work cleanly. > > I didn't see any obvious standard way of coping with this situation. > Did I miss it? I imagined that maybe we'd skip these cases, but I didn't > see evidence of that. I could also imagine a facility whereby we note > that the configure was not clean, and then refuse to run make test > (or at least refuse to run the full winetest battery). Should we make > libxslt non optional (or at least require an explicit --without-libxslt > in order to build without it)? Hi Jeremy, This could be a good option. libxslt should properly be non-optional since msxml3 relys on it. >From the Makefile.in, its appears to have linked to libxslt for quite some time, but was never an issue since it was never used. Francois Gouget raised this bug, http://bugs.winehq.org/show_bug.cgi?id=13035 that libslt should be dynamic, which could be another option. Best Regards Alistair Leslie-Hughes
Right way to cope with user error in make test?
So...turns out that in this flood of new reporting, that one of the errors only happened to me, and it further turns out to be entirely user error; I didn't have libxslt. So, the obvious first solution is for me to actually read my configure results and deal with it. But I think I serve nicely as an example of the sort of incompetent user for whom it would still be nice to have make test work cleanly. I didn't see any obvious standard way of coping with this situation. Did I miss it? I imagined that maybe we'd skip these cases, but I didn't see evidence of that. I could also imagine a facility whereby we note that the configure was not clean, and then refuse to run make test (or at least refuse to run the full winetest battery). Should we make libxslt non optional (or at least require an explicit --without-libxslt in order to build without it)? Cheers, Jeremy
Re: ALSA Midi port names
"Free Ekanayaka" <[EMAIL PROTECTED]> wrote: > I attach an amended patch for this bug: > > http://bugs.winehq.org/show_bug.cgi?id=13241 As it's been said the first hunk of your patch looks incorrect and seems not related. Also, please use your real name, Wine doesn't accept anonymous patches. -- Dmitry.
Re: [Wine] Call for help with Wine 1.0 testing
> Say, who maintains that web site? It'd be handy to have an option to > suppress rows that have neither crashes nor failures; right now you have > to scroll vertically a whole lot to see all the failures. I'm not sure. The source is in this git tree: http://source.winehq.org/git/tools.git Cheers, Jeremy
Re: [Wine] Call for help with Wine 1.0 testing
On Thu, May 15, 2008 at 10:47 AM, Jeremy White <[EMAIL PROTECTED]> wrote: > One key goal for Wine 1.0 is that all of its conformance > tests run successfully on nearly all systems. We would really like > your help in figuring out how close we are to that goal. > > To that end, if you are comfortable with checking Wine out via git, > could you please visit this page: > http://wiki.winehq.org/MakeTestFailures The results are pouring in at http://test.winehq.org/data/2470b0b31605133ec046330dd79fdccaa7ba33fe/#group_Wine Say, who maintains that web site? It'd be handy to have an option to suppress rows that have neither crashes nor failures; right now you have to scroll vertically a whole lot to see all the failures. - Dan
Re: Call for help with Wine 1.0 testing
Jeremy White codeweavers.com> writes: > > Hi Folks, > > One key goal for Wine 1.0 is that all of its conformance > tests run successfully on nearly all systems. We would really like > your help in figuring out how close we are to that goal. > > To that end, if you are comfortable with checking Wine out via git, > could you please visit this page: >http://wiki.winehq.org/MakeTestFailures > and follow the instructions there? (It's really simple; build current > git Wine, download + run a script). > > And, if you're a Wine developer, since Alexandre is away and the code freeze > is on, why not look for one of those failures in your own make test results and see > if you can fix it? > > Thanks! > > Jeremy > > Unfortunately the test crashes here with: Running: d3d8:volume (60 of 335) fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex s fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8 fixme:win:EnumDisplayDevicesW ((null),0,0x33f7cc,0x), stub! Running: d3d9:d3d9ex (61 of 335) fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex s amplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8 ) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f8cc,0x), stub! X Error of failed request: GLXBadDrawable Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 263 Current serial number in output stream: 263 Those tests in d3d8/d3d9 used to pass fine here a few weeks ago
Call for help with Wine 1.0 testing
Hi Folks, One key goal for Wine 1.0 is that all of its conformance tests run successfully on nearly all systems. We would really like your help in figuring out how close we are to that goal. To that end, if you are comfortable with checking Wine out via git, could you please visit this page: http://wiki.winehq.org/MakeTestFailures and follow the instructions there? (It's really simple; build current git Wine, download + run a script). And, if you're a Wine developer, since Alexandre is away and the code freeze is on, why not look for one of those failures in your own make test results and see if you can fix it? Thanks! Jeremy
Re: mono progress on mixed-mode assemblies...
> From: Juan Lang > The main contributors that have not done so that I saw after a quick > perusal were Alexandre and Rob Shearman. If you can't get their > permission, you'd have to start with the last MIT/X11 licensed > version, or get Transgaming's most recent ReWind version and start > from there. I had a look at msvcrt of the latest ReWind that is quite old but should be enough as well for the reqired parts. After examining the mixed-mode msvcrt (just the metadata not the code) I found that it contains little if any managed code so I will most likely be able to forward calls to a native msvcrt. As a conclusion I think that there will be no licensing problems. > I'm not sure if you realise it, but Wine is licensed under the LGPL, not > the GPL so I don't think using Wine's msvcrt code would be a problem > with inlining and using non-GPL programs. Inlining (done by the JIT at run time) is not just linking (that is permitted LGPL) and may not be permitted by LGPL. Kornél
Re: Configure question about Wine / HAL
I was building the port, and hal / dbus were both installed. The funny thing was that the first time I built the port, it didn't even get this far, it said : "checking for hal/libhal.h... no", but if I checked in /usr/local/include/hal, libhal.h was in there. Then I made a link to /usr/include "ln -s /usr/local/include/hal /usr/include/hal" and was able to get this far now. I will cvsup again tonight and recheck this to confirm my findings though. -- Kris Moore PC-BSD Software http://www.pcbsd.com Tijl Coosemans wrote: > On Wednesday 14 May 2008 22:03:35 Kris Moore wrote: >> I'm trying to get Wine to compile with HAL support on FreeBSD, and >> running into this error: >> >>> checking dbus/dbus.h usability... yes >>> checking dbus/dbus.h presence... yes >>> checking for dbus/dbus.h... yes >>> checking hal/libhal.h usability... yes >>> checking hal/libhal.h presence... yes >>> checking for hal/libhal.h... yes >>> checking for dbus_connection_close in -ldbus-1... no >>> configure: error: libhal development files not found, no dynamic device >>> support. >>> This is an error since --with-hal was requested. >> What exactly is -ldbus-1? Is there a way around this? Configure is >> finding the dbus and hal headers properly, and they both work >> properly on the system. > > Are you building using the wine port? Because that should autodetect > HAL when it's installed. If you're not using the port and running > configure yourself you probably need to set LDFLAGS. Something like: > > env CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure > --verbose --with-hal > > !DSPAM:1,482bfef620034310919711! > >
richedit: text that does not need scrollbar should also result in a scroll range of 0. Tests for this behavior. Try 2.
Alex Villacís Lasso escribió:
Eric Pouech escribió:
Alex Villacís Lasso a écrit :
Even though the code freeze is still in effect, I post this so that
it will be reviewed. For more information, see bug #12311.
Changelog:
* richedit: empty text should result in a scroll range of 0.
* Tests for this behavior.
what I don't understand is why the height of an empty doc is not zero
(I had similar issues with the height of a doc where we
systematically get one row too much). I believe this root cause
should be fixed instead of the band aid your patch is providing
A+
The height of the document is irrelevant. Instead, if the actual
height is less than the height of the client area, the scrollbar
should also be set to zero, as shown by tests included in the attached
patch. Empty text is just one special case.
Changelog:
* Text that does not need to be scrolled should also result in a
scroll range of zero
* Tests for this behavior
The previous version resulted in a misassignment of the range when scrollbars
forced visible but scroll range makes scrollbar visible. This version fixes it.
Changelog:
* Text that does not need to be scrolled should also result in a scroll
range of zero
* Tests for this behavior
--
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
diff --git a/dlls/riched20/paint.c b/dlls/riched20/paint.c
index 7bb1a01..1cddf58 100644
--- a/dlls/riched20/paint.c
+++ b/dlls/riched20/paint.c
@@ -689,15 +689,10 @@ void ME_Scroll(ME_TextEditor *editor, int value, int type)
si.nMin = 0;
- if (ME_GetTextLength(editor) > 0)
+ if (editor->nTotalLength > editor->sizeWindow.cy)
{
si.nMax = editor->nTotalLength;
si.nPage = editor->sizeWindow.cy;
-if (bForcedVisible)
-{
- TRACE("Setting page to max to preserve scrollbar...\n");
- si.nPage = si.nMax;
-}
} else {
si.nMax = si.nPage = 0;
if (bForcedVisible)
diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c
index c17cc40..7d9bf42 100644
--- a/dlls/riched20/tests/editor.c
+++ b/dlls/riched20/tests/editor.c
@@ -1930,6 +1930,15 @@ static void test_EM_SCROLL(void)
/* test a richedit box containing a single line of text */
SendMessage(hwndRichEdit, WM_SETTEXT, 0, (LPARAM) "a");/* one line of text */
+ memset(&si, 0, sizeof(si));
+ si.cbSize = sizeof(si);
+ si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+ GetScrollInfo(hwndRichEdit, SB_VERT, &si);
+ ok(si.nMin == 0, "si.nMin == %d, expected 0\n", si.nMin);
+ ok(si.nMax == 0, "si.nMax == %d, expected 0\n", si.nMax);
+ ok(si.nPos == 0, "si.nPos == %d, expected 0\n", si.nPos);
+ ok(si.nPage == 0, "si.nPage == %d, expected 0\n", si.nPage);
+
expr = 0x0001;
for (i = 0; i < 4; i++) {
static const int cmd[4] = { SB_PAGEDOWN, SB_PAGEUP, SB_LINEDOWN, SB_LINEUP };
Re: mono progress on mixed-mode assemblies...
Kornél Pál wrote: > Also note that Mono's Class Library is licensed under MIT/X11 because > inlining (done by the runtime) may be incompatible with GPL that would not > allow non-GPL programs to be executed within Mono. Would it be possible to > have a MIT/X11 licensed msvcrt? I'm not sure if you realise it, but Wine is licensed under the LGPL, not the GPL so I don't think using Wine's msvcrt code would be a problem with inlining and using non-GPL programs. However, I understand that having a uniform license for Mono's Class Library is probably highly desirable. -- Rob Shearman
Re: mono progress on mixed-mode assemblies...
> I've learned the hard way that it doesn't make sense to discuss this stuff > before you actually have the code. So I'd suggest you first go and see if you > can get the authors of that dll to agree to relicense for you and once that's > done, we can discuss what happens with Wine's copy. I'll try to make this process a little easier for you. The code was MIT/X11 licensed prior to 2002, so you don't need explicit permission from authors prior to that time. Furthermore, some of the authors since that time have explicitly licensed their contributions as LGPL and MIT/X11. At least Eric Pouch and I are in that set. Transgaming has a list somewhere, though I couldn't find it just now. The main contributors that have not done so that I saw after a quick perusal were Alexandre and Rob Shearman. If you can't get their permission, you'd have to start with the last MIT/X11 licensed version, or get Transgaming's most recent ReWind version and start from there. --Juan
Re: regressions running Photoshop?
On Thu, May 15, 2008 at 3:33 AM, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: > The culprit is: > > 4046075462c00f4479f185d1c0514584ff851223 is first bad commit > commit 4046075462c00f4479f185d1c0514584ff851223 > Author: Andrew Talbot <[EMAIL PROTECTED]> > Date: Tue May 13 22:41:58 2008 +0100 > > cabinet: Remove order-of-evaluation dependencies. > > In particular the following change: > > -n -= (e = (e = ZIPWSIZE - ((d &= ZIPWSIZE-1) > w ? d : w)) > n > ?n:e); > +d = max(d & (ZIPWSIZE - 1), w); > +e = min(ZIPWSIZE - d, n); > +n -= e; > > I'll send a patch. Thanks! I feel bad - Susan had identified that as the culprit for a Dragon Naturally Speaking regression, and I emailed the author rather than the list. Might have saved you an hour if I had sent it to the list. - Dan
Re: regressions running Photoshop?
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: > "Dan Kegel" <[EMAIL PROTECTED]> wrote: > >> Hmm. I just tried running Photoshop CS2 trial and Photoshop 5.5 trial, >> and both failed on current wine. >> >> CS2 complained "not enough DOS memory", >> and 5.5 complained >> lcms: Error #12288; Too many tags (2025813777) >> >> PS6 works, though. > > This looks like an installer problem. Photoshop CS2 installed with rc1 > works, the one installed with today's git doesn't. The culprit is: 4046075462c00f4479f185d1c0514584ff851223 is first bad commit commit 4046075462c00f4479f185d1c0514584ff851223 Author: Andrew Talbot <[EMAIL PROTECTED]> Date: Tue May 13 22:41:58 2008 +0100 cabinet: Remove order-of-evaluation dependencies. In particular the following change: -n -= (e = (e = ZIPWSIZE - ((d &= ZIPWSIZE-1) > w ? d : w)) > n ?n:e); +d = max(d & (ZIPWSIZE - 1), w); +e = min(ZIPWSIZE - d, n); +n -= e; I'll send a patch. -- Dmitry.
Re: regressions running Photoshop?
"Dan Kegel" <[EMAIL PROTECTED]> wrote: > Hmm. I just tried running Photoshop CS2 trial and Photoshop 5.5 trial, > and both failed on current wine. > > CS2 complained "not enough DOS memory", > and 5.5 complained > lcms: Error #12288; Too many tags (2025813777) > > PS6 works, though. This looks like an installer problem. Photoshop CS2 installed with rc1 works, the one installed with today's git doesn't. -- Dmitry.
Re: Configure question about Wine / HAL
On Wednesday 14 May 2008 22:03:35 Kris Moore wrote: > I'm trying to get Wine to compile with HAL support on FreeBSD, and > running into this error: > >> checking dbus/dbus.h usability... yes >> checking dbus/dbus.h presence... yes >> checking for dbus/dbus.h... yes >> checking hal/libhal.h usability... yes >> checking hal/libhal.h presence... yes >> checking for hal/libhal.h... yes >> checking for dbus_connection_close in -ldbus-1... no >> configure: error: libhal development files not found, no dynamic device >> support. >> This is an error since --with-hal was requested. > > What exactly is -ldbus-1? Is there a way around this? Configure is > finding the dbus and hal headers properly, and they both work > properly on the system. Are you building using the wine port? Because that should autodetect HAL when it's installed. If you're not using the port and running configure yourself you probably need to set LDFLAGS. Something like: env CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --verbose --with-hal
Re: mono progress on mixed-mode assemblies...
On Wednesday 14 May 2008 14:48:53 Kornél Pál wrote: > But I would like to know if the Wine community is willing to license msvcrt > under MIT/X11 after that in the future in Wine's source repository to help > Mono? I've learned the hard way that it doesn't make sense to discuss this stuff before you actually have the code. So I'd suggest you first go and see if you can get the authors of that dll to agree to relicense for you and once that's done, we can discuss what happens with Wine's copy. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: ws2_32: Test for invalid hostnames again.
On Wednesday 14 May 2008 18:37:56 Dan Kegel wrote: > Kai, > that test will always fail on some systems. How about this: > just test for whether that function completes at all, rather > than testing for success. Seriously, if an ISP gets you to a spam page for nonexistant.winehq.org, can't we sue them for abusing the winehq.org trade mark? This really seems like breaking a valid test just to work around broken ISPs. I admit that I'm a bit miffed that I didn't catch this in the 1-hour window between you sending that patch and Alexandre committing it, as it's now my time that's wasted by having to try again and again for a patch that gets past the discussion the initial patch should have gotten. But yeah, I agree removing the ok() is acceptable as I'm mostly checking for a crash bug. I'll send another patch. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
