wine-devel July 2010

wine-devel@winehq.org

114 participants
459 discussions

Re: cmd: Fix cmd's mishandling of quote-enclosed command strings
by Jacek Caban 16 Jul '10

16 Jul '10

On 7/16/10 1:16 PM, Wilbert Ho wrote: > cmd mishandles quote-enclosed command strings because the leading > quote is included in the string when wine searches through the > built-in commands (dir is a builtin, but "dir is not). > > $ ./wine cmd.exe /c "dir README" > wine: cannot find L"C:\\windows\\system32\\dir.exe" > File not found > > To fix this, offset the string being compared to the array of builtins > by the number of leading quotes before doing the comparison. > +dir /b Makefile test_builtins.cmd +dir /b Makefile +dir /b test_builtins.cmd +dir /b "Makefile" +dir /b "test_builtins.cmd" +"dir /b Makefile" +"dir /b test_builtins.cmd" You can't assume that these files are present when running the test. If you need additional files for test, you have to create them in runtime. In this particular case it looks like you could choose other builtin command for test that doesn't require any additional file. Jacek

1 0

Re: cmd: Fix cmd's mishandling of quote-enclosed command strings
by testbot＠testbot.winehq.org 16 Jul '10

16 Jul '10

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=3340 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === W2KPROSP4 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === WXPPROSP3 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === W2K3R2SESP2 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === WVISTAADM (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === W2K8SE (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === W7PRO (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === W7PROX64 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d === W7PROX64 (64 bit) === batch.c:188: Test failed: unexpected end of output in line 46, expected 0x4d

1 0

Use of broken()
by James McKenzie 16 Jul '10

16 Jul '10

All: I've been making statements on the mailing list about some of the less documented features of Wine coding. I've also stated that asking questions is much better than asking permission....(in a very round about way.) So here goes: I am building a test for the EM_FINDWORDBREAK function in riched20. There are eight different test cases, but I found differences in one of them: WB_CLASSIFY: For the input value 0x85, Windows 7 returns the value 0x14. Windows 2000 and Windows NT 4 return a zero. Would it be appropriate to use the broken() function at this point? This has been the case for all test runs against these particular VMs on the testbot. I thank you in advance for assistance rendered. James McKenzie

1 0

Re: Please remove / block user from bugzilla
by James Mckenzie 16 Jul '10

16 Jul '10

Henri Verbeet <hverbeet(a)gmail.com> wrote: > >On 14 July 2010 16:26, Dan Kegel <dank(a)kegel.com> wrote: >> If you ask me, >> http://bugs.winehq.org/show_bug.cgi?id=6971#c371 >> is more objectionable, because it shows the Wine >> community to be ill-mannered and hostile to newbies. >Sure, it could have been worded more carefully, but I don't buy the >"taints us all" theory. > >However, if we're talking about being harmful to the project, I think >it's far more insidious and actively harmful to pretend being an >active / respected Wine developer and giving potential new developers >bad advice from that position. Because what happens is that those >people take that advice in good faith, start writing patches, and >perhaps even develop some habits based on it. But when those patches >then hit wine-patches and get shot down during review, it's the >reviewers that get blamed for being "picky" or "harsh", while in some >cases the entire premise on which those patches are based is simply >wrong. I think that does far more harm to new developers than "being >mean to someone on the internet". > >Of course with Wine being an open project there's not a whole lot we >can do about people saying whatever they like, except perhaps teaching >potential new developers about things like "git shortlog -s -n >--since={5year}". > On that vein of thought, why don't we have a code standard page? I've been asking this question and maybe this should be my next area of concern after the release of Wine 1.2 and the reinput of my patches. This way, I can use my 'years of expertise' and what I've learned about this project as far as coding practices. I don't want to wait on AJ to do this. James McKenzie

3 2

WINE - ODBC - MSSQL Server
by Sarves K 15 Jul '10

15 Jul '10

Hi I just tried to configure an windows application which requires a connection from a remote mssql server. But I not succeded in it. I am getting Connection failed : SQLState : '01000' SQL Server Error : 10061 ..................... Connection failed : SQLState : '08001' SQL Server Error : 17 .......... I set the connection type as TCP/IP and port number also were correct. What could be the reason.. Thanks Sarves Sri Lanka

1 0

re: Test questions: defining test structures as global variables and quick floating point reference
by Dan Kegel 15 Jul '10

15 Jul '10

Misha wrote: > 2) Finally, as you have noticed, per Dan's advice, I have implemented > this function: > ... > These seem, if anything, much simpler, and, I have noticed in the case > of very complicated test data, more accurate. > > I am going to change my code to use these latter functions, even though > they are not technically as good comparators as my current ones. If the simpler routines work, that's fine, go with what's most readable. It's still good to know about the issues raised in http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm for those times when it's hard to figure out the right epsilon ahead of time. - Dan

1 0

Re: WineConf 2010
by James Mckenzie 15 Jul '10

15 Jul '10

Francois Gouget <fgouget(a)free.fr> wrote: > >Hi, > > >WineConf 2010 is taking shape: the date has been set and we are now in >the final stages of picking the venue. > >The host city: Paris > Paris is a big city, where is the venue? James McKenzie

2 1

Test questions: defining test structures as global variables and quick floating point reference
by Misha Koshelev 15 Jul '10

15 Jul '10

Dear All: Thank you again for all your help. To remind you, I am working on fixing: http://bugs.winehq.org/show_bug.cgi?id=22918 And, as we are currently in code freeze, I have a GitHub repo here in which I am making relevant changes: http://github.com/misha680/wine/commits/master I am going over my patches and had a few questions with which I'd appreciate your help. Specifically, I'd like to know the answers, if possible, sooner rather than later, so that in case things come up later when I submit patches, I can simply reference the relevant wine-devel discussions. My questions are as follows. 1) In some tests, I need to declare global variables to store test data. For example, in this patch: http://github.com/misha680/wine/commit/17d2bb17d5868bd533dba6f1e1f9d8e6753b… I declare these structures: #define MAX_CYLINDER_VERTICES 1000 /* arbitrary */ D3DXVECTOR3 cylinder_test_vertex_data[MAX_CYLINDER_VERTICES]; 1a) Is this kosher? The other option would be to dynamically allocate, but this seems like a lot of overhead for a test. If I declare such structures _within_ functions, I seem to have problems with memory access to these structures (perhaps they are too big for stack)? 1b) I utilize similar structures in other tests. Currently, I declare a separate structure for each test? Is it preferable to: i) _declare a separate structure for each test, say: #define MAX_CYLINDER_VERTICES 1000 /* arbitrary */ D3DXVECTOR3 cylinder_test_vertex_data[MAX_CYLINDER_VERTICES]; #define MAX_SPHERE_VERTICES 1000 /* arbitrary */ D3DXVECTOR3 sphere_test_vertex_data[MAX_CYLINDER_VERTICES]; or ii) _declare a common structure for _all_ tests #define MAX_ALL_TEST_VERTICES 1000 /* arbitrary */ D3DXVECTOR3 all_test_vertex_data[MAX_CYLINDER_VERTICES]; and use such a structure in all my tests? 2) Finally, as you have noticed, per Dan's advice, I have implemented this function: /* http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm * "I think the answer is 10,000 but since floating point math is imperfect I’ll accept the maxUlps floats above and the maxUlps floats below that value." */ static BOOLEAN AlmostEqual2sComplement(float A, float B, int maxUlps) { int aInt, bInt, intDiff; /* Make sure maxUlps is non-negative and small enough that the * default NAN won't compare as equal to anything. */ assert(maxUlps > 0 && maxUlps < 4 * 1024 * 1024); aInt= *(int*)&A; /* Make aInt lexicographically ordered as a twos-complement int */ if (aInt < 0) aInt = 0x80000000 - aInt; /* Make bInt lexicographically ordered as a twos-complement int */ bInt = *(int*)&B; if (bInt < 0) bInt = 0x80000000 - bInt; intDiff = abs(aInt - bInt); if (intDiff <= maxUlps) return TRUE; return FALSE; } It works very nicely, and is most accurate. However, I have since noticed that mesh.c has the following functions defined: #define admitted_error 0.0001f #define compare_vertex_sizes(type, exp) \ got=D3DXGetFVFVertexSize(type); \ ok(got==exp, "Expected: %d, Got: %d\n", exp, got); static BOOL compare(FLOAT u, FLOAT v) { return (fabs(u-v) < admitted_error); } static BOOL compare_vec3(D3DXVECTOR3 u, D3DXVECTOR3 v) { return ( compare(u.x, v.x) && compare(u.y, v.y) && compare(u.z, v.z) ); } These seem, if anything, much simpler, and, I have noticed in the case of very complicated test data, more accurate. I am going to change my code to use these latter functions, even though they are not technically as good comparators as my current ones. If there are any objections/comments re this, please let me know. Thank you Misha

1 0

WineConf 2010
by Francois Gouget 15 Jul '10

15 Jul '10

Hi, WineConf 2010 is taking shape: the date has been set and we are now in the final stages of picking the venue. The host city: Paris The date: Saturday 20th and Sunday 21st of November So mark the date in your calendar and start booking your plane tickets; this will be the place to be for Wine developers. Note that most further communication will happen on the wineconf(a)winehq.org mailing list so subscribe there to get all the details. You will also find all the details you need as they become available on WineConf 2010's Wiki page: http://wiki.winehq.org/WineConf2010 -- Francois Gouget <fgouget(a)free.fr>

1 0

added some Git morsels
by Misha Koshelev 15 Jul '10

15 Jul '10

Dear All: Hope you are all doing well. Per Dan's suggestions, and since I have been working with GitHub, I have added some morsels to the Wiki page: http://wiki.winehq.org/GitWine * Per Mike Kaplinskiy's great advice, removing trailing whitespace: http://wiki.winehq.org/GitWine * For git-rebase -i, my own caveats about losing patches: http://wiki.winehq.org/GitWine#head-079f5369fdb9346845a4a8c82475eb7a198312be * Finally, a GitHub guide, with some of my own morsels: http://wiki.winehq.org/GitWine#head-0e6d3133a16d3a26de956c500675e5e623462a9e Hopefully this will be useful to future Wine developers. I am coming close to having D3DXCreateCylinder and Sphere working... however, unfortunately the real world calls (apparently my car is declared "totaled" per my insurance company... sigh). In any case, hoping 1.2 is just around the corner. Thank you Misha

1 0

← Newer
1
...
30
31
32
33
34
35
36
...
46
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2010