> Does anyone know exactly what problem the locale stuff is fixing? And
> a follow-on, is there another way to fix it?
The problem is that we parse things like decimals for coordinates (0.)
which exist in the C locale. So we need to make sure the parsing code works in
C locale not any other
After making the changes to use the alternative thread-safe Match
function, the next failure is with obLocale which is another global.
Commenting out "free (d->old_locale_string);" semi-works around it for
now (with a memory leak) but it can still segfault elsewhere in the
locale code.
Does anyone
I've just realised that David Koes has already fixed this, by
providing just such an interface, a Match function where you pass in
the vector for storing the matches. I owe you a pint or two, David.
Note to self: as part of the API cleanup, we should remove the other functions.
- Noel
On 19 Febr
I've made progress, but my current problem is that it's not possible
to match the same SmartsPattern on different threads (as required, for
example, by the typers, where sets of smarts patterns are initialised
once and then reused). The matchers store the results as part of the
pattern instead of r
