On Fri, 29 Jan 2010, Austin English wrote:
> Flex isn't GLPv3, it's got a BSD license:
> http://flex.sourceforge.net/manual/Copyright.html#Copyright
You're right, and I had actually checked that a few weeks ago and
confused it with something else now.
Excellent. Please do file a PR against FreeB
On Fri, 29 Jan 2010, Austin English wrote:
> Right. But it's a bug in the sense that FreeBSD is shipping an
> _extremely_ old version of flex ;-).
True.
> Can you put in a request to update flex for FreeBSD 8.1/9.0? Or
> should I register/file a bug?
Filing a request is fine, if you want to do
On Fri, Jan 29, 2010 at 1:44 PM, Gerald Pfeifer wrote:
> On Fri, 29 Jan 2010, Austin English wrote:
>> Right. But it's a bug in the sense that FreeBSD is shipping an
>> _extremely_ old version of flex ;-).
>
> True.
>
>> Can you put in a request to update flex for FreeBSD 8.1/9.0? Or
>> should I r
On 01/29/2010 07:17 PM, Tony Wasserka wrote:
> Am 28.01.2010 21:42, schrieb Loïc Hoguin:
>>
>> What would be the solution then to have a chance to get Tony's work
>> committed if he can't/won't do the rest of the work himself
> FWIW, I handed in my skilled-work paper today, so I've had some spare
>
Am Friday 29 January 2010 15:01:55 schrieb Geoffrey Hausheer:
> Is there anything I can do to move this patch forward? I've fixed all the
> issues that have been raised so far. I have no dea what it is waiting on,
> and if there is anything I can do to get it committed or if it is just a
> questi
Am Friday 29 January 2010 01:20:24 schrieb Henri Verbeet:
> On 29 January 2010 00:21, Michael Stefaniuc wrote:
> > On 01/28/2010 10:59 PM, Henri Verbeet wrote:
> >> On 28 January 2010 22:39, Stefan Leichter
> >>
> >> wrote:
> >>> Is this a know problem? Is a work around available?
> >>
> >> Yeah,
Am 28.01.2010 21:42, schrieb Loïc Hoguin:
>
> What would be the solution then to have a chance to get Tony's work
> committed if he can't/won't do the rest of the work himself
FWIW, I handed in my skilled-work paper today, so I've had some spare
time today again. I just prepared a patch which imple
On Thu, Jan 28, 2010 at 7:03 PM, Gerald Pfeifer wrote:
> On Wed, 27 Jan 2010, Tom Wickline wrote:
>> The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is
>> installed from ports.
>>
>> # flex --version
>> flex version 2.5.4
>>
>> The version check passes on Linux and OpenSolaris but Free
Is there anything I can do to move this patch forward? I've fixed all the
issues that have been raised so far. I have no dea what it is waiting on,
and if there is anything I can do to get it committed or if it is just a
question of being patient. As I said previously I'd happily write a test
fo
On Friday 29 January 2010 12:21:27 Henri Verbeet wrote:
> On 29 January 2010 11:35, Stefan Dösinger wrote:
> > +static HMODULE d3d9_handle = 0;
>
> This is redundant.
>
> > +hr = IDirect3DVertexBuffer9_Lock(buffer, 0, 0, (void *) &bufstart,
> > 0); +ok(hr == D3D_OK, "IDirect3DVertexBuffe
Michael Stefaniuc writes:
> Anyway the usage of write(2) in NTDLL_dbg_vprintf() is *wrong* as it
> doesn't check for short writes nor errors. It is good enough for debug
> output and better than using the FILE * functions but not good enough to
> prevent interleaving. It even introduces an opport
On Friday 29 January 2010 12:02:39 Henri Verbeet wrote:
> You also
> seem to have a problem with storing derived limits in
> wined3d_gl_limits, but I don't see why. Where the limit is stored is a
> separate issue from what it contains though.
The name mostly. MaxSimultaneousTextures=8(with arbfp) d
Alexandre Julliard wrote:
> Michael Stefaniuc writes:
>
>> Incorrect. Wine doesn't use write(2) but vfprintf(3) which operates on
>> FILE handles; the output is buffered aka a vfprintf call won't translate
>> 1:1 to a write(2) system call. But even if it would directly use
>> write(2), that syste
On 29 January 2010 11:35, Stefan Dösinger wrote:
> +static HMODULE d3d9_handle = 0;
This is redundant.
> +hr = IDirect3DVertexBuffer9_Lock(buffer, 0, 0, (void *) &bufstart, 0);
> +ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock failed, 0x%08x\n", hr);
> +hr = IDirect3DVertexBuffer9_Unlo
Michael Stefaniuc writes:
> Incorrect. Wine doesn't use write(2) but vfprintf(3) which operates on
> FILE handles; the output is buffered aka a vfprintf call won't translate
> 1:1 to a write(2) system call. But even if it would directly use
> write(2), that system call isn't atomic. A lot of peop
On 29 January 2010 11:01, Stefan Dösinger wrote:
> On Friday 29 January 2010 00:55:19 Henri Verbeet wrote:
>> Almost. The texture_stages limit is supposed to indicate the number of
>> texture stages the GL implementation can support, I don't think
>> there's a reason to change that. What needs to
On Friday 29 January 2010 10:35:11 Henri Verbeet wrote:
> On 28 January 2010 22:50, Stefan Dösinger wrote:
> > + * Copyright (C) 2010 Stefan Dösinger(For CodeWeavers)
>
> Please use UTF-8 like the other source files. (I'd also suggest a
> space and a lowercase 'F').
Oh, crappy windows editor. I'l
Ken Thomases wrote:
> On Jan 28, 2010, at 5:21 PM, Michael Stefaniuc wrote:
>
>> On 01/28/2010 10:59 PM, Henri Verbeet wrote:
>>> On 28 January 2010 22:39, Stefan Leichter
>>> wrote:
Is this a know problem? Is a work around available?
>>> Yeah, that's a known problem. As a workaround y
On Wed, 27 Jan 2010, Tom Wickline wrote:
> The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is
> installed from ports.
>
> # flex --version
> flex version 2.5.4
>
> The version check passes on Linux and OpenSolaris but FreeBSD has a
> harder time with it.
>
> Gerald has a workaround f
On Friday 29 January 2010 00:55:19 Henri Verbeet wrote:
> Almost. The texture_stages limit is supposed to indicate the number of
> texture stages the GL implementation can support, I don't think
> there's a reason to change that. What needs to change is that we
> assign its value based on the fragm
Jason Edmeades writes:
> What I dont understand is why the NtClose for the handle does not
> remove it from the 'open' list - I think from my reading of the
> fd_destroy code it will put it onto the closed list if there are other
> references to the same inode, although thats where my debugging w
On 01/28/2010 05:48 PM, Henri Verbeet wrote:
Paul Vriens wrote:
Doesn't the DXGI_ERROR_NOT_FOUND return value tell us there is no D3D10
capable adapter (instead of any adapter)?
Possibly, but my understanding was that on Vista and higher DXGI is
shared across pretty much the entire graphics su
On 28 January 2010 22:50, Stefan Dösinger wrote:
> + * Copyright (C) 2010 Stefan Dösinger(For CodeWeavers)
Please use UTF-8 like the other source files. (I'd also suggest a
space and a lowercase 'F').
23 matches
Mail list logo
