On Mon, Jan 30, 2012 at 23:21, Ken Thomases wrote:
> On Jan 30, 2012, at 10:09 PM, Austin English wrote:
>
>> @@ -1723,7 +1723,7 @@ then
>> saved_CFLAGS="$CFLAGS"
>> CFLAGS="$CFLAGS -Wlogical-op -Werror"
>> AC_CACHE_CHECK([for broken string.h that generates warnings with
>> -Wlogical-op]
On Jan 30, 2012, at 10:09 PM, Austin English wrote:
> @@ -1723,7 +1723,7 @@ then
>saved_CFLAGS="$CFLAGS"
>CFLAGS="$CFLAGS -Wlogical-op -Werror"
>AC_CACHE_CHECK([for broken string.h that generates warnings with
> -Wlogical-op], ac_cv_c_logicalop_noisy,
> - AC_COMPILE_IFELSE([AC_LA
On Mon, 30 Jan 2012, Scott Ritchie wrote:
[...]
> If the user never customizes the app-specific prefix with winecfg or
> similar, then copying the new registry should work yes?
Application configuration data (think Tools -> Options menu) is often
stored in the registry...
> > Besides that there
joerg-cyril.hoe...@t-systems.com skrev 2012-01-30 18:30:
> Of the same vein, one liners like
> EnterCS
> This-> playing = StateStopped;
> LeaveCS
> are suspicious too. What does that guarantee?
Perhaps that another thread doing as below isn't fooled into
calling both one() and three()?
EnterCS
i
On 01/30/2012 01:58 AM, Francois Gouget wrote:
> On Fri, 27 Jan 2012, Scott Ritchie wrote:
> [...]
>> To me, this sounds an awful lot like an overlay file system. Would
>> unionfs-fuse be the correct solution here? The .desktop file that sets
>> the Wine prefix and also launches the app could mou
2012/1/30 Vitaliy Margolen :
>
> I'm afraid you'll have to dig up some documentation about what is the max
> value here is then. The fact that it works doesn't mean it's correct.
>
> Vitaliy.
>
>
The only official documentation I can find is in
Documentation/input/ff.txt and it doesn't say anythin
On Mon, Jan 30, 2012 at 06:52:36PM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Andre Eikum wrote:
> >>> +sc = AudioQueueEnqueueBufferWithParameters(This->aqueue,
> >>> +This->public_buffer, 0, NULL, 0, 0, 0, NULL,
> >>> + &req_time, &start_time);
> >> NULL=ASAP is exa
joerg-cyril.hoe...@t-systems.com writes:
> Hi,
>
> Andrew Eikum wrote:
>>I wonder if it's appropriate for code freeze.
> You choose:
> - either 1.4 keeps the old code as is and suffers random dead-locks, or
> - 1.4 integrates code void of race-conditions on the basis of a solid design.
Can you po
joerg-cyril.hoe...@t-systems.com writes:
> Perhaps that way, the relationship is obvious.
>
> Please choose whether to apply the original patch #82900 or this one.
> It used instead "if(!err)" i.e. the 0 return code that ALSA documents.
The previous one was better, but you need to get rid of that
Hi,
Andre Eikum wrote:
>>> +sc = AudioQueueEnqueueBufferWithParameters(This->aqueue,
>>> +This->public_buffer, 0, NULL, 0, 0, 0, NULL,
>>> + &req_time, &start_time);
>> NULL=ASAP is exactly what we want. We don't want ALSA/dmix behavior,
>> where it'll silently skip over
Hi,
Andrew Eikum wrote:
>I wonder if it's appropriate for code freeze.
You choose:
- either 1.4 keeps the old code as is and suffers random dead-locks, or
- 1.4 integrates code void of race-conditions on the basis of a solid design.
>When working on this patch, were you able to identify
>specific
On Mon, Jan 30, 2012 at 11:03:52AM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> +sc = AudioQueueEnqueueBufferWithParameters(This->aqueue,
> +This->public_buffer, 0, NULL, 0, 0, 0, NULL, &req_time,
> &start_time);
> I advise against setting req_time. This can only frag
On Mon, Jan 30, 2012 at 11:37:17AM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Fixes bug #29657
>
While I like the idea of this patch and how you implemented it, I
wonder if it's appropriate for code freeze.
The main problem in that bug is that the CA driver can deadlock, or
release memory
On 01/30/2012 03:08 AM, joerg-cyril.hoe...@t-systems.com wrote:
Michael Stefaniuc wrote:
But now I see basestd.h defines LONG32.
LONG32 is kinda redundant. LONG is 32bit on all Windows
versions on 16bit, 32bit and 64bit Windows.
Ah, thank you. However in our particular case, the value that
ge
If I can say my opinion, I disagree on the usage of HeapAlloc/HeapFree for that
known amount of memory.
Instead, for granting compatibility with MSVC, I would continue to use a
structure in stack memory by simply using _alloca() and something like this:
LPBITMAPINFO bmi = (LPBITMAPINFO)
_alloca(
On 01/29/2012 04:31 PM, Marcel Hasler wrote:
The limit 0x7fff mentioned in input.h doesn't concern the number of
iterations, just durations. I couldn't find anything on an upper limit
for 'value'. I've tested 0x7fff and it works just fine.
I'm afraid you'll have to dig up some documentation
Folks,
We are now in code freeze, so all patches that are not obviously
harmless need to have a justification as to why the patch should be
applied. In most cases, that simply means pointing to the corresponding
bug that is fixed by the patch.
Patches that seem risky will be marked pending or def
Thomas Faber writes:
> This removes the use of a Variable-Length Array in ImageList_CreateImage
> and replaces it with HeapAlloc/HeapFree, as it is done in several
> other functions in this file.
> Alas, FIELD_OFFSET is "not const enough" for ANSI C.
Using sizeof instead would be preferable.
--
Michael Stefaniuc wrote:
>>But now I see basestd.h defines LONG32.
>LONG32 is kinda redundant. LONG is 32bit on all Windows
>versions on 16bit, 32bit and 64bit Windows.
Ah, thank you. However in our particular case, the value that
getbuf_last is derived from is UINT32, not UINT, so for symmetry,
I
Andrew,
The good news is that your underrun patch prevents mmdevapi from writing
less and less frames in mmdevapi/tests/render:test_worst_case
http://test.winehq.org/data/f0cfa7cf46d7c832fb8429d1a1b7c49c46c0/mac_jch-osx58-gecko/mmdevapi:render.html
>render.c:1631: Released 86436=98x882 -0 fram
On Fri, 27 Jan 2012, Scott Ritchie wrote:
[...]
> To me, this sounds an awful lot like an overlay file system. Would
> unionfs-fuse be the correct solution here? The .desktop file that sets
> the Wine prefix and also launches the app could mount the FUSE
> filesystem, and the user-space Wine pref
Hello Joerg,
On 01/30/2012 09:46 AM, joerg-cyril.hoe...@t-systems.com wrote:
thank you very much for finding a bug in my code.
I'll have to meditate signed/unsigned conversions for the next months.
Perhaps it's my lack of familiarity with the MS-Windows API that had
me not find a signed equiva
Andrew,
thank you very much for finding a bug in my code.
I'll have to meditate signed/unsigned conversions for the next months.
Perhaps it's my lack of familiarity with the MS-Windows API that had
me not find a signed equivalent of UINT32. Indeed there's none in
windef.h. So I choose 'long'. Bu
Please ignore this patch, it seems to break make crosstest.
Cheers
Rico
Am 30.01.2012 09:00, schrieb Rico Schüller:
Hi,
this is try 2 for fixing the build for d3dx9_36 without requiring to
make all includes.
Improvements:
- don't use a generic rule, use a file specific one
Cheers
Rico
---
Vitaliy Margolen writes:
> On 01/29/2012 10:54 AM, Dmitry Timoshkov wrote:
>> Austin English wrote:
>>
>>> Forgot the include changes.
>>
>> Forwarding it to LCMapString would be much better.
>>
>
> Also could we please stop adding stubs before the release? It seems
> every new stub dll opens up
25 matches
Mail list logo
