So I looked into this, trying to solve it by calling printf through the FFI with a locale setup and cleanup.
The difficulty comes from the fact that printf is a variadic function.. Factor's ffi doesn't support them, at least no in a cross platform manner, right? So a workaround could be to wrap printf in C many times, compile that to a shared library and call the different wrappers with the FFI depending on the number of arguments and their types, but it would be nicer to have a better support of variadic functions. Anyway, it (kind of) worked on linux x86_64 with the following code: http://paste.factorcode.org/paste?id=3584 Since printf is a variadic function, you have to use FUNCTION-ALIAS to create functions with the correct number of arguments and the correct types. So for example, FUNCTION-ALIAS: mysnprintf-int2 int snprintf ( char* result, size_t size, c-string format, int d, int d2 ) would work too. However, passing floats didn't work on linux x86_64, because the system V AMD64 ABI says that the number of float arguments must be in RAX before calling the function, and factor always sets this to 0. With the following diff, it worked for 1 float: in cpu/x86/64/64.factor (and basis/cpu/x86/64/64.factor ??) -M: x86.64 %prepare-var-args ( -- ) RAX RAX XOR ; +M: x86.64 %prepare-var-args ( -- ) RAX 1 MOV ; I don't know how hard it would be to generate the correct value for RAX for variable arguments. Also, I'm not sure if it works better for other ABI/platforms. Do you think that's something worth investigating ? Jon On Wed, Aug 12, 2015 at 7:10 AM, Georg Simon <georg.si...@auge.de> wrote: > Am Tue, 11 Aug 2015 09:02:33 -0700 > schrieb John Benediktsson <mrj...@gmail.com>: > > Thank you. So I didn't overlook existing locales support. > > > Properly supporting locales, even in a small way, would be a good > > thing to add. > > > > Factor is currently locale-independent, partly because of a desire for > > homoiconicity, and partly because it prevents things like tests that > > break depending on the system locale[1]. > > > > We have discussed adding a locale vocabulary or a with-locale > > combinator that can influence presentation of numbers and strings, > > maybe looking at how other languages work[2]. Probably we'd want to > > keep the math.parser locale independent, but provide ways for things > > like present / printf to be locale-aware. > > > > If this is an issue for something you are building, you could use > > alien.ffi to call sprintf or use C++ stringstream or something and > > call the library from Factor, or do something slow like this, calling > > out to Python: > > > > : format-with-locale ( n locale -- s ) > > swap [ > > "python" , "-c" , > > "import locale; locale.setlocale(locale.LC_ALL, \"%s\"); > > print(locale.format(\"%%f\", %s))" sprintf , > > ] { } make B utf8 [ readln ] with-process-reader ; > > > > IN: scratchpad 1.5 "fr_FR" format-with-locale . > > 1,500000 > > > > --- > > [1] https://github.com/slavapestov/factor/issues/905 > > [2] https://docs.python.org/3/library/locale.html > > > ------------------------------------------------------------------------------ > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk >
------------------------------------------------------------------------------
_______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
