Re: d3dx9: Implement D3DXSHEvalConeLight
Hi,
in addition to what I already told you in #winehackers (that is,
please rename the test struct field red_in to red_out and red_out to
red_expected, or something like that), you should take the chance to
do some more cleanup. That means e.g. use "const" instead of "CONST"
as Rico already suggested and fix the indentation of the last comment
you're adding.
There are a few other things I don't really like but it's about code
style and my personal preferences, so you are free to ignore them.
I'd write the test structure declaration as:
struct
{
float *red_out, *green_out, *blue_out;
const float *red_expected, *green_expected, *blue_expected;
float radius, red_offset, green_offset, blue_offset;
}
test[] =
{
{rout, gout, bout, table, &table[72], &table[144], 0.5f, 1.01f,
1.02f, 1.03f},
...
(I'm sure Gmail will wrap and make this piece of code unreadable, but well...)
In general I'd also avoid using caps in variable names (e.g.
r_intensity instead of Rintensity).
Re: [PATCH] netstat: Clarify labels in UDP statistics.
On 2013-02-09 23:15, Frédéric Delanoy wrote: "Invalid Datagrams" is too vague. It could mean datagrams sent or received. I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it. On 2013-02-09 23:15, Frédéric Delanoy wrote: If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating This isn't (only) a translation ambiguity issue, this is about the original texts, especially "No Ports". Or are you trying to suggest that I add #msgctxt#udp_received_stats# to that "Invalid Datagrams"? -- Lauri Kenttä
Re: [PATCH 2/4] urlmon: Fixed QueryInfo tests during BINDSTATUS_PROXYDETECTING notification
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=24361 Your paranoid android. === WVISTAADM (32 bit url) === url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1868: Test failed: binding failed: 800c0005, expected 800c0019 url.c:1879: Test failed: res = 2efd, expected 800c0019 url.c:3024: Test failed: Got 800c0005 url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 800c0019 url.c:1879: Test failed: res = 2efd, expected 800c0019 url.c:3024: Test failed: Got 800c0005 url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2efd, expected url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3153: Test failed: expected OnDataAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2efd, expected url.c:3027: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3028: Test failed: unk == NULL url.c:3030: Test failed: Expected security problem to be ignored. url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected url.c:1879: Test failed: res = 2ee7, expected url.c:3353: Test failed: expected Obj_OnProgress_SENDINGREQUEST url.c:3357: Test failed: expected OnResponse url.c:3359: Test failed: expected Obj_OnProgress_MIMETYPEAVAILABLE url.c:3360: Test failed: expected Obj_OnProgress_BEGINDOWNLOADDATA url.c:3366: Test failed: expected Obj_OnProgress_CLASSIDAVAILABLE url.c:3367: Test failed: expected Obj_OnProgress_BEGINSYNCOPERATION url.c:
Re: [PATCH 2/4] urlmon: Fixed QueryInfo tests during BINDSTATUS_PROXYDETECTING notification
On 02/12/13 17:32, Marvin wrote: > 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=24361 > > Your paranoid android. > > > === WVISTAADM (32 bit url) === > url.c:1868: Test failed: binding failed: 800c0005, expected > url.c:1879: Test failed: res = 2ee7, expected > url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 > url.c:3036: Test failed: unk == NULL > (...) These seem to be (random) network failure. I've got it all succeeding before sending patches: https://testbot.winehq.org/JobDetails.pl?Key=24358 Jacek
Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
On Tue, 12 Feb 2013 15:49:18 +0100 wrote: > Hi, > > Johannes Krol wrote: > >Joerg, if you want the complete log I can send it to you by PM, it's > >about 1.7M. > I don't need that for now. What I need are the 119 missing bytes between > 17.015:003b:trace:midi:modLongData dwBufferLength=125 ! > 17.015:003b:trace:midi:modLongData F0 42 40 ... 00 00 00 > > Please copy&paste & adapt this code to produce a full hex dump: > http://source.winehq.org/source/dlls/winmm/winmm.c#L1066 > > In particular, I want to know if there's some F7 amid that data > (remember that your original patch precisely stopped at a F7...) > and what the bytes following that F7 look like. 9.532:0023:trace:winmm:MMDRV_Message Calling message(dev=2 msg=59 usr=0x8000 p1=0x00b281b8 p2=0x0040) 9.532:003a:warn:midi:modLongData Alleged system exclusive buffer is not correct Please report with MIDI file 9.532:0023:trace:midi:ALSA_midMessage (0002, 003B, 8000, 00B281B8, 0040); 9.532:003a:trace:midi:modLongData dwBufferLength=88 ! f0 42 9.532:0023:trace:midi:midAddBuffer (0002, 0xb281b8, 0040); 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.K@z. 7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@... 00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ...@..|. 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 01 7f f7 00 00 00 9.532:003a:trace:midi:modLongData dwBytesRecorded=0 So there is an F7 there... Maybe the app expects that the driver scans through the buffer for the F7 and doesn't send the following bytes... In any case, adding an F7 at the end works for my hardware but it isn't correct...
winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
Hi, Johannes Krol wrote: >Joerg, if you want the complete log I can send it to you by PM, it's >about 1.7M. I don't need that for now. What I need are the 119 missing bytes between 17.015:003b:trace:midi:modLongData dwBufferLength=125 ! 17.015:003b:trace:midi:modLongData F0 42 40 ... 00 00 00 Please copy&paste & adapt this code to produce a full hex dump: http://source.winehq.org/source/dlls/winmm/winmm.c#L1066 In particular, I want to know if there's some F7 amid that data (remember that your original patch precisely stopped at a F7...) and what the bytes following that F7 look like. >This could be interpreted to mean that Windows will add the 0xF7 >marker, if it was missing, when any other MIDI message is sent. That's a possible interpretation, however your log snippet shows no sign of sending another message. Do you have MIDI/ALSA debugging tools that can show you whether ALSA truly sends out the 125 bytes? That too would help identify the problem. Thank you, Jörg Höhle
Re: Where to put Chinese translation of the Wine user guide?
Am 12.02.2013 13:10, schrieb Jactry Zeng: > Hi folks, > > A Chinese Wine user Liu Hongcong had translated [1] the Wine user guide > [2] to Chinese three years ago, the translation looks mostly good to me. > It is a pity to leave his translation outside of the official wine website. > With his consent, I want to put his translation to winehq. But I can't find > where to add it into in website's source [3]. Or I should add it into wiki? > > Thanks for any comment! > > [1] http://blog.csdn.net/hongmy525/article/details/2238600 > [2] http://www.winehq.org/docs/wineusr-guide/index > [3] http://source.winehq.org/git/website.git/ It belongs here: http://source.winehq.org/git/docs.git/tree The guides have a po system it seems. see the "fr" folder for the french translation. It might make it a harder work than just copy&paste, though it's maybe a good idea that this get's touched again. -- Best Regards, André Hentschel
Where to put Chinese translation of the Wine user guide?
Hi folks, A Chinese Wine user Liu Hongcong had translated [1] the Wine user guide [2] to Chinese three years ago, the translation looks mostly good to me. It is a pity to leave his translation outside of the official wine website. With his consent, I want to put his translation to winehq. But I can't find where to add it into in website's source [3]. Or I should add it into wiki? Thanks for any comment! [1] http://blog.csdn.net/hongmy525/article/details/2238600 [2] http://www.winehq.org/docs/wineusr-guide/index [3] http://source.winehq.org/git/website.git/
Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
On Mon, 11 Feb 2013 19:41:27 +0100
wrote:
> Johannes Kroll asked:
> >Did this patch get through? I don't see it on
> >http://source.winehq.org/patches/ ...
>
> It did.
> You looked too late in patches/. Committed patches are deleted sooner than
> rejected ones that are in turn deleted sooner than new/pending patches.
Okay.
> I'm still interested in your testing my other MIDI patches. I fact I have a
> queue of half a dozen patches ready for submission, except that I'd like
> somebody to test them with real MIDI HW.
>
> There's another patch yet to be written: midiOutLongMessage CAN be used for
> coalesced non-sysex messages. This affects winealsa. Wineoss needs no
> change,
> because it simply dumps the bytes, one by one, regardless of SysEx or
> standard message. ALSA needs different API functions to be used. I've yet
> to check MacOSX CoreMIDI.
You asked me to test what happens when I remove the code that adds
F0/F7 markers when they are missing. I changed modLongData like this:
[...]
/* FIXME: MS doc is not 100% clear. Will lpData only contain system
exclusive
* data, or can it also contain raw MIDI data, to be split up and sent to
* modShortData() ?
* If the latest is true, then the following WARNing will fire up
*/
if (lpData[0] != 0xF0 || lpData[lpMidiHdr->dwBufferLength - 1] != 0xF7) {
WARN("Alleged system exclusive buffer is not correct\n\tPlease report
with MIDI file\n");
lpNewData = HeapAlloc(GetProcessHeap(), 0, lpMidiHdr->dwBufferLength +
2);
}
else
{
WARN("modLongData got SysEx message with correct F0/F7 markers.\n");
}
TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
TRACE(" %02X %02X %02X ... %02X %02X %02X\n",
lpData[0], lpData[1], lpData[2], lpData[lpMidiHdr->dwBufferLength-3],
lpData[lpMidiHdr->dwBufferLength-2],
lpData[lpMidiHdr->dwBufferLength-1]);
switch (MidiOutDev[wDevID].caps.wTechnology) {
case MOD_FMSYNTH:
/* FIXME: I don't think there is much to do here */
break;
case MOD_MIDIPORT:
if (lpData[0] != 0xF0) {
//~ /* Send start of System Exclusive */
//~ len_add = 1;
//~ lpNewData[0] = 0xF0;
//~ memcpy(lpNewData + 1, lpData, lpMidiHdr->dwBufferLength);
//~ WARN("Adding missing 0xF0 marker at the beginning of "
//~ "system exclusive byte stream\n");
WARN("*** Not adding missing 0xF0 marker.\n");
}
if (lpData[lpMidiHdr->dwBufferLength-1] != 0xF7) {
//~ /* Send end of System Exclusive */
//~ if (!len_add)
//~ memcpy(lpNewData, lpData, lpMidiHdr->dwBufferLength);
//~ lpNewData[lpMidiHdr->dwBufferLength + len_add] = 0xF7;
//~ len_add++;
//~ WARN("Adding missing 0xF7 marker at the end of "
//~ "system exclusive byte stream\n");
WARN("*** Not adding missing 0xF7 marker.\n");
}
[...]
I then started the korg kontrol editor with the nanopad2 attached to
USB. It does find the nanopad correctly, and it can receive the scene
set correctly. But when I try to write the scene set, it fails with a
timeout message box.
The log first indicates several SysEx message with included F0/F7 is
requested to be written, this looks like this:
2.663:0031:trace:midi:modLongData (, 0x1cbc10, 0040);
2.663:0031:warn:midi:modLongData modLongData got SysEx message with correct
F0/F7 markers.
2.663:0031:trace:midi:modLongData dwBufferLength=6 !
2.663:0031:trace:midi:modLongData F0 42 50 ... 00 01 F7
Then, a SysEx with start marker, but no end marker is requested to be
sent (and I don't add the end marker):
17.015:003b:trace:midi:ALSA_modMessage (0005, 0008, 8001, 001CA7A8,
0040);
17.015:003b:trace:midi:modLongData (0005, 0x1ca7a8, 0040);
17.015:003b:warn:midi:modLongData Alleged system exclusive buffer is not
correct
Please report with MIDI file
17.015:003b:trace:midi:modLongData dwBufferLength=125 !
17.015:003b:trace:midi:modLongData F0 42 40 ... 00 00 00
17.015:003b:warn:midi:modLongData *** Not adding missing 0xF7 marker.
17.015:003b:trace:midi:modLongData client = 20 port = 0
17.015:003b:trace:midi:MIDI_NotifyClient wDevID = 0005 wMsg = 969 dwParm1 =
1CA7A8 dwParam2 =
17.015:003b:trace:driver:DriverCallback (0023, task 0002, 0x8001, 03C9,
00B28110, 001CA7A8, )
17.015:003b:trace:driver:DriverCallback Done
17.015:003b:trace:winmm:MMDRV_Message => MMSYSERR_NOERROR
17.015:0023:trace:winmm:midiOutUnprepareHeader (0x8001, 0x1ca7a8, 64)
17.015:0023:trace:winmm:MMDRV_Get (0x8001, 0003, N)
17.015:0023:trace:winmm:MMDRV_Message (MidiOut 5 6 0x8001 0x001ca7a8
0x0040)
17.015:0023:trace:winmm:MMDRV_Message Calling message(dev=5 msg=6
usr=0x8001 p1=0x001ca7a8 p2=0x0040)
17.015:0023:trace:midi:ALSA_modMessage (0
