Re: [Kicad-developers] macOS 10.15 packages
The 10.14 packages work on 10.14 and 10.15, and have since 2 or 3 days since 10.15 came out. Let's make sure it's clear on the website. The readme is clear, but that's inside the download :) Adam On Thu, Feb 13, 2020 at 5:03 PM Wayne Stambaugh wrote: > > Someone sent me a direct email asking about packages for macOS 10.15. > Is there a reason why we don't have 10.15 packages yet? If so, will the > 10.14 packages work on 10.15? I would like to give a sensible answer if > possible. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] macOS 10.15 packages
Wayne, According to an earlier email thread [1], the 10.14 packages should work on 10.15. There is just an issue with our naming of them not including 10.15,and the website not saying it. [1] https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg37489.html On Thu, 13 Feb 2020, 23:03 Wayne Stambaugh, wrote: > Someone sent me a direct email asking about packages for macOS 10.15. > Is there a reason why we don't have 10.15 packages yet? If so, will the > 10.14 packages work on 10.15? I would like to give a sensible answer if > possible. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] macOS 10.15 packages
Someone sent me a direct email asking about packages for macOS 10.15. Is there a reason why we don't have 10.15 packages yet? If so, will the 10.14 packages work on 10.15? I would like to give a sensible answer if possible. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Hi Wayne, On 13.02.20 20:47, Wayne Stambaugh wrote: > One thing that can be said > for sure about 64 bit internal units is that there will be a performance > hit on 32 bit architectures. The questions are how much and do we care? I'd expect that to be negligible compared to cache effects, where we lose a bit because objects grow in size, and gain a bit because we get rid of a few megabytes of almost-but-not-quite duplicated code. If we were interested in micro-optimizing, unified internal units would allow linking everything into a big application, dropping the requirement for kifaces to be position-independent code, which would give 32-bit x86 a 2-5% speedup. The big gain of unified internal units would be on the developer side, because we'd improve compilation speed, and we'd spend a lot less time explaining to new developers why we're building position independent static libraries, and why certain functions cannot be used from functions inside common/. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Symbol library help
On 2/13/20 12:59 PM, Seth Hillbrand wrote: > On 2020-02-12 17:38, Wayne Stambaugh wrote: >> Does anyone know if one of the KiCad symbol libraries has a symbol that >> utilizes bezier curves or has a sample library that does? I'm just >> about done with the new symbol library file formatter and I would like >> to test the bezier support with something other than a canned sample to >> make sure the formatting is correct. Thanks in advance for the help. >> >> Cheers, >> >> Wayne > > Did we ever implement a control in LibEdit for bezier? I know we're > halfway there in pcbnew but I've never seen bezier controls on the > LibEdit side. I don't believe bezier curves were ever implemented in the symbol library editor. We've been dragging along the LIB_BEZIER object for as long as I can remember. I don't know if anyone has been using manually edited symbol library files or if they would even render in the schematic and symbol library editors. Maybe JP can shed some light on this. I just don't like the idea of having untested formatter and parser code for objects that we don't and/or cannot use. > > -Seth > > Seth Hillbrand > KiCad Services Corporation > https://www.kipro-pcb.com > +1 530 302 5483 | +1 212 603 9372 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Compiling the internal units code multiple times is ugly but it could be replaced by a pure virtual class that implements the internal units specific scaling. Although a single common internal unit would be cleaner. While 64 bit 1nm internal units would solve some issues, we have far bigger issues to resolve than this for V6. There is also a significant risk that it could break existing code so it's definitely not going to happen for V6. We can discuss it for V7. One thing that can be said for sure about 64 bit internal units is that there will be a performance hit on 32 bit architectures. The questions are how much and do we care? Cheers, Wayne On 2/13/20 10:06 AM, Thomas Pointhuber wrote: > Hi Wayne, > > I think, I was present at FOSDEM 2019 when talking about this issue. > > From what I understand, the current approach requires KiCad to compile > the units for each package separately (because e.g. mapping IU<->mm is > always different). This has two big problems: > > 1. the same code has to be compiled multiple times. > 2. there is no "true" mapping from IU to other units. When I for example > want to create a python API with one type of geometric primitives, this > is a real problem. When I want to script into eeschema and pcbnew at the > same time, how to choose the correct units? > > The solution discussed was to move to 64bit and to use > constexpr/templates handling unit conversion. So a programmer can for > example enter 2mm and the compiler automatically converts it into the > internal unit like nm. > > I'm still in favour of improving this. The same with angles. > > Regards, > Thomas > > > Am 13.02.20 um 15:46 schrieb Wayne Stambaugh: >> Hi Johannes, >> >> Thank you for your suggestion but the internal units for each format >> were chosen for a specific reason. There really is no justifiable >> reason to change them as they have been carefully selected based on the >> requirements of the objects they represent. Conversion code is provided >> for each internal unit so plotting to standard units such as >> millimeters, inches, etc is trivial. I'm not opposed to adding support >> for changing the plot units. I am opposed to changing the internal units. >> >> Cheers, >> >> Wayne >> >> On 2/13/20 9:32 AM, Johannes Pfister wrote: >>> The KiCAD code uses all kinds of different units for distances. >>> Amongst other things I found: >>> nm: pcbnew internal units >>> 10nm: Gerbview internal units >>> 100nm EEschema internal units >>> 1um: PL-Editor internal units >>> 0.1mil (2.54um): SetViewport >>> 1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils >>> And the native File formats use mm (pcbnew) and mil (EEschema). >>> Something like SVG exports in 0.1 mil steps. I think that this is not >>> very consistent and something like a PLOTTER class needs to handle >>> different IU-sizes. >>> >>> My idea is to rewrite the internal units so that nm are used >>> everywhere inside the source code, and only parts that write or read >>> files and display data to or read data from the user should convert it >>> to another unit system. I don't want to change any file formats. >>> That would make it a bit more straightforward, more consistent, metric >>> and an SVG-Plotter would use a metric step size. The disadvantage >>> would be that there would be an about 2m or 4m limit in every >>> direction, assuming int is 32 bit, which is AFAIK true for all >>> platforms KiCAD current supports. >>> >>> Before i rewrite code, can you say what you guys think about it? >>> >>> >>> Johannes Pfister >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Le 13/02/2020 à 20:08, jp charras a écrit : > Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit : >> Hi Johannes, >> >> Thank you for your suggestion but the internal units for each format >> were chosen for a specific reason. There really is no justifiable >> reason to change them as they have been carefully selected based on the >> requirements of the objects they represent. Conversion code is provided >> for each internal unit so plotting to standard units such as >> millimeters, inches, etc is trivial. I'm not opposed to adding support >> for changing the plot units. I am opposed to changing the internal units. >> >> Cheers, >> >> Wayne > > I fully agree with Wayne. > > Why these different units (I am talking only about coordinates, not angles): > Pcbnew uses 1nm. > Due to the fact a "int" is widely used in code for many calculations, the > actual size of a board is roughly > INT_MAX / 1.414 with a margin: say INT_MAX/2. > Why INT_MAX / 1.414? > Because we need to calculate distances (and inside a square, the max dist is > INT_MAX / 1.414) and we also > need margins. Sorry: the max dist is INT_MAX inside a square having a size of INT_MAX / 1.414 -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit : > Hi Johannes, > > Thank you for your suggestion but the internal units for each format > were chosen for a specific reason. There really is no justifiable > reason to change them as they have been carefully selected based on the > requirements of the objects they represent. Conversion code is provided > for each internal unit so plotting to standard units such as > millimeters, inches, etc is trivial. I'm not opposed to adding support > for changing the plot units. I am opposed to changing the internal units. > > Cheers, > > Wayne I fully agree with Wayne. Why these different units (I am talking only about coordinates, not angles): Pcbnew uses 1nm. Due to the fact a "int" is widely used in code for many calculations, the actual size of a board is roughly INT_MAX / 1.414 with a margin: say INT_MAX/2. Why INT_MAX / 1.414? Because we need to calculate distances (and inside a square, the max dist is INT_MAX / 1.414) and we also need margins. So I am expecting 1 nm allows boards up to 1 meter length, not much more. From the max bord size POV, 10nm is a better choice for board max size, but creates rounding issues during conversion between inches and mm (see tools/test-nm-biu-to-ascii-mm-round-tripping.cpp) *Do not expect* using a 64 bit coordinate: many calculations already use int64 for intermediate calculations using int32 coordinates. Especially our Clipper polygon library. Gerbview uses 10nm because some Gerber files use large coordinates and the conversion between inches and mm is not as important as in Pcbnew. New Eeschema uses 100 nm because this is also a good choice for a schematic (some users use very larges sheet sizes) > > On 2/13/20 9:32 AM, Johannes Pfister wrote: >> The KiCAD code uses all kinds of different units for distances. >> Amongst other things I found: >> nm: pcbnew internal units >> 10nm: Gerbview internal units >> 100nm EEschema internal units >> 1um: PL-Editor internal units >> 0.1mil (2.54um): SetViewport >> 1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils >> And the native File formats use mm (pcbnew) and mil (EEschema). >> Something like SVG exports in 0.1 mil steps. I think that this is not >> very consistent and something like a PLOTTER class needs to handle >> different IU-sizes. >> >> My idea is to rewrite the internal units so that nm are used >> everywhere inside the source code, and only parts that write or read >> files and display data to or read data from the user should convert it >> to another unit system. I don't want to change any file formats. >> That would make it a bit more straightforward, more consistent, metric >> and an SVG-Plotter would use a metric step size. The disadvantage >> would be that there would be an about 2m or 4m limit in every >> direction, assuming int is 32 bit, which is AFAIK true for all >> platforms KiCAD current supports. >> >> Before i rewrite code, can you say what you guys think about it? >> >> >> Johannes Pfister >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Symbol library help
On 2020-02-12 17:38, Wayne Stambaugh wrote: Does anyone know if one of the KiCad symbol libraries has a symbol that utilizes bezier curves or has a sample library that does? I'm just about done with the new symbol library file formatter and I would like to test the bezier support with something other than a canned sample to make sure the formatting is correct. Thanks in advance for the help. Cheers, Wayne Did we ever implement a control in LibEdit for bezier? I know we're halfway there in pcbnew but I've never seen bezier controls on the LibEdit side. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Hi,
On 13.02.20 16:06, Thomas Pointhuber wrote:
> The solution discussed was to move to 64bit and to use
> constexpr/templates handling unit conversion. So a programmer can for
> example enter 2mm and the compiler automatically converts it into the
> internal unit like nm.
> I'm still in favour of improving this. The same with angles.
Angles have to go first, because we have many different representations
based on lengths, and several of the 2D representations have overloaded
"rotate" functions that consume an angle -- so if we were to add new
length/vector/size/distance types, we'd need to add more "rotate"
functions for all of these as well.
For angles, this is somewhat complicated by the fact that we have three
different representations (radians, degrees, tenths of a degree), and
the latter can also be floating point or integer. Adding new classes is
somewhat[1] straightforward[2], but the code actually using it is full
of magic multiplications and divisions with factors like 0.1, 10,
M_PI/1800, 1800/M_PI and so on, all of which are scalar so they aren't
caught by making the new type deliberately incompatible.
Once angles are done, the same thing can be done for lengths, where,
thankfully, the magic values are somewhat confined to the headers.
One thing I really like is that we can express things like
angle a = 90_deg;
and in places where we need a scalar, such as the file reader/writer
code, we can then use
out << ( a / deg );
to write a value in degrees ("deg" is a global constexpr angle object
with a value of M_PI/180. :) ).
For the foreseeable future I'm going to concentrate on net ties, so if
anyone wants to run wild with the angle code, go ahead.
Simon
[1] lol
[2] https://gitlab.com/GyrosGeier/kicad/-/commits/refactor/angle
signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Hi Wayne, I think, I was present at FOSDEM 2019 when talking about this issue. From what I understand, the current approach requires KiCad to compile the units for each package separately (because e.g. mapping IU<->mm is always different). This has two big problems: 1. the same code has to be compiled multiple times. 2. there is no "true" mapping from IU to other units. When I for example want to create a python API with one type of geometric primitives, this is a real problem. When I want to script into eeschema and pcbnew at the same time, how to choose the correct units? The solution discussed was to move to 64bit and to use constexpr/templates handling unit conversion. So a programmer can for example enter 2mm and the compiler automatically converts it into the internal unit like nm. I'm still in favour of improving this. The same with angles. Regards, Thomas Am 13.02.20 um 15:46 schrieb Wayne Stambaugh: > Hi Johannes, > > Thank you for your suggestion but the internal units for each format > were chosen for a specific reason. There really is no justifiable > reason to change them as they have been carefully selected based on the > requirements of the objects they represent. Conversion code is provided > for each internal unit so plotting to standard units such as > millimeters, inches, etc is trivial. I'm not opposed to adding support > for changing the plot units. I am opposed to changing the internal units. > > Cheers, > > Wayne > > On 2/13/20 9:32 AM, Johannes Pfister wrote: >> The KiCAD code uses all kinds of different units for distances. >> Amongst other things I found: >> nm: pcbnew internal units >> 10nm: Gerbview internal units >> 100nm EEschema internal units >> 1um: PL-Editor internal units >> 0.1mil (2.54um): SetViewport >> 1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils >> And the native File formats use mm (pcbnew) and mil (EEschema). >> Something like SVG exports in 0.1 mil steps. I think that this is not >> very consistent and something like a PLOTTER class needs to handle >> different IU-sizes. >> >> My idea is to rewrite the internal units so that nm are used >> everywhere inside the source code, and only parts that write or read >> files and display data to or read data from the user should convert it >> to another unit system. I don't want to change any file formats. >> That would make it a bit more straightforward, more consistent, metric >> and an SVG-Plotter would use a metric step size. The disadvantage >> would be that there would be an about 2m or 4m limit in every >> direction, assuming int is 32 bit, which is AFAIK true for all >> platforms KiCAD current supports. >> >> Before i rewrite code, can you say what you guys think about it? >> >> >> Johannes Pfister >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Hi Johannes, Thank you for your suggestion but the internal units for each format were chosen for a specific reason. There really is no justifiable reason to change them as they have been carefully selected based on the requirements of the objects they represent. Conversion code is provided for each internal unit so plotting to standard units such as millimeters, inches, etc is trivial. I'm not opposed to adding support for changing the plot units. I am opposed to changing the internal units. Cheers, Wayne On 2/13/20 9:32 AM, Johannes Pfister wrote: > The KiCAD code uses all kinds of different units for distances. > Amongst other things I found: > nm: pcbnew internal units > 10nm: Gerbview internal units > 100nm EEschema internal units > 1um: PL-Editor internal units > 0.1mil (2.54um): SetViewport > 1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils > And the native File formats use mm (pcbnew) and mil (EEschema). > Something like SVG exports in 0.1 mil steps. I think that this is not > very consistent and something like a PLOTTER class needs to handle > different IU-sizes. > > My idea is to rewrite the internal units so that nm are used > everywhere inside the source code, and only parts that write or read > files and display data to or read data from the user should convert it > to another unit system. I don't want to change any file formats. > That would make it a bit more straightforward, more consistent, metric > and an SVG-Plotter would use a metric step size. The disadvantage > would be that there would be an about 2m or 4m limit in every > direction, assuming int is 32 bit, which is AFAIK true for all > platforms KiCAD current supports. > > Before i rewrite code, can you say what you guys think about it? > > > Johannes Pfister > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Internal units in the KiCAD source code
The KiCAD code uses all kinds of different units for distances. Amongst other things I found: nm: pcbnew internal units 10nm: Gerbview internal units 100nm EEschema internal units 1um: PL-Editor internal units 0.1mil (2.54um): SetViewport 1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils And the native File formats use mm (pcbnew) and mil (EEschema). Something like SVG exports in 0.1 mil steps. I think that this is not very consistent and something like a PLOTTER class needs to handle different IU-sizes. My idea is to rewrite the internal units so that nm are used everywhere inside the source code, and only parts that write or read files and display data to or read data from the user should convert it to another unit system. I don't want to change any file formats. That would make it a bit more straightforward, more consistent, metric and an SVG-Plotter would use a metric step size. The disadvantage would be that there would be an about 2m or 4m limit in every direction, assuming int is 32 bit, which is AFAIK true for all platforms KiCAD current supports. Before i rewrite code, can you say what you guys think about it? Johannes Pfister ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
