Rafał Mużyło wrote:
> Going on an assumption, that 0 is a magic value (standing for 'point'),
> compare against it. Fixes 6ab04040e52465e77558a067309e8a54bdc0f32c regression,
> so would be nice if this got into wine 1.6.
It would be nice to see some test cases first.
--
Dmitry.
What if rect.Width is 0.25? Shouldn't we still clip then?
On Wed, May 22, 2013 at 4:19 PM, Alan W. Irwin
wrote:
> On 2013-05-22 14:31-0700 Austin English wrote:
>
>> This is better suited for the forum, but:
>>
>> http://wiki.winehq.org/RegressionTesting#head-a7150fa43baeaab304403f27a930647ea13648b7
>
>
> Hi Austin:
>
> Thanks for that reference which is
On 2013-05-22 14:31-0700 Austin English wrote:
This is better suited for the forum, but:
http://wiki.winehq.org/RegressionTesting#head-a7150fa43baeaab304403f27a930647ea13648b7
Hi Austin:
Thanks for that reference which is helpful for a git newbie like
myself. I had some additional questions,
ymlink trick discussed in my previous recent thread).
> However, I have just discovered a puzzling case where MSYS bash.exe
> redirection now fails for ctest.exe compared to wine-1.5.19.
>
> To reproduce this regression download the Windows binary version of
> cmake-1.8.10.2
> (which in
discovered a puzzling case where MSYS bash.exe
redirection now fails for ctest.exe compared to wine-1.5.19.
To reproduce this regression download the Windows binary version of
cmake-1.8.10.2
(which includes cmake.exe and ctest.exe)
and install it. Also download and install MinGW/MSYS. In the past,
I
On 2012-12-28 10:22-0800 Alan W. Irwin wrote:
[...Let's] leave
it like this. Wine-1.5.20 has introduced an obvious regression for an
important Windows app (the MinGW gcc compiler for Windows) that has
been working for years for prior Wine versions.
Grant communicated to me off list th
On 2012-12-28 13:45+0100 Frédéric Delanoy wrote:
Other users have issues with wine but they don't generally complain as
loudly as you did.
It is possible I was not cautious enough with my tone, but let's leave
it like this. Wine-1.5.20 has introduced an obvious regression for an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
this patch is causing CS:GO (Counter Strike: Global Offensive) to exit
silently on startup.
(Commit: 5fae649bdf14fb63b8d44984eda6edd1094a3314)
- -Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mo
On 3 May 2012 07:17, Alexey Loukianov wrote:
> Trying to pinpoint the cause using oprofile produced no valuable results: it
> either me not able to use this wonderful profiler correctly or the issue is of
> such kind that isn't easily tracked by oprofile.
>
Personally I think perf is a bit nicer t
d version of "Perfect World" MMORPG game client from "Mail.Ru
> Games Corp") that seems to suffer huge FPS regression which I believe to be
> a bug in nVIDIA drivers rather than a regression in Wine...
>
So I'm still trying to investigate this issue and have some
On 4/16/12, Alexey Loukianov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 16.04.2012 04:28, Vitaliy Margolen wrote:
>> Of course it won't - they are binary blobs from Nvidia. Not much to see
>> there. All you really looking for are time spent in that library.
>>
>
> Vitaliy, I don'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
16.04.2012 04:28, Vitaliy Margolen wrote:
> Of course it won't - they are binary blobs from Nvidia. Not much to see
> there. All you really looking for are time spent in that library.
>
Vitaliy, I don't expect oprofile to find hidden COFF or DWARF 2
On 04/15/2012 04:44 PM, Alexey Loukianov wrote:
With oprofile I hit another trouble - it seems that this tool is unable to
fetch symbols from libGL
Of course it won't - they are binary blobs from Nvidia. Not much to see
there. All you really looking for are time spent in that library.
Vitaliy.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
15.04.2012 21:50, Stefan Dösinger wrote:
> your best bet would be using something like oprofile to find out which GL
> calls show performance changes.
Well, I had compiled/installed APITrace 3.0 and oprofile 0.9.7 on my system,
but it seems that it'd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
15.04.2012 21:50, Stefan Dösinger wrote:
> It could also be because of some additional features added in newer
> drivers. 16 byte alignment for vertex buffers is a possibility, I believe
> it was added in the 280 drivers. You can check this by disablin
Am Sonntag, 15. April 2012, 07:22:34 schrieb Alexey Loukianov:
> When I configure an app to run in a windowed mode I've got around 40 FPS on
> game login screen with nVIDIA drivers 275.09.07, but switching into using
> more recent versions causes FPS to drop to around ~10.
It could be a driver bug
to try to
investigate a case.
What I've got here is an app (localized version of "Perfect World" MMORPG game
client from "Mail.Ru Games Corp") that seems to suffer huge FPS regression
which I believe to be a bug in nVIDIA drivers rather than a regression in Wine.
Details
the most part I create and triage related bug
>>> reports, but recently I also started tinkering with code, specifically
>>> with comctl library, which I am most familiar with.
>>>
>>> Back on subject. I thought I found a regression - on Wine 1.4 package
>>>
also started tinkering with code, specifically
>> with comctl library, which I am most familiar with.
>>
>> Back on subject. I thought I found a regression - on Wine 1.4 package
>> downloaded from launchpad the "New query" button works fine, while on my
>> comp
most familiar with.
Back on subject. I thought I found a regression - on Wine 1.4 package
downloaded from launchpad the "New query" button works fine, while on my
compiled Wine it produces an error. So I did:
git reset --hard wine-1.4
make
and, surprisingly, I still had the proble
Marcus, Alexey, thank you for your ideas. I just did several builds to
see how to make things work. Here's what I got:
make clean && make - does not work (the problem persists)
make distclean && ./configure && make - same as above
git clean -xdf && ./configure && make - this one finally worked.
I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
12.04.2012 12:23, Daniel Jeliński wrote:
> ... This time make clean && make depend && make did not help.
>
I had hit the problems like you describe several times while doing bisecting.
After a lot of trial and error testing I had finally come up with
t; specifically with comctl library, which I am most familiar with.
>
> Back on subject. I thought I found a regression - on Wine 1.4
> package downloaded from launchpad the "New query" button works fine,
> while on my compiled Wine it produces an error. So I did:
>
>
. I thought I found a regression - on Wine 1.4 package
downloaded from launchpad the "New query" button works fine, while on my
compiled Wine it produces an error. So I did:
git reset --hard wine-1.4
make
and, surprisingly, I still had the problem with the compiled version.
How
2012/1/3 Frédéric Delanoy :
> Might be difficult to explain to "plain" users though. Some already
> struggle performing a regression test (most won't even bother), let
> alone understanding the fine details of what a regression really
> represents.
>
The original th
I had hoped this was one of those threads that would go away if I
ignored it. Oh well.
I actually think there's value in handling anything that breaks an
application as a regression. Despite claims to the contrary, we like
users to test releases and find regressions sooner rather than late
en doing The Right Thing (TRT)?
>>
>> Yes, it reduces the noise to let you concentrate on the real
>> regressions, i.e. the ones where working code got broken, and where you
>> can get useful information from the previous state.
>>
>> Having a new piece of co
it reduces the noise to let you concentrate on the real
> regressions, i.e. the ones where working code got broken, and where you
> can get useful information from the previous state.
>
> Having a new piece of code tagged a regression is just noise, there's
> nothing you can do
joerg-cyril.hoe...@t-systems.com writes:
> Hi,
>
>> Bugs in newly added code cannot be regressions.
>>
>> Similarly, if we add a dll and some app starts using it and breaks,
>> technically that's not a regression even though the behavior got worse,
>> b
Hi,
> Bugs in newly added code cannot be regressions.
>
> Similarly, if we add a dll and some app starts using it and breaks,
> technically that's not a regression even though the behavior got worse,
> because it has always been broken, it just wasn't exercised before.
W
On Tue, Jan 3, 2012 at 01:10, Saulius Krasuckas wrote:
> * On Mon, 2 Jan 2012, Dan Kegel wrote:
>>
>> If an app stops working because some missing feature is added to an
>> existing DLL, it should not be tagged as a regression even though it is
>> from the app's po
* On Mon, 2 Jan 2012, Dan Kegel wrote:
>
> If an app stops working because some missing feature is added to an
> existing DLL, it should not be tagged as a regression even though it is
> from the app's point of view, right?
> (Thinking of the installers for Photoshop CS3 an
On Mon, Jan 2, 2012 at 2:58 AM, Alexandre Julliard wrote:
> Obviously it's important, and we have an importance field in bugzilla
> for that. But the regression keyword has a specific meaning: there has
> to be a piece of code that worked and then got broken. Bugs in newly
> add
Dan Kegel writes:
> On Sun, Jan 1, 2012 at 6:32 PM, Austin English
> wrote:
>> That _particular_ test never worked, so it's not a regression. A code
>> change in d3d itself that broke a previously working test/application
>> would be a valid regression.
>
&g
On Sun, Jan 1, 2012 at 6:32 PM, Austin English wrote:
>> http://bugs.winehq.org/show_bug.cgi?id=29094
>> Henri removed the regression keyword and sha1sum without comment.
>>
>> What's the reasoning there? Is Henri saying there's
>> something wrong with my
g.cgi?id=29094
> for it, and marked it as a regression (since
> tests/device.c used to pass, but fails here
> after that commit).
>
> Henri removed the regression keyword and sha1sum without comment.
>
> What's the reasoning there? Is Henri saying there's
> someth
Happy New Year's Eve, everyone!
002447357c2b1feca5ef2649429fc55f70238901
added a IDirect3DDevice9::SetCursorPosition() test to d3d9.
That test never worked here, I think. I filed
http://bugs.winehq.org/show_bug.cgi?id=29094
for it, and marked it as a regression (since
tests/device.c used to
On Mon, Nov 21, 2011 at 11:12, Wolfgang Walter wrote:
> Hello,
>
> I just tested version 1.3.33. With this version an application we use shows
> its icons with wrong colors. The background of the icons is wrong, too. I
> bisected it to commit c9a7bb715d2db1512db30deb11e4676e76791a07.
>
> I then ch
Hello,
I just tested version 1.3.33. With this version an application we use shows
its icons with wrong colors. The background of the icons is wrong, too. I
bisected it to commit c9a7bb715d2db1512db30deb11e4676e76791a07.
I then checked that by replacing nulldrv_StretchDIBits in 1.3.33 with its
ol
On Tue, 25 Oct 2011, Damjan Jovanovic wrote:
[...]
> Now the next question is, how to get the binaries to run on any distro? Or
> should I just compile on Ubuntu because most people run that (do they still,
> after Unity?)?
Compile on Debian Stable or even Debian OldStable, taking care to still
m
2011/10/18 André Hentschel
> Am 18.10.2011 10:45, schrieb Damjan Jovanovic:
> > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th
> October 2011 in only 7 days, generating a Git repository of Wine binaries
> that's only 26 gigabytes in size. Regression t
build snapshot,
and placing that on a server somewhere?
e.g. a folder full of
36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files?
Then one could write a simple wine regression bisect tool that implements
similar semantics to git bisect, but would essentially wrap wget. Then in your
s
On Wed, Oct 19, 2011 at 04:18:50PM +0200, Frédéric Delanoy wrote:
> On Wed, Oct 19, 2011 at 15:50, Marcus Meissner wrote:
> > On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote:
> >>
> >>
> >> On 19/10/11 13:43, Frédéric Delanoy wrote:
> >> >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth
On Wed, Oct 19, 2011 at 15:50, Marcus Meissner wrote:
> On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote:
>>
>>
>> On 19/10/11 13:43, Frédéric Delanoy wrote:
>> >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth
>> >wrote:
>> >>Alternatively, have you considered doing a .tar.gz of every bu
On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote:
>
>
> On 19/10/11 13:43, Frédéric Delanoy wrote:
> >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth
> >wrote:
> >>Alternatively, have you considered doing a .tar.gz of every build snapshot,
> >>and placing that on a server somewhere?
> >
On 19/10/11 13:43, Frédéric Delanoy wrote:
On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth wrote:
Alternatively, have you considered doing a .tar.gz of every build snapshot,
and placing that on a server somewhere?
e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files?
> Then one could write a simple wine regression bisect tool that implements
> similar semantics to git bisect, but would essentially wrap wget. Then in
> your server you could have an index file which is a list of the sha commit
> ids.
>
> This would save the user having to clone
Alternatively, have you considered doing a .tar.gz of every build snapshot, and
placing that on a server somewhere?
e.g. a folder full of36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files?
Then one could write a simple wine regression bisect tool that implements
similar semantics to git
2011/10/18 André Hentschel
> Am 18.10.2011 10:45, schrieb Damjan Jovanovic:
> > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th
> October 2011 in only 7 days, generating a Git repository of Wine binaries
> that's only 26 gigabytes in size. Regression t
Am 18.10.2011 10:45, schrieb Damjan Jovanovic:
> This tool compiled all 35000 or so commits from Wine 1.0 to around 4th
> October 2011 in only 7 days, generating a Git repository of Wine binaries
> that's only 26 gigabytes in size. Regression testing with binaries is a
> pleasu
On Tue, Oct 18, 2011 at 10:26, Dmitry Timoshkov wrote:
> Austin English wrote:
>
>
>> > Reverting a patch in latest git is not always possible, instead it's
>> > a very useful test to revert the patch at the suspected regression point
>> > and see if th
Austin English wrote:
> > Reverting a patch in latest git is not always possible, instead it's
> > a very useful test to revert the patch at the suspected regression point
> > and see if that really helps.
>
> That still doesn't require a full regressi
On Tue, Oct 18, 2011 at 09:01, Dmitry Timoshkov wrote:
> Damjan Jovanovic wrote:
>> > Moreover, often users get asked 'does reverting commit ' help? Without
>> > performing a proper regression test it's impossible to asnwer that
>> > question.
Damjan Jovanovic wrote:
> > Moreover, often users get asked 'does reverting commit ' help? Without
> > performing a proper regression test it's impossible to asnwer that
> > question.
> >
> >
> Reverting a commit in the latest git is just 1 ro
On Tue, Oct 18, 2011 at 2:32 PM, Dmitry Timoshkov wrote:
> Henri Verbeet wrote:
>
> > On 18 October 2011 10:45, Damjan Jovanovic wrote:
> > > (especially during "reverse regression testing"), users find it too
> long and
> > > technical, and on
On Tue, Oct 18, 2011 at 13:42, Damjan Jovanovic wrote:
> If you are talking about using compiling with ccache instead of the binary
> repository, "configure" alone is > 40 seconds
configure -C option can speed it up a lot
Henri Verbeet wrote:
> On 18 October 2011 10:45, Damjan Jovanovic wrote:
> > (especially during "reverse regression testing"), users find it too long and
> > technical, and only a small minority of regressions are ever bisected. And
> Not true. Even for the regressi
On 18 October 2011 13:42, Damjan Jovanovic wrote:
> There's currently another 182 regressions that were closed "ABANDONED".
> Maybe if regression testing was easier and faster, people wouldn't abandon
> them?
>
Maybe. That's 182 closed ABANDONED, out of 2590
other idea I had is that users should be able to regression test
> through a GUI tool. Maybe the GUI tool can just download and run the +/-
> 122 MB binary snapshots for specific commits, instead of having the
> entire binary repository locally?
>
> Any other ideas? Would you like
On Tue, Oct 18, 2011 at 12:08 PM, Henri Verbeet wrote:
> On 18 October 2011 10:45, Damjan Jovanovic wrote:
> > (especially during "reverse regression testing"), users find it too long
> and
> > technical, and only a small minority of regressions are ever bisected.
&g
On 18 October 2011 10:45, Damjan Jovanovic wrote:
> (especially during "reverse regression testing"), users find it too long and
> technical, and only a small minority of regressions are ever bisected. And
Not true. Even for the regressions that are still open it's currentl
On Tue, Oct 18, 2011 at 10:45 AM, Damjan Jovanovic wrote:
> Hi
>
> Since the beginning, I've had issues with regression testing. Despite the
> fact it's very useful, it takes forever, it's easy to make a mistake
> (especially during "reverse regression te
Hi
Since the beginning, I've had issues with regression testing. Despite the
fact it's very useful, it takes forever, it's easy to make a mistake
(especially during "reverse regression testing"), users find it too long and
technical, and only a small minority of regressio
On 4 October 2011 13:29, Damjan Jovanovic wrote:
> Hi
>
> Where do we find that list of regressions by author, that was in
> Alexandre's keynote at Wineconf?
http://source.winehq.org/regressions
- Reece
Hi
Where do we find that list of regressions by author, that was in
Alexandre's keynote at Wineconf?
Thank you
Damjan Jovanovic
ced a regression recently where the audio
stopped working properly after the main menu (commit B). This
triggered a memory of a similar experience I had where commit A caused
the same behavior, but it only did so for PulseAudio users. So, on a
hunch, I reverted commit A on the latest git and found
On 29/08/2011 2:37 AM, Alan W. Irwin wrote:
> While I am doing those additional investigations, please consider
> the question of why there is a huge difference between built-in and
> executable latency for MSYS bash commands under wine. To start
> that investigation it would be good to compare
On 2011-08-29 07:56+1000 Ben Peddell wrote:
On 29/08/2011 2:37 AM, Alan W. Irwin wrote:
bash.exe-3.1$ time /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe
hello
hello
real0m0.503s
user0m0.080s
sys 0m0.020s
Also, I tried
time (x; x; x; x; x; x; x; x; x; x), where "x" represents
On 29/08/2011 2:37 AM, Alan W. Irwin wrote:
> bash.exe-3.1$ time /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe
> hello
> hello
>
> real0m0.503s
> user0m0.080s
> sys 0m0.020s
>
> Also, I tried
> time (x; x; x; x; x; x; x; x; x; x), where "x" represents the complete
> echo command ab
mply the above correctly spelled command took only
0.150 seconds for 1.2-rc3 which implies a factor of 3 regression in
latency for wine 1.3.27. However, for those old tests my MinGW/MSYS
software stack was different so I will attempt to replicate them again
(and also the bash timing versions abo
On Sat, Aug 27, 2011 at 5:22 PM, Alan W. Irwin
wrote:
[...]
> bash.exe-3.1$ which echo
> /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe
>
> bash.exe-3.1$ time echo "hello"
> hello
>
> real 0m0.000s
> user 0m0.000s
> sys 0m0.000s
>
> This shows there is at least one command (echo) ava
s 10 times worse than in the 1.3.9
case, typical cmake configurations are something like 25 (!) times
slower than the corresponding Linux command.
What can be done to address this bad command-startup latency
regression for wine?
I would be happy to run any tests that might point to a solution. For
exampl
Hey Susan,
On 06/21/2011 01:03 PM, Susan Cragin wrote:
> >Susan Cragin wrote:
> >> I think a regression was introduced today. I got the following trying to
> >> run NatSpeak 11.0 with today's git.
> >> wine-1.3.22-255-g4c0c0d3
> >> Should I do a r
>Susan Cragin wrote:>> I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. >> wine-1.3.22-255-g4c0c0d3>> Should I do a regression test and file a bug, or is it obvious from this? >> Or is it me -- something
Susan Cragin wrote:
> I think a regression was introduced today. I got the following trying to run
> NatSpeak 11.0 with today's git.
> wine-1.3.22-255-g4c0c0d3
> Should I do a regression test and file a bug, or is it obvious from this?
> Or is it me -- something to do with m
On Mon, Jun 20, 2011 at 21:00, Susan Cragin wrote:
> I think a regression was introduced today. I got the following trying to run
> NatSpeak 11.0 with today's git.
> wine-1.3.22-255-g4c0c0d3
> Should I do a regression test and file a bug, or is it obvious from this?
> Or is i
I think a regression was introduced today. I got the following trying to run
NatSpeak 11.0 with today's git.
wine-1.3.22-255-g4c0c0d3
Should I do a regression test and file a bug, or is it obvious from this?
Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0
k
On May 23, 2011, at 12:13 PM,
wrote:
> - I'm now wondering whether thread affinity may play a role.
> Alas, I don't know how to disable one core with Mac OS X 10.5.8
Double-click on /Developer/Extras/PreferencePanes/Processor.prefPane. That
will install it to System Preferences. Then, you
On Monday 23 May 2011 19:13:10 joerg-cyril.hoe...@t-systems.com wrote:
> This looks like a serious performance degradation over time, isn't it?
> Actually, the situation is much subtler and so confusing that I don't
> know what to think about it.
I'd say this is a perfo
Hi,
please consider the following WINEDEBUG=+fps numbers.
1.1.24 24-19 fps, depending on orientation
1.3.16 14-7 fps
1.3.18-291-g9da9240 14-6 fps
1.3.18-342-gab199f5 13-5 fps
1.3.19-46-g3025f7f 8 fps
1.3.20 7-4 fps
The low fps results in jerky character
On 05/17/2011 12:43 PM, Susan Cragin wrote:
I compile every git. So last compile was the day before this one.
However, I don't remember if I tried to run NatSpeak, so the error
might be as much as two days old?
If something worked before and don't work anymore, it's a reg
ctl unsupported ioctl 74080>> susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking10/Program$ >> >> I had just compiled today's git. >> wine-1.3.20-44-gddad22d>> >> Is there a regression test in my future?>> >Hi,>When did you com
ENTS
> fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080
> susan@ubuntu:~/.wine/drive_c/Program
> Files/Nuance/NaturallySpeaking10/Program$
>
> I had just compiled today's git.
> wine-1.3.20-44-gddad22d
>
> Is there a regression test in my future?
>
Hi,
When
/NaturallySpeaking10/Program$
I had just compiled today's git.
wine-1.3.20-44-gddad22d
Is there a regression test in my future?
2011/1/13 André Hentschel :
> ---
> libs/wine/config.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libs/wine/config.c b/libs/wine/config.c
> index e15012b..2c365a4 100644
> --- a/libs/wine/config.c
> +++ b/libs/wine/config.c
> @@ -456,7 +456,7 @@ const char *wine
Le 11/12/2010 00:04, Alan W. Irwin a écrit :
The command
wineconsole --backend=curses cmd
hangs with the following error message for 1.3.8:
err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec "?" wait timed
out in thread 0065, blocked by , retrying (60 sec)
On 2010-12-10 15:14-0800 Juan Lang wrote:
Hi Alan,
you should open a bug for this rather than ask here. (Also, I just
tried on Ubuntu 10.04 with Wine 1.3.9 here, and I can't confirm.)
Thanks, Juan, for your reply which inspired me to build wine-1.3.9, and
indeed the issue has been fixed for t
On 2010-12-10 15:04-0800 Alan W. Irwin wrote:
I should have added that the configure step for my wine-1.3.8 build
used no options other than --prefix. That means I built the
32-bit version of wine-1.3.8 on my 64-bit (amd64) Intel box as confirmed
by
softw...@raven> file ~/wine/install/bin/wine
Hi Alan,
you should open a bug for this rather than ask here. (Also, I just
tried on Ubuntu 10.04 with Wine 1.3.9 here, and I can't confirm.)
--Juan
"make
install" steps seem fine as well. I am generally pretty happy with
wine-1.3.8 except for this one curses backend regression.
Can others confirm this issue?
Is there some workaround such as using a different version of ncurses?
Here are the curses-related packages I have installe
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=6625
Your paranoid android.
Hello guys,
I thought about doing a regression report like Rafael Wysocki is doing
for the Linux Kernel
http://marc.info/?l=linux-kernel&m=127344241607730&w=4
but I got cured when looking at the regression list on bugs.winehq.org.
We have at least by a factor of three too many reg
2010/5/18 Reece Dunn :
>
>
> should work on all platforms that support SVG.
>
> - Reece
Chromium doesn't like the object markup. It shows tiny frames with
scrollbars. It seems there is no cross-platform way to simply display
an SVG image.
--
Remco
2010/5/18 André Hentschel :
> Am 18.05.2010 15:17, schrieb Dan Kegel:
>> On Mon, May 17, 2010 at 11:00 PM, Reece Dunn wrote:
http://kegel.com/wine/yagmarkdata/wine-1.1.44-245.html
>>>
>>> Can you use something like:
>>>
>>> >> type="image/svg+xml">
>>> >> type="image/svg+xml">
>>> >> alt="E
On Tue, May 18, 2010 at 2:42 PM, Dan Kegel wrote:
> On Tue, May 18, 2010 at 3:07 AM, Scott Ritchie wrote:
>> > http://kegel.com/wine/yagmarkdata/wine-1.1.44-245.html
>>
>> What tool are you using to make them?
>
> gnuplot. The script (if you can call it that) I use is at
> http://code.google.com
Am 18.05.2010 15:17, schrieb Dan Kegel:
> On Mon, May 17, 2010 at 11:00 PM, Reece Dunn wrote:
>>> http://kegel.com/wine/yagmarkdata/wine-1.1.44-245.html
>>
>> Can you use something like:
>>
>> > type="image/svg+xml">
>> > type="image/svg+xml">
>> > alt="E8400 GT220 - Ubuntu 10.04 LTS - e8400 - 3
On Mon, May 17, 2010 at 11:00 PM, Reece Dunn wrote:
>> http://kegel.com/wine/yagmarkdata/wine-1.1.44-245.html
>
> Can you use something like:
>
> type="image/svg+xml">
> type="image/svg+xml">
> alt="E8400 GT220 - Ubuntu 10.04 LTS - e8400 - 3dmark06 3DMark Score">
>
>
>
> so that this will
On Tue, May 18, 2010 at 3:07 AM, Scott Ritchie wrote:
> > http://kegel.com/wine/yagmarkdata/wine-1.1.44-245.html
>
> What tool are you using to make them?
gnuplot. The script (if you can call it that) I use is at
http://code.google.com/p/winezeug/source/browse/trunk/yagmark-plot.sh
> I recommen
On Tue, May 18, 2010 at 1:13 AM, Sven Baars wrote:
>> http://kegel.com/wine/yagmarkdata/wine-1.1.44-245.html
>
> Just a question. What's this about?
>
> Vista Wine ratio
> heaven2_d3d9_Video_memory1024.00256.00 0.2
1 - 100 of 1246 matches
Mail list logo
