[Kicad-developers] msys2 ngspice-git package.

[Wayne Stambaugh]

I just submitted a pull request[1] for a new ngspice-git package for the
msys2 project so you can build the latest version of ngspice from the
head of the project git repo.  This will allow you to build a version of
ngspice that resolves the know simulation issues in the current stable
release of ngspice.  I also grab the latest documentation in pdf format
from the ngspice website since AFAIK you cannot build the latex
documentation from source on msys2.  If you can't wait for the msys2
project to accept the pull request, you can grab the PKGBUILD file from
the ngspice-git-package branch of my fork [2] of the mingw packages.
Are we enabling spice on windows nightly builds yet?  I haven't had time
to look.  If not, this should make life easier.

[1]: https://github.com/Alexpux/MINGW-packages/pull/1720
[2]: https://github.com/stambaughw/MINGW-packages/tree/ngspice-git-package

___
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] [PATCH v2] [Git] Set some file attributes

[Niki Guldbrand]

* Added .gitattributes, with every file extension found in the repo.
* Add context aware diff support to C/C++/HTML/Python, and:
  * Mark frag as C++.
  * Mark i as Python.
* Mark patch files to be ignored during normalization, because some
  of the patches in patches/* have mixed line endings.
* Mark svg files to always use lf as EOL on all platforms.

Signed-off-by: Niki Guldbrand 
---
 .gitattributes | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000..1de467c
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,59 @@
+# Set the default behavior, in case people don't have core.autocrlf set.
+* text=auto
+
+# Explicitly declare text files you want to always be normalized and converted
+# to native line endings on checkout.
+*.awk text
+*.bat text eol=crlf
+*.c text diff=cpp
+*.cc text diff=cpp
+*.cfg text
+*.cir text
+*.cmake text
+*.cmp text
+*.conf text
+*.cpp text diff=cpp
+*.dcm text
+*.desktop text
+*.dxf text
+*.emn text
+*.emp text
+*.fbp text
+*.fnt text
+*.fodt text
+*.frag text diff=cpp
+*.gbr text
+*.h text diff=cpp
+*.hpp text diff=cpp
+*.html text diff=html
+*.i text diff=python
+*.json text
+*.keywords text
+*.kicad_pcb text
+*.kicad_wks text
+*.lib text
+*.md text
+*.mod text
+*.net text
+*.patch -text
+*.plist text
+*.pro text
+*.py text diff=python
+*.rc text diff=cpp
+*.sch text
+*.sh text
+*.svg text eol=lf
+*.txt text
+*.vert text
+*.xml text
+*.xpm text
+*.xsl text
+
+# Denote all files that are truly binary and should not be modified.
+*.bmp binary
+*.icns binary
+*.ico binary
+*.jpg binary
+*.odt binary
+*.pdf binary
+*.png binary
___
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] Add a cmake option for legacy canvas

[Wayne Stambaugh]

On 9/17/2016 6:59 AM, Simon Wells wrote:
> As legacy canvas in pcbnew is legacy is it worth conditional compiling
> all the code related and only used by legacy canvas based on a cmake
> option aka something like
> 
> KICAD_BUILD_LEGACY_CANVAS with a default of ON, this will allow people
> who have no use for the legacy canvas as they have a truly functional
> opengl canvas to see in their usual workflow if anything is missing.
> 
> I realise that wayne is waiting on a replacement non-gl dependent GAL
> canvas before removing legacy, but in the interim is it worth making
> it an option making less work later on when its time to remove it
> 
> Simon
> 

I'm not sure what this would buy the project in terms of usefulness.  As
far as I am concerned there are still to far too many issues with the
gal canvas and new tool framework for me to give the go ahead to pull
the plug on the legacy canvas.  Here is my short list:

Stability: the current state of the p router stability is not what it
needs to be.  We still have users that seem to be able to crash it at
will.  It seems to me there are memory management issues at play here
that need some scrutiny.  IMO this needs to be bullet proof.  Period.

Polish: there are too many missing context menu entries from the gal
context menus which make the gal canvases less convenient to use than
the legacy canvas.  The last I heard, custom hot keys are still not
respected by gal but I could be wrong about this.  There is still no
track clearance indicator even routing a single trace.  There is a long
laundry list of these types of minor annoyances that KiCad users have
come to expect.

Speed: unfortunately there are still platforms were opengl is not usable
and the cairo canvas is unacceptably slow.  Either the cairo canvas will
need a significant increase in performance or someone will have to write
a wxDC painter object or we just keep putting it off until opengl works
well everywhere.

Once these issues are addressed, then we can start talking about
removing the legacy canvas.  Until then, it will have to stay.  I'm not
willing to force users (me) over to it until it's ready for prime time.
None of this should really surprise anyone.  We've discussed it many
times.  Now's your chance to be a hero and step up to the plate and fix
these issues.

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

[Kicad-developers] [RFC] .gitattributes

[Niki Guldbrand]

Hi All.

I would like a comment on my classification of the .gitattributes added
by the attached patch.

I have been trough every file extension found in the repo, and tried to
clasify them.

I would like to know if there are any special cases among them, other
than *.bat, else I'll resend the edited patch where the text entries
are trimmed down, as the first statemen of the file sets the default
for all unlisted files.


-- 
Niki Guldbrand From b9fb3f9f4dc4a428d1afae05181c2ce29653433b Mon Sep 17 00:00:00 2001
Message-Id: 
From: Niki Guldbrand 
Date: Sun, 18 Sep 2016 20:54:29 +0200
Subject: [PATCH] [Git] Set some file attributes
To: KiCAD Developers 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.9.3"

This is a multi-part message in MIME format.
--2.9.3
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


* Added .gitattributes, with every file extension found in the repo
  defined for verification.

Signed-off-by: Niki Guldbrand 
---
 .gitattributes | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 .gitattributes


--2.9.3
Content-Type: text/x-patch; name="0001-Git-Set-some-file-attributes.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Git-Set-some-file-attributes.patch"

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000..cbce659
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,59 @@
+# Set the default behavior, in case people don't have core.autocrlf set.
+* text=auto
+
+# Explicitly declare text files you want to always be normalized and converted
+# to native line endings on checkout.
+*.awk text
+*.bat text eol=crlf
+*.c text
+*.cc text
+*.cfg text
+*.cir text
+*.cmake text
+*.cmp text
+*.conf text
+*.cpp text
+*.dcm text
+*.desktop text
+*.dxf text
+*.emn text
+*.emp text
+*.fbp text
+*.fnt text
+*.fodt text
+*.frag text
+*.gbr text
+*.h text
+*.hpp text
+*.html text
+*.i text
+*.json text
+*.keywords text
+*.kicad_pcb text
+*.kicad_wks text
+*.lib text
+*.md text
+*.mod text
+*.net text
+*.patch text
+*.plist text
+*.pro text
+*.py text
+*.rc text
+*.sch text
+*.sh text
+*.svg text
+*.txt text
+*.vert text
+*.xml text
+*.xpm text
+*.xsl text
+
+# Denote all files that are truly binary and should not be modified.
+*.bmp binary
+*.icns binary
+*.ico binary
+*.jpg binary
+*.odt binary
+*.pdf binary
+*.png binary

--2.9.3--


___
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] SWIG binding

[Nick Østergaard]

That sounds to me like it would make sense use kicad-python such that we
can get yhe external API defined, and _ideally_ we could do whatever
internally to kicad, let that be swig replacement or not.

I suspect that having the external API defined would make it easier to find
a better implementation and tests. But I warn you, I am by no means an
expert in this kind of work.

Den 18/09/2016 16.15 skrev "Michael Steinberg" :

> Hello all!
> Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:
>
>
>
> On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> [...]
>>
>>
> I agree with all that as well. I think the best thing to do is create a
> PCB API
> which provides C bindings and people can make whatever scripting
> language API on top of that; this way there will be a much more uniform
> scheme for everyone. I was thinking about this while working on the STEP
> exporter but the more I looked at things, the bigger the job became.
> Eventually I thought it would take me a year or even more hacking at it
> part-time so I put it on the deferred list of things to do. Until we have
> such
> an API, I think things will be a bit of a mess. On the other hand some
> people want a scripting API now and can't wait for some part-time coder
> to come up with something in a year or two.
>
>
> So I conclude that we pretty much all agree it's a bad idea to export a
> rather unconstrained set of internals to python or any scripting. I think
> we also agree that we can't just drop the current state immediately. Beside
> these points I see a set of diverging technical strategies to implement it
> the right way (tm):
>
> 1.) Keep SWIG, wrap the output on the python side to a specified API
> 2.) Drop SWIG and interface with python.h ourselves without convenience
> libraries
> 3.) Drop SWIG, implement a C-API, write bindings in any language vs. C-API
> 4.) Drop SWIG, use compiler-based c++ bindings adhering the specified API
> (pybind11-like), using wrappers where necessary
>
> What has not been mentioned for completeness:
> 5.) Keep SWIG, use a constrained export set possibly using wrappers to
> adhere the specified API
>
> Anything missing from the list?
>
> Of course every alternative takes a specified API for granted, where we
> haven none, yet. I cannot compare the techniques at the current point of
> time, since I simply have no experience creating a C-API for C++ code.
> Where some stuff seems obvious as how to get right, I need to think about
> technicalities of how to implement move-semantics, smart-pointers, etc.. I
> have some experience using techniques like pybind11 or luabind, where one
> doesn't have these problems, because C++ is not stripped away at the
> binding level. So I'll have to delve into it and play around creating a
> super-limited sample binding in every alternative just to come to a
> personal conclusion.
> While the C-API seems like being the best solution technically, we'd need
> to develop the C-part and also convenience wrappers on the Python side just
> to be on par with the current state, right? Will there be enough developers
> with enough time to pull that off, I fear I doubt that, but as I said, I'll
> need to play around with this. It is however possible to create a binding
> vs. "the specified API" without taking this route, and it is also possible
> to switch the implementation technique later without changing the
> experienced binding semantics.
> Just how large of a deprecation-timespan would you think is necessary to
> make such changes? I think there are "some" devs who are eager to go in and
> refactor quite some parts, but we simply cannot do this right now due to
> this problem. So we're pretty much in a state where we can only add stuff
> on top, right, where adding already means fixing it for the future, too?
>
> Cheers!
> Michael
>
> ___
> 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] [PATCH][RFC] Footprint wizards

[Nick Østergaard]

Hi Oliver

The new checkbox works better i think. But thre is still some jumping
around with it when it sort of "selected" by the cursor. Also it shows
that small dashed box where there is usallly text for a checkbox it
seems.

This is on linux, I don't know if the same is seen on other platforms.

2016-09-15 14:55 GMT+02:00 Oliver Walters :
> Ok, round two!
>
> 1. I have fixed the issue relating to comma-separated decimals.
>
> 2. Boolean values now use the wxGridCellBoolRenderer which means they always
> display as checkboxes
>
> Here is an example of the boolean values rendering ->
> http://oi65.tinypic.com/24pmp9d.jpg
>
> And an example of the multiple-choice parameter ->
> http://oi67.tinypic.com/xkrvw5.jpg
>
> Finally, a screenshot of available parameter types ->
> http://oi63.tinypic.com/2lne6gh.jpg
>
> I have attached the updated patch.
>
> LMK if there's anything else I need to do :)
>
> On Wed, Sep 14, 2016 at 10:09 PM, Oliver Walters
>  wrote:
>>
>> Hi all,
>>
>> First time submitting a patch, so here goes
>>
>
>
>
> ___
> 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] SWIG binding

[Michael Steinberg]

Hello all!

Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:



On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski 
> wrote:


[...]


I agree with all that as well. I think the best thing to do is create 
a PCB API

which provides C bindings and people can make whatever scripting
language API on top of that; this way there will be a much more uniform
scheme for everyone. I was thinking about this while working on the STEP
exporter but the more I looked at things, the bigger the job became.
Eventually I thought it would take me a year or even more hacking at it
part-time so I put it on the deferred list of things to do. Until we 
have such

an API, I think things will be a bit of a mess. On the other hand some
people want a scripting API now and can't wait for some part-time coder
to come up with something in a year or two.



So I conclude that we pretty much all agree it's a bad idea to export a 
rather unconstrained set of internals to python or any scripting. I 
think we also agree that we can't just drop the current state 
immediately. Beside these points I see a set of diverging technical 
strategies to implement it the right way (tm):


1.) Keep SWIG, wrap the output on the python side to a specified API
2.) Drop SWIG and interface with python.h ourselves without convenience 
libraries

3.) Drop SWIG, implement a C-API, write bindings in any language vs. C-API
4.) Drop SWIG, use compiler-based c++ bindings adhering the specified 
API (pybind11-like), using wrappers where necessary


What has not been mentioned for completeness:
5.) Keep SWIG, use a constrained export set possibly using wrappers to 
adhere the specified API


Anything missing from the list?

Of course every alternative takes a specified API for granted, where we 
haven none, yet. I cannot compare the techniques at the current point of 
time, since I simply have no experience creating a C-API for C++ code. 
Where some stuff seems obvious as how to get right, I need to think 
about technicalities of how to implement move-semantics, smart-pointers, 
etc.. I have some experience using techniques like pybind11 or luabind, 
where one doesn't have these problems, because C++ is not stripped away 
at the binding level. So I'll have to delve into it and play around 
creating a super-limited sample binding in every alternative just to 
come to a personal conclusion.
While the C-API seems like being the best solution technically, we'd 
need to develop the C-part and also convenience wrappers on the Python 
side just to be on par with the current state, right? Will there be 
enough developers with enough time to pull that off, I fear I doubt 
that, but as I said, I'll need to play around with this. It is however 
possible to create a binding vs. "the specified API" without taking this 
route, and it is also possible to switch the implementation technique 
later without changing the experienced binding semantics.
Just how large of a deprecation-timespan would you think is necessary to 
make such changes? I think there are "some" devs who are eager to go in 
and refactor quite some parts, but we simply cannot do this right now 
due to this problem. So we're pretty much in a state where we can only 
add stuff on top, right, where adding already means fixing it for the 
future, too?


Cheers!
Michael
___
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] pcbnew tools uses long instead of intptr_t

[Nick Østergaard]

Ok, so maybe it was since the 2.6.5 update of freetype that those
dependencies was added.

KiCad uses boost, so of course boost is needed. The skip just skips
downloading and building boost when building and uses the system
boost. Also the option is obsolete now.

2016-09-18 15:02 GMT+02:00 Gustav Bergquist :
> libfreetype depends on libgraphite2
> _pcbnew.kiface dependency chain: libfreetype > libharfbuzz > libglib > libpcre
> _pcbnew.kiface dependency chain: libfreetype > libgraphite2
> libboost_regex dependency chain: libicuu > libicudt
>
> Why libboost is included i don't know. The -DKICAD_SKIP_BOOST=ON seems not to 
> be honored (or means something different than i assume).
>
> No, i have not compiled OCE myself, i used the kicad-winbuilder to build 
> where OCE is a dependency.
>
> I have compiled OCE once but never installed it and it was a different msys 
> system.
> Looking at the makefiles, produced during kicad-winbuilder build, it's clear 
> that it is the oce package which is being used.
> 
> From: Nick Østergaard [oe.n...@gmail.com]
> Sent: 18 September 2016 09:42
> To: Gustav Bergquist
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] pcbnew tools uses long instead of intptr_t
>
> 2016-09-18 1:04 GMT+02:00 Gustav Bergquist :
>> Hello,
>>
>> I just managed to setup a build environment on windows and noticed that
>> kicad/pcbnew/tools/pcb_editor_control.cpp
>> kicad/pcbnew/tools/pcbnew_control.cpp
>> have  when  probably is more correct.
>>
>> See attached patches.
>>
>> Next up the wx ABI and wxPython ABI differs so i have built wxwidgets and 
>> wxpython from source.
>> if anyone needs help with this i am happy to help.
>>
>> With the new OCE library for the 3D viewer the following dll-files is 
>> necessary in the bin folder:
>> libpcre*.dll
>> libicu*.dll
>> libgraphite2.dll
>>
>
> I still don't understand what exactly depends on those dll's. Did you
> build OCE yourself? If so, with which options?
>
>> /Gustav
>> ___
>> 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] pcbnew tools uses long instead of intptr_t

[Gustav Bergquist]

libfreetype depends on libgraphite2
_pcbnew.kiface dependency chain: libfreetype > libharfbuzz > libglib > libpcre
_pcbnew.kiface dependency chain: libfreetype > libgraphite2
libboost_regex dependency chain: libicuu > libicudt

Why libboost is included i don't know. The -DKICAD_SKIP_BOOST=ON seems not to 
be honored (or means something different than i assume).

No, i have not compiled OCE myself, i used the kicad-winbuilder to build where 
OCE is a dependency.

I have compiled OCE once but never installed it and it was a different msys 
system.
Looking at the makefiles, produced during kicad-winbuilder build, it's clear 
that it is the oce package which is being used.

From: Nick Østergaard [oe.n...@gmail.com]
Sent: 18 September 2016 09:42
To: Gustav Bergquist
Cc: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] pcbnew tools uses long instead of intptr_t

2016-09-18 1:04 GMT+02:00 Gustav Bergquist :
> Hello,
>
> I just managed to setup a build environment on windows and noticed that
> kicad/pcbnew/tools/pcb_editor_control.cpp
> kicad/pcbnew/tools/pcbnew_control.cpp
> have  when  probably is more correct.
>
> See attached patches.
>
> Next up the wx ABI and wxPython ABI differs so i have built wxwidgets and 
> wxpython from source.
> if anyone needs help with this i am happy to help.
>
> With the new OCE library for the 3D viewer the following dll-files is 
> necessary in the bin folder:
> libpcre*.dll
> libicu*.dll
> libgraphite2.dll
>

I still don't understand what exactly depends on those dll's. Did you
build OCE yourself? If so, with which options?

> /Gustav
> ___
> 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] [PATCH] Remove assert in pcbnew on osx with a debug build

[Simon Wells]

nickoe has commented on irc whether this is required on any platform,
unfortunately i do not have any other platform for testing on, However
the wxwidgets documention states that wxPaintDC should only be used in
"native onpaint" handlers, what native means in this instance i am
unsure, however on debug builds on osx i get many assertions due to
this so have opted to #ifndef it out.



On Sun, Sep 18, 2016 at 4:37 PM, Simon Wells  wrote:
> ---
>  common/draw_panel_gal.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>

___
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] pcbnew tools uses long instead of intptr_t

[Nick Østergaard]

2016-09-18 1:04 GMT+02:00 Gustav Bergquist :
> Hello,
>
> I just managed to setup a build environment on windows and noticed that
> kicad/pcbnew/tools/pcb_editor_control.cpp
> kicad/pcbnew/tools/pcbnew_control.cpp
> have  when  probably is more correct.
>
> See attached patches.
>
> Next up the wx ABI and wxPython ABI differs so i have built wxwidgets and 
> wxpython from source.
> if anyone needs help with this i am happy to help.
>
> With the new OCE library for the 3D viewer the following dll-files is 
> necessary in the bin folder:
> libpcre*.dll
> libicu*.dll
> libgraphite2.dll
>

I still don't understand what exactly depends on those dll's. Did you
build OCE yourself? If so, with which options?

> /Gustav
> ___
> 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