On Sun, Aug 29, 2010 at 7:00 PM, James McKenzie
wrote:
> One additional note: We should, as a project, not accept 'broken' code. I
> work with a real-time project and get paid for this that soon will have this
> policy in effect. No broken code, it is way to hard to go back and fix it
> later.
On Mon, Aug 30, 2010 at 8:00 AM, James McKenzie
wrote:
>
> Also, Max's code has shown up in another 'for pay' project and where
> implementation was done, works. Where implementation is not complete, it is
> seriously broken. The problem is where it works and does not work is not
> cleanly defin
On 08/29/2010 12:43 AM, Jeff Cook wrote:
On Tue, Aug 3, 2010 at 7:49 AM, Vitaliy Margolen
wrote:
+memcpy(ww->ds_desc.szDesc, description,
+min( (sizeof(ww->ds_desc.szDesc) - 1), strlen(description))
);
This does not guarantee that ww->ds_desc.szDesc will be \0 terminated.
Vi
On Sun, Aug 29, 2010 at 7:12 PM, Jeremy White wrote:
>> This could also help. If I recall correctly, Jeremy White mentioned
>> at Wineconf 2008 that this was a major reason they haven't invested
>> serious energy into one themselves: they had a hard time finding an
>> application that they cared
> This could also help. If I recall correctly, Jeremy White mentioned
> at Wineconf 2008 that this was a major reason they haven't invested
> serious energy into one themselves: they had a hard time finding an
> application that they cared about that benefited significantly from a
> DIB engine.
Juan Lang wrote:
Hi Jeff,
this has in fact come up before, and been addressed. The main problem
with the current attempt, as far as I know, is that the risk of
regressions is so high that only very high quality changes stand any
chance of getting accepted. In the case of a DIB engine, the atte
Octavian Voicu wrote:
Try running:
git config --global color.ui auto
This will activate colorful output for all git commands (in particular
for `git diff' too).
Then, when you run `git diff' from a terminal you will see whitespace
errors (eg. trailing whitespace) highlighted with a red backgro
David Adam wrote:
Looks like you are trying very hard to avoid the [try 4] moniker.
Please add this to each version of the patch you are submitting. Use
the notes feature of git commit to put in why you are submitting a new try.
Second, if the patch will NOT apply due to whitespace issues,
Try running:
git config --global color.ui auto
This will activate colorful output for all git commands (in particular
for `git diff' too).
Then, when you run `git diff' from a terminal you will see whitespace
errors (eg. trailing whitespace) highlighted with a red background.
Hope it helps,
Oct
Hi Jeff,
this has in fact come up before, and been addressed. The main problem
with the current attempt, as far as I know, is that the risk of
regressions is so high that only very high quality changes stand any
chance of getting accepted. In the case of a DIB engine, the attempts
have usually r
On 29 August 2010 20:45, David Adam wrote:
>
- You clearly ignored my previous comments about trailing spaces.
- This patch changes a lot more things than just allowing DDSCL_NORMAL
| DDSCL_FULLSCREEN. E.g. the call to
IWineD3DDevice_AcquireFocusWindow().
- Still needs more tests. For example, is
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=4844
Your paranoid android.
W dniu 29.08.2010 18:33, Octavian Voicu pisze:
2010/8/29 Mariusz Pluciński:
Could you tell me is there proper way to tell make to track changes in my
custom file? Expected effect is running wrc while build if there was
modification in my .gdf.xml file (currently, it is started only if .rc file
w
2010/8/29 Mariusz Pluciński :
> Could you tell me is there proper way to tell make to track changes in my
> custom file? Expected effect is running wrc while build if there was
> modification in my .gdf.xml file (currently, it is started only if .rc file
> was modified). Of course, Makefiles in Win
W dniu 26.08.2010 18:34, (Marvin) pisze:
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/Jo
2010/8/29 :
>
> Hope i don't bother you much, but i guess you would tell me...
>
> I still have a problem with FarCry installer. During that i found
> HEAP issue - based on assumption, that message "Heap invalid in-use
> arena magic 00eefeee" is unhealthy.
>
> So program allocates 6fc bytes at 0x1
On 28 August 2010 23:35, Misha Koshelev wrote:
> One point of clarification if possible.
>
> The need for D3DXFVFFromDeclarator() from the standpoint ID3DXMesh is
> for the GetFVF() function.
>
> It seems, per dlls/d3d9/tests/vertexdeclaration.c test_decl_to_fvf
> that the same functionality (to r
On Sun, Aug 29, 2010 at 6:18 AM, Jeff Cook wrote:
> Alexandre is right that the
> architecture is a lot of work, but I am not asking for him to write
> out a complete spec, and I don't think the community is, either; the
> main thing, as far as I can tell, is that the interaction and feedback
> on
I hate to stir the pot, especially as an unknown in the community, but
I've spent the last few hours reading WINE's history regarding DIB
engines and it is pretty distressing.
I have seen expressions of frustration from many regarding the
handling of the mostly-functional DIB engine that Massimo w
On 08/29/2010 02:36 AM, James McKenzie wrote:
Alexandre:
Can we avoid a typo by substituting:
"Did not returned \n"
with
"Did not return \n"
for each instance in the file?
Thank you.
James McKenzie
Sorry for the typo, I guess I wrote it too fast.
And no problem, I'll send a try2.
Hope i don't bother you much, but i guess you would tell me...
I still have a problem with FarCry installer. During that i found
HEAP issue - based on assumption, that message "Heap invalid in-use
arena magic 00eefeee" is unhealthy.
So program allocates 6fc bytes at 0x14c160 and free those bytes
21 matches
Mail list logo
