Re: services: Remove an unused variable.
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
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); )
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/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/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
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
- 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
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
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)
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
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
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).
