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=23957
Your paranoid android
Am 16.01.2013 00:56, schrieb Marvin:
> 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
On 01/15/2013 01:08 PM, Piotr Caban wrote:
On 1/15/13 7:59 PM, Michael Ost wrote:
On 01/15/2013 03:39 AM, Piotr Caban wrote:
The crash is caused by incomplete FlsFree implementation. There's a
comment in it's code that says what needs to be added:
/* FIXME: add equivalent of ThreadZeroTlsCell h
On 1/15/13 7:59 PM, Michael Ost wrote:
On 01/15/2013 03:39 AM, Piotr Caban wrote:
The crash is caused by incomplete FlsFree implementation. There's a
comment in it's code that says what needs to be added:
/* FIXME: add equivalent of ThreadZeroTlsCell here */
Really? Are you sure that's it?
Yes
On Tue, Jan 15, 2013 at 9:15 PM, Damjan Jovanovic wrote:
> On Tue, Jan 15, 2013 at 9:06 PM, André Hentschel wrote:
>> Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
>>> Hi
>>>
>>> I've hacked together a simple tool for analyzing Wine code. Currently
>>> it can do the following:
>>> 1. Find BOOL f
On Tue, Jan 15, 2013 at 9:06 PM, André Hentschel wrote:
> Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
>> Hi
>>
>> I've hacked together a simple tool for analyzing Wine code. Currently
>> it can do the following:
>> 1. Find BOOL functions returning non-BOOL.
>> 2. Find HRESULT functions returnin
Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
> Hi
>
> I've hacked together a simple tool for analyzing Wine code. Currently
> it can do the following:
> 1. Find BOOL functions returning non-BOOL.
> 2. Find HRESULT functions returning non-HRESULTs.
> 3. Generate a TRACE() for each function showin
On 01/15/2013 03:39 AM, Piotr Caban wrote:
On 01/15/13 00:32, Michael Ost wrote:
Here's a link to a zip file that includes the prebuilt .exe and .dll
windows binaries that crash in wine. Plus the code.
https://dl.dropbox.com/u/97386125/msvcrt-dll-problem.zip
The crash is caused by incomplete F
On Tue, Jan 15, 2013 at 06:51:59PM +0100, Maarten Lankhorst wrote:
> Op 07-01-13 16:58, Andrew Eikum schreef:
> > This patch breaks the sound on Zaxxon[1] on both CoreAudio and ALSA
> > without PulseAudio. I didn't test OSS. It skips around on the ship's
> > shooting noises. I've attached good and
Damjan Jovanovic writes:
> I'd like to add the following features at some stage:
> * Populate all functions with a TRACE() of their arguments, if they
> don't already have it.
Please don't do that. There are many functions that we don't need to
trace, or that already have traces in sub-functions
Hi Kyle,
On Tue, Jan 15, 2013 at 8:10 AM, Kyle Auble wrote:
> The one thing that would probably help a lot is if there was a regularly
> updated tarball of the wiki content either at WineHQ or Lattica's FTP
> again. I
> haven't messed with cron itself much, but my archive.cron script should
> pa
Hi folks,
Thanks for all the help and hits -- much appreciated.
I ended up writing a few scripts myself that cleaned up
both the pages and users. It should do for now.
Please let me know if you see any problems with the
wiki, I hope I wasn't over-eager when cleaning up spam :)))
Cheers,
Dimi.
On Tue, Jan 15, 2013 at 1:06 PM, Dimi Paun wrote:
> Thanks everyone for your help!
> I'll take down the Pages spreadsheet.
> Now, what about the users? Those are files (not directories) so we don't
> face
> the same low limit (32k), but it would be nice if we could, somehow, cleanup
> those files
2013/1/15 Alexandre Julliard :
> Daniel Jelinski writes:
>
>> These are tests for bug 32529. Since commit
>> ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e
>> (Don't load bitmap glyphs when using subpixel rendering in GetGlyphOutline)
>> GetTextExtentPoint returns different results before and after gly
2013/1/15 :
> Christian costa wrote:
>>> But I don't know whether there's some harmless general SysEx that we
>>> can send out. Maybe some MIDI guru could suggest some?
>>What do you by harmless ? For what ? A midi HW device connected to the midi
>>port ?
>
> A harmless MIDI message, perhaps the
Christian costa wrote:
>> But I don't know whether there's some harmless general SysEx that we
>> can send out. Maybe some MIDI guru could suggest some?
>What do you by harmless ? For what ? A midi HW device connected to the midi
>port ?
A harmless MIDI message, perhaps there exists a NOP SysEx
On Mon, 14 Jan 2013 11:42:46 +0100
wrote:
> Hi,
>
> Johannes Kroll wrote:
> >+for(i = 0; i < lpMidiOutHdr->dwBufferLength; i++)
> >+if((unsigned char)lpMidiOutHdr->lpData[i] == 0xF7 && i <
> >lpMidiOutHdr->dwBufferLength-1)
>
> What about
> for(i = 0; i+1 < lpMidiOutHdr->dwBuf
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=23943
Your paranoid android
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-01-15 08:33, schrieb Henri Verbeet:
> If this fails, we're going to try hardware vertex processing
> again, but I don't think this is something we want to specify for
> every single test anyway. If this is just for a single test that
> needs so
Hi,
2013/1/15 :
> Hi,
>
> Christian costa wrote:
>>+lpNewData[lpMidiHdr->dwBufferLength + len_add] = 0xF7;
> Here you're using spaces only, whereas the surrounding code uses TAB8.
It was not intended for submission. If I submit a patch, I will
removed all these tabs.
>
>>I tested it
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=23941
Your paranoid android
Daniel Jelinski writes:
> These are tests for bug 32529. Since commit
> ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e
> (Don't load bitmap glyphs when using subpixel rendering in GetGlyphOutline)
> GetTextExtentPoint returns different results before and after glyphs are
> loaded,
> at least for wine
On 01/15/13 00:32, Michael Ost wrote:
Here's a link to a zip file that includes the prebuilt .exe and .dll
windows binaries that crash in wine. Plus the code.
https://dl.dropbox.com/u/97386125/msvcrt-dll-problem.zip
The crash is caused by incomplete FlsFree implementation. There's a
comment in
Hi,
Christian costa wrote:
>+lpNewData[lpMidiHdr->dwBufferLength + len_add] = 0xF7;
Here you're using spaces only, whereas the surrounding code uses TAB8.
>I tested it with the unit test attached.
Instead of some isolated unit test, it would be preferable to
add to winmm/tests/midi.c
Damjan Jovanovic wrote:
> What does this patch do? libv4l1.h includes libv4l1-videodev.h which
> is a copy of linux/videodev.h. You should only need the one or the
> other. Are you saying there is a system where libv4l1.h is present but
> incomplete, and you need to include linux/videodev.h toget
What does this patch do? libv4l1.h includes libv4l1-videodev.h which
is a copy of linux/videodev.h. You should only need the one or the
other. Are you saying there is a system where libv4l1.h is present but
incomplete, and you need to include linux/videodev.h together with it?
Thank you
Damjan
On
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=23929
Your paranoid android
27 matches
Mail list logo
