Re: Hebrew: update
On Sat, 27 Aug 2011, Frédéric Delanoy wrote: [...] 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). Again this won't be a problem if you a PO tool for edition or use Emacs' PO mode. 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 Again this is not what the PO tools do and it is them that format the PO file when Alexandre updates them. Besides for long messages the msgid string starts on the next line so the msgstr should do the same. You could complain about this to the gettext authors though (I just doubt they would change it). -- 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: buildbot status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Is it possible to set up a slave that e.g. runs only the d3d tests? I have some older machines with older GPUs that are still worth covering(Radeon X1600, Geforce 7, maybe even the Radeon 9000 mobility), but I am not sure if the machines as a whole are powerful enough to run all the tests. I think there isn't really a need to run the mostly platform independent tests like msi and shell32 everywhere. Stefan Am 27.08.2011 um 21:00 schrieb 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. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOWgeDAAoJEN0/YqbEcdMwLc8P/R9xTvNW/1pMB+lPRHyPI2U5 5TuLYenjPfBZl5iCBa6JQ8WOiZWhHTkeVR3DWoW9c2gawYnVt3GSDjpt92DDNmQ+ pn22jt8zHog8OrVpnJ4r3QrOZU6ssyYT/xqAEUQidky/qb12EmYWImMKC8n6Z+C+ iSvi5u+CEanvJCXL3Ce8ZexnTC77qXIRVdH1uvU5eQbTIoXTsQmbgroonnxq+LO1 4tesPh0rDsuwxKaljwlu0OUWZEvf9qHIBC297Hu6SWwLXngktFpGj2nCOuliZOLf HPgm2I9D/YTKPhNp4gB5RSu5/0sQaLr/ywj1xof+osgWocEe9xXeWhI1X2HEBXnH 2ThgHPXbHFTFdyqvWCO0TdHk3oL2v142rQQeR0CklBqqWp+lSXSdl8y83d6Zty0v jrcIlgHwRidnrMtrT9ZHpY+qq8otjMWTdw8G6cY81wRaw/fCesEiinxz7LW9mOn0 nkj8ZOiZnS/xTEws/qXWrepFx5UuuXM2n+ETHvye7AX7H080iba1uAgWl1ecBw7+ 12bxM7De2Pp/VTiBCK7Ngfk2lQ+JHf8qE3T0GlJWkMOvCRoItt9kNdCYzZ4Jykh0 mbwXsCkI7WrtBDESkwt+2zl4KbUl7LJVI+Mv1g5CunzDyBlRr+ldZBfKGHVfLhX9 y2sy4RppkWdctvsufQxA =vXXK -END PGP SIGNATURE-
Re: buildbot status
On 08/27/2011 12:00 PM, Dan Kegel wrote: - 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. I can get to work on backporting all the things Wine needs to the buildbot for 10.04, btw. Thanks, Scott Ritchie
Re: Hebrew: update
On Sat, 27 Aug 2011, Yaron Shahrabani wrote: [...] 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. I did some tests in Windows 7. cmd, ipconfig and net are translated to French but not to Russian (LTR), Japanese (LTR) or Hebrew (RTL). So I don't know if it would support the output of RTL strings from console applications such as usage or error messages. If anyone knows of an application I could test. In all cases the prompt is LTR (the path itself being an LTR string anyway: c:\Users\...). -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.
Re: buildbot status
On Sun, Aug 28, 2011 at 2:16 AM, Stefan Dösinger stefandoesin...@gmx.at wrote: Is it possible to set up a slave that e.g. runs only the d3d tests? I have some older machines with older GPUs that are still worth covering(Radeon X1600, Geforce 7, maybe even the Radeon 9000 mobility), but I am not sure if the machines as a whole are powerful enough to run all the tests. I think there isn't really a need to run the mostly platform independent tests like msi and shell32 everywhere. Yes, I can set up a builder type that only triggers on d3d-related changes and only runs d3d tests. - Dan
Re: Severe regression in wine startup latencies
On 2011-08-27 18:11-0700 Daniel Verkamp wrote: 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). You are absolutely right. bash.exe-3.1$ time /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe hello hello real0m0.503s user0m0.080s sys 0m0.020s Also, I tried time (x; x; x; x; x; x; x; x; x; x), where x represents the complete echo command above, and the result was real0m5.281s user0m0.800s sys 0m0.200s In other words, it is the executable echo command that has the latency, not the built-in time command or built-in echo command. I have done some other time tests on MSYS bash built-ins such as test, and they were essentially instantaneous as well while the executable versions were slow (~0.5 seconds like above). Does this difference between built-in and executable latency give a clue about what the issue is? To move to a slightly different topic, after reviewing my previous notes about the 0.150 second latency of commands for 1.2-rc3 (the last time I checked this), it appears that I tested latency a different way, e.g., wine@raven time wine MinGW/bin/mingw32-make.exe --version GNU Make 3.82 Built for i386-pc-mingw32 Copyright (C) 2010 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.405s user0m0.080s sys 0m0.040s A half second is a huge amount of computer time. This time does not appear to be due to wine setup since if you misspell the executable name you get fast results: wine@raven time wine MinGW/bin/mingw32-make.exe1 --version wine: cannot find 'MinGW/bin/mingw32-make.exe1' real0m0.006s user0m0.000s sys 0m0.008s This style of latency check corresponds to the cmake MinGW Makefiles generator approach which builds with pure MinGW commands without using MSYS at all so these sorts of latency checks are still relevant to the fundamental question of reducing overall latency of CMake builds on wine. My notes imply the above correctly spelled command took only 0.150 seconds for 1.2-rc3 which implies a factor of 3 regression in latency for wine 1.3.27. However, for those old tests my MinGW/MSYS software stack was different so I will attempt to replicate them again (and also the bash timing versions above) with the only change being wine-1.2 versus wine-1.3.27. I will also, just for kicks, try wine-bash (a much older bash version that started as a port of bash to NT) timing tests as well for the two wine versions. While I am doing those additional investigations, please consider the question of why there is a huge difference between built-in and executable latency for MSYS bash commands under wine. To start that investigation it would be good to compare the wine results for those two cases with the Windows results for those two cases. (I assume the two time results for built-in versus executable will be fairly similar in the Windows case, but that assumption needs to be checked.) I don't have access to Windows myself. Anybody up for doing that simple test and reporting the results back here? The automatic MinGW/MSYS installer at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/ makes it easy to install the relevant MinGW/MSYS software on both wine and Windows. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: Hebrew: update
On 08/28/2011 01:19 PM, Francois Gouget wrote: On Sat, 27 Aug 2011, Yaron Shahrabani wrote: [...] 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. I did some tests in Windows 7. cmd, ipconfig and net are translated to French but not to Russian (LTR), Japanese (LTR) or Hebrew (RTL). So I don't know if it would support the output of RTL strings from console applications such as usage or error messages. If anyone knows of an application I could test. Yes. It's called "type". Take a Hebrew text stored in a Windows 1255 encoded file, and "type file", see what happens. The order, if I understand this correctly, will be logical. For ease of use: שלום should display (top to bottom is left to right): ם ו ל ש but will probably display: ש ל ו ם -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
re: [po]updated korean resource
Patch failed to apply here: patching file po//ko.po Hunk #1 succeeded at 775 (offset -4 lines). Hunk #2 succeeded at 783 (offset -4 lines). Hunk #3 succeeded at 798 (offset -4 lines). Hunk #4 FAILED at 8714. Hunk #5 FAILED at 8809. Hunk #6 succeeded at 8812 (offset -23 lines). Hunk #7 FAILED at 8968. Hunk #8 succeeded at 10220 (offset -25 lines). 3 out of 8 hunks FAILED -- saving rejects to file po//ko.po.rej Also, please send plain text email next time (but still with the patch as an attachment).
Re: [po]updated korean resource
2011/8/28 Dan Kegel d...@kegel.com: Patch failed to apply here: patching file po//ko.po Hunk #1 succeeded at 775 (offset -4 lines). Hunk #2 succeeded at 783 (offset -4 lines). Hunk #3 succeeded at 798 (offset -4 lines). Hunk #4 FAILED at 8714. Hunk #5 FAILED at 8809. Hunk #6 succeeded at 8812 (offset -23 lines). Hunk #7 FAILED at 8968. Hunk #8 succeeded at 10220 (offset -25 lines). 3 out of 8 hunks FAILED -- saving rejects to file po//ko.po.rej Works fine for me. Also, don't use patch to apply git patches.
Re: [po]updated korean resource
On Sun, Aug 28, 2011 at 2:33 PM, Henri Verbeet hverb...@gmail.com wrote: Works fine for me. Also, don't use patch to apply git patches. Strange: $ git apply korean.patch error: patch failed: po/ko.po:8715 error: po/ko.po: patch does not apply Maybe it's in how I fetched the patch? $ wget http://source.winehq.org/patches/data/78034 $ sha1sum 78034 b363a8529306e5e8fef896f79cdf0580fa20e298 78034 But even if I do $ wget 'http://www.winehq.org/pipermail/wine-patches/attachments/20110825/aa6694e4/attachment-0001.obj' $ git apply attachment-0001.obj it still fails similarly. What is the right sha1sum for the patch?
Re: Severe regression in wine startup latencies
On 29/08/2011 2:37 AM, Alan W. Irwin wrote: bash.exe-3.1$ time /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe hello hello real0m0.503s user0m0.080s sys 0m0.020s Also, I tried time (x; x; x; x; x; x; x; x; x; x), where x represents the complete echo command above, and the result was real0m5.281s user0m0.800s sys 0m0.200s [snip] While I am doing those additional investigations, please consider the question of why there is a huge difference between built-in and executable latency for MSYS bash commands under wine. To start that investigation it would be good to compare the wine results for those two cases with the Windows results for those two cases. (I assume the two time results for built-in versus executable will be fairly similar in the Windows case, but that assumption needs to be checked.) I don't have access to Windows myself. Anybody up for doing that simple test and reporting the results back here? The automatic MinGW/MSYS installer at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/ makes it easy to install the relevant MinGW/MSYS software on both wine and Windows. Under MSYS 1.0.17 running on Windows 7 x64 SP1: bash.exe-3.1$ /bin/bash --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. bash.exe-3.1$ alias x='/bin/echo.exe -n .' bash.exe-3.1$ time x . real0m0.031s user0m0.000s sys 0m0.015s bash.exe-3.1$ time (x;x;x;x;x;x;x;x;x;x) .. real0m0.296s user0m0.075s sys 0m0.136s This shows a latency of approximately 2 jiffies for each command - 1 jiffy in Windows is 15.6ms. -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/
Re: [po]updated korean resource
On 28 August 2011 23:51, Dan Kegel d...@kegel.com wrote: Maybe it's in how I fetched the patch? $ wget http://source.winehq.org/patches/data/78034 $ sha1sum 78034 b363a8529306e5e8fef896f79cdf0580fa20e298 78034 That's a different patch, superseded by this one. I suppose that could have been indicated with something slightly more verbose than updated, but nevertheless.
re: rpcrt4:properly unmarshall EMUM16 discriminant
Didn't apply here: $ git apply text fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead.
Re: rpcrt4:properly unmarshall EMUM16 discriminant
Dan, On 08/29/2011 12:18 AM, Dan Kegel wrote: Didn't apply here: $ git apply text don't use git apply but git am. git am knows how to deal with emails and email encoded patches. fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead. bye michael
Re: rpcrt4:properly unmarshall EMUM16 discriminant
Le 29/08/2011 00:40, Michael Stefaniuc a écrit : Dan, On 08/29/2011 12:18 AM, Dan Kegel wrote: Didn't apply here: $ git apply text don't use git apply but git am. git am knows how to deal with emails and email encoded patches. fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead. bye michael Hello! Should I resend it anyway? Regards. Jérôme.
Re: rpcrt4:properly unmarshall EMUM16 discriminant
On 08/29/2011 12:45 AM, Jérôme Gardou wrote: Le 29/08/2011 00:40, Michael Stefaniuc a écrit : Dan, On 08/29/2011 12:18 AM, Dan Kegel wrote: Didn't apply here: $ git apply text don't use git apply but git am. git am knows how to deal with emails and email encoded patches. fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead. Should I resend it anyway? Yes, it really is corrupt as git am doesn't likes it either. git am /tmp/rpcrt4\:properly\ unmarshall\ EMUM16\ discriminant.eml Applying: rpcrt4:properly unmarshall EMUM16 discriminant fatal: corrupt patch at line 10 bye michael
Re: Cmd tests timeout and splitting tests
On Sun, Aug 28, 2011 at 01:24, Octavian Voicu octavian.vo...@gmail.com wrote: Hello, I've noticed a lot of timeouts for cmd tests lately, which is not so surprising with all the new incoming tests. Which timeouts are you talking about? On windows machines? Never experienced a timeout Could you give me some link? 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. It's difficult to test in complete isolation given that we use our own dogfood (i.e. run with cmd) for cmd tests. Also you would have to run all the tests anyway, since a small change to a builtin can lead to regressions in other parts. The association .cmd/.exp would have to be handled specially as well. Frédéric
Re: rpcrt4:properly unmarshall EMUM16 discriminant
Le 29/08/2011 00:49, Michael Stefaniuc a écrit : On 08/29/2011 12:45 AM, Jérôme Gardou wrote: Le 29/08/2011 00:40, Michael Stefaniuc a écrit : Dan, On 08/29/2011 12:18 AM, Dan Kegel wrote: Didn't apply here: $ git apply text don't use git apply but git am. git am knows how to deal with emails and email encoded patches. fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead. Should I resend it anyway? Yes, it really is corrupt as git am doesn't likes it either. git am /tmp/rpcrt4\:properly\ unmarshall\ EMUM16\ discriminant.eml Applying: rpcrt4:properly unmarshall EMUM16 discriminant fatal: corrupt patch at line 10 bye michael Done. Hopefully this is correctly formatted now. Regards. Jérôme.
Re: rpcrt4:properly unmarshall EMUM16 discriminant
2011/8/28 Jérôme Gardou jerome.gar...@laposte.net: Done. Hopefully this is correctly formatted now. Yes, it applies fine now.
re: Cmd tests timeout and splitting tests
Hi Octavian, the intention was to just add new TESTCMD resources into rsrc.rc when test_builtins.cmd got too big but I never thought the tests would be so slow, splitting them by adding new rsrc.rc entries wouldn't help a timeout problem. I'd go for solution #3, too, but it's troubling that test names would be duplicated in the Makefile.in and in rsrc.rc. An awful thought just occurred to me: we could make test_builtins.cmd itself take a parameter saying which subtest to run. That would avoid needing to modify rsrc.rc, but you'd still need to figure out how to iterate through the tests. - Dan
re: kernel32: Add UDF support Based on Steven Wallace work. Should fix the wine side of bug #26273
Fails tests here?
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
kernel32_test.exe.so volume.c touch volume.ok
fixme:volume:DefineDosDeviceW
(0x,La:,LZ:\\home\\dank\\wineslave.dir\\sandbox\\slave\\runtests\\build\\dlls\\kernel32\\tests)
DDD_RAW_TARGET_PATH flag not set, not supported yet
volume.c:105: Tests skipped: can't test removing fake drive
fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not
yet supported
volume.c:359: Test failed: GetVolumeInformationA root failed, last error 66
volume.c:401: Test failed: GetVolumeInformationA with \ failed, last error 66
volume.c:423: Test failed: GetVolumeInformationA failed, last error 66
volume.c:434: Test failed: GetVolumeInformationA failed, last error 66
volume.c:445: Test failed: GetVolumeInformationA failed, root=C:\, last error=66
volume.c:451: Test failed: GetVolumeInformationA did fail,
root=\\?\C:\, last error=66
volume.c:458: Test failed: GetVolumeInformationA did fail,
root=\\.\C:\, last error=66
volume.c:486: Test failed: GetVolumeInformationA failed,
root=\\?\Volume{----0043}\, last error=66
fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for
IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
Command exited with non-zero status 8
0.02user 0.04system 0:00.09elapsed 80%CPU (0avgtext+0avgdata 22992maxresident)k
0inputs+0outputs (0major+5625minor)pagefaults 0swaps
make[1]: *** [volume.ok] Error 8
re: kernel32: Improve GetVolumeInformation filesystem flags I set flags value according to my tests which may differ from a windows version to another.
Fails to build here, since it depends on the patch include/winnet.h: Add more GetVolumeInformation system flags, but you didn't mark them as being part of a series. See Subject Line in http://wiki.winehq.org/SubmittingPatches volume.c: In function ‘GetVolumeInformationW’: volume.c:672: error: ‘FILE_SUPPORTS_REPARSE_POINTS’ undeclared (first use in this function) volume.c:672: error: (Each undeclared identifier is reported only once volume.c:672: error: for each function it appears in.) volume.c:672: error: ‘FILE_SUPPORTS_SPARSE_FILES’ undeclared (first use in this function) volume.c:672: error: ‘FILE_VOLUME_QUOTAS’ undeclared (first use in this function) make[1]: *** [volume.o] Error 1 You probably also want to use shorter subject lines, and move more of the patch description into the body of your message.
buildbot status
The buildbot now uses ccache, which sped up builds tremendously. Cycle time of build slaves with ccache using is 10-11 minutes; the e8400 and q9300 are almost as fast as the i7 now. (Dunno about the celeron yet.) A few more flaky tests are now blacklisted, and the cluster has been running all afternoon without a glitch. I hope to turn on email notifications sometime this week.
