01:37:07 jclulow: completely fair. There's probably *already* some banking software to have hit the 2038 bug 01:59:30 though banking software is more likely to use COBOL date formats than those based on the Unix Epoch 02:34:24 who 02:34:37 (sorry) 06:01:46 Yeah, I would not be using time(2) or ctime(3C) for anything where I actually cared about time, haha 14:07:50 Release r151054 (LTS/stable) is available - https://omnios.org/article/r54 16:09:05 did some digging into libstc++ locale support. The "generic" code we use today throws exceptions on contact with a non-C locale facet. Looks like we're about five xlocale.h *_l entrypoints away from being able to use the "dragonfly" libstdc++ locale code. 16:09:25 (motivated by seeing my gnucash port crash unless LC_ALL=C) 16:14:15 looks like: strtof_l strtod_l strtold_l localeconv_l wcsftime_l 16:25:10 sommerfeld: https://www.illumos.org/issues/7354 16:49:59 There was some discussion around some of those in the past. If those are useful, it probably wouldn't be too bad to look at. 17:00:04 this reminds me, I was wondering a while ago if we have translation strings for system messages somewhere? 17:00:51 yes 17:05:53 we do create po files (./proto/root_i386/usr/lib/locale/C/LC_MESSAGES/) but thats about it. 17:15:22 but nothing besides C, or did I miss that? 17:15:56 there are no translations, no 17:16:15 i'm guessing those were never released back in the day? 17:16:22 (i.e. we'd had to do the work ourselves) 17:17:35 probably. I would not really expect there to be many anyhow... 17:18:33 i'd have thought solaris would have had a fair number of translations, but it's also not something i ever had to look into... 17:22:18 yep, if we had old ones that were just a bit outdated it might have been fun to get any new strings done - but starting from scratch looks a lot more daunting 17:25:59 i thought someone mentioned there was a site (or sites) where you could pay people to do the translation (though not sure how expensive or how good the results would be) 17:26:11 Yeah, I'll take a look at adding those five functions (a first glance suggests it shouldn't be hard). 17:26:42 or i suppose (stepping into a minefield here) we could see how well chatgpt or the like does as an initial starting point 17:27:12 (there's probably other considerations we'd need to look at if we wanted to seriously entertain the latter) 17:27:22 yea, s11 definitely has them for de_* but ... then again, once done, the translations will last long time considering the rate of changes we have;) 17:28:30 i mean, even though my german and spanish is both limited and absolutely horrible, I'd like to see us have translations since I think it'd reduce a potential barrier for people that are interested 17:28:31 not sure about the possible copyright claims related to AI;) 17:28:47 so not something i felt there was much I could do to help there.. 17:29:19 yeah, that'd be the big concern since it seems like the law on that (at least in the US) is far from settled 17:37:41 also I think we still have hidden bugs due to gettext() masking the format strings 17:38:35 jbk: yeah, chances are good that a LLM would just regurgitate another OS's copyrighted translation of the same error message. 17:39:29 or well, produce output indistinguishable from another OS's copyrighted translation.. 17:39:45 .. but then so might a human translator.. 17:40:51 yeah, i can't imagine that in least some cases, there's going only be a small (even 1) number of correct translations 17:41:28 e.g. I'm guessing there aren't many ways to say 'File not found' in many languages 17:48:37 One rathole I went down for the gnucash port was around lconv->*grouping. As best I can tell there are 4 values for "grouping" that are actually used ("" - no grouping, "\177" - no grouping, "\003" - every 3 digits used in most of the world, "\003\002" - south asian 1,00,00,000.00). Some systems have "" in the C locale. We have "\177", and I belive so does FreeBSD. MacOS and Linux have "". 17:49:21 Lots of mechanism for only a couple different variants. 18:00:11 jbk: plus there's the matter of providing sufficient context to translators so they understand that "file" isn't referring to a rasp-like woodworking tool or a line of people or animals one behind each other... 18:29:41 Filed https://illumos.org/issues/17416 18:49:58 oooh 19:16:10 Illumos-related dad joke of the day... realtime audio production fork of OmniOS:ΩniOS... 20:17:25 * jbk resists the urge to comment :P 21:47:47 I love a good dad joke, but I'm missing the subtlety here beyond s/Om/{Ohm,Ω}/g 22:11:18 danmcd: perhaps there's some sort of impedance to your sense of humor.. 22:12:27 oh, oh no 22:19:04 I thought it was a music-software reference, but my music-software pointer is uninitialized so SEGV. 22:23:05 richlowe: okay, should __EXTENSIONS__ imply _LCONV_C99 (in , included by ) ? 22:23:13 I'd think it should.. 22:25:34 Hm, I think so. 22:27:41 I'll make that part of 17416 22:29:44 __EXTENSIONS__ on its is probably insufficient. 22:29:51 *on its own 22:30:02 That is C89 + extensions should probably not see it? 22:34:29 so ((defined(_STRICT_STDC) || defined(__EXTENSIONS__)) && defined(_STDC_C99)) || defined(_LCONV_C99)? 22:37:40 Maybe? Let me go read a few docs. 22:38:12 thanks for taking a look.. 22:38:33 No problem. I had had some notes to look at those a while back so appreciate you looking at adding those functions. 22:39:26 I have them prototyped to the point where I'm running a nightly. 22:39:31 It was not hard. 22:42:33 So thinking on it a bit more, the C89 specific bit makes me a bit uncertain. A part of me thinks it kind of wants to be just #if !defined(_STRICT_SYMBOLS) || defined(_STDC_C99) || defined(_LCONV_C99). 22:43:29 That would mean non-strict C89 does see it. It also means that older POSIX will not see it, but I think that's a bit to go double check is who first introduced the extensions. 22:44:41 The new stuff would just be the simple if !defined _STRICT_SYMBOLS. 22:46:06 Yeah, I think seeing it in C89 in a non-strict mode is probably... fine. 22:46:59 new functions land in xlocale.h which is not in standards-land. 22:47:11 Ah, then you're fine.