aMule Forum
English => Multiplatform => Win32 => Topic started by: Radek on May 07, 2009, 07:30:11 PM
-
Hi!
When starting amulegui under WinXP I get a popup with a lot of "Timer creation failed" lines in it.
The program seems to work o.k., though.
BTW: did any of you try to start amulegui on the command line (msys) under WinXP with arguments? I wanted some verbosity and tried "-v" and received a message that it's an unknown option. Then I tried the listed "--verbose" and received the next funny message - somewhat inconsistent, but amusing ;)
-
Current SVN is 9596 - please try it with that (on general principles...).
If problem persists, please try my MSVC build if it has the same problem.
Do you have an ancient hardware without high precision timers?
Then I tried the listed "--verbose" and received the next funny message - somewhat inconsistent, but amusing ;)
You mean "catalog file for domain 'amule' not found" or the thing about X11 resolutions?
-
Sorry, that was a typo! I meant r9593!
For me r9593 is the latest revision - the tarballs.xml doesn't get updated too often...
I use a PC with one of the first AMD64-Processors (AMD Athlon 64 3000+).
It's about 5 years old, I think. But for me it's good enough, as I only write software and don't play games or something.
I don't think that the hardware is the problem. In any case I don't have anything newer than that except my server, which is a VIA C3 1000MHz under Debian (very economical, but not a good idea to try Win$ on that :) ).
When the tarball is shown on the website I'll try that one, of course.
When I find the time I'll check your MSVC build, too. I have VS6 and VS2005 installed here, but I don't use them much anymore, because nowadays I program mostly under *NIX or in embedded environments with self-contained software.
Let's see, what happens.
About the usage messages: yes, I mean those niceties and that the usage helps are not consistent. Not very important, I only noticed that, because I tried to get some more output from amulegui. A normal Win$ user hardly will start any program with a gui on the command line.
OT another remark: the test-suite is still failing. Now it's 4 out of 8 test, which fail...
Running test-collection "CUInt128" with 58 test-cases:
Test "Reading/writing byte sequences"
Test "ToHexString"
Test "ToBinaryString"
Test "Get32BitChunk"
Failure running:
p:/sources/amule-svn/unittests/tests/CUInt128Test.cpp:114 -- Exception of type CAssertFailureException not raised.
Test "operator==(const CUInt128&)"
Test "operator==(uint32_t)"
Test "operator==(uint32_t, const CUInt128&)"
Test "CUInt128()"
Test "CUInt128(const CUInt128&)"
Test "CUInt128(bool)"
Test "CUInt128(uint32_t)"
Test "operator=(const CUInt128&)"
Test "operator=(uint32_t)"
Test "Set32BitChunk"
Failure running:
p:/sources/amule-svn/unittests/tests/CUInt128Test.cpp:212 -- Exception of type CAssertFailureException not raised.
Test "SetValue(const CUInt128&)"
Test "SetValue(uint32_t)"
Test "SetValueRandom"
Test "SetValueBE"
Test "StoreCryptValue"
Test "ShiftLeft"
Test "Add(const CUInt128&)"
Test "Add(uint32_t)"
Test "Subtract(const CUInt128&)"
Test "Subtract(uint32_t)"
Test "XOR(const CUInt128&)"
Test "operator<<=(unsigned)"
Test "operator+=(const CUInt128&)"
Test "operator+=(uint32_t)"
Test "operator-=(const CUInt128&)"
Test "operator-=(uint32_t)"
Test "operator^=(const CUInt128&)"
Test "operator^=(uint32_t)"
Test "GetBitNumber"
Test "SetBitNumber"
Failure running:
p:/sources/amule-svn/unittests/tests/CUInt128Test.cpp:539 -- Exception of type CAssertFailureException not raised.
Test "operator!=(const CUInt128&)"
Test "operator!=(uint32_t)"
Test "operator!=(uint32_t, const CUInt128&)"
Test "operator<(const CUInt128&)"
Test "operator<=(const CUInt128&)"
Test "operator>(const CUInt128&)"
Test "operator>=(const CUInt128&)"
Test "operator<(uint32_t)"
Test "operator<=(uint32_t)"
Test "operator>(uint32_t)"
Test "operator>=(uint32_t)"
Test "operator<(uint32_t, const CUInt128&)"
Test "operator<=(uint32_t, const CUInt128&)"
Test "operator>(uint32_t, const CUInt128&)"
Test "operator>=(uint32_t, const CUInt128&)"
Test "operator+(const CUInt128&)"
Test "operator-(const CUInt128&)"
Test "operator^(const CUInt128&)"
Test "operator+(uint32_t)"
Test "operator-(uint32_t)"
Test "operator^(uint32_t)"
Test "operator+(uint32_t, const CUInt128&)"
Test "operator-(uint32_t, const CUInt128&)"
Test "operator^(uint32_t, const CUInt128&)"
FAIL: CUInt128Test
Running test-collection "Format" with 16 test-cases:
Test "ConstructorAndGetString"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:72 -- Exception of type CAssertFailureException not raised.
Test "SetStringAndGetString"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:99 -- Exception of type CAssertFailureException not raised.
Test "InjectwxChar"
Test "InjectInteger"
Test "InjectFloatAndDouble"
Test "InjectString"
Test "InjectNULLString"
Test "MultipleFields"
Test "EscapedPercentageSign"
Test "MalformedFields"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:310 -- Exception of type CAssertFailureException not raised.
Test "NotReady"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:348 -- Exception of type CAssertFailureException not raised.
Test "WrongTypes"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:376 -- Exception of type CAssertFailureException not raised.
Test "NotSupported"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:401 -- Exception of type CAssertFailureException not raised.
Test "Overfeeding"
Failure running:
p:/sources/amule-svn/unittests/tests/FormatTest.cpp:426 -- Exception of type CAssertFailureException not raised.
Test "64bValues"
Test "Printable"
FAIL: FormatTest
Running test-collection "CFile" with 4 test-cases:
Test "Constructor"
Failure running:
p:/sources/amule-svn/unittests/tests/FileDataIOTest.cpp:769 -- Exception of type CRunTimeException not raised.
Test "Create"
Test "SetLength"
Test "GetAvailable"
FAIL: FileDataIOTest
Running test-collection "CPath" with 11 test-cases:
Test "DefaultConstructor"
Test "PathConstructor"
Test "CopyConstructor"
Test "Operators"
Test "JoinPaths"
Test "StartsWith"
Test "IsSameDir"
Test "GetPath_FullName"
Test "Cleanup"
Test "AddPostFix"
Failure running:
p:/sources/amule-svn/unittests/tests/PathTest.cpp:348 -- Expected '\\foo_1.bar' but got '\foo_1.bar'
Test "Extensions"
FAIL: PathTest
-
For me r9593 is the latest revision - the tarballs.xml doesn't get updated too often...
That's fine of course. I was taking you literally about 9493. There are no changes in the last few refs that might affect your problem.
I use a PC with one of the first AMD64-Processors (AMD Athlon 64 3000+).
It's about 5 years old, I think. But for me it's good enough, as I only write software and don't play games or something.
Should be fine (though I don't know the exact CPU specs). Can you post a screenshot of that timer error messages?
When I find the time I'll check your MSVC build, too. I have VS6 and VS2005 installed here, but I don't use them much anymore,
Just run the exe, no need to build anything.
-
I thought you meant some sources, which I could/should compile with MSVC.
Ok, I tried the amuleGUI.exe from your website: It does not show those timer errors...
That's the screenshot:
-
What information do you find in the log view ? The internal remotegui messages are prefixed with "remotegui:" or something. Any hint there?
Ok, I tried the amuleGUI.exe from your website: It does not show those timer errors...
So it's not a hardware problem.
-
The only "internal" lines I found in the log (except for the standard startup messages) are those:
2009-05-08 19:55:04 (remote-GUI): Error: Timer creation failed.
2009-05-08 19:55:04 (remote-GUI): Error: Timer creation failed.
I believe this will not help much...
-
Since SVN r9640 the problem seems to be fixed.
I noticed a new version of msw/timer.cpp while doing my weekly wxWidgets-update. Maybe that was the real reason for the disappearing error message.
In any case: case closed for now!
-
The timer in case was the redraw timer of the graphs. With wx 2.9 I got the problem too. (And noticed the whole timer logic wasn't working as supposed to.) It was fixed in 9618, with an update in 9642.
What wx versions are you using? 2.9 support is very alpha. While it works rather fine on MSW (with a hack for the broken networking...) it crashes permanently on Linux.
-
I'm using wxWidgets 2.8.10 here (shared source directory for Debian and Win$)
Usually once a week I do an SVN update of my wxWidgets sources with -rWX_2_8_BRANCH. And while doing the latest update on Saturday (May 30th) I noticed the new msw/timer.cpp.