kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

On Saturday, 24 de January de 2015 at 14:25, Piers Titus van der Torren wrote:

> On Sat, Jan 24, 2015 at 11:58 AM, Miguel Ángel Ajo <majopela@xxxxxxxxxx (mailto:majopela@xxxxxxxxxx)> wrote:
> > Hi, I’ve been playing a bit around, being able to locally define the default units [1]
> > but I’m not satisfied with it, because the implementation is not thread safe (big  
> > sad-face “:-(“  )
> >  
> Another option would be to use the default unit from the general settings (g_UserUnit), that way nothing has to be stored in the python module. Just user unit versions of the conversion functions would do:
> def _from_user_units(val):
>     unit = pcbnew.GetAbbreviatedUnitsLabel()
>     if unit == 'in':
>         return pcbnew.FromMM(float(val) * 25.4)
>     elif unit == 'mm':
>         return pcbnew.FromMM(float(val))
>  
> However I think this may add more problems than being clear about a default unit and having easy conversion functions. (mostly on the user side with forgetting to set/check default units, but also on the internal side where float rounding issues might appear, 1.0/2.54*2.54 = 0.9999999999999999 with float precision)
>  

I believe relying on user settings would render scripts incompatible depending on the settings the user
configured.

If we set an standard needs to be compatible forever and all.

For just in case using contexts doesn’t work (starts to look like it’s not possible (thread safe)  
without hacking too much - looking back stack frames until finding last unit settings, I’ve
created this poll:

https://www.surveymonkey.com/s/YBSKM9C

Does it look reasonable before sharing starting an specific thread?.
  
>  
> > (ignore the Point(x,y) Size(x,y) passing, Piers, you really convinced me
> > it’s more reasonable to just use (x,y) where we can.
> >  
> > I have forked your lib here:  https://github.com/KiCad/kicad-python (https://github.com/KiCad/kicad-python/blob/master/kicad/units.py) to retain
> > your original authorship.
> >  
> > I have also added sphinx so we can build the docs as normally done for python
> > APIs [2] and a bit of testing [3] which is passed over here, along with pep8 / flake8 checks
> > [4], for that may be it’s better to use travis-ci as it has better integration to
> > github.
> >  
> Thanks, good to have more structure. What's the reason you didn't rename pcbnew_easy.py to kicad/pcbnew.py? I don't see the need for a subdirectory there.
>   
> > I will be playing a bit more around the default units context, as a second option
> > we could default to inches or mm (with the ability to explicitly provide other unit
> > in parameters).  
>  
> Nice to see these experiments with contexts, it's a nifty idea.
> However I still think the easiest and most versatile solution would be to have default units and a recursive inch_to_mm (or shorter: in2mm) function.
>  
> For example combining units like in the following action would be hard with a units='in' parameter:
>  
> m.add_pad(position=in2mm((0, 0.1)), drill=1.0)
>  
> I do use both units sometimes because some things are standardized in inch, like pin header spacing, but in that case I still use metric drill sizes, so I think this example is a realistic action.
>   
> > I would guess that mm is more common among users, because of the european
> > origin of the software, but may be a poll would be good here.
> >  
> >  
>  
>  
>  And most American companies finally use metric units too nowadays (at least in most datasheets I encounter)
> >  
> > Best regards,
> > Miguel Ángel.
> >  
> > [1] https://github.com/KiCad/kicad-python/blob/master/kicad/units.py  
> > [2] http://ci.kicad-pcb.org/job/kicad-python/ws/doc/build/html/index.html
> > [3] https://github.com/KiCad/kicad-python/tree/master/kicad/tests/unit
> > [4] http://ci.kicad-pcb.org/job/kicad-python/
> >  
> >   
> >  
>  
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>