Re: [Kicad-developers] Git transition

2016-08-11 Thread Simon Wells
In regards to this, Currently bzr revs are just the number and the git
revs are the bzr number and the git sum. Is it worthwhile (esspeically
in the title bar just changing this to git-BZRREV or just git-SUM
since git will be the primary vcs?

On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
 wrote:
> Sounds good!  I think that timeline is fine.
>
> Adam Wolf
>
>
> On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:
>>
>> You have a couple of options.
>>
>> You could just clone directly from the source mirror on github for
>> testing then update the url when we go live with git on launchpad.
>>
>> You could create your own clone of the github source mirror and add a
>> remote link to your own personal git branch on launchpad and use that
>> for testing.  This is what I have been using.  The set the url to push
>> to your own git repo on launchpad run:
>>
>> git remote add launchpad
>> git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev
>>
>> git push launchpad (OPTIONAL-REPO-NAME-ON-LP)
>>
>> You will now have your own kicad git repo on launchpad which you can
>> clone for testing.
>>
>> On 8/11/2016 3:36 PM, Adam Wolf wrote:
>> > It should.  Can we somehow push a copy of what it is now so I have
>> > something to build against?
>> >
>> > On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh > > > wrote:
>> >
>> > If we go live with git on 8/21, will that give you enough time to
>> > get
>> > things squared away on your end?
>> >
>> > On 8/11/2016 2:41 PM, Adam Wolf wrote:
>> > > The Git part will take maybe 1 week for OS X.  I am in favor of
>> > this
>> > > transition.
>> > >
>> > > Adam Wolf
>> > >
>> > >
>> > > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh" > > 
>> > > >>
>> > wrote:
>> > >
>> > > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
>> > > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>> > > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>> > > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>> > >  The last time I looked, notifications of repo commits
>> > still
>> > > were not
>> > >  implemented.  This is a show stopper for me.  I don't
>> > want to
>> > > have to
>> > >  constantly grep the git commit log to see what changed.
>> > If change
>> > >  notifications are working correctly, then I'm OK with
>> > moving
>> > > forward on
>> > >  this if you can get the bug fix linking working.  We
>> > definitely
>> > > should
>> > >  do some testing before we go live with this.
>> > > >>>
>> > > >>> I see there is an option to set notifications, in the same
>> > way
>> > > as for
>> > > >>> the bazaar branches ("Edit your subscriptions" on the
>> > right side
>> > > pane).
>> > > >>> I could not verify it, as likely I cannot receive
>> > notifications
>> > > for the
>> > > >>> changes I introduce. Even if it does not work, I can
>> > implement
>> > > it in my
>> > > >>> webhook.
>> > > >>
>> > > >> I spent some time yesterday creating my own git clone of
>> > kicad on
>> > > LP and
>> > > >> I noticed that the subscriptions that I need appear to be
>> > > available for
>> > > >> git repos so we shouldn't need any webhooks in for that
>> > unless
>> > > they do
>> > > >> not work.
>> > > >
>> > > > If they do not work, let me know and I will fix it in the
>> > hook.
>> > > >
>> > > >>>
>> > > >>> The webhook has reached beta stage. I have created a dummy
>> > > project for
>> > > >>> testing purposes, where you can see a bug report [1] and a
>> > > commit [2]
>> > > >>> with message that includes a "fix(es)?[
>> > ]+(lp:|#)?([0-9]+)"
>> > > regex match.
>> > > >>> When it is detected, it automatically adds a message,
>> > changes
>> > > the bug
>> > > >>> status and assignee. One thing that is not possible right
>> > now is
>> > > linking
>> > > >>> with git branches, as apparently launchpad does not handle
>> > this
>> > > at the
>> > > >>> moment (or I could not find the right format to specify a
>> > branch).
>> > > >>
>> > > >> Bug report linking is very important to me since I am
>> > responsible for
>> > > >> the stable branch.  If there is no support for this yet,
>> > I'm OK with
>> > > >> adding the bug report number to the first line of the
>> > commit
>> > > message and
>> > > >> the URL somewhere in the commit message body.  If 

Re: [Kicad-developers] Integrated Simulator

2016-08-11 Thread Simon Wells
When there is a FindNgspice.cmake file it would also allow removal of
#include <../share/ngspice/include/ngspice/sharedspice.h> as it is a
horrible include and should really be added to the -I path

On Fri, Aug 12, 2016 at 3:37 AM, Wayne Stambaugh  wrote:
> Congratulations on everyone who made the is happen.  This is a nice
> feature for KiCad and hopefully users will find it useful.
>
> There are a few things will need to addressed that I missed when I
> initially evaluated the code.
>
> Maybe I missed it but I do not see any indication that the ngspice
> headers and libraries are detected during cmake configuration (see
> attachment).  This is a major no-no.  All external dependencies must be
> found during configuration.  As a developer, there are few things that
> make kick a software package to the curb faster than getting 3/4 of way
> through a 30+ minute build only have the build fail because there is a
> missing dependency header or library.  This should fail during
> configuration to inform the developer that there are missing
> dependencies.  Please write a FindNgSpice.cmake file.  I know I've said
> this in the past but I will reiterate it, if you add a new dependency to
> KiCad you *must* add the configuration code to ensure that all of the
> required headers and/or libraries can be found before a valid
> configuration can be completed.
>
> Also, please update the Documentation/development/compiling.md file with
> the added optional ng-spice dependency.  This is the official compiling
> document that gets pushed to the kicad website so it needs to be kept up
> to date.
>
> Thanks again everyone for your hard work.
>
> Cheers,
>
> Wayne
>
>
> On 8/11/2016 9:07 AM, Maciej Sumiński wrote:
>> I have just merged the ngspice branch. It is still required to enable
>> KICAD_SPICE switch in cmake in order to use it, so it does not cause
>> problems on systems without ngspice library installed.
>>
>> Regards,
>> Orson
>>
>> On 08/05/2016 09:40 PM, Maciej Sumiński wrote:
>>> I had spoken with ngspice devs and they have suggested me a workaround
>>> for the bug. Unfortunately, it requires a patch that is currently not
>>> included in the release version, so we resort to building from the
>>> source again.
>>>
>>> To ease the pain, I have updated get_libngspice_so.sh [1]. Now it should
>>> build the correct library version for Linux, Windows (mingw64) & OS X. I
>>> have managed to run the script successfully on all the mentioned
>>> platforms, but I still do not have KiCad compiled on OS X, so I was not
>>> able to test it there.
>>>
>>> I have updated the ngspice branch in my github repository [2]:
>>> - applied fixes for Win7 & OS X (thank you Jean-Pierre & Johannes)
>>> - resized dialogs, so all the fields are visible and windows fit 1024x768
>>> - fixed a few minor bugs
>>> - corrected demo circuits
>>> - cleared, formatted & documented the code
>>>  & added some documentation
>>> I consider the code ready for merge. If there are no objections, I would
>>> like to proceed next week.
>>>
>>> Regards,
>>> Orson
>>>
>>> 1. https://orson.net.pl/pub/libngspice/get_libngspice_so.sh
>>> 2. https://github.com/orsonmmz/kicad-source-mirror/tree/ngspice
>>>
>>> On 07/21/2016 11:16 PM, Chris Pavlina wrote:
 Really, really nice! I made it do a thing! 
 https://misc.c4757p.com/kicad_sim.png

 I feel bad to provide a bug report on my very first communcation on
 this, but... found one: not sure if this sort of thing is actually
 standard SPICE or an LTspice extension, but I tried parameterizing a
 component value, setting a resistor's value to {R} - that sort of thing
 leads to irrecoverable lockups here.

 On Thu, Jul 21, 2016 at 09:37:57PM +0200, Tomasz Wlostowski wrote:
> Hi,
>
> As some of you have noticed, we've been working on a "secret" feature
> during the hackathon at CERN. The feature we're talking about is an
> integrated circuit simulator. Currently it features:
> - Seamless integration into schematic editor,
> - AC/Transient/DC sweep simulations,
> - Voltage probing from the schematics,
> - Live tuning of component values.
>
> A video demonstrating the capabilities of the new simulator is available
> on Tom's YouTube channel [1].
>
> The code is currently available in the ngspice branch on Tom's GitHub
> [2] for review & testing. It's a big feature, so we didn't want to push
> it immediately to the product branch. We'll greatly appreciate your
> feedback!
>
> The simulator uses ngspice [3] as the Spice kernel. We'd like to thank
> ngspice developers for providing a DLL interface which made seamless
> integration of ngspice into Kicad possible.
>
> In order to get started:
> - install ngspice shared library (is not provided by many Linux distros,
> Arch Linux is a known exception, so you might have to compile it from
> the sources with 

[Kicad-developers] [PATCH] DRC: do not close and reopen progress dialog

2016-08-11 Thread Chris Pavlina
I'm running into an extremely irritating UI bug with DRC on this big
board - halfway through DRC, the progress dialog is torn down and
reopened. DRC is taking two full minutes with this board, which means I
invariably do something else while it runs - and when it pops up the
second progress dialog, that dialog receives any spacebar key press I
may have been making whilst typing, cancelling DRC. I did it three times
in a row earlier today. I wanted to throw my workstation out the window.

This patch fixes that. The DRC task creates a single progress bar dialog
and hands it to anything that needs it, keeping it open until the end.

-- 
Chris
>From aa10c0a898acd6b20caf09378803b6aa7f6590b1 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Thu, 11 Aug 2016 15:03:03 -0400
Subject: [PATCH] DRC: do not close and reopen progress dialog

---
 include/wxPcbStruct.h  |  6 ++-
 pcbnew/drc.cpp | 71 ++
 pcbnew/drc_stuff.h |  5 ++-
 pcbnew/zones_by_polygon_fill_functions.cpp | 34 +-
 4 files changed, 74 insertions(+), 42 deletions(-)

diff --git a/include/wxPcbStruct.h b/include/wxPcbStruct.h
index 887e7f3..fe46542 100644
--- a/include/wxPcbStruct.h
+++ b/include/wxPcbStruct.h
@@ -63,6 +63,7 @@ class REPORTER;
 struct PARSE_ERROR;
 struct IO_ERROR;
 class FP_LIB_TABLE;
+class wxProgressDialog;
 
 namespace PCB { struct IFACE; } // KIFACE_I is in pcbnew.cpp
 
@@ -1416,8 +1417,11 @@ public:
  * @param aActiveWindow = the current active window, if a progress bar is shown
  *  = NULL to do not display a progress bar
  * @param aVerbose = true to show error messages
+ * @param aProgressDialog = if non-NULL, use this progress dialog instead of
+ *  creating one.
  */
-int Fill_All_Zones( wxWindow * aActiveWindow, bool aVerbose = true );
+int Fill_All_Zones( wxWindow * aActiveWindow, bool aVerbose = true,
+wxProgressDialog *aProgressDialog = NULL );
 
 
 /**
diff --git a/pcbnew/drc.cpp b/pcbnew/drc.cpp
index c2c6e1a..08eb86f 100644
--- a/pcbnew/drc.cpp
+++ b/pcbnew/drc.cpp
@@ -1,10 +1,9 @@
-
 /*
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2004-2015 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2014 Dick Hollenbeck, d...@softplc.com
- * Copyright (C) 2016 KiCad Developers, see change_log.txt for contributors.
+ * Copyright (C) 2016 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -187,6 +186,11 @@ void DRC::RunTests( wxTextCtrl* aMessages )
 // ( the board can be reloaded )
 m_pcb = m_pcbEditorFrame->GetBoard();
 
+wxProgressDialog *progressDialog = new wxProgressDialog( _( "Design Rule Check" ), wxEmptyString,
+100, aMessages ? aMessages->GetParent() : m_pcbEditorFrame,
+wxPD_AUTO_HIDE | wxPD_CAN_ABORT | wxPD_APP_MODAL | wxPD_ELAPSED_TIME );
+
+
 // Ensure ratsnest is up to date:
 if( (m_pcb->m_Status_Pcb & LISTE_RATSNEST_ITEM_OK) == 0 )
 {
@@ -213,7 +217,7 @@ void DRC::RunTests( wxTextCtrl* aMessages )
 // update the m_drcDialog listboxes
 updatePointers();
 
-return;
+goto out;
 }
 
 // test pad to pad clearances, nothing to do with tracks, vias or zones.
@@ -235,7 +239,7 @@ void DRC::RunTests( wxTextCtrl* aMessages )
 wxSafeYield();
 }
 
-testTracks( aMessages ? aMessages->GetParent() : m_pcbEditorFrame, true );
+testTracks( aMessages ? aMessages->GetParent() : m_pcbEditorFrame, true, progressDialog );
 
 // Before testing segments and unconnected, refill all zones:
 // this is a good caution, because filled areas can be outdated.
@@ -246,7 +250,7 @@ void DRC::RunTests( wxTextCtrl* aMessages )
 }
 
 m_pcbEditorFrame->Fill_All_Zones( aMessages ? aMessages->GetParent() : m_pcbEditorFrame,
-  false );
+  false, progressDialog );
 
 // test zone clearances to other zones
 if( aMessages )
@@ -299,6 +303,9 @@ void DRC::RunTests( wxTextCtrl* aMessages )
 // to unnecessarily scroll.
 aMessages->AppendText( _( "Finished" ) );
 }
+
+out:
+progressDialog->Destroy();
 }
 
 
@@ -491,46 +498,52 @@ void DRC::testPad2Pad()
 }
 
 
-void DRC::testTracks( wxWindow *aActiveWindow, bool aShowProgressBar )
+void DRC::testTracks( wxWindow *aActiveWindow, bool aShowProgressBar,
+wxProgressDialog *aProgressDialog )
 {
 wxProgressDialog * progressDialog = NULL;
-const int delta = 500;  // This is the number of tests between 2 calls to the
+const int delta = 256;  // This is the number of tests between 2 calls to the
 // progress bar
-int count = 0;
+int 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Adam Wolf
Sounds good!  I think that timeline is fine.

Adam Wolf

On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:

> You have a couple of options.
>
> You could just clone directly from the source mirror on github for
> testing then update the url when we go live with git on launchpad.
>
> You could create your own clone of the github source mirror and add a
> remote link to your own personal git branch on launchpad and use that
> for testing.  This is what I have been using.  The set the url to push
> to your own git repo on launchpad run:
>
> git remote add launchpad
> git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev
>
> git push launchpad (OPTIONAL-REPO-NAME-ON-LP)
>
> You will now have your own kicad git repo on launchpad which you can
> clone for testing.
>
> On 8/11/2016 3:36 PM, Adam Wolf wrote:
> > It should.  Can we somehow push a copy of what it is now so I have
> > something to build against?
> >
> > On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh  > > wrote:
> >
> > If we go live with git on 8/21, will that give you enough time to get
> > things squared away on your end?
> >
> > On 8/11/2016 2:41 PM, Adam Wolf wrote:
> > > The Git part will take maybe 1 week for OS X.  I am in favor of
> this
> > > transition.
> > >
> > > Adam Wolf
> > >
> > >
> > > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  > 
> > > >>
> wrote:
> > >
> > > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> > >  The last time I looked, notifications of repo commits
> still
> > > were not
> > >  implemented.  This is a show stopper for me.  I don't
> want to
> > > have to
> > >  constantly grep the git commit log to see what changed.
> > If change
> > >  notifications are working correctly, then I'm OK with
> moving
> > > forward on
> > >  this if you can get the bug fix linking working.  We
> > definitely
> > > should
> > >  do some testing before we go live with this.
> > > >>>
> > > >>> I see there is an option to set notifications, in the same
> way
> > > as for
> > > >>> the bazaar branches ("Edit your subscriptions" on the
> > right side
> > > pane).
> > > >>> I could not verify it, as likely I cannot receive
> > notifications
> > > for the
> > > >>> changes I introduce. Even if it does not work, I can
> implement
> > > it in my
> > > >>> webhook.
> > > >>
> > > >> I spent some time yesterday creating my own git clone of
> > kicad on
> > > LP and
> > > >> I noticed that the subscriptions that I need appear to be
> > > available for
> > > >> git repos so we shouldn't need any webhooks in for that
> unless
> > > they do
> > > >> not work.
> > > >
> > > > If they do not work, let me know and I will fix it in the
> hook.
> > > >
> > > >>>
> > > >>> The webhook has reached beta stage. I have created a dummy
> > > project for
> > > >>> testing purposes, where you can see a bug report [1] and a
> > > commit [2]
> > > >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> > > regex match.
> > > >>> When it is detected, it automatically adds a message,
> changes
> > > the bug
> > > >>> status and assignee. One thing that is not possible right
> > now is
> > > linking
> > > >>> with git branches, as apparently launchpad does not handle
> > this
> > > at the
> > > >>> moment (or I could not find the right format to specify a
> > branch).
> > > >>
> > > >> Bug report linking is very important to me since I am
> > responsible for
> > > >> the stable branch.  If there is no support for this yet,
> > I'm OK with
> > > >> adding the bug report number to the first line of the commit
> > > message and
> > > >> the URL somewhere in the commit message body.  If I give
> the OK
> > > to use
> > > >> git, I will expect all developers that have commit
> > privileges to the
> > > >> product repo to follow this without exception.  The commit
> > > message for
> > > >> bug report fixes must have this format:
> > > >>
> > > >> Description of bug report fix. (fixes lp:)
> > > >>
> > > >> * https://bugs.launchpad.net/kicad/+bug/
> 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Wayne Stambaugh
You have a couple of options.

You could just clone directly from the source mirror on github for
testing then update the url when we go live with git on launchpad.

You could create your own clone of the github source mirror and add a
remote link to your own personal git branch on launchpad and use that
for testing.  This is what I have been using.  The set the url to push
to your own git repo on launchpad run:

git remote add launchpad
git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev

git push launchpad (OPTIONAL-REPO-NAME-ON-LP)

You will now have your own kicad git repo on launchpad which you can
clone for testing.

On 8/11/2016 3:36 PM, Adam Wolf wrote:
> It should.  Can we somehow push a copy of what it is now so I have
> something to build against?
> 
> On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh  > wrote:
> 
> If we go live with git on 8/21, will that give you enough time to get
> things squared away on your end?
> 
> On 8/11/2016 2:41 PM, Adam Wolf wrote:
> > The Git part will take maybe 1 week for OS X.  I am in favor of this
> > transition.
> >
> > Adam Wolf
> >
> >
> > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  
> > >> wrote:
> >
> > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >  The last time I looked, notifications of repo commits still
> > were not
> >  implemented.  This is a show stopper for me.  I don't want to
> > have to
> >  constantly grep the git commit log to see what changed. 
> If change
> >  notifications are working correctly, then I'm OK with moving
> > forward on
> >  this if you can get the bug fix linking working.  We
> definitely
> > should
> >  do some testing before we go live with this.
> > >>>
> > >>> I see there is an option to set notifications, in the same way
> > as for
> > >>> the bazaar branches ("Edit your subscriptions" on the
> right side
> > pane).
> > >>> I could not verify it, as likely I cannot receive
> notifications
> > for the
> > >>> changes I introduce. Even if it does not work, I can implement
> > it in my
> > >>> webhook.
> > >>
> > >> I spent some time yesterday creating my own git clone of
> kicad on
> > LP and
> > >> I noticed that the subscriptions that I need appear to be
> > available for
> > >> git repos so we shouldn't need any webhooks in for that unless
> > they do
> > >> not work.
> > >
> > > If they do not work, let me know and I will fix it in the hook.
> > >
> > >>>
> > >>> The webhook has reached beta stage. I have created a dummy
> > project for
> > >>> testing purposes, where you can see a bug report [1] and a
> > commit [2]
> > >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> > regex match.
> > >>> When it is detected, it automatically adds a message, changes
> > the bug
> > >>> status and assignee. One thing that is not possible right
> now is
> > linking
> > >>> with git branches, as apparently launchpad does not handle
> this
> > at the
> > >>> moment (or I could not find the right format to specify a
> branch).
> > >>
> > >> Bug report linking is very important to me since I am
> responsible for
> > >> the stable branch.  If there is no support for this yet,
> I'm OK with
> > >> adding the bug report number to the first line of the commit
> > message and
> > >> the URL somewhere in the commit message body.  If I give the OK
> > to use
> > >> git, I will expect all developers that have commit
> privileges to the
> > >> product repo to follow this without exception.  The commit
> > message for
> > >> bug report fixes must have this format:
> > >>
> > >> Description of bug report fix. (fixes lp:)
> > >>
> > >> * https://bugs.launchpad.net/kicad/+bug/
> 
> >  >
> > >>
> > >> If this is not acceptable, then the git transition will
> have to wait
> > >> until Canonical gets git bug report linking implemented or
> Orson
> > 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Adam Wolf
It should.  Can we somehow push a copy of what it is now so I have
something to build against?

On Thu, Aug 11, 2016, 1:52 PM Wayne Stambaugh  wrote:

> If we go live with git on 8/21, will that give you enough time to get
> things squared away on your end?
>
> On 8/11/2016 2:41 PM, Adam Wolf wrote:
> > The Git part will take maybe 1 week for OS X.  I am in favor of this
> > transition.
> >
> > Adam Wolf
> >
> >
> > On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  > > wrote:
> >
> > On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >  The last time I looked, notifications of repo commits still
> > were not
> >  implemented.  This is a show stopper for me.  I don't want to
> > have to
> >  constantly grep the git commit log to see what changed.  If
> change
> >  notifications are working correctly, then I'm OK with moving
> > forward on
> >  this if you can get the bug fix linking working.  We definitely
> > should
> >  do some testing before we go live with this.
> > >>>
> > >>> I see there is an option to set notifications, in the same way
> > as for
> > >>> the bazaar branches ("Edit your subscriptions" on the right side
> > pane).
> > >>> I could not verify it, as likely I cannot receive notifications
> > for the
> > >>> changes I introduce. Even if it does not work, I can implement
> > it in my
> > >>> webhook.
> > >>
> > >> I spent some time yesterday creating my own git clone of kicad on
> > LP and
> > >> I noticed that the subscriptions that I need appear to be
> > available for
> > >> git repos so we shouldn't need any webhooks in for that unless
> > they do
> > >> not work.
> > >
> > > If they do not work, let me know and I will fix it in the hook.
> > >
> > >>>
> > >>> The webhook has reached beta stage. I have created a dummy
> > project for
> > >>> testing purposes, where you can see a bug report [1] and a
> > commit [2]
> > >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> > regex match.
> > >>> When it is detected, it automatically adds a message, changes
> > the bug
> > >>> status and assignee. One thing that is not possible right now is
> > linking
> > >>> with git branches, as apparently launchpad does not handle this
> > at the
> > >>> moment (or I could not find the right format to specify a
> branch).
> > >>
> > >> Bug report linking is very important to me since I am responsible
> for
> > >> the stable branch.  If there is no support for this yet, I'm OK
> with
> > >> adding the bug report number to the first line of the commit
> > message and
> > >> the URL somewhere in the commit message body.  If I give the OK
> > to use
> > >> git, I will expect all developers that have commit privileges to
> the
> > >> product repo to follow this without exception.  The commit
> > message for
> > >> bug report fixes must have this format:
> > >>
> > >> Description of bug report fix. (fixes lp:)
> > >>
> > >> * https://bugs.launchpad.net/kicad/+bug/
> 
> >  >
> > >>
> > >> If this is not acceptable, then the git transition will have to
> wait
> > >> until Canonical gets git bug report linking implemented or Orson
> > beats
> > >> them to it.
> > >
> > > I spoke with a Launchpad developer and they have it already in
> their
> > > todo list. There is a plan to migrate Launchpad itself to git, so I
> > > believe they will do it well.
> > >
> > > From what I heard, currently it is possible to link git merge
> requests
> > > to bug reports, so it may temporarily solve the problem.
> >
> > I'll see if I can figure out how to do this and if it works we can
> use
> > it instead of adding the bug report url to the commit message.  I
> wonder
> > if we can link a commit to a bug report?  That could be an issue if
> we
> > cannot.  I don't want to have to always create a separate branch,
> push
> > it to my personal repo, and then merge it into the product branch for
> > simple bug fixes.
> >
> > >
> > >>> All we need to do is to set a webhook pointing to my script [3].
> > If it
> > >>> is accepted, then I am going to create a separate lp account for
> the
> > >>> automated changes.
> > >>>
> > >>> Currently the webhook works on my home server which has a high
> > uptime,
> > >>> but still it is not 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Wayne Stambaugh
If we go live with git on 8/21, will that give you enough time to get
things squared away on your end?

On 8/11/2016 2:41 PM, Adam Wolf wrote:
> The Git part will take maybe 1 week for OS X.  I am in favor of this
> transition.
> 
> Adam Wolf
> 
> 
> On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  > wrote:
> 
> On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>  The last time I looked, notifications of repo commits still
> were not
>  implemented.  This is a show stopper for me.  I don't want to
> have to
>  constantly grep the git commit log to see what changed.  If change
>  notifications are working correctly, then I'm OK with moving
> forward on
>  this if you can get the bug fix linking working.  We definitely
> should
>  do some testing before we go live with this.
> >>>
> >>> I see there is an option to set notifications, in the same way
> as for
> >>> the bazaar branches ("Edit your subscriptions" on the right side
> pane).
> >>> I could not verify it, as likely I cannot receive notifications
> for the
> >>> changes I introduce. Even if it does not work, I can implement
> it in my
> >>> webhook.
> >>
> >> I spent some time yesterday creating my own git clone of kicad on
> LP and
> >> I noticed that the subscriptions that I need appear to be
> available for
> >> git repos so we shouldn't need any webhooks in for that unless
> they do
> >> not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> >>>
> >>> The webhook has reached beta stage. I have created a dummy
> project for
> >>> testing purposes, where you can see a bug report [1] and a
> commit [2]
> >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)"
> regex match.
> >>> When it is detected, it automatically adds a message, changes
> the bug
> >>> status and assignee. One thing that is not possible right now is
> linking
> >>> with git branches, as apparently launchpad does not handle this
> at the
> >>> moment (or I could not find the right format to specify a branch).
> >>
> >> Bug report linking is very important to me since I am responsible for
> >> the stable branch.  If there is no support for this yet, I'm OK with
> >> adding the bug report number to the first line of the commit
> message and
> >> the URL somewhere in the commit message body.  If I give the OK
> to use
> >> git, I will expect all developers that have commit privileges to the
> >> product repo to follow this without exception.  The commit
> message for
> >> bug report fixes must have this format:
> >>
> >> Description of bug report fix. (fixes lp:)
> >>
> >> * https://bugs.launchpad.net/kicad/+bug/
> 
> >>
> >> If this is not acceptable, then the git transition will have to wait
> >> until Canonical gets git bug report linking implemented or Orson
> beats
> >> them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
> 
> I'll see if I can figure out how to do this and if it works we can use
> it instead of adding the bug report url to the commit message.  I wonder
> if we can link a commit to a bug report?  That could be an issue if we
> cannot.  I don't want to have to always create a separate branch, push
> it to my personal repo, and then merge it into the product branch for
> simple bug fixes.
> 
> >
> >>> All we need to do is to set a webhook pointing to my script [3].
> If it
> >>> is accepted, then I am going to create a separate lp account for the
> >>> automated changes.
> >>>
> >>> Currently the webhook works on my home server which has a high
> uptime,
> >>> but still it is not as reliable as dedicated servers. If there is
> >>> someone willing to host it on a better machine, I will be
> pleased to help.
> >>>
> >>> If you are curious about the source code, then I can put it in
> the KiCad
> >>> github (once I get a repository there) or just post it somewhere.
> >>
> >> I can create a repo on github or you can create a repo on launchpad.
> >> Either way is fine by me.  If you want to use github, let me know
> what
> >> name you want for the repo and your github 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Adam Wolf
The Git part will take maybe 1 week for OS X.  I am in favor of this
transition.

Adam Wolf

On Aug 11, 2016 1:31 PM, "Wayne Stambaugh"  wrote:

> On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> >> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>  The last time I looked, notifications of repo commits still were not
>  implemented.  This is a show stopper for me.  I don't want to have to
>  constantly grep the git commit log to see what changed.  If change
>  notifications are working correctly, then I'm OK with moving forward
> on
>  this if you can get the bug fix linking working.  We definitely should
>  do some testing before we go live with this.
> >>>
> >>> I see there is an option to set notifications, in the same way as for
> >>> the bazaar branches ("Edit your subscriptions" on the right side pane).
> >>> I could not verify it, as likely I cannot receive notifications for the
> >>> changes I introduce. Even if it does not work, I can implement it in my
> >>> webhook.
> >>
> >> I spent some time yesterday creating my own git clone of kicad on LP and
> >> I noticed that the subscriptions that I need appear to be available for
> >> git repos so we shouldn't need any webhooks in for that unless they do
> >> not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> >>>
> >>> The webhook has reached beta stage. I have created a dummy project for
> >>> testing purposes, where you can see a bug report [1] and a commit [2]
> >>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
> match.
> >>> When it is detected, it automatically adds a message, changes the bug
> >>> status and assignee. One thing that is not possible right now is
> linking
> >>> with git branches, as apparently launchpad does not handle this at the
> >>> moment (or I could not find the right format to specify a branch).
> >>
> >> Bug report linking is very important to me since I am responsible for
> >> the stable branch.  If there is no support for this yet, I'm OK with
> >> adding the bug report number to the first line of the commit message and
> >> the URL somewhere in the commit message body.  If I give the OK to use
> >> git, I will expect all developers that have commit privileges to the
> >> product repo to follow this without exception.  The commit message for
> >> bug report fixes must have this format:
> >>
> >> Description of bug report fix. (fixes lp:)
> >>
> >> * https://bugs.launchpad.net/kicad/+bug/
> >>
> >> If this is not acceptable, then the git transition will have to wait
> >> until Canonical gets git bug report linking implemented or Orson beats
> >> them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
>
> I'll see if I can figure out how to do this and if it works we can use
> it instead of adding the bug report url to the commit message.  I wonder
> if we can link a commit to a bug report?  That could be an issue if we
> cannot.  I don't want to have to always create a separate branch, push
> it to my personal repo, and then merge it into the product branch for
> simple bug fixes.
>
> >
> >>> All we need to do is to set a webhook pointing to my script [3]. If it
> >>> is accepted, then I am going to create a separate lp account for the
> >>> automated changes.
> >>>
> >>> Currently the webhook works on my home server which has a high uptime,
> >>> but still it is not as reliable as dedicated servers. If there is
> >>> someone willing to host it on a better machine, I will be pleased to
> help.
> >>>
> >>> If you are curious about the source code, then I can put it in the
> KiCad
> >>> github (once I get a repository there) or just post it somewhere.
> >>
> >> I can create a repo on github or you can create a repo on launchpad.
> >> Either way is fine by me.  If you want to use github, let me know what
> >> name you want for the repo and your github user name and I will set up
> >> the repo and give you admin rights.
> >
> > I have just pushed the code to Launchpad [1] and consider it ready to
> > go. There is also a new account (KiCad Janitor) awaiting approval for
> > kicad-developers membership, so all the changes will be done using this
> > dedicated account.
> >
> > The webhook has been modified to accept a wider set of phrases
> > indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
> >
> > Let me know when the git repository is set up, so I can install the
> webhook.
>
> This will require some coordination with our package devs.  Package
> devs, when can we be ready to provide nightly builds from the git 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Wayne Stambaugh
On 8/11/2016 5:17 AM, Maciej Sumiński wrote:
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
>> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
 The last time I looked, notifications of repo commits still were not
 implemented.  This is a show stopper for me.  I don't want to have to
 constantly grep the git commit log to see what changed.  If change
 notifications are working correctly, then I'm OK with moving forward on
 this if you can get the bug fix linking working.  We definitely should
 do some testing before we go live with this.
>>>
>>> I see there is an option to set notifications, in the same way as for
>>> the bazaar branches ("Edit your subscriptions" on the right side pane).
>>> I could not verify it, as likely I cannot receive notifications for the
>>> changes I introduce. Even if it does not work, I can implement it in my
>>> webhook.
>>
>> I spent some time yesterday creating my own git clone of kicad on LP and
>> I noticed that the subscriptions that I need appear to be available for
>> git repos so we shouldn't need any webhooks in for that unless they do
>> not work.
> 
> If they do not work, let me know and I will fix it in the hook.
> 
>>>
>>> The webhook has reached beta stage. I have created a dummy project for
>>> testing purposes, where you can see a bug report [1] and a commit [2]
>>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
>>> When it is detected, it automatically adds a message, changes the bug
>>> status and assignee. One thing that is not possible right now is linking
>>> with git branches, as apparently launchpad does not handle this at the
>>> moment (or I could not find the right format to specify a branch).
>>
>> Bug report linking is very important to me since I am responsible for
>> the stable branch.  If there is no support for this yet, I'm OK with
>> adding the bug report number to the first line of the commit message and
>> the URL somewhere in the commit message body.  If I give the OK to use
>> git, I will expect all developers that have commit privileges to the
>> product repo to follow this without exception.  The commit message for
>> bug report fixes must have this format:
>>
>> Description of bug report fix. (fixes lp:)
>>
>> * https://bugs.launchpad.net/kicad/+bug/
>>
>> If this is not acceptable, then the git transition will have to wait
>> until Canonical gets git bug report linking implemented or Orson beats
>> them to it.
> 
> I spoke with a Launchpad developer and they have it already in their
> todo list. There is a plan to migrate Launchpad itself to git, so I
> believe they will do it well.
> 
> From what I heard, currently it is possible to link git merge requests
> to bug reports, so it may temporarily solve the problem.

I'll see if I can figure out how to do this and if it works we can use
it instead of adding the bug report url to the commit message.  I wonder
if we can link a commit to a bug report?  That could be an issue if we
cannot.  I don't want to have to always create a separate branch, push
it to my personal repo, and then merge it into the product branch for
simple bug fixes.

> 
>>> All we need to do is to set a webhook pointing to my script [3]. If it
>>> is accepted, then I am going to create a separate lp account for the
>>> automated changes.
>>>
>>> Currently the webhook works on my home server which has a high uptime,
>>> but still it is not as reliable as dedicated servers. If there is
>>> someone willing to host it on a better machine, I will be pleased to help.
>>>
>>> If you are curious about the source code, then I can put it in the KiCad
>>> github (once I get a repository there) or just post it somewhere.
>>
>> I can create a repo on github or you can create a repo on launchpad.
>> Either way is fine by me.  If you want to use github, let me know what
>> name you want for the repo and your github user name and I will set up
>> the repo and give you admin rights.
> 
> I have just pushed the code to Launchpad [1] and consider it ready to
> go. There is also a new account (KiCad Janitor) awaiting approval for
> kicad-developers membership, so all the changes will be done using this
> dedicated account.
> 
> The webhook has been modified to accept a wider set of phrases
> indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
> 
> Let me know when the git repository is set up, so I can install the webhook.

This will require some coordination with our package devs.  Package
devs, when can we be ready to provide nightly builds from the git repo?
Does anyone else have any issues with converting over to git?  Speak now
or forever hold your peace.

> 
> Regards,
> Orson
> 
> 1. https://launchpad.net/kicad-git-hook
> 
>> Thanks for working on this.
>>
>> Cheers,
>>
>> Wayne
>>
>>>
>>> Regards,
>>> Orson
>>>
>>> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
>>> 2.
>>> 

Re: [Kicad-developers] Integrated Simulator

2016-08-11 Thread Wayne Stambaugh
Congratulations on everyone who made the is happen.  This is a nice
feature for KiCad and hopefully users will find it useful.

There are a few things will need to addressed that I missed when I
initially evaluated the code.

Maybe I missed it but I do not see any indication that the ngspice
headers and libraries are detected during cmake configuration (see
attachment).  This is a major no-no.  All external dependencies must be
found during configuration.  As a developer, there are few things that
make kick a software package to the curb faster than getting 3/4 of way
through a 30+ minute build only have the build fail because there is a
missing dependency header or library.  This should fail during
configuration to inform the developer that there are missing
dependencies.  Please write a FindNgSpice.cmake file.  I know I've said
this in the past but I will reiterate it, if you add a new dependency to
KiCad you *must* add the configuration code to ensure that all of the
required headers and/or libraries can be found before a valid
configuration can be completed.

Also, please update the Documentation/development/compiling.md file with
the added optional ng-spice dependency.  This is the official compiling
document that gets pushed to the kicad website so it needs to be kept up
to date.

Thanks again everyone for your hard work.

Cheers,

Wayne


On 8/11/2016 9:07 AM, Maciej Sumiński wrote:
> I have just merged the ngspice branch. It is still required to enable
> KICAD_SPICE switch in cmake in order to use it, so it does not cause
> problems on systems without ngspice library installed.
> 
> Regards,
> Orson
> 
> On 08/05/2016 09:40 PM, Maciej Sumiński wrote:
>> I had spoken with ngspice devs and they have suggested me a workaround
>> for the bug. Unfortunately, it requires a patch that is currently not
>> included in the release version, so we resort to building from the
>> source again.
>>
>> To ease the pain, I have updated get_libngspice_so.sh [1]. Now it should
>> build the correct library version for Linux, Windows (mingw64) & OS X. I
>> have managed to run the script successfully on all the mentioned
>> platforms, but I still do not have KiCad compiled on OS X, so I was not
>> able to test it there.
>>
>> I have updated the ngspice branch in my github repository [2]:
>> - applied fixes for Win7 & OS X (thank you Jean-Pierre & Johannes)
>> - resized dialogs, so all the fields are visible and windows fit 1024x768
>> - fixed a few minor bugs
>> - corrected demo circuits
>> - cleared, formatted & documented the code
>>  & added some documentation
>> I consider the code ready for merge. If there are no objections, I would
>> like to proceed next week.
>>
>> Regards,
>> Orson
>>
>> 1. https://orson.net.pl/pub/libngspice/get_libngspice_so.sh
>> 2. https://github.com/orsonmmz/kicad-source-mirror/tree/ngspice
>>
>> On 07/21/2016 11:16 PM, Chris Pavlina wrote:
>>> Really, really nice! I made it do a thing! 
>>> https://misc.c4757p.com/kicad_sim.png
>>>
>>> I feel bad to provide a bug report on my very first communcation on
>>> this, but... found one: not sure if this sort of thing is actually
>>> standard SPICE or an LTspice extension, but I tried parameterizing a
>>> component value, setting a resistor's value to {R} - that sort of thing
>>> leads to irrecoverable lockups here.
>>>
>>> On Thu, Jul 21, 2016 at 09:37:57PM +0200, Tomasz Wlostowski wrote:
 Hi,

 As some of you have noticed, we've been working on a "secret" feature
 during the hackathon at CERN. The feature we're talking about is an
 integrated circuit simulator. Currently it features:
 - Seamless integration into schematic editor,
 - AC/Transient/DC sweep simulations,
 - Voltage probing from the schematics,
 - Live tuning of component values.

 A video demonstrating the capabilities of the new simulator is available
 on Tom's YouTube channel [1].

 The code is currently available in the ngspice branch on Tom's GitHub
 [2] for review & testing. It's a big feature, so we didn't want to push
 it immediately to the product branch. We'll greatly appreciate your
 feedback!

 The simulator uses ngspice [3] as the Spice kernel. We'd like to thank
 ngspice developers for providing a DLL interface which made seamless
 integration of ngspice into Kicad possible.

 In order to get started:
 - install ngspice shared library (is not provided by many Linux distros,
 Arch Linux is a known exception, so you might have to compile it from
 the sources with --with-ngshared --enable-xspice options).  Windows
 DLLs, msys2 PKGBUILD & binary packages (to be included soon in
 the official msys2 repo, currently merged to
 https://github.com/Alexpux/MINGW-packages/) & Linux script to build the
 library are available at [4].
 - compile eeschema with -DKICAD_SPICE=ON option,
 - have a look at some examples in demos/simulation directory.

 

Re: [Kicad-developers] Git transition

2016-08-11 Thread Chris Pavlina
I stand by my recommendation to use a "Fixes: lp:n" on a line by
itself. This is _established convention_ in git commit messages. A quick
example from the Linux kernel tree has Reported-by, Requested-by, Cc,
Signed-off-by all formatted in this way.

Come on... it's established convention already, use it. We don't have to
be different for the sake of it.

lp: without "Fixes" may not be obvious at first glance to people
unfamiliar with our conventions.

On Thu, Aug 11, 2016 at 04:09:11PM +0200, Nick Østergaard wrote:
> Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
> >
> > On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > > On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> > >> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> > >>> The last time I looked, notifications of repo commits still were not
> > >>> implemented.  This is a show stopper for me.  I don't want to have to
> > >>> constantly grep the git commit log to see what changed.  If change
> > >>> notifications are working correctly, then I'm OK with moving forward
> on
> > >>> this if you can get the bug fix linking working.  We definitely should
> > >>> do some testing before we go live with this.
> > >>
> > >> I see there is an option to set notifications, in the same way as for
> > >> the bazaar branches ("Edit your subscriptions" on the right side pane).
> > >> I could not verify it, as likely I cannot receive notifications for the
> > >> changes I introduce. Even if it does not work, I can implement it in my
> > >> webhook.
> > >
> > > I spent some time yesterday creating my own git clone of kicad on LP and
> > > I noticed that the subscriptions that I need appear to be available for
> > > git repos so we shouldn't need any webhooks in for that unless they do
> > > not work.
> >
> > If they do not work, let me know and I will fix it in the hook.
> >
> > >>
> > >> The webhook has reached beta stage. I have created a dummy project for
> > >> testing purposes, where you can see a bug report [1] and a commit [2]
> > >> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
> match.
> > >> When it is detected, it automatically adds a message, changes the bug
> > >> status and assignee. One thing that is not possible right now is
> linking
> > >> with git branches, as apparently launchpad does not handle this at the
> > >> moment (or I could not find the right format to specify a branch).
> > >
> > > Bug report linking is very important to me since I am responsible for
> > > the stable branch.  If there is no support for this yet, I'm OK with
> > > adding the bug report number to the first line of the commit message and
> > > the URL somewhere in the commit message body.  If I give the OK to use
> > > git, I will expect all developers that have commit privileges to the
> > > product repo to follow this without exception.  The commit message for
> > > bug report fixes must have this format:
> > >
> > > Description of bug report fix. (fixes lp:)
> > >
> > > * https://bugs.launchpad.net/kicad/+bug/
> > >
> > > If this is not acceptable, then the git transition will have to wait
> > > until Canonical gets git bug report linking implemented or Orson beats
> > > them to it.
> >
> > I spoke with a Launchpad developer and they have it already in their
> > todo list. There is a plan to migrate Launchpad itself to git, so I
> > believe they will do it well.
> >
> > From what I heard, currently it is possible to link git merge requests
> > to bug reports, so it may temporarily solve the problem.
> >
> > >> All we need to do is to set a webhook pointing to my script [3]. If it
> > >> is accepted, then I am going to create a separate lp account for the
> > >> automated changes.
> > >>
> > >> Currently the webhook works on my home server which has a high uptime,
> > >> but still it is not as reliable as dedicated servers. If there is
> > >> someone willing to host it on a better machine, I will be pleased to
> help.
> > >>
> > >> If you are curious about the source code, then I can put it in the
> KiCad
> > >> github (once I get a repository there) or just post it somewhere.
> > >
> > > I can create a repo on github or you can create a repo on launchpad.
> > > Either way is fine by me.  If you want to use github, let me know what
> > > name you want for the repo and your github user name and I will set up
> > > the repo and give you admin rights.
> >
> > I have just pushed the code to Launchpad [1] and consider it ready to
> > go. There is also a new account (KiCad Janitor) awaiting approval for
> > kicad-developers membership, so all the changes will be done using this
> > dedicated account.
> >
> > The webhook has been modified to accept a wider set of phrases
> > indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
> >
> 
> I would like to suggest that we don't write "fixes:" as a prefix, I don't
> see it adds any added information. Simply write:
> lp:4232442
> 
> And in the 

Re: [Kicad-developers] [PATCH] Memoize SHAPE_LINE_CHAIN bounding box computation

2016-08-11 Thread Maciej Sumiński
Just to let you know: I had asked Tom and he had had nothing against the
patch, so Chris has committed it.

Regards,
Orson

On 08/10/2016 04:19 PM, Wayne Stambaugh wrote:
> Orson & Tom,
> 
> Please look over this patch when you get a chance to see if it makes
> sense to commit it.
> 
> Thanks,
> 
> Wayne
> 
> On 8/6/2016 9:36 PM, Chris Pavlina wrote:
>> The board I'm working on is quite complex and makes KiCad _very_ slow,
>> so I'm working on a bit of profiling and optimizing. The attached patch
>> memoizes SHAPE_LINE_CHAIN bounding box computation, which is a hot spot
>> during netlist sync (presumably when trace/net connections are
>> calculated). For my specific case, it results in a 38% speedup, from 21
>> seconds down to 13 seconds.
>>
>> Next hotspot to tackle is NETLIST_OBJECT_LIST::BuildNetListInfo :)
>>
>>
>>
>> ___
>> 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] Git transition

2016-08-11 Thread Nick Østergaard
Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
>
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >>> The last time I looked, notifications of repo commits still were not
> >>> implemented.  This is a show stopper for me.  I don't want to have to
> >>> constantly grep the git commit log to see what changed.  If change
> >>> notifications are working correctly, then I'm OK with moving forward
on
> >>> this if you can get the bug fix linking working.  We definitely should
> >>> do some testing before we go live with this.
> >>
> >> I see there is an option to set notifications, in the same way as for
> >> the bazaar branches ("Edit your subscriptions" on the right side pane).
> >> I could not verify it, as likely I cannot receive notifications for the
> >> changes I introduce. Even if it does not work, I can implement it in my
> >> webhook.
> >
> > I spent some time yesterday creating my own git clone of kicad on LP and
> > I noticed that the subscriptions that I need appear to be available for
> > git repos so we shouldn't need any webhooks in for that unless they do
> > not work.
>
> If they do not work, let me know and I will fix it in the hook.
>
> >>
> >> The webhook has reached beta stage. I have created a dummy project for
> >> testing purposes, where you can see a bug report [1] and a commit [2]
> >> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
match.
> >> When it is detected, it automatically adds a message, changes the bug
> >> status and assignee. One thing that is not possible right now is
linking
> >> with git branches, as apparently launchpad does not handle this at the
> >> moment (or I could not find the right format to specify a branch).
> >
> > Bug report linking is very important to me since I am responsible for
> > the stable branch.  If there is no support for this yet, I'm OK with
> > adding the bug report number to the first line of the commit message and
> > the URL somewhere in the commit message body.  If I give the OK to use
> > git, I will expect all developers that have commit privileges to the
> > product repo to follow this without exception.  The commit message for
> > bug report fixes must have this format:
> >
> > Description of bug report fix. (fixes lp:)
> >
> > * https://bugs.launchpad.net/kicad/+bug/
> >
> > If this is not acceptable, then the git transition will have to wait
> > until Canonical gets git bug report linking implemented or Orson beats
> > them to it.
>
> I spoke with a Launchpad developer and they have it already in their
> todo list. There is a plan to migrate Launchpad itself to git, so I
> believe they will do it well.
>
> From what I heard, currently it is possible to link git merge requests
> to bug reports, so it may temporarily solve the problem.
>
> >> All we need to do is to set a webhook pointing to my script [3]. If it
> >> is accepted, then I am going to create a separate lp account for the
> >> automated changes.
> >>
> >> Currently the webhook works on my home server which has a high uptime,
> >> but still it is not as reliable as dedicated servers. If there is
> >> someone willing to host it on a better machine, I will be pleased to
help.
> >>
> >> If you are curious about the source code, then I can put it in the
KiCad
> >> github (once I get a repository there) or just post it somewhere.
> >
> > I can create a repo on github or you can create a repo on launchpad.
> > Either way is fine by me.  If you want to use github, let me know what
> > name you want for the repo and your github user name and I will set up
> > the repo and give you admin rights.
>
> I have just pushed the code to Launchpad [1] and consider it ready to
> go. There is also a new account (KiCad Janitor) awaiting approval for
> kicad-developers membership, so all the changes will be done using this
> dedicated account.
>
> The webhook has been modified to accept a wider set of phrases
> indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
>

I would like to suggest that we don't write "fixes:" as a prefix, I don't
see it adds any added information. Simply write:
lp:4232442

And in the rare event it is for multiple bugs just append more lines of it.

> Let me know when the git repository is set up, so I can install the
webhook.
>
> Regards,
> Orson
>
> 1. https://launchpad.net/kicad-git-hook
>
> > Thanks for working on this.
> >
> > Cheers,
> >
> > Wayne
> >
> >>
> >> Regards,
> >> Orson
> >>
> >> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
> >> 2.
> >>
https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
> >> 3. https://orson.net.pl/kicad_git_hook
> >>
> >>> Before every starts beating the GitHub drum, I have one major issue
with
> >>> GitHub and that is control.  There is no way that I know of to
moderate
> >>> a project on github.  

Re: [Kicad-developers] Integrated Simulator

2016-08-11 Thread Maciej Sumiński
I have just merged the ngspice branch. It is still required to enable
KICAD_SPICE switch in cmake in order to use it, so it does not cause
problems on systems without ngspice library installed.

Regards,
Orson

On 08/05/2016 09:40 PM, Maciej Sumiński wrote:
> I had spoken with ngspice devs and they have suggested me a workaround
> for the bug. Unfortunately, it requires a patch that is currently not
> included in the release version, so we resort to building from the
> source again.
> 
> To ease the pain, I have updated get_libngspice_so.sh [1]. Now it should
> build the correct library version for Linux, Windows (mingw64) & OS X. I
> have managed to run the script successfully on all the mentioned
> platforms, but I still do not have KiCad compiled on OS X, so I was not
> able to test it there.
> 
> I have updated the ngspice branch in my github repository [2]:
> - applied fixes for Win7 & OS X (thank you Jean-Pierre & Johannes)
> - resized dialogs, so all the fields are visible and windows fit 1024x768
> - fixed a few minor bugs
> - corrected demo circuits
> - cleared, formatted & documented the code
>  & added some documentation
> I consider the code ready for merge. If there are no objections, I would
> like to proceed next week.
> 
> Regards,
> Orson
> 
> 1. https://orson.net.pl/pub/libngspice/get_libngspice_so.sh
> 2. https://github.com/orsonmmz/kicad-source-mirror/tree/ngspice
> 
> On 07/21/2016 11:16 PM, Chris Pavlina wrote:
>> Really, really nice! I made it do a thing! 
>> https://misc.c4757p.com/kicad_sim.png
>>
>> I feel bad to provide a bug report on my very first communcation on
>> this, but... found one: not sure if this sort of thing is actually
>> standard SPICE or an LTspice extension, but I tried parameterizing a
>> component value, setting a resistor's value to {R} - that sort of thing
>> leads to irrecoverable lockups here.
>>
>> On Thu, Jul 21, 2016 at 09:37:57PM +0200, Tomasz Wlostowski wrote:
>>> Hi,
>>>
>>> As some of you have noticed, we've been working on a "secret" feature
>>> during the hackathon at CERN. The feature we're talking about is an
>>> integrated circuit simulator. Currently it features:
>>> - Seamless integration into schematic editor,
>>> - AC/Transient/DC sweep simulations,
>>> - Voltage probing from the schematics,
>>> - Live tuning of component values.
>>>
>>> A video demonstrating the capabilities of the new simulator is available
>>> on Tom's YouTube channel [1].
>>>
>>> The code is currently available in the ngspice branch on Tom's GitHub
>>> [2] for review & testing. It's a big feature, so we didn't want to push
>>> it immediately to the product branch. We'll greatly appreciate your
>>> feedback!
>>>
>>> The simulator uses ngspice [3] as the Spice kernel. We'd like to thank
>>> ngspice developers for providing a DLL interface which made seamless
>>> integration of ngspice into Kicad possible.
>>>
>>> In order to get started:
>>> - install ngspice shared library (is not provided by many Linux distros,
>>> Arch Linux is a known exception, so you might have to compile it from
>>> the sources with --with-ngshared --enable-xspice options).  Windows
>>> DLLs, msys2 PKGBUILD & binary packages (to be included soon in
>>> the official msys2 repo, currently merged to
>>> https://github.com/Alexpux/MINGW-packages/) & Linux script to build the
>>> library are available at [4].
>>> - compile eeschema with -DKICAD_SPICE=ON option,
>>> - have a look at some examples in demos/simulation directory.
>>>
>>> Happy simulating,
>>> Tom
>>>
>>> [1] https://youtu.be/A2_-hdRcf4U
>>> [2] https://github.com/twlostow/kicad-dev/tree/ngspice
>>> [3] http://ngspice.sourceforge.net/
>>> [4] https://orson.net.pl/pub/libngspice
>>>
>>> ___
>>> 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
> 




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] Git transition

2016-08-11 Thread Maciej Sumiński
On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
>> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
>>> The last time I looked, notifications of repo commits still were not
>>> implemented.  This is a show stopper for me.  I don't want to have to
>>> constantly grep the git commit log to see what changed.  If change
>>> notifications are working correctly, then I'm OK with moving forward on
>>> this if you can get the bug fix linking working.  We definitely should
>>> do some testing before we go live with this.
>>
>> I see there is an option to set notifications, in the same way as for
>> the bazaar branches ("Edit your subscriptions" on the right side pane).
>> I could not verify it, as likely I cannot receive notifications for the
>> changes I introduce. Even if it does not work, I can implement it in my
>> webhook.
> 
> I spent some time yesterday creating my own git clone of kicad on LP and
> I noticed that the subscriptions that I need appear to be available for
> git repos so we shouldn't need any webhooks in for that unless they do
> not work.

If they do not work, let me know and I will fix it in the hook.

>>
>> The webhook has reached beta stage. I have created a dummy project for
>> testing purposes, where you can see a bug report [1] and a commit [2]
>> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex match.
>> When it is detected, it automatically adds a message, changes the bug
>> status and assignee. One thing that is not possible right now is linking
>> with git branches, as apparently launchpad does not handle this at the
>> moment (or I could not find the right format to specify a branch).
> 
> Bug report linking is very important to me since I am responsible for
> the stable branch.  If there is no support for this yet, I'm OK with
> adding the bug report number to the first line of the commit message and
> the URL somewhere in the commit message body.  If I give the OK to use
> git, I will expect all developers that have commit privileges to the
> product repo to follow this without exception.  The commit message for
> bug report fixes must have this format:
> 
> Description of bug report fix. (fixes lp:)
> 
> * https://bugs.launchpad.net/kicad/+bug/
> 
> If this is not acceptable, then the git transition will have to wait
> until Canonical gets git bug report linking implemented or Orson beats
> them to it.

I spoke with a Launchpad developer and they have it already in their
todo list. There is a plan to migrate Launchpad itself to git, so I
believe they will do it well.

From what I heard, currently it is possible to link git merge requests
to bug reports, so it may temporarily solve the problem.

>> All we need to do is to set a webhook pointing to my script [3]. If it
>> is accepted, then I am going to create a separate lp account for the
>> automated changes.
>>
>> Currently the webhook works on my home server which has a high uptime,
>> but still it is not as reliable as dedicated servers. If there is
>> someone willing to host it on a better machine, I will be pleased to help.
>>
>> If you are curious about the source code, then I can put it in the KiCad
>> github (once I get a repository there) or just post it somewhere.
> 
> I can create a repo on github or you can create a repo on launchpad.
> Either way is fine by me.  If you want to use github, let me know what
> name you want for the repo and your github user name and I will set up
> the repo and give you admin rights.

I have just pushed the code to Launchpad [1] and consider it ready to
go. There is also a new account (KiCad Janitor) awaiting approval for
kicad-developers membership, so all the changes will be done using this
dedicated account.

The webhook has been modified to accept a wider set of phrases
indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).

Let me know when the git repository is set up, so I can install the webhook.

Regards,
Orson

1. https://launchpad.net/kicad-git-hook

> Thanks for working on this.
> 
> Cheers,
> 
> Wayne
> 
>>
>> Regards,
>> Orson
>>
>> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
>> 2.
>> https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
>> 3. https://orson.net.pl/kicad_git_hook
>>
>>> Before every starts beating the GitHub drum, I have one major issue with
>>> GitHub and that is control.  There is no way that I know of to moderate
>>> a project on github.  Anyone with a github account can submit a pull
>>> requests at anytime even if they are not part of the dev team.  As
>>> project leader, this is an issue.  I'm already a my limit with the
>>> development team we have in place and I really don't want to deal with a
>>> wide open code hosting.  I also have no way of removing someone from the
>>> list should I need to.  I know it hasn't happened yet but I am not naive
>>> enough to think that it wont happen.  At this time, I