#emc-devel | Logs for 2010-10-06

[07:56:16] <micges_work> hello
[07:56:27] <micges_work> I have weird problem
[07:58:24] <micges_work> I've written python program that use gcode.so from emc to process gcode files(simmilar to Axis' preview generator)
[07:59:21] <micges_work> it was made for understanding and testing task<->interp interface
[08:00:44] <micges_work> problem is that interpreter called from gcode.so from python code doesn't process '.' (period) sign, all real values are rounded to int
[08:01:58] <micges_work> I've located that buggy function is strtod() in Interp::read_real_number()
[08:02:47] <micges_work> it seems that it is some localization problem, but I can't fix it
[08:03:22] <micges_work> please help
[08:04:04] <psha> try running with LC_ALL=C
[08:05:37] <psha> LC_ALL=C python progname
[08:05:57] <psha> if this works then just set locale (or just conversion rules) in program
[08:06:42] <micges_work> I've tried many LC option but none seems to work
[08:06:44] <psha> smth like 'import locale; locale.setlocale(locale.LC_NUMERIC, 'C')
[08:06:59] <micges_work> but I haven't try C
[08:07:02] <micges_work> thanks
[08:07:32] <micges_work> I'm at work now, I'll test it this afternoon
[08:09:30] <psha> it's 'default' locale, sometimes referred as POSIX
[12:18:08] <jepler> I suspect psha is right. at the moment, you have to have LC_NUMERIC=C (or at least one which uses "." for RADIXCHAR) when calling into the interpreter. we could test explicitly for this, since it's tripped up a number of people in the past. http://emergent.unpy.net/files/sandbox/rs274-detect-and-provoke-locale-problem.mbox
[12:34:08] <micges_work> can't we detect locale on interp init and save it somewhere?
[12:58:12] <jepler> micges_work: No. Calling setlocale() in rs274 will break multithreaded programs that use the library, because setlocale() applies to all threads
[12:58:50] <jepler> on the other hand, an application that uses locales, threads and calls rs274 can establish whatever locking is required to set LC_NUMERIC=C during any call into rs274
[13:03:49] <micges_work> I see
[13:03:51] <micges_work> thanks
[13:17:10] <jepler> I wish I knew offhand whether anything else in rs274 breaks with a non-C locale set, because with C++ it's relatively easy to write a non-locale-respecting conversion from string to double
[14:14:00] <jepler> READ => g0x[1---3]
[14:14:00] <jepler> 5 N..... STRAIGHT_TRAVERSE(-2,0000, 0,0000, 0,0000, 0,0000, 0,0000, 0,0000)
[14:14:13] <jepler> huh, I'm a tiny bit surprised this is accepted
[14:14:36] <jepler> READ => g0x-+-+-+-3
[14:14:36] <jepler> 7 N..... STRAIGHT_TRAVERSE(3,0000, 0,0000, 0,0000, 0,0000, 0,0000, 0,0000)
[14:14:47] <cradek> I thought that was a known result of adding unary -
[14:15:35] <jepler> I guess so
[14:15:54] <jepler> the "number" when read_real_number is reached is "-3"
[14:25:54] <psha> http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator
[14:26:08] <psha> like -+-+- but for C :)