Menu
▾
▴
mingw-users
|
From: DAVENPORT, M. <mda...@co...> - 2017-05-28 23:03:19
|
Is there any chance of clock_gettime being implemented in MinGW? MinGW64 has it but I don't like MinGW64. Source code is public domain. See link below. It would also need at least clockid_t and clock_getcpuclockid. https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html Marc |
|
From: Peter R. <pe...@ly...> - 2017-05-29 07:30:21
|
On 2017-05-29 00:38, DAVENPORT, MARC wrote: > Is there any chance of clock_gettime being implemented in MinGW? MinGW64 has it but I don't like MinGW64. Source code is public domain. See link below. It would also need at least clockid_t and clock_getcpuclockid. > > https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109 Hmm, their CLOCK_MONOTONIC wraps, and rather quickly too on some machines [1]; it's nothing more than a dirty hack as it's not monotonic at all. Unless I'm missing something non-obvious... Cheers, Peter [1] I've seen machines wrap the performance counter within the hour, albeit many years ago, but the non-handling of the fundamental timer wrap problem persists. |
|
From: Keith M. <kei...@us...> - 2017-07-06 14:45:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apologies for the delayed reply ... this seems to have slipped under my radar. > On 2017-05-29 00:38, DAVENPORT, MARC wrote: >> Is there any chance of clock_gettime being implemented in MinGW? I think I've said this before; (if not, I've certainly alluded to it): your best chance of getting such requests accepted is to file them as "Feature Requests", at https://sourceforge.net/p/mingw/bugs/new/, and then invite other users to vote for them, (by posting a notification here). >> MinGW64 has it but I don't like MinGW64. Source code is public >> domain. See link below. It would also need at least clockid_t ... It would, if the API is to be supported; prior to POSIX.1-2008, the entire API was optional, and even now all but CLOCK_REALTIME appear to remain so. In any case, right now, I would be able to offer tentative implementations for CLOCK_REALTIME and CLOCK_MONOTONIC, but... >> and clock_getcpuclockid. ...this may NOT be required, because a) it is required only when the CLOCK_PROCESS_CPUTIME_ID option (_POSIX_CPUTIME feature) is supported, and b) I do not currently have even a tentative implementation for it. Notwithstanding the lack of enthusiasm exhibited here, if you'd care to raise the appropriate "Feature Request" ticket, I'll attach my tentative implementation for consideration. On 29/05/17 08:30, Peter Rosin replied: >> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109 > > Hmm, their CLOCK_MONOTONIC wraps, and rather quickly too on some > machines [1]; it's nothing more than a dirty hack as it's not > monotonic at all. > > Unless I'm missing something non-obvious... I don't know. I haven't looked at their implementation, (nor will I), so I cannot comment. My tentative implementation does not appear to exhibit any such trait: indeed, with a reported update frequency of 3,579,545 ticks per second, (on my GNU/Linux hosted WinXP VM), and a 64-bit limit of 2^63 ticks before wrap-around, it should outlive any likely uptime cycle of the host, (or any of us, for that matter)! - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZXkz0AAoJEMCtNsY0flo/PEIQAJi697fRiENNJ+Iw/7MAEPC9 2SzpUFAEXJubB34QENQRDuKN5NWKRFXzvB019IEYkIDL2BxFGBkFTyyDDLP9M+mr fakRQmABPFD7eLFAvZu4tzffgA4tChkNYFCUDey34XDQaw41UKWJoOFkt7JuE5dc 66ICJW+g9KiuHa+h7if3gW9MH+lxMEO6ZV9u5GYlk7ET8tm3llwAVjKHsSq/jvmF usxVATkEKD5Tv36xDUc78mTG/LpdUEXQBgEVslXNKzaRYpZX9XdG8okQtk4eHT4O YyS0HslqLQcfN79nvYbBW/BQq6k+9ZtyqSlkQbsaS8aW5V/ccPFt9a3ce6Gadelx 5rZv93gUp7yzUR8qjf7RalbLhp/yPnWD3dIPELCxZwUqmqa8uHP0rCI9REKkkfaL wkAvih1Jcrnsp1mX0c4aUmURN1o5oK+N8ZTSPqqn29KuztKMdB0chpWKRCItJf7x F2bgFCtpwdy4a50QbkgrLzpdnh5m3wIKP6yr2dlWD2bccaRBqE7OxnsSce9IZoGQ fJ8AmzRjRQ+5n07TrlP/u8VlMgLDGF7yvbx21miHwVwRqHrfyFz3xGu5QMUBAlQg dou2FjgQW5Rwkoxury5WouSmdneaUC7j7jChkzopuW+Nna2AfFd/HyvSP4a4qJot ei/mj2HS4SZnOrDZ9Y8l =K0+V -----END PGP SIGNATURE----- |
|
From: Anton S. <ant...@gm...> - 2017-08-13 13:46:42
|
Keith Marshall to Marc Davenport: > Is there any chance of clock_gettime being imple- > mented in MinGW? > > I think I've said this before; (if not, I've cer- > tainly alluded to it): your best chance of getting > such requests accepted is to file them as "Feature > Requests", at > > https://sourceforge.net/p/mingw/bugs/new/ , > > and then invite other users to vote for them, (by > posting a notification here). Done: https://sourceforge.net/p/mingw/bugs/2349/ I couldn't register this issue as a feature request because when I selected "Feature Requests" in the "Ticket" drop-down list the "Create Ticked" button became locked, so I made it an "Issue". -- Please, do not forward replies to my e-mail. |
|
From: Keith M. <kei...@us...> - 2017-08-13 15:25:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/08/17 14:46, Anton Shepelev wrote: > Keith Marshall to Marc Davenport: >> Is there any chance of clock_gettime being implemented in MinGW? >> >> I think I've said this before; (if not, I've certainly alluded to >> it): your best chance of getting such requests accepted is to file >> them as "Feature Requests", at >> >> https://sourceforge.net/p/mingw/bugs/new/ , >> >> and then invite other users to vote for them, (by posting a >> notification here). > > Done: > > https://sourceforge.net/p/mingw/bugs/2349/ > > I couldn't register this issue as a feature request because when I > selected "Feature Requests" in the "Ticket" drop-down list the > "Create Ticked" button became locked, so I made it an "Issue". You did it right. The https://sourceforge.net/p/mingw/bugs/new/ link, which I gave you previously, takes you directly to the form which you should complete. No need to invoke the "Tickets" drop-down, or the "Create Ticket" button ... just specify the ticket type as "Feature", as you complete the form, (which is what you did). FTR, all but the "Issues" tracker, under the "Tickets" drop-down, are considered deprecated, and are provided only to access old tickets; a comment, at the top of each such tracker, instructs you to use the "Issues" tracker, for submission of new tickets. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZkG9hAAoJEMCtNsY0flo/5msP/R3NpMYHC0u9zc12fhpyEXck xo3qJIQX7pHSttupsXm3o69CLTPIc0TBngxzdjTga4DnUNLLGL9IswYCsYk6/9rv rzPLKDGE44YJcsmyNOqTrcyqIWuR2SZEurO38lTS8Ulx+P03agVIIznqgi5O3my2 3nBAGbgOqISPpndhCRZ5wSQ0CHnvpUtNisuS/QoYihpZLH90brBOZJ8pHa3kHw8y 9wfRIZTtILvVLyVZ4y0xIMjBPIecgbJEyOL6IKu0nz+6e2IoZmH7bk1uplGnwc7T /cz8cCVQdt9RVADeKHzJdXOCJMWgm2NyGLOdY1vv2zQTZOs3lzwXqpaxW5b58hU9 XiP6DGQ4b9pK8HmFkO5ll+E4oZHnc7Owd5s33LgDOMUKeV6cDsbmAEhT6urEmKsM 9y8KB9VCHP2WZCRG4EMvjtmwV9ucSUFnIxKGnYApEPDrSoXFQXtcpXlfRkThTpMg XWRJOQCCI5aGZcnTShm2/T1fMIYeZAFOkFYJkBT/uVSD8Pa8I4jaO8PH+s9abx4B Sg1Sw4tZ9jEbUh08Q3KVi8QQlKt4xLGSJRWa6ek/k+22QGKZHufe6BZhZfecm6kh il3vx+sQEO3YHq8MRr6OwcDd7bSOXzm4n0M9iKC/XLPSidstJf5ea/OCSVWOnSPO CBwerZ8atbQmXF9rxrUo =kv7S -----END PGP SIGNATURE----- |
|
From: Anton S. <ant...@gm...> - 2017-08-13 20:05:07
|
Thank you for the patch, Keith. Do I understand
aright from the readme file that the simplest way to
build the library is using "use the special version
of Jam made for Mingw32"? Where can I take this ver-
sion and the corresponding jamfiles? Although the
readme says that "tt should be available from the
same place you got this file," it is absent from the
mingw-mingw-org-wsl source archive. If the sources
from git do note come with a working build scripts,
is there some instructions on building them?
P.S.: I cannot reply to the relevant message because
Gmane's NNTP server is not showing new mes-
sage. If they do not fix it soon enough, I
shall switch to plain e-mail.
--
Please, do not forward replies to my e-mail.
|
|
From: Keith M. <kei...@us...> - 2017-08-13 22:16:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/08/17 21:04, Anton Shepelev wrote: > Thank you for the patch, Keith. Do I understand aright from the > readme file that the simplest way to build the library is using > "use the special version of Jam made for Mingw32"? I guess we should dump that readme.txt file; it is long obsolete. See: https://sourceforge.net/p/mingw/mailman/message/35845151/, (and note my follow-up instruction about ensuring that you are on the right git branch). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZkM+cAAoJEMCtNsY0flo/g0kQALLBeDM3WTb8c2a2MgwlCseM QvpbUhAopWyZ9/wAdyzxk9I3oGc1yqYj6/wGQSh+MRXI8v2rvN1ZnX+gDDainzfE DgDF89KCaCTEvSgT8LJ8zjDl7l4mk5HN+kE/yDU9OILbtzAdCO/xe/wegxVVetYJ 0TMsJ263yhPgSqmyz7TexD8dm+cauHO8862QDscVe8baLwgAzgk8hcWpcnIT4JP2 nUzZV7Yt8D1TK2be3GBjlAaLTtBfe794oe84nwLXsqV7rw4GH2CvuFvqh7XZOXOb Bf9YPda09GJjI9yz2c8uBRDHapm8FPAZO+yNkWM+ejy5USTFqQ3wlk8zcgFE6vF8 TVFVqrnqNsI20GRMScJ3wAt/1oD4TN46QD4Dj5o9NfXDki3+K8OzA1Cap1IdCzvU DKwjbIkMgaSf/VQSZi+kHKYyJbYLnUr6jIe4ir2NfaCeER/eujM9LXys2LkA/7XO dk0SZXzMXhHNhJ+njqjJhkn6TmDlB0bm/PAUXANF2PJ/DVC49Tu8ivwkJzKFWCx/ E7jQTRHx/dokOJETmV6CxTSytlqFyBkjVpNHLAa84QzTcf+knQDhycoFqLAfE56P 7UuhT0n0Uks71kWXRjzuZcNsyha2pMFX9dCsWypmUmZpu+PD9G4Qci3gv4ivOXdY 5A+C2CX69igGwCuKZEmK =CpXJ -----END PGP SIGNATURE----- |
|
From: Keith M. <kei...@us...> - 2017-12-16 13:26:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/05/17 23:38, DAVENPORT, MARC wrote: > Is there any chance of clock_gettime being implemented in MinGW? > MinGW64 has it but I don't like MinGW64. Source code is public > domain. See link below. It would also need at least clockid_t > and clock_getcpuclockid. In spite of the disappointingly apathetic user response, in terms of votes cast on Anton's corresponding feature request ticket: https://sourceforge.net/p/mingw/bugs/2349/ I have decided to include implementations for CLOCK_REALTIME, and for CLOCK_MONOTONIC support only, via commit: https://sourceforge.net/p/mingw/mingw-org-wsl/ci/ecc51ca60bf82d678260fa7b119a9f42b3b77fb7/ This will be incorporated into the mingwrt-5.1 release, which I hope to publish early in 2018. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaNRu2AAoJEMCtNsY0flo/UCoQAJaxcXZofECj1/Y/3V4bENJ9 9+M7a3pBO9OvtmFa8cS+T91/Mbja+5HIIMJ6Q3ni4f5kF0tIGFqLo30ZsdRfmpy1 uML+LTEieW8wqNljwNNr0dZH8RBRjYUeJe4MzMgFVO/+b89haE3H5BaG3W2t3yHz bgczQqpcvZQCabgdRNC6UkFMhjqL2jtYyp2FaV3UKsTMDQfsZuftDHCVcnsbB0l9 +7BLsHiycTqQ4/Xs652KMdwJtINy+4xy8NAHdigpDyft7buVtWFQOpnfcS0T9Zql aMY0Ojgz419Qp3n3jDn9uEZvaW1pV3gOt6sKzULEtVSoOU+tQ9INbQhwLRLmcs95 T6adcyp28/qCkArOKzukxIi5B1KfcEdJOG9xnY1fIVYS3IhMdE+45cQNPlgcSav4 TeJvRzmnrRxMeWBMM3vL/b6aGwrYtwoYlF4MER959ZI7p67vNp7hosBYtxhKnCl6 XCzjB6NenD2c9M1xIw7ow97QWbsYDjnBQDsZKnD9QeVT/3bYqwBCF2+GZqGqa7PB Ry69S2T5WeD5xjSQg43IBQMcyII7PEPRVj9QT+LInVS0zhJXOtRh4nzZVkIgKSH7 w6/E1vacefCCYOOWYK7fIXPaeDljcr1QSaA97XwaVBf3jbh6C5b4dFjLGDdztsNk o/0Nyl/+GIhythaX9qBu =Jjvr -----END PGP SIGNATURE----- |
|
From: Eli Z. <el...@gn...> - 2017-12-16 14:20:25
|
> Date: Sat, 16 Dec 2017 13:12:22 +0000 > From: Keith Marshall via MinGW-users <min...@li...> > > In spite of the disappointingly apathetic user response, in terms of > votes cast on Anton's corresponding feature request ticket: > https://sourceforge.net/p/mingw/bugs/2349/ > > I have decided to include implementations for CLOCK_REALTIME, and for > CLOCK_MONOTONIC support only, via commit: > https://sourceforge.net/p/mingw/mingw-org-wsl/ci/ecc51ca60bf82d678260fa7b119a9f42b3b77fb7/ > > This will be incorporated into the mingwrt-5.1 release, which I hope > to publish early in 2018. Thanks! |
