Comments for Came for the beer, stayed for the Freedom http://audidude.com Programming is not a spectator sport Fri, 27 Aug 2010 18:03:26 +0000 http://wordpress.org/?v=2.9 hourly 1 Comment on GDateTime by Morten Welinder http://audidude.com/?p=477&cpage=1#comment-724 Morten Welinder Fri, 27 Aug 2010 18:03:26 +0000 http://audidude.com/?p=477#comment-724 The implementation is an unmitigated disaster. See bug 628137. This should clearly have been using GDate for all the date calculations. It is non-trivial to get right. Even worse, there seems to have been no thoughts about error handling in the API. That really should be fixed before it gets into a stable release. The implementation is an unmitigated disaster. See bug 628137.

This should clearly have been using GDate for all the date calculations. It is non-trivial to get right.

Even worse, there seems to have been no thoughts about error handling in the API. That really should be fixed before it gets into a stable release.

]]> Comment on GDateTime by chergert http://audidude.com/?p=477&cpage=1#comment-719 chergert Thu, 26 Aug 2010 16:41:45 +0000 http://audidude.com/?p=477#comment-719 Daniel, GCalendar stuff is not yet added. But the goal is to do that later on once we can solidify the API. hb, it should be trivial to add 8601 parsing since you can convert to/from GTimeVal. Daniel, GCalendar stuff is not yet added. But the goal is to do that later on once we can solidify the API.

hb, it should be trivial to add 8601 parsing since you can convert to/from GTimeVal.

]]> Comment on GDateTime by chergert http://audidude.com/?p=477&cpage=1#comment-718 chergert Thu, 26 Aug 2010 16:38:23 +0000 http://audidude.com/?p=477#comment-718 Miguel, I actually agree. In fact, that is how I originally wrote it. However, it was decided that having more structures on the stack will end up being tougher to maintain and build an API around. Miguel, I actually agree. In fact, that is how I originally wrote it. However, it was decided that having more structures on the stack will end up being tougher to maintain and build an API around.

]]> Comment on GDateTime by Miguel de Icaza http://audidude.com/?p=477&cpage=1#comment-716 Miguel de Icaza Thu, 26 Aug 2010 15:28:58 +0000 http://audidude.com/?p=477#comment-716 The only odd thing here is that this is reference counted. The value of reference counting here in my opinion is very low. It should instead have structure semantics. Similar to "struct stat" in the kernel API. The only odd thing here is that this is reference counted.

The value of reference counting here in my opinion is very low. It should instead have structure semantics.

Similar to “struct stat” in the kernel API.

]]> Comment on GDateTime by hb http://audidude.com/?p=477&cpage=1#comment-715 hb Thu, 26 Aug 2010 15:12:39 +0000 http://audidude.com/?p=477#comment-715 Great, thanks for that work. Are there plans to include ISO 8601 string parsing, too? Great, thanks for that work. Are there plans to include ISO 8601 string parsing, too?

]]> Comment on GDateTime by Daniel Morgan http://audidude.com/?p=477&cpage=1#comment-714 Daniel Morgan Thu, 26 Aug 2010 11:40:22 +0000 http://audidude.com/?p=477#comment-714 Very nice. I like the sorting of gdatetime. Does it include your changes for gcalendar as well? Very nice. I like the sorting of gdatetime. Does it include your changes for gcalendar as well?

]]> Comment on GDateTime by frederik http://audidude.com/?p=477&cpage=1#comment-712 frederik Thu, 26 Aug 2010 09:51:24 +0000 http://audidude.com/?p=477#comment-712 @Philip Van Hoof: But they are only called "_printf" if they take printf format specifiers plus varargs. The date formatting has different format specifiers and takes no varargs. @Philip Van Hoof: But they are only called “_printf” if they take printf format specifiers plus varargs. The date formatting has different format specifiers and takes no varargs.

]]> Comment on GDateTime by Philip Van Hoof http://audidude.com/?p=477&cpage=1#comment-711 Philip Van Hoof Thu, 26 Aug 2010 09:39:45 +0000 http://audidude.com/?p=477#comment-711 @Emmanuel: I agree that to_string() is nicer and probably fits better with Vala. However, for format strings it looks like GLib usually uses _printf style: g_string_printf g_string_append_printf g_strdup_printf g_markup_printf_escaped vs. g_quark_to_string g_credentials_to_string g_icon_to_string g_inet_address_to_string @Emmanuel:

I agree that to_string() is nicer and probably fits better with Vala. However, for format strings it looks like GLib usually uses _printf style:

g_string_printf
g_string_append_printf
g_strdup_printf
g_markup_printf_escaped

vs.

g_quark_to_string
g_credentials_to_string
g_icon_to_string
g_inet_address_to_string

]]> Comment on GDateTime by frederik http://audidude.com/?p=477&cpage=1#comment-710 frederik Thu, 26 Aug 2010 09:39:00 +0000 http://audidude.com/?p=477#comment-710 @Emmanuel: Yes, "_printf" usually prints something (formatted). However, "_to_string" functions usually don't take a format string parameter. I would call it "_format". @Emmanuel: Yes, “_printf” usually prints something (formatted). However, “_to_string” functions usually don’t take a format string parameter. I would call it “_format”.

]]> Comment on GDateTime by chergert http://audidude.com/?p=477&cpage=1#comment-709 chergert Thu, 26 Aug 2010 09:34:20 +0000 http://audidude.com/?p=477#comment-709 The to_string() methods don't take parameters for formatting. So it wouldn't be any more consistent. The to_string() methods don’t take parameters for formatting. So it wouldn’t be any more consistent.

]]>