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 a
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
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
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
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 w
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 issue
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
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
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
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
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 co
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
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 GetSizeMil
13 matches
Mail list logo
