← Back to team overview

kicad-developers team mailing list archive

Re: Locale fix in KiCAD is not working (breaks my build)


Ok, committed in 4008, cleanups included. 

Finally I used the LOCALE_IO implementation, because converting in
some situations didn't work, and my time was exhausting for today…

I think there are some locale manipulators in std:: c++ that would
let us do those conversions without switching system locale, but we will have to try.

Miguel Angel Ajo
skype: ajoajoajo

On 15/03/2013, at 17:17, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 03/15/2013 10:16 AM, Miguel Angel Ajo Pelayo wrote:
>> I'm doing it with pleasure, there's nothing better than reading
>> standardized code when
>> you get used to an style.
>> One question: I'm uncrustifying, and diff-checking my .cpps/.hs, as
>> for sure I'd forget many things manually.
>> It seems that it's adding spaces to align variable declarations in
>> blocks
>> int PYTHON_FOOTPRINT_WIZARD::GetNumParameterPages()
>> {
>>    int         ret = 0;
>>    PyLOCK      lock;
>>    // Time to call the callback
>>    PyObject*   result = CallMethod( "GetNumParameterPages", NULL );
>> Is this acceptable or enforced by our current policy?
> Yes to acceptable.  I am sure I put that in the uncrustify config
> file.  Look at my code, I do that all the time.
> (Uncrustify aligns to the nearest tab stop, which is sometimes overly
> far to the right, *but is better than not at all*.
> I don't know that uncrustify uses tab=4 in that determination.....  It
> should, but may not be.  You can also tell it just to find the nearest
> column to the right.
> The C++ code in uncrustify is pretty well written stuff, but sometimes
> I dream about having unlimited time and making it even better that it
> already is, which is crazy good. 
> Its biggest problem is that it has to please too many personal tastes,
> and that leads to a lot of config variables.)
> To be honest, you can also mostly just look at my code, duplicate it,
> and it will probably be acceptable.

Follow ups