Re: services: Remove an unused variable.

2011-08-27 Thread Francois Gouget
On Fri, 26 Aug 2011, Frédéric Delanoy wrote:
[...]
  -        DWORD err;
          const WCHAR *argv[2];
          service = services_list[i];
          argv[0] = service-name;
          argv[1] = NULL;
  -        err = service_start(service, 1, argv);
  +        service_start(service, 1, argv);
          /* FIXME: do something if the service failed to start */
          release_service(service);
      }
 
 Wouldn't it be better to do something with err rather than muting (as
 the comment suggests)?

Maybe but what? The FIXME does not even say. In the meantime a FIXME 
comment is not a good enough reason to keep a compilation warning imho. 
And conversely fixing a compilation warning is not 'muting' a FIXME 
comment.


-- 
Francois Gouget fgou...@codeweavers.com  


Re: Hebrew: update

2011-08-27 Thread Francois Gouget
On Sat, 27 Aug 2011, Frédéric Delanoy wrote:

 On Fri, Aug 26, 2011 at 15:14, Francois Gouget fgou...@free.fr wrote:
  On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
  ...
  On the translation side I still think that copying untranslated strings
  over is wrong ...
 
 Actually, for standardization, empty msgstr should also be marked with
 , fuzzy IMHO.

Why?

An empty msgstr is unambiguously untranslated. Also I would define the 
standard by what the gettext tools do and when they generate a new po 
file they don't mark all empty msgstrs as fuzzy.

If the problem is that you have trouble finding untranslated messages in 
a text editor, then that's one point where having a dedicated PO editor 
helps (or emacs' PO mode).


-- 
Francois Gouget fgou...@free.fr  http://fgouget.free.fr/
  E-Voting: Those who cast the votes decide nothing.
 Those who count the votes decide everything.


Re: [PATCH] msiexec: implement a sane server stub (i.e. not while(TRUE); )

2011-08-27 Thread Bernhard Loos
On Fri, Aug 26, 2011 at 9:11 AM, Hans Leidekker h...@codeweavers.com wrote:
 On Fri, 2011-08-26 at 04:58 +0200, Bernhard Loos wrote:

 - * Copyright 2007 Google (James Hawkins)
 + * Copyright 2011 Bernhard Loos

 Please keep the original copyright information.


Well, there is basically nothing left of the original file.




Re: Hebrew: update

2011-08-27 Thread Frédéric Delanoy
2011/8/27 Francois Gouget fgou...@free.fr:
 On Sat, 27 Aug 2011, Frédéric Delanoy wrote:

 On Fri, Aug 26, 2011 at 15:14, Francois Gouget fgou...@free.fr wrote:
  On Tue, 23 Aug 2011, Yaron Shahrabani wrote:
  ...
  On the translation side I still think that copying untranslated strings
  over is wrong ...

 Actually, for standardization, empty msgstr should also be marked with
 , fuzzy IMHO.

 Why?

 An empty msgstr is unambiguously untranslated. Also I would define the
 standard by what the gettext tools do and when they generate a new po
 file they don't mark all empty msgstrs as fuzzy.

OK didn't know that
 If the problem is that you have trouble finding untranslated messages in
 a text editor, then that's one point where having a dedicated PO editor
 helps (or emacs' PO mode).

Not really a problem, it's just easier to find when you can have
translated multiline msgstr like
msgid some long text
msgstr 
some very long
translation

(I have to use relatively complex regexp to find those cases).

To remain consistent with the gettext tools, for multiline
translation, the generated po entry should be IMO sthg like
msgid some long text
msgstr some very 
long translation

i.e. the start of the translation remains on the same line as 'msgstr'

Frédéric




Re: services: Remove an unused variable.

2011-08-27 Thread Frédéric Delanoy
2011/8/27 Francois Gouget fgou...@codeweavers.com:
 On Fri, 26 Aug 2011, Frédéric Delanoy wrote:
 [...]
  -        DWORD err;
          const WCHAR *argv[2];
          service = services_list[i];
          argv[0] = service-name;
          argv[1] = NULL;
  -        err = service_start(service, 1, argv);
  +        service_start(service, 1, argv);
          /* FIXME: do something if the service failed to start */
          release_service(service);
      }

 Wouldn't it be better to do something with err rather than muting (as
 the comment suggests)?

 Maybe but what? The FIXME does not even say. In the meantime a FIXME
 comment is not a good enough reason to keep a compilation warning imho.
 And conversely fixing a compilation warning is not 'muting' a FIXME
 comment.

Well what the warning complains about is not technically fixed, just hidden.
I agree warnings are bad in general, but in this very case, you don't
solve the problem (absence of error checking) but simply hide the
symptom (warning).
(You could convert the commented fixme into a real one instead)

This is no different than changing

rc = myFun1(...)
rc = myFun2(...)
ok (rc...)

into

myFun1(...)
rc = myFun2(...)
ok (rc...)

which is generally frowned upon by AJ

Frédéric




Re: Hebrew: update

2011-08-27 Thread Shachar Shemesh

  
  
On 08/26/2011 04:35 PM, Yaron Shahrabani wrote:
  
It might sound weird but the Israeli community really doesn't
care
about this terminal bug

AFAIK, the Windows console does not do BiDi either (which would
  mean that, in order to be bug compatible with Windows, neither
  should wineconsole). To be fair, it has been quite a while since I
  last checked, so something may have budged on that front.
The greater problem is that BiDi console is an unsolvable
  problem. I have not played much with MLTerm, but with Konsole, I
  keep it as a handy "turn on, look, turn off" feature. Without a
  good semantic understanding of the string it is almost impossible
  to perform BiDi reordering, and the results vary from barely
  readable to undecipherable.
Shachar
  

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

  





buildbot status

2011-08-27 Thread Dan Kegel
- stability problems
The buildbot cluster is not ready for prime time yet.
My ubuntu 11.04-based slaves tend
to lock up within a day with either an OOM failure, an X livelock, or
something else.  So I brought an ubuntu 10.04.3 slave online and
moved the buildmaster off onto its own machine;
let's see what breaks next.

- Slave speed
Here is the complete build-and-test time (and the build time alone)
for four CPUs:
54 (48)  celeron @ 2.80 GHz (headless, so it's not running all tests)
17 (10)  E8400 @ 3.00GHz
14 (6)   Q9300 @ 2.50GHz
12 (4)   i7 920 @ 2.67GHz

I will probably stick with slaves that are core 2 duo or better,
so patches can get fast feedback.




Re: Hebrew: update

2011-08-27 Thread Yaron Shahrabani
On Sat, Aug 27, 2011 at 5:32 PM, Shachar Shemesh shac...@shemesh.biz wrote:
 On 08/26/2011 04:35 PM, Yaron Shahrabani wrote:

 It might sound weird but the Israeli community really doesn't care about
 this terminal bug

 AFAIK, the Windows console does not do BiDi either (which would mean that,
 in order to be bug compatible with Windows, neither should wineconsole). To
 be fair, it has been quite a while since I last checked, so something may
 have budged on that front.
Well... you can look at it that way, technically speaking you are
absolutely correct but since there is a fix that allows displaying and
working with Hebrew in terminal this decision is simply kicking in the
user's face.

Microsoft had this decision in Windows XP, many DOS apps that were
supported until Windows 98 were no longer supported and had to search
for alternative or keep using an unsupported operating system.
This move eventually forced most of these businesses to go with the
flow and pay thousands of dollars to upgrade their software after they
already spent thousands of dollars few years prior to the release of
XP.

Supporting forced end-of-life of a product? Seems very Microsoftish ☺

 The greater problem is that BiDi console is an unsolvable problem. I have
 not played much with MLTerm, but with Konsole, I keep it as a handy turn
 on, look, turn off feature. Without a good semantic understanding of the
 string it is almost impossible to perform BiDi reordering, and the results
 vary from barely readable to undecipherable.
The reason MLTerm is not widely used that it doesn't support themes
which makes the window look very ugly and not so friendly.
But MLTerm definitely works better than Konsole, If you have the time
to take a look at it you'll be surprised (Ignore the window
decorations of course).

What I'm saying is that unlike Microsoft which had its own political
reasons to cease their Hebrew support in console wine should support
it.
There is a way of using Hebrew in console, the fix is described in this URL:
http://eesh.net/WinHeb/

Works in Vista as well, doesn't work in Win7 though...

Kind regards,
Yaron Shahrabani.

 Shachar

 --
 Shachar Shemesh
 Lingnu Open Source Consulting Ltd.
 http://www.lingnu.com





Cmd tests timeout and splitting tests

2011-08-27 Thread Octavian Voicu
Hello,

I've noticed a lot of timeouts for cmd tests lately, which is not so
surprising with all the new incoming tests.

I think test_builtins.cmd should be split in a few files, which would
then be run separately. An added benefit is that it would permit
putting tests that affect other tests in separate files.

In order to fix the timeout problem it's not enough to split the tests
in different files. Each file has to be run on its own from winetest.

I see following solutions:

1) Hack winetest and increase timeout just for cmd.exe batch tests.

2) Allow individual tests to receive a parameter.

Downside is that make_ctests needs to be changed a bit (to recognize
filenames given as test.c:param), and a manual rule for running
MAKECTESTS needs to be added to the Makefile of those tests, which
would list all the tests + values for the params.

3) Add a new source file for each .cmd file.

All the batch running meat would still be in batch.c, with main test
function non-static. A header file with prototypes and a macro for
defining a test would be included in subsequent tests.


I would go for number 3, I think it's the cleanest solution (although
it would add a few more source files). Any comments on that?

Octavian




re: [PATCH] attrib: Move implementation from cmd.exe to the standalone command (try 2)

2011-08-27 Thread Dan Kegel
Hi Christian,
your patch causes test failures in programs/cmd/tests here:
...
batch.c:301: Test failed: unexpected char 0x41 position 0 in line 545
(got 'ATTRIB - Displays or changes file attributes.', wanted
'not-r.test not found after delete, good')
batch.c:295: Test failed: unexpected end of line 546 (got '', wanted
'r.test found before delete, good')
- Dan




Severe regression in wine startup latencies

2011-08-27 Thread Alan W. Irwin

The startup latency of commands run under wine-1.3.27 is much worse than it
used to be.

I did the following experiment with bash-3.1.17 that you get with the
latest (mingw-get-inst-20110802.exe) MinGW/MSYS installer.

wineconsole --backend=curses MinGW/msys/1.0/bin/bash.exe

Then I ran the following commands within that MSYS bash environment.

bash.exe-3.1$ which echo
/z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe

bash.exe-3.1$ time echo hello
hello

real0m0.000s
user0m0.000s
sys 0m0.000s

This shows there is at least one command (echo) available under wine
that executes with essentially zero latency.  So the problem cannot be
the time wine takes to read the executable file
(/z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe in this case). But
the rest of the commands I tried had latencies near 1 second.  (I only
report the second run in each case to make sure as much as possible is
cached in memory for maximum speed.)

bash.exe-3.1$ time bash --version
GNU bash, version 3.1.17(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.

real0m0.905s
user0m0.160s
sys 0m0.060s


bash.exe-3.1$ time cmake-2.8.5-win32-x86/bin/cmake --version
cmake version 2.8.5

real0m0.922s
user0m0.080s
sys 0m0.020s

bash.exe-3.1$ time make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i686-pc-msys

real0m0.540s
user0m0.100s
sys 0m0.020s

bash.exe-3.1$ time gcc --version
gcc.exe (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


real0m0.901s
user0m0.080s
sys 0m0.040s

Those are horrendous latencies.  The last time I did such tests
(for wine-1.3.9) the corresponding latency numbers were almost an order of 
magnitude
better, and Linux latencies were two orders (!) of magnitude better
than these.

==Linux latency results here

To prove those Linux latency results once again
here are the corresponding results under Linux:

wine@raven which echo
/bin/echo
wine@raven time echo hello
hello

real0m0.000s
user0m0.000s
sys 0m0.000s

wine@raven time bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

real0m0.001s
user0m0.004s
sys 0m0.000s

wine@raven time cmake --version
cmake version 2.8.2

real0m0.008s
user0m0.004s
sys 0m0.008s

wine@raven time make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu

real0m0.001s
user0m0.004s
sys 0m0.000s

wine@raven time gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


real0m0.001s
user0m0.000s
sys 0m0.000s

==End of Linux latency results

I compiled wine-1.3.27 with -O3, and I run it with the wineserver
turned on and

export WINEDEBUG='fixme-all'

Why is its command startup latency typically an order of magnitude
worse than previous wine versions (1.3.9 is the one I previously
tested in detail), and ~two orders of magnitude worse than the Linux
case?

Although startup latencies are not much of an issue if you are running
just one command such as a game, they are a serious issue for those
like me attempting to build software on the wine platform.  I
previously complained here about this issue for cmake-1.3.9 where
cmake configuration and make commands were roughly 2-3 times slower
than the corresponding Linux case because both commands execute _a
lot_ of subcommands where latency delays accumulate like crazy.  But
now that the wine-1.3.27 latency is 10 times worse than in the 1.3.9
case, typical cmake configurations are something like 25 (!) times
slower than the corresponding Linux command.

What can be done to address this bad command-startup latency
regression for wine?

I would be happy to run any tests that might point to a solution. For
example, I did run top from time to time while running the very long
cmake configuration step, and the cpu's (I have a duo core system)
were mostly idle indicating the latency bottleneck (whatever it is)
does not involve excessive amounts of cpu time.  However, wineserver

Re: Severe regression in wine startup latencies

2011-08-27 Thread Daniel Verkamp
On Sat, Aug 27, 2011 at 5:22 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
[...]
 bash.exe-3.1$ which echo
 /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe

 bash.exe-3.1$ time echo hello
 hello

 real    0m0.000s
 user    0m0.000s
 sys     0m0.000s

 This shows there is at least one command (echo) available under wine
 that executes with essentially zero latency.  So the problem cannot be
 the time wine takes to read the executable file
 (/z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe in this case). But
 the rest of the commands I tried had latencies near 1 second.  (I only
 report the second run in each case to make sure as much as possible is
 cached in memory for maximum speed.)

Aside from any actual slowdown, this test is not accurate - echo is a
shell builtin.  Try timing running the actual echo executable (with
full path) rather than just echo (which will run the builtin).