Re: [Monotone-devel] strptime not in MinGW time.h
Thomas Keller m...@thomaskeller.biz writes: I think its sufficient to disable the date format changing on win32 for now I'm not clear exactly what this would mean. The date format is specified either by --date_fmt or by the Lua hook get_date_format_spec. I don't see an easy way to disable those on Win32. date_fmt is used in lots of places for date output. Perhaps you mean disable commit date changing, not disable date format changing. That makes more sense. and trigger a warning if the original entered value has been changed by the user to a value our date parsing infrastructure cannot understand. This is better than disabling it completly on win32 and if somebody cares he / she can contribute the work to include strptime into monotone as suggested earlier to make it fully work. The only place strptime is needed is in cmd_ws_commit.cc get_log_message_interactively; it parses the date from the changelog text, which the user may have edited. We can disable editing the commit date, by simply not putting that field in the text sent to the edit_comment hook. Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. On Win32, this check will always fail, because strptime is not implemented. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. That way, even on Unix, if the user provides a date_fmt that strptime doesn't like, commit won't fail. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Stephen Leake stephen_le...@stephe-leake.org writes: Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. This is now implemented in a8147b11ee2d598835a4e1cec0e9782e4388e679. All tests are passing on Win32. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Sat, May 22, 2010 at 4:09 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. On Win32, this check will always fail, because strptime is not implemented. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. That way, even on Unix, if the user provides a date_fmt that strptime doesn't like, commit won't fail. We need to make it visually obvious in the editor when editing the date won't have any effect, if we do this. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Zack Weinberg za...@panix.com writes: On Sat, May 22, 2010 at 4:09 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. On Win32, this check will always fail, because strptime is not implemented. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. That way, even on Unix, if the user provides a date_fmt that strptime doesn't like, commit won't fail. We need to make it visually obvious in the editor when editing the date won't have any effect, if we do this. It turned out to be better than that. If date_fmt is not valid, just use the default date format (and issue a warning); you can then edit the date. Now tested on Win32 and Debian; all tests are passing. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Am 22.05.10 17:11, schrieb Stephen Leake: Stephen Leake stephen_le...@stephe-leake.org writes: Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. This is now implemented in a8147b11ee2d598835a4e1cec0e9782e4388e679. All tests are passing on Win32. Not quite for me though on Mac OS X - the test commit_default_editor fails. The last two test there read check(mtn(--branch, testbranch, commit, --date-format, foo), 0, false, true) check(qgrep(date format 'foo' cannot be used for .. commit; using default instead, stderr)) but instead of warning about the unusable format, it aborts completely for me (probably nearby cmd_ws_commit.cc:1543). Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Am 23.05.10 00:22, schrieb Thomas Keller: Am 22.05.10 17:11, schrieb Stephen Leake: Stephen Leake stephen_le...@stephe-leake.org writes: Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. This is now implemented in a8147b11ee2d598835a4e1cec0e9782e4388e679. All tests are passing on Win32. Not quite for me though on Mac OS X - the test commit_default_editor fails. The last two test there read check(mtn(--branch, testbranch, commit, --date-format, foo), 0, false, true) check(qgrep(date format 'foo' cannot be used for .. commit; using default instead, stderr)) but instead of warning about the unusable format, it aborts completely for me (probably nearby cmd_ws_commit.cc:1543). Wait, forget it - it was a local problem. Sorry for the noise. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Derek Scherger de...@echologic.com writes: On Thu, May 20, 2010 at 5:04 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: It's currently dying with some mysterious C messages: These do _not_ look easy to fix. So I'm looking at where strptime is used, to see what the impact of this is. It's used in three places: get_log_message_interactively, if date_fmt is not empty status, to check that date_fmt is compatible with get_log_message_interactively commit, to check that date_fmt is compatible with something (I'm not sure what) With the new changelog editor you may edit the Date: header as part of a commit, strptime is used to parse the date from the commit editor. The format is deemed to be acceptable if the current date is unchanged after being formatted and parsed with it. date_fmt is set by the user, via a command line option or hook_get_date_format_spec. So this is in support of user-configurable date formats. ... used in the changelog editor, as far as I know nothing else uses strptime to parse dates. Ok, good. How important is that? Perhaps we could simply say user-configurable date formats not available on Win32. I'm ok with that. Or editing the Date: header is unsupported on Win32 Ok, I'll see if I can make this work. Then we can release, and come up with a better solution later. One option would be to find Microsoft's date parsing function (there must be one somewhere) and use a platform.hh wrapper. I tried searching for parse date on MSDN, and got over 1,000 hits; the first couple of pages were all in .NET or Visual Basic or some other high level layer. There does not seem to be a way to restrict the search to plain C API! So I gave up. Anticipating that, and as a clean way to avoid the compilation error, I'll add a wrapper parse_date in platform.hh now, making it take the same parameters as strptime. The Win32 version will throw an error. Hmm. Maybe it needs to support only a standard format instead? I'll also see if this compiles on Cygwin. Has anyone compiled on Mac since the changelog editor landed? Hmm. I just did some wider web searching, and found this: http://stackoverflow.com/questions/234171/parse-a-date-from-a-string-in-win32 Apparently Win32 can convert a SystemTime struct to a formatted string, but cannot then parse the string. Which explains why every higher-level package has its own way of parsing dates. Wonderfull. Boost has a Date_Time library, but I suspect we don't want to go there. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Am 21.05.2010 11:24, schrieb Stephen Leake: Derek Scherger de...@echologic.com writes: Perhaps we could simply say user-configurable date formats not available on Win32. I'm ok with that. Or editing the Date: header is unsupported on Win32 Ok, I'll see if I can make this work. Then we can release, and come up with a better solution later. One option would be to find Microsoft's date parsing function (there must be one somewhere) and use a platform.hh wrapper. I tried searching for parse date on MSDN, and got over 1,000 hits; the first couple of pages were all in .NET or Visual Basic or some other high level layer. There does not seem to be a way to restrict the search to plain C API! So I gave up. Anticipating that, and as a clean way to avoid the compilation error, I'll add a wrapper parse_date in platform.hh now, making it take the same parameters as strptime. The Win32 version will throw an error. Hmm. Maybe it needs to support only a standard format instead? I'll also see if this compiles on Cygwin. Has anyone compiled on Mac since the changelog editor landed? Yes, continuously :) No problems there. Hmm. I just did some wider web searching, and found this: http://stackoverflow.com/questions/234171/parse-a-date-from-a-string-in-win32 Apparently Win32 can convert a SystemTime struct to a formatted string, but cannot then parse the string. Which explains why every higher-level package has its own way of parsing dates. Wonderfull. Boost has a Date_Time library, but I suspect we don't want to go there. I think its sufficient to disable the date format changing on win32 for now and trigger a warning if the original entered value has been changed by the user to a value our date parsing infrastructure cannot understand. This is better than disabling it completly on win32 and if somebody cares he / she can contribute the work to include strptime into monotone as suggested earlier to make it fully work. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Thomas Moschny thomas.mosc...@gmx.de writes: Stephen Leake stephen_le...@stephe-leake.org: Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. MinGW uses (i.e. provides headers for) the standard C runtime as provided by the Windows OS. And as far as I understand, there's simply no strptime() in that runtime, so we have to provide our own implementation (which basically means copying one of the various versions already provided by other open source projects). Well, now I know why glibc is not in MinGW: configure: running configure fragment for add-on nptl *** The GNU C library is currently not available for this platform. *** So far nobody cared to port it and if there is no volunteer it *** might never happen. So, if you have interest to see glibc on *** this platform visit *** http://www.gnu.org/software/libc/porting.html *** and join the group of porters So I tried copying just the part needed for strptime to monotone/glibc, and compiling there. It's currently dying with some mysterious C messages: ../monotone/glibc/strptime_l.c: In function `__strptime_internal': ../monotone/glibc/strptime_l.c:387: error: `locale' undeclared (first use in this function) ../monotone/glibc/strptime_l.c:387: error: (Each undeclared identifier is reported only once ../monotone/glibc/strptime_l.c:387: error: for each function it appears in.) ../monotone/glibc/strptime_l.c:781: error: structure has no member named `tm_gmtoff' ../monotone/glibc/strptime_l.c:783: error: structure has no member named `tm_gmtoff' ../monotone/glibc/strptime_l.c:783: error: structure has no member named `tm_gmtoff' ../monotone/glibc/strptime_l.c:1122: warning: assignment makes pointer from integer without a cast ../monotone/glibc/strptime_l.c:1126: error: dereferencing pointer to incomplete type ../monotone/glibc/strptime_l.c:1127: error: dereferencing pointer to incomplete type ../monotone/glibc/strptime_l.c:1128: error: dereferencing pointer to incomplete type ../monotone/glibc/strptime_l.c:1131: error: dereferencing pointer to incomplete type These do _not_ look easy to fix. So I'm looking at where strptime is used, to see what the impact of this is. It's used in three places: get_log_message_interactively, if date_fmt is not empty status, to check that date_fmt is compatible with get_log_message_interactively commit, to check that date_fmt is compatible with something (I'm not sure what) date_fmt is set by the user, via a command line option or hook_get_date_format_spec. So this is in support of user-configurable date formats. How important is that? Perhaps we could simply say user-configurable date formats not available on Win32. I'm ok with that. But it looks like some parts of monotone need to parse dates stored in certs, which may be in some user-configurable format? That seems like a bad idea in the first place (so I hope I'm wrong). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Thu, May 20, 2010 at 5:04 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: It's currently dying with some mysterious C messages: These do _not_ look easy to fix. So I'm looking at where strptime is used, to see what the impact of this is. It's used in three places: get_log_message_interactively, if date_fmt is not empty status, to check that date_fmt is compatible with get_log_message_interactively commit, to check that date_fmt is compatible with something (I'm not sure what) With the new changelog editor you may edit the Date: header as part of a commit, strptime is used to parse the date from the commit editor. The format is deemed to be acceptable if the current date is unchanged after being formatted and parsed with it. date_fmt is set by the user, via a command line option or hook_get_date_format_spec. So this is in support of user-configurable date formats. ... used in the changelog editor, as far as I know nothing else uses strptime to parse dates. How important is that? Perhaps we could simply say user-configurable date formats not available on Win32. I'm ok with that. Or editing the Date: header is unsupported on Win32 But it looks like some parts of monotone need to parse dates stored in certs, which may be in some user-configurable format? That seems like a bad idea in the first place (so I hope I'm wrong). These are all stored as ISO 8601 dates -MM-DDTHH:MM:SS possibly also with millisecond values in them, I'm not sure of that. The date_t class is able to parse this format natively without using strptime. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Derek Scherger de...@echologic.com writes: On Tue, May 18, 2010 at 2:49 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: which identifies 'strptime' as an XSI; X/Open System Interfaces Extension. So apparently MinGW doesn't support that. Annotate says 'strptime' was added recently, as part of the changelog-editor work: Uh oh. Can this be rewritten using more standard libraries? Do you have any in mind? No, but see below. This sounds like maybe mingw missed it. Maybe it will appear in a future release? http://www.mail-archive.com/bug-gnu...@gnu.org/msg17739.html Hmm. That says it's merely a header problem. So I added a local declaration of the function in dates.cc: extern char *strptime (__const char *__restrict __s, __const char *__restrict __fmt, struct tm *__tp); but now I get a link error: dates.o: In function `ZN6date_t24from_formatted_localtimeERKSsS1_': c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_string.h:1456: undefined reference to `strptime(char const*, char const*, tm*)' So it's not just a header problem. We could possibly copy an strptime implementation into our win32 directory I suppose. Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. But we should be able to get the source from the Debian glibc package; I'll give that a try. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Wed, May 19, 2010 at 05:56:43AM -0400, Stephen Leake wrote: This sounds like maybe mingw missed it. Maybe it will appear in a future release? http://www.mail-archive.com/bug-gnu...@gnu.org/msg17739.html Hmm. That says it's merely a header problem. So I added a local declaration of the function in dates.cc: extern char *strptime (__const char *__restrict __s, __const char *__restrict __fmt, struct tm *__tp); but now I get a link error: dates.o: In function `ZN6date_t24from_formatted_localtimeERKSsS1_': c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_string.h:1456: undefined reference to `strptime(char const*, char const*, tm*)' Should it be declared as extern C? The compiler may be looking for the mangled name with this declaration. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Jack Lloyd ll...@randombit.net writes: On Wed, May 19, 2010 at 05:56:43AM -0400, Stephen Leake wrote: This sounds like maybe mingw missed it. Maybe it will appear in a future release? http://www.mail-archive.com/bug-gnu...@gnu.org/msg17739.html Hmm. That says it's merely a header problem. So I added a local declaration of the function in dates.cc: extern char *strptime (__const char *__restrict __s, __const char *__restrict __fmt, struct tm *__tp); but now I get a link error: dates.o: In function `ZN6date_t24from_formatted_localtimeERKSsS1_': c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_string.h:1456: undefined reference to `strptime(char const*, char const*, tm*)' Should it be declared as extern C? The compiler may be looking for the mangled name with this declaration. Good point. But it didn't help; same link error. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Wed, May 19, 2010 at 3:56 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. FWIW man strptime here says: SYNOPSIS #define _XOPEN_SOURCE /* glibc2 needs this */ #include time.h Any chance that fixes it? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Stephen Leake stephen_le...@stephe-leake.org: Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. MinGW uses (i.e. provides headers for) the standard C runtime as provided by the Windows OS. And as far as I understand, there's simply no strptime() in that runtime, so we have to provide our own implementation (which basically means copying one of the various versions already provided by other open source projects). -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
Derek Scherger de...@echologic.com writes: On Wed, May 19, 2010 at 3:56 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Various web links hint that strptime is in glibc, so I don't understand why it's not in MinGW. FWIW man strptime here says: SYNOPSIS #define _XOPEN_SOURCE /* glibc2 needs this */ #include time.h Any chance that fixes it? Sorry, no. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Tue, May 18, 2010 at 2:49 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: which identifies 'strptime' as an XSI; X/Open System Interfaces Extension. So apparently MinGW doesn't support that. Annotate says 'strptime' was added recently, as part of the changelog-editor work: Uh oh. Can this be rewritten using more standard libraries? Do you have any in mind? Date formatting and parsing seems to be quite a ghetto. Boost maybe? This sounds like maybe mingw missed it. Maybe it will appear in a future release? http://www.mail-archive.com/bug-gnu...@gnu.org/msg17739.html We could possibly copy an strptime implementation into our win32 directory I suppose. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
