April 2011 - Wine-Devel - list.winehq.org

re: VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

by Dan Kegel

Nikolay wrote: >> Who has authority to approve it? > A patch? Alexandre Julliard, he's the only project maintainer. > Send a patch to wine-patches at winehq.org when you think > it's ready and you'll get some feedback if it's not. Be sure to send it to winetestbot first, and fix any problems it finds; see http://wiki.winehq.org/SubmittingPatches - Dan

April 24, 2011

Re: VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

by Nikolay Sivov

On 4/23/2011 22:46, John Fremlin wrote: > Nikolay Sivov<bunglehead(a)gmail.com> writes: > >> On 4/23/2011 22:22, John Fremlin wrote: >>> Nikolay Sivov<bunglehead(a)gmail.com> writes: >>> >>>> On 4/23/2011 19:00, John Fremlin wrote: >>>>> Europeans write dates generally as dd-mm-yyyy. This makes sense. So does >>>>> yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some >>>>> reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere >>>>> as far as I know and contradicts the MS behaviour. >>>>> >>>>> I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 >>>>> >>>>> I've included a patch which fixes the problem and adds a testcase. Is >>>>> there anything I can do to improve the chances that this fairly >>>>> unambiguous fix meets the next release? -- I have some secret and >>>>> cunning plans which are unfortunately predicated on this being fixed. >>>>> @@ -3458,6 +3458,7 @@ static void test_VarDateFromStr(void) >>>>> DFS("02.01.1970"); EXPECT_DBL(25570.0); >>>>> DFS("02.13.1970"); EXPECT_DBL(25612.0); >>>>> DFS("02-13-1970"); EXPECT_DBL(25612.0); >>>>> + DFS("2020-01-11"); EXPECT_DBL(43841.0); >>>> Hi, John. >>>> >>>> This is locale-dependent thing, so it will need at least more tests >>>> for different locales (locales with different default month/day order >>>> I mean). >>> Hi Nikolay, >>> >>> Is there really ever a locale which actually parses ydm under the native >>> implementation? >> Not really, as far as I know. My point was to test with different >> pattern anyway. For example for >> yyyy/mm/dd and dd/mm/yyyy locales. Also this particular test is not >> very descriptive cause >> month and day in it both fit month or day range, so you can't tell how >> it's interpreted. > I don't understand the confusion here? > > The single test extra test is explicitly for a date that can only be > converted either as y-m-d or the imaginary Wine-only y-d-m format. That > should be interpreted in exactly one way, and it is interpreted > incorrectly at the moment. The patch fixes that. Yes, I got it. Wine converts 2020-01-11 string as 1st of November while native treats it as 11th of January. What I meant that test data should be clear about what field is day and what's a month. For your case it could be '2020-01-30' to make 30 invalid value for a month. > If you want extra tests, I'm sure they'd be great, but I think this > pretty unambiguously represents an improvement. About additional tests, what about cases like '2020-20-01' on locales that use 'mm/dd/yyyy' or '2020-01-30' for locales that are 'dd/mm/yyyy'? Even if you're sure patch doesn't break that it's always better to add more tests (maybe some tests for that are in already). > Who has authority to approve it? A patch? Alexandre Julliard, he's the only project maintainer. Send a patch to wine-patches(a)winehq.org when you think it's ready and you'll get some feedback if it's not.

April 23, 2011

Re: VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

by Nikolay Sivov

On 4/23/2011 22:22, John Fremlin wrote: > Nikolay Sivov<bunglehead(a)gmail.com> writes: > >> On 4/23/2011 19:00, John Fremlin wrote: >>> Europeans write dates generally as dd-mm-yyyy. This makes sense. So does >>> yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some >>> reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere >>> as far as I know and contradicts the MS behaviour. >>> >>> I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 >>> >>> I've included a patch which fixes the problem and adds a testcase. Is >>> there anything I can do to improve the chances that this fairly >>> unambiguous fix meets the next release? -- I have some secret and >>> cunning plans which are unfortunately predicated on this being fixed. >>> @@ -3458,6 +3458,7 @@ static void test_VarDateFromStr(void) >>> DFS("02.01.1970"); EXPECT_DBL(25570.0); >>> DFS("02.13.1970"); EXPECT_DBL(25612.0); >>> DFS("02-13-1970"); EXPECT_DBL(25612.0); >>> + DFS("2020-01-11"); EXPECT_DBL(43841.0); >> Hi, John. >> >> This is locale-dependent thing, so it will need at least more tests >> for different locales (locales with different default month/day order >> I mean). > Hi Nikolay, > > Is there really ever a locale which actually parses ydm under the native > implementation? Not really, as far as I know. My point was to test with different pattern anyway. For example for yyyy/mm/dd and dd/mm/yyyy locales. Also this particular test is not very descriptive cause month and day in it both fit month or day range, so you can't tell how it's interpreted.

April 23, 2011

Re: VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

by John Fremlin

Nikolay Sivov <bunglehead(a)gmail.com> writes: > On 4/23/2011 19:00, John Fremlin wrote: >> Europeans write dates generally as dd-mm-yyyy. This makes sense. So does >> yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some >> reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere >> as far as I know and contradicts the MS behaviour. >> >> I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 >> >> I've included a patch which fixes the problem and adds a testcase. Is >> there anything I can do to improve the chances that this fairly >> unambiguous fix meets the next release? -- I have some secret and >> cunning plans which are unfortunately predicated on this being fixed. >> @@ -3458,6 +3458,7 @@ static void test_VarDateFromStr(void) >> DFS("02.01.1970"); EXPECT_DBL(25570.0); >> DFS("02.13.1970"); EXPECT_DBL(25612.0); >> DFS("02-13-1970"); EXPECT_DBL(25612.0); >> + DFS("2020-01-11"); EXPECT_DBL(43841.0); > Hi, John. > > This is locale-dependent thing, so it will need at least more tests > for different locales (locales with different default month/day order > I mean). Hi Nikolay, Is there really ever a locale which actually parses ydm under the native implementation? The patch is clearly an improvement I think . . . I could restrict it solely to apply to the English UK locale if that would satisfy the concern? It would meet my needs. I've tested it under English UK for all dates up to 100k (which crashed gcc amusingly until compiled without optimization).

April 23, 2011

Re: VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

by Nikolay Sivov

On 4/23/2011 19:00, John Fremlin wrote: > Europeans write dates generally as dd-mm-yyyy. This makes sense. So does > yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some > reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere > as far as I know and contradicts the MS behaviour. > > I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 > > I've included a patch which fixes the problem and adds a testcase. Is > there anything I can do to improve the chances that this fairly > unambiguous fix meets the next release? -- I have some secret and > cunning plans which are unfortunately predicated on this being fixed. > @@ -3458,6 +3458,7 @@ static void test_VarDateFromStr(void) > DFS("02.01.1970"); EXPECT_DBL(25570.0); > DFS("02.13.1970"); EXPECT_DBL(25612.0); > DFS("02-13-1970"); EXPECT_DBL(25612.0); > + DFS("2020-01-11"); EXPECT_DBL(43841.0); Hi, John. This is locale-dependent thing, so it will need at least more tests for different locales (locales with different default month/day order I mean).

April 23, 2011

Re: Matching Windows 7 folder locations?

by newsletter [at] Schiermeier-Software

Hello Dan, wdrwo> Windows 7 changed the folders in c:/users/$USERNAME around a bit. not only 'a bit'. There are a lot of changes in the folder structure since Vista: See URL: <http://msdn.microsoft.com/en-us/library/dd378457(v=VS.85).aspx> -- Joerg Schiermeier

April 23, 2011

ERROR: Compile wine tests on WINDOWS with MS C/C++

by Gerold Jens Wucherpfennig

Regarding: 5.5.4. Standalone, using the Microsoft C++ Toolkit of http://www.winehq.org/docs/winedev-guide/testing-windows : I tried to compile dlls/rasapi32/test/rasapi.c on Windows and got these error messages: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. rasapi.c .\wine/test.h(66) : error C2143: syntax error : missing '{' before 'const' .\wine/test.h(70) : error C2054: expected '(' to follow 'inline' .\wine/test.h(71) : error C2085: 'winetest_strcmpW' : not in formal parameter li st .\wine/test.h(71) : error C2143: syntax error : missing ';' before '{' -- Gerold

April 23, 2011

VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

by John Fremlin

Europeans write dates generally as dd-mm-yyyy. This makes sense. So does yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere as far as I know and contradicts the MS behaviour. I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 I've included a patch which fixes the problem and adds a testcase. Is there anything I can do to improve the chances that this fairly unambiguous fix meets the next release? -- I have some secret and cunning plans which are unfortunately predicated on this being fixed.

April 23, 2011

Re: Missing backtrace when debugging a game

by Eric Pouech

Le 23/04/2011 11:34, Jerome Leclanche a écrit : > I'm currently trying to debug http://bugs.winehq.org/show_bug.cgi?id=25977. > > Even when running "winedbg bin/release/loader.exe", this is what happens: > > Unhandled exception: page fault on read access to 0x00000000 in 32-bit > code (0x00365327). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:00365327 ESP:0033dd20 EBP:000003d9 EFLAGS:00010246( R- -- I Z- -P- ) EBP has a "strange" value, so likely the current function has been compiled without frame pointer support (or has been screwed up) you need the debug info associated with that program to go further. do you have it ? or does the exec contain FPO information (winedump could be handy here) "reading" the stack shows that calling function is at 0x3670f9 so disas 0x3670f9 might give you better info A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 23, 2011

Re: Missing backtrace when debugging a game

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 23.04.2011 um 11:34 schrieb Jerome Leclanche: > Any advice, or idea why this would happen? For example the stack could be broken > Furthermore, is it a bug with winedbg, and worth filing? If you think it is some problem with the debugger you may have more luck with gdb. On OSX this sometimes gives more helpful output. But I am afraid you'll need other debugging techniques like logfiles. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNsqKRAAoJEN0/YqbEcdMwjHIP+wZc/5gVsQ/a7NpNHu4w0bcm u7ZBMZFfa2vPFTj+FrvqCEI0YawIs7Jzu/f9mzslzKrAnp3Jj0u2ZnNClYOBeRSV EE1b+R91hyeclW9CybmgFX+gfQQcZR1Mu+8qHs9Bi3RtDkoeQc5HEpa2Y6lpf5Zj 7zEDoXFoR1wKW0GF2TC8AIeDmRH9ZV1UYkSPtvrGH54hSHH0tW+QReg1oXlwitym xvvqeBfvobOGSiC9faD6CG8R+YizDkUz6/4pjkV4B0qzpMEYn19f6cWRg32HduVh gXZPmkvOZTMTaBVRarKXAkSlNy++5U9tiQcdY4DM1zS/SMVBHWSXOnHLsMpFNgEU pJuSmBN3n0YJx2AcnVMNLO6UxkLCoyAF4GKhlfa74BNfQ5jNbdW4+MpiB/S+yIiC 55NIgXzh7b6k9iK1gJz8FAq/APIxNICKiOaoSiPX4NvTMqChZAZZ1akjJITbav/d msUuL98uxRjfvxu4b7k5qDf1rfY8AhKEC3fTRxuKoGNaqAcgKmGFVYyCQ2yw12NW pWugHQNgtxJU3pF7gc3DP2wEeQYZcq1gdkQs/NlftlWnKWuxcn1i+iEbfCjzBRcb krads/XDe/w8OP1LJdtLhR9LCU27evL+9YQ5xTMBJ1A2QG6uS3fVy0AiiRdEHi0x eN1II6SuucLuh3fdDB0w =J71s -----END PGP SIGNATURE-----

April 23, 2011