July 2013 - Wine-Devel - list.winehq.org

Re: Possibility of adding a new patch status

by Ken Sharp

There's also "Pending". On 30/07/13 04:16, Hugh McMaster wrote: > Hi everyone, > > Wine patches currently have a status described in http://source.winehq.org/patches, yet for patches with the status of 'New', the status becomes confusing. > > The legend describes 'New' status as "Patch not even looked at yet, there's still hope...". This is ideal for new patches submitted within that 24-hour commit cycle. > > But I'm finding it difficult to follow patches that remain with a status of 'New' for longer than the 24-hour patch cycle. Obviously, on the weekend, patches are held over till Monday, so a longer lead-time is expected. During weekdays, however, it is unclear what is happening with some patches. This, ultimately, raises the question of timeliness. > > Has the patch been looked at? If it has, the status often describes what action was taken - committed, rejected, superseded, etc. This is fine, but some patches remain with a status of 'New'. > > Experience has told me that patches remaining with a status of 'New' are incorrect in some way. But this is not always the case. > > If the patch is incorrect, but close to being accepted, the patch's status should reflect this, by changing to something like "Revision needed". Of course, the "Rejected" status is also appropriate, depending on the severity of coding error. > > Also, there are likely to be many times when the maintainer has not had time to evaluate some patches. This means the patch is not new (i.e. recently submitted), but is awaiting review. Once again, I believe the patch status should reflect this situation. The status could be "Not yet reviewed". > > In summary, the 'New' status should be reserved for patches that are actually new. > > Just some thoughts. > > > >

July 30, 2013

Re: [1/2] msxml3: Implement IMXAttributes_removeAttributes()

by Jacek Caban

Hi Nikolay, On 07/30/13 12:42, Nikolay Sivov wrote: > + dst = &This->attr[index]; > + src = &This->attr[index+1]; > + > + memmove(dst, src, This->length-index-1); *sizeof(*dst) Cheers, Jacek

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined >> >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. >> >> >> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real >> >> version. So for instance libtiff 3.9.7 has it defined to 20120922, >> >> 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate >> >> between 3.x and 4.x at compile time. >> > >> > I see that this patch is now marked as 'pending'. Are my arguments not >> > clear enough? >> >> You shouldn't check the version, but the actual problem (i.e. the size >> of the offending type). Also please avoid unnecessary changes. > > What changes do you consider as unnecessary? For instance, changing tsize_t when the problem is with toff_t. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2013

Re: [2/2] wininet: Handle NULL input string in str_to_buffer.

by 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.org/JobDetails.pl?Key=26482 Your paranoid android. === WXPX64 (64 bit http) === http.c:4661: Test failed: 4832: expected status 100 got 10 http.c:4661: Test failed: 4876: expected status 100 got 40 http.c:4634: Test failed: ar->dwResult = 0, expected 1 http.c:4661: Test failed: 4885: expected status 70 got 100 http: unhandled exception c0000005 at 0000000000495D94

July 30, 2013

Re: [1/2] wininet: Ignore INTERNET_FLAG_NO_CACHE_WRITE only for GET requests.

by 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.org/JobDetails.pl?Key=26481 Your paranoid android. === WXPX64 (32 bit http) === http.c:4588: Test failed: 4759: expected status 100 got 10 http.c:4588: Test failed: 4803: expected status 100 got 40 http.c:4561: Test failed: ar->dwResult = 0, expected 1 http.c:4588: Test failed: 4812: expected status 70 got 100 http: unhandled exception c0000005 at 7722EDEA

July 30, 2013

Re: [2/2] iphlpapi: Add partial support for the module classes in GetExtendedTcpTable and GetExtendedUdpTable.

by 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.org/JobDetails.pl?Key=26480 Your paranoid android. === WVISTAX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 74A19E2F === W2K8SE (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 7596A09A === W7PROX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 77E03915 === WVISTAX64 (64 bit iphlpapi) === Timeout === W7PROX64 (64 bit iphlpapi) === No test summary line found

July 30, 2013

Re: [1/2] iphlpapi: Add support for the listener and connection classes in GetExtendedTcpTable.

by 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.org/JobDetails.pl?Key=26479 Your paranoid android. === WVISTAX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 74A19E2F === W2K8SE (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 7596A09A === WVISTAX64 (64 bit iphlpapi) === Timeout

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined > >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. > >> > >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real > >> version. So for instance libtiff 3.9.7 has it defined to 20120922, > >> 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate > >> between 3.x and 4.x at compile time. > > > > I see that this patch is now marked as 'pending'. Are my arguments not > > clear enough? > > You shouldn't check the version, but the actual problem (i.e. the size > of the offending type). Also please avoid unnecessary changes. What changes do you consider as unnecessary? -- Dmitry.

July 30, 2013

Re: riched20: ITextDocument stubs for ITextServices (retry)

by Jacek Caban

On 07/29/13 17:55, Caibin Chen wrote: >> +struct tagReTxtDoc { >> + IUnknown *outerObj; >> + ME_TextEditor *editor; >> + ITextDocument iTextDocumentIface; >> +}; >> >> Do you really need a separated structure for that? Wouldn't adding ITextDocument implementation to ITextServicesImpl be enough? > This structure will be used in both ITexstServicesImpl and > IRichEditOleImpl(richole.c). For now IRichEditOleImpl has its own > implementation(stub) of ITextDocument and ITextSelection. A stub of > ITextSelection is needed before removing IRichEditOleImpl's own > implementation and use the separate one. > There are already several patches that are ready for review once this > patch get submitted. I see, assuming that substantial part of the implementation may really be shared between those objects, that makes sense. Bellow is review of the remaining part of the patch: +struct tagReTxtDoc { + IUnknown *outerObj; + ME_TextEditor *editor; + ITextDocument iTextDocumentIface; +}; Please follow http://wiki.winehq.org/COMGuideline about naming convention (*_iface names). +ITextDocument *ReTxtDoc_get_ITextDocument(ReTxtDoc *document) +{ + TRACE("(%p)\n", document); + return &document->iTextDocumentIface; +} Full declaration of ReTxtDoc in a header (so you don't need such helper) would be cleaner, IMO. new file mode 100644 index 0000000..02579b2 --- /dev/null +++ b/dlls/riched20/txtdoc.h How about using an existing header? Thanks, Jacek

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. >> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real >> version. So for instance libtiff 3.9.7 has it defined to 20120922, >> 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate >> between 3.x and 4.x at compile time. > > I see that this patch is now marked as 'pending'. Are my arguments not > clear enough? You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2013