I think git-SUM is something like that:
$ git log --oneline | wc -l
В Пятница, 12 авг. 2016 в 11:26 , Nick Østergaard
написал:
What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?
I personally like the way we have it now with the build date, the
bzrlike revn
As the spice stuff requires build time options would this not be
better as a normal dynamic linked library? I think that
dlopen/wxDynamicLibrary should really only be used for plugins.
I have updated my kicad-app.sh to download nad build the ngspice
revision but am running into issues with the bun
On Fri, Aug 12, 2016 at 04:31:52PM -0400, Wayne Stambaugh wrote:
> [snip] I just want to do things because that's what all the
> cool kids are doing. If it makes sense, then we should adopt it. If
> not we should do what is appropriate for us. In this case is seems to
> make sense.
We're only t
On 8/12/2016 4:30 PM, Chris Pavlina wrote:
> On Fri, Aug 12, 2016 at 03:34:35PM -0400, Wayne Stambaugh wrote:
>> On 8/11/2016 11:28 AM, Chris Pavlina wrote:
>>> I stand by my recommendation to use a "Fixes: lp:n" on a line by
>>> itself. This is _established convention_ in git commit messages.
On Fri, Aug 12, 2016 at 03:34:35PM -0400, Wayne Stambaugh wrote:
> On 8/11/2016 11:28 AM, Chris Pavlina wrote:
> > 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
What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?
I personally like the way we have it now with the build date, the
bzrlike revno serial and the git sha1.
Or are you suggesting to do like (2016-08-03 2383bcf-6299)-product
instead of (2016-08-03 BZR 6299, Git
On 8/12/2016 5:36 AM, Maciej Sumiński wrote:
> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
> [snip]
>> 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? T
I'm OK with git-SUM rather than the obnoxiously long git rev numbers.
Anyone object to this?
On 8/12/2016 1:25 AM, Simon Wells wrote:
> 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
On 8/11/2016 11:28 AM, Chris Pavlina wrote:
> 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
Interesting. It _is_ much, much faster on the release build.
I'm sorry, but I think you're wrong here - debug builds NEED to be
usable, so developers will actually do significant amounts of real work
with kicad in an environment where they can track down any issues they
have with it. I still consi
This is also defined in , and likely to be a compiler intrinsic.
---
common/widgets/mathplot.cpp | 6 --
1 file changed, 6 deletions(-)
diff --git a/common/widgets/mathplot.cpp b/common/widgets/mathplot.cpp
index 3a1896b..f9de3ae 100644
--- a/common/widgets/mathplot.cpp
+++ b/common/widgets/
Something really really minor.
There is no icon for the Simulator menu (Tools -> Simulator). :D :D :D
Excellent work btw.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://
Le 12/08/2016 à 19:32, Chris Pavlina a écrit :
> Hm, debug or release? I don't recall from looking through the netlist
> code whether it had any major bits switched off in release builds or
> not. I'm pretty much always running on a debug build.
Release build.
I don't think there are many bits sw
Hm, debug or release? I don't recall from looking through the netlist
code whether it had any major bits switched off in release builds or
not. I'm pretty much always running on a debug build.
On Fri, Aug 12, 2016 at 07:09:37PM +0200, jp charras wrote:
> Le 12/08/2016 à 18:26, Chris Pavlina a écri
Le 12/08/2016 à 18:26, Chris Pavlina a écrit :
> Ah, no - I got a bit off scope there, I'm talking about the whole
> project. Generating the netlist in eeschema is very slow, which means
> sch->pcb sync is slow. Not necessarily a task for you specifically, I'm
> just kind of enumerating the bits w
Ah, no - I got a bit off scope there, I'm talking about the whole
project. Generating the netlist in eeschema is very slow, which means
sch->pcb sync is slow. Not necessarily a task for you specifically, I'm
just kind of enumerating the bits where kicad's been annoying me on this
project.
:)
On F
On 12.08.2016 15:22, Chris Pavlina wrote:
> - Netlist generation. I had a go at rewriting the algorithm for this
> (it's O(n^3) and doesn't need to be...) but didn't get very far with
> limited time.
Do you mean ratsnest?
Cheers,
T.
___
Mailing list
On Fri, Aug 12, 2016 at 05:18:57PM +0200, Maciej Sumiński wrote:
> There is a set of patches for the PNS router [1] coded by Tom that we
> would like to commit soon (a few teasers: locking tracks & vias,
> removing tracks while the router is active, 45-degree tuning meanders).
>
> One of the chang
There is a set of patches for the PNS router [1] coded by Tom that we
would like to commit soon (a few teasers: locking tracks & vias,
removing tracks while the router is active, 45-degree tuning meanders).
One of the changes adds a possibility to specify differential pairs
width & gap per net cla
On 8/12/2016 10:44 AM, Maciej Sumiński wrote:
> On 08/12/2016 04:38 PM, Wayne Stambaugh wrote:
> [snip]
>>> Hi Orson,
>>>
>>> I saw your commit. Thanks for addressing this issue in a timely mannor.
>>> I have on minor comment. FindFoo.cmake files should always have an
>>> option to override the
On 08/12/2016 04:38 PM, Wayne Stambaugh wrote:
[snip]
>> Hi Orson,
>>
>> I saw your commit. Thanks for addressing this issue in a timely mannor.
>> I have on minor comment. FindFoo.cmake files should always have an
>> option to override the default find location which should take
>> precedence o
On 8/12/2016 10:36 AM, Wayne Stambaugh wrote:
> On 8/12/2016 10:10 AM, Maciej Sumiński wrote:
>> On 08/11/2016 05:37 PM, 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
On 8/12/2016 10:10 AM, Maciej Sumiński wrote:
> On 08/11/2016 05:37 PM, 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
On 08/11/2016 05:37 PM, 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 miss
Sure. You can use it as a benchmark for all the other things that are
slow in KiCad too :D
https://github.com/c4puter/motherboard/raw/master/motherboard.kicad_pcb
Things I have found to be irritatingly slow with this board, that might
be worth looking at:
- Ending routing operations on a highly
Gah, it works here. There's always some system-specific issue with wx,
isn't there.
Okay, don't merge, I'll test this on all the platforms.
On Fri, Aug 12, 2016 at 02:45:37PM +0200, jp charras wrote:
> Le 12/08/2016 à 02:32, Chris Pavlina a écrit :
> > I'm running into an extremely irritating UI
On 12.08.2016 02:32, Chris Pavlina wrote:
> 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
Le 12/08/2016 à 02:32, Chris Pavlina a écrit :
> 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
On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
[snip]
> 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
29 matches
Mail list logo
