From attila.lendvai at gmail.com Thu Sep 29 13:18:39 2011 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 29 Sep 2011 15:18:39 +0200 Subject: [cl-l10n-devel] cl-l10n changes since version 0.4 In-Reply-To: <255B2CE9-E436-45DE-906C-A2FFF46686DE@media.mit.edu> References: <255B2CE9-E436-45DE-906C-A2FFF46686DE@media.mit.edu> Message-ID: hello Ian, (i've CC'd the list, i hope you don't mind) first of all, the old branch is still available if you don't want to bother with the new things and need the old date parsing code: http://common-lisp.net/cgi-bin/darcsweb.cgi?r=cl-l10n-cl-l10n.unix-locale-files;a=summary as of the parsers: parse-number is available as a standalone system. for timestring parsing local-time has some functions. you may also find this useful, it's in our web-server for HTTP stuff: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.web-server;a=headblob;f=/source/util/timestring-parsing.lisp if you need the old dwim-ish timestring parsing, then i suggest to copy-paste it into your codebase (or stick to the old l10n repo). in the new l10n, based on http://cldr.org , timestring parsing is not done yet. the locale description files contain patterns that can also be used to generate/derive/command parsers, not only formatters, but not much has been explored in that area yet. the formatters are mostly done, but that's also not 100% complete. > If you aren't planning support, is there some hooks/support I could build on to create a symmetric solution for parsing in cl-l10n? as of now, there's no parsing of any sort in the head of cl-l10n, so no API either. let me know if you have more specific questions, or especially actual use-cases. this is all that comes to my mind for now. -- ?attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C ?963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 From attila.lendvai at gmail.com Thu Sep 29 17:22:46 2011 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 29 Sep 2011 19:22:46 +0200 Subject: [cl-l10n-devel] cl-l10n changes since version 0.4 In-Reply-To: <8AED03E6-4CAD-4911-9777-A1EDDA231111@media.mit.edu> References: <255B2CE9-E436-45DE-906C-A2FFF46686DE@media.mit.edu> <8AED03E6-4CAD-4911-9777-A1EDDA231111@media.mit.edu> Message-ID: fyi, i've pushed a patch that extends the README with bits'n'pieces of this discussion. > Any guess on the scale of effort to build parser-generator > from the cldr patterns that parse strings based on the locale > the user is from? ?Would also want to generate format > hinting out of that data. as of parsing, this is the related part of the latest version of the cldr spec: http://www.unicode.org/reports/tr35/tr35-21.html#Lenient_Parsing i don't know how much effort it is, but generating formatters from the format strings The Right Way is not trivial. look at the code and you'll see all the shifting of computation between compile/runtime... although, The Really Right Way would be to let a partial evaluator eliminate what is possible at compile time, but let's just not go there in the scope of this... :) > I also would like to be able to deploy my application > automatically on top of quicklisp without too many > exception cases. i understand you pain, and that's why i've mentioned that copy-pasting the dwimish date parser code into the project is something i'd consider as a v0.1 solution, because the effort it takes is uncomparable to writing the parser compiler. -- ?attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C ?963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06