GIMP Version: 2.8.14
Operating System: Windows
GIMP Experience: Basic Level

List any relevant plug-ins or scripts:
Gimp-G'MIC

---

I put this memo here for those who may encounter the same problem:
- when the O.S (Windows in my case) is installed, it sets some editing formats according to the country in which it is installed
- one of these "formats" is related to number editing
- in Italy (as in many other countries) a number such as 1234 units and 56 cents is expressed as 1.234,56 (as opposed to US where it is expressed as 1,234.56)
- as long as these editing formats are used only to "print" numeric data no problem,
BUT
there is a big BUT when the edited form is used in a program as numeric input:
THIS HAPPENS WHEN A G'MIC FILTER IS CALLED FROM INSIDE A SCRIPT
because the filter is called as a string and -if there is a need to pass a value stored in a numeric field- so that the script uses the formula "(number->string field)", this is developed using the O.S. formats and the filter crashes! because G'MIC receives a not understandable/applicable value.
In my practical experience I was trying to use one of my scripts (which runs properly on my home computer) in another gimp/gmic installation and I got a crash; the parameter was the result of a calculation and was 1 followed by 1865 as decimal part.
Trying to understand the mystery, I added a simple trace statement i.e. "(gimp-message (number->string value))"; in my home computer it was shown as 1.1865 while in the other computer it was shown as 1,1865.0 and obviously G'MIC could not accept it.
Hence in the other system I had to go to Control Panel >> International Options >> Advanced Setting and change the "," into "." and viceversa for editing numbers.
After that, no more problem: the script runs there as in my home computer.

I hope this memo can help other people who:
- live in countries which use the same editing format for the number as Italy uses
- write (or make use) of script which invoke G'MIC commands using the (number->string scheme expression)

Changing country settings on the other computer to make your script run is a bit over the top. It is your responsibility as a script author to make your script more independent of local country settings.

In any programming language worth its salt you can specify a "locale" that indicates among other things how numbers should be formatted (commas, dots, groupings...) and there is a universal, no-frills locale called "C" (from the programming language) which is what programs use when they want to be country-independent under the hood. Otherwise you can format the number yourself.

thanks, but I do not understand what you want to say to me: in practice, what should a scheme script set in order to have the STATEMENT (number->string field) WORK APPROPRIATELY IN EACH COUNTRY?

a set of questions to SCHEME's gurus (to solve the above problem w/o modifying the O.S set-ups, as Ofnuts correctly suggests):
a) is there the possibility to have a "number->string" implementation which always return a string in the US standard number editing style (as required by G'MIC and almost any other program language)?
b) is there the possibility to have the source code of the built-in "number-string" proc to be able to implement point a) ?
c) is there any other way to inform gimp scheme that it has to use always the decimal point to separate the integer part from the decimal part of a number?

....and so on: any other practical suggestion?

thanks a lot

I don't know the particulars for Scheme. You could have to write the formatting routine yourself.

On point b):
the number->string procedure is defined in the file script-fu.init (in your system scripts folder) thus:

ie. it ends-up calling atom->string ..and that procedure is a built-in TinyScheme procedure, which itself simply calls C function snprintf() to do the formatting.

So it would appear to be the snprintf() function (in the GCC libc library) that is actually doing the locale-specific formatting and you will not be able to change the behaviour of number->string without hacking script-fu.init or TinyScheme ..which is out of the question for this relatively minor problem.

I think you will have to implement your own formatting procedure.

thanks Jonathan!
so it's not inside the scheme portion where the problem lies, it's in a called C function -sprintf()-
out of my possibilities
BTW, it is NOT a personal problem: any person who wants to write or use scripts where a G'MIC function is called having (as common) a calculated number will be in trouble:
- writing if he/she wants to share his/her code or simply lives in a "decimal point is comma" country and is writing own scripts
- using if he/she has a "locale" different from the author

anyhow, I will have a look for a simple solution...

Any person writing TinyScheme scripts. In Python by default all the string<->number conversions are done with the 'C' locale.

I'm curious if this 'Syntax of numerical constants' info is relevant?
FYI, I'm trying to learn about Scheme.

Not directly. That's MIT Scheme and it doesn't go into details about locale-specific formatting.
Gimp uses TinyScheme, which itself just exploits the string-formatting functions in the underlying C language.
It's those latter routines (in the GNU C Compiler's standard library) which are actually doing the locale-specific formatting here.

You had another good opportunity to recommend Python! hehehe...ya, a much more complete and "consistent" language.

Really, in this case, i guess that there is a bug in TinyScheme: it SHOULD take care of "locale", it is used worldwide...

Surely it's a bug in G'MIC as when it's converting from strings into numbers it's NOT using the locale.

Anyway, what you need is a function to either do the number->string with the full-stop decimal mark, or a function to replace the commas in number/strings with full-stops.

Kevin

No,no,no!
TinyScheme isn't bothered with locale - it just assumes the underlying C will take care of that.
The problem here is that TinyScheme does not provide a constant decimal-point-only format, which is what G'MIC requires. (The G'MIC interpreter expects fractional numbers to be represented with a dot as decimal mark ..and no commas since it uses comma to separate parameters.)
That's not a bug, per se, but it is an inconvenience which Python has mitigated by furnishing the "C" locale.

ok, let's call it just an inconvenience, but the bottom line is:
- no coder can use tinyscheme scripts calling gmic without impacting the utilization of those scripts
(or the system setups)
for a set of international languages (tinyscheme - gimp - gmic) it is a severe inconvenience

(the easiest solution? : a "number->script" built-in function with a parameter specifying the output format...)

Don't want to get spammed but you Euros just don't know the difference between a comma and period or how to use them. lololol

Now I know I'll be spiced hammed soon enough. lolol

Although G'MIC is, of course, French in origin, "continental" number format (ie. using comma as decimal mark and dot as thousands separator) is actually incompatible with G'MIC's command syntax (which uses comma as parameter separator).


Post-processing the string produced by number->string won't work if thousands-separators are used in the locale, eg:
1,234.56 = 1234.56 in UK/US/etc
1,234.56 = 1.23456 in France/Italy/etc
In the latter form, the comma is the decimal mark and the dot is the thousands-separator. The post-processing would have to know/assume the locale's designation ..which is precisely the problem!

You're wading into a quagmire, Lyle.
There is a long history to this ..see https://en.wikipedia.org/wiki/Decimal_mark
And don't just assume that you Yanks have got it "right", 'cos us Brits came very close to going the "continental" way.

That's one. lolol

Come on folks; I like fried spam. lol

There's also Period=Full Stop. A period is a measure of time not a dot.

Well done, Kimba. Teach Mr. Kroll some manners.