On 03/05/2018 07:52 PM, hauptmech wrote:
> The attached patch may fix the build error seen after the RPATH patch.
I was able to build the latest source on my machine with this patch included.
While one run is hardly conclusive, I think this patch has merit.
I'll do some additional runs, and hop
The attached patch may fix the build error seen after the RPATH patch.
>From 4bdf9c309ae7a794014d5c3240ad8599b1273dc9 Mon Sep 17 00:00:00 2001
From: hauptmech
Date: Tue, 6 Mar 2018 13:46:05 +1300
Subject: [PATCH] Fix dependency bug introduced in RPATH patch e0b33ee8
MIME-Version: 1.0
Content-Typ
Sorry, you did and I missed it.
A dependency was missed. I think the following might fix it.
in pcbnew/CMakeLists.txt
-add_dependencies( pcbnew_kiface specctra_lexer_source_files )
+add_dependencies( pcbnew_kiface_objects specctra_lexer_source_files )
On 06/03/18 13:10, Nick Østergaard wrote:
On 03/05/2018 06:55 PM, Nick Østergaard wrote:
> I reproduce in a clean workspace like this:
> git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
> cd kicad_steven/
> mkdir build
> cd build/
> cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF
> -DKICAD_SCRIPTING_WXP
I just gave you hints on how to reproduce this. I suspect the most
important part is the high number of make jobs. I use cmake version 3.10.2
on archlinux.
2018-03-06 1:03 GMT+01:00 hauptmech :
> If you have any hints on how to reproduce the failure I can try to help.
> The cmake version being us
If you have any hints on how to reproduce the failure I can try to help.
The cmake version being used might help.
On 06/03/18 12:55, Nick Østergaard wrote:
I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
cd kicad_steven/
mkdir
Go here https://bugs.launchpad.net/kicad/+bug/1753592
Den 6. mar. 2018 12.58 AM skrev "Clemens Koller" :
> Debug build of SHA1 ID: 5a33f09
> KiCad-from-scratch (no configs, etc...)
> When I open GerbView, I immediately get:
>
>
> ASSERT INFO:
> ./src/gtk/scrolwin.cpp(227): assert "scrolled" faile
Debug build of SHA1 ID: 5a33f09
KiCad-from-scratch (no configs, etc...)
When I open GerbView, I immediately get:
ASSERT INFO:
./src/gtk/scrolwin.cpp(227): assert "scrolled" failed in DoShowScrollbars():
window must be created
BACKTRACE:
[1] wxScrollHelper::DoShowScrollbars(wxScrollbarVisibility
I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
cd kicad_steven/
mkdir build
cd build/
cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF
-DKICAD_SCRIPTING_WXPYTHON=OFF
make -j40
On 5.0.0-rc2-dev-101-gf7ef010fe
2018-03
Clemens,
I merged your patch. Thank you for your contribution to KiCad.
Cheers,
Wayne
On 02/27/2018 05:35 PM, Clemens Koller wrote:
> replace: File -> File(s) when wxFD_MULTIPLE
> replace: Load -> Open
> replace: Erase -> Clear
> add Excellon / Gerber where it makes sense
> re-sort File menu
>
Ok, now I also see that issue. It could very easily be that RPATH commit
making the build system unstable. It is a problem that the generated files
are not in the build dir, but in the source dir.
2018-03-05 23:22 GMT+01:00 Nick Østergaard :
> It also seem to build correctly on jenkins.
>
> 2018-
Hi!
I am wondering how difficult it might get to apply the Push & Shove idea also
to components including all attached traces and use rigid body simulation of a
physics engine to get it pushed and shoved around?
Quick & Dirty ideas: KiCad exports as .SVG. Blender imports .SVG.
The rest is easy,
Hi again,
just wanted to share some of my OpenMP on macOS experience, FWIW:
I used both clang-5.0.1 and clang-6.0 from MacPorts.
KiCad builds fine with it.
It works fine on my build machine (b).
On my MacBook (a) such a build always crashes when ratsnest changes after I
opened the PCB (e.g. mov
It also seem to build correctly on jenkins.
2018-03-05 23:16 GMT+01:00 Steven A. Falco :
> I'm going to retract this report. It builds correctly on copr, so the
> problem must be something in my local setup.
>
> Sorry for the noise.
>
> Steve
>
> _
I'm going to retract this report. It builds correctly on copr, so the problem
must be something in my local setup.
Sorry for the noise.
Steve
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launc
I ran a bisection, and it looks like the first bad commit is:
e0b33ee8a Fix RPATH not removed in shared object file for python
I can build its predecessor, 62bcf4fde41, without any problems. I attached the
bisect log, showing which commits I tried to build, and the results.
Steve
On
I didn't mean to infer that the final location of a part would be
determined by the schematic, just the initial placement of parts in pcbnew
when the netlist is first read. Similar to the spread out all components
tool. A starting point.
I can also imagine a tool that would try to minimise the ove
> On Mar 5, 2018, at 11:49 AM, Russell Oliver wrote:
>
> In terms of automatically arranging components a force directed graph
> algorithm may work quite nicely, especially if the algorithm is seeded with
> the layout of components on the schematic.
>
> A simplistic version would be to just
Yeah, this is a really tough part of leading a project, figuring out
what is whim and what is worth adjusting course for. Anyway, I'll
finish the patch, get it checked, and then present my case.
On 06/03/18 04:01, Wayne Stambaugh wrote:
This happened last stable release. Users wait to the
So it is already implemented in the legacy canvas:
-Global spread and place -> Spread out All Footprints
-Autoroute -> Automatically Route All Footprints
Well, two clicks instead one just one.
I'm with Wayne: no effort should be added to autorouting as there are
plenty of features to sort out.
Yes it does. I'm building on Fedora via the "mock" tool, which always starts
from an empty directory. Just to be sure, I removed the entire "mock" working
area, and I even re-downloaded the source repositories. I'll try pushing the
build up to the Copr build-system, and I'll report back with
The "spring" constants in a force directed graph algorithm could be set by
a user given priority or even by the length of schematic wires.
On Tue, 6 Mar 2018 05:53 Jon Evans, wrote:
> In many commercial tools you can use some or another feature to mark up
> the design at the schematic level with
In many commercial tools you can use some or another feature to mark up the
design at the schematic level with what components "go together".
Then that information is used during PCB placement, the first-pass arrange
of components when you start designing a board can place those components
together
In terms of automatically arranging components a force directed graph
algorithm may work quite nicely, especially if the algorithm is seeded with
the layout of components on the schematic.
A simplistic version would be to just arrange components on board sheet as
to their position on the schemati
Does the compile error exist after you make clean and re-make?
2018-03-05 10:20 GMT-08:00 Steven A. Falco :
> I just got a build error on Linux, at git commit 218f66a08, which appears
> to be the latest commit.
>
> In file included from /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/
> specct
I love wxWidgets. :(
> On 5 Mar 2018, at 18:38, Wayne Stambaugh wrote:
>
> I'm still seeing this issue on windows as of commit 218f66a08. The
> scrollbars are shown greyed out initially after the zoom extents but it
> appears that on windows, the paint area does not include the scollbar
> widt
I'm still seeing this issue on windows as of commit 218f66a08. The
scrollbars are shown greyed out initially after the zoom extents but it
appears that on windows, the paint area does not include the scollbar
width when the scollbar is greyed out but does include them as soon as
you pan and they g
On 3/5/2018 1:15 PM, Jon Evans wrote:
> I believe embedded symbols is part of the file format / library format
> change heading.
It is part of the new schematic file format.
>
> Back-annotation support in general is under the heading of "Pin and Part
> Swapping" in the roadmap, and it's a good i
I just got a build error on Linux, at git commit 218f66a08, which appears to be
the latest commit.
In file included from
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra.h:36:0,
from
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_i
I believe embedded symbols is part of the file format / library format
change heading.
Back-annotation support in general is under the heading of "Pin and Part
Swapping" in the roadmap, and it's a good idea to include re-annotating
components as part of that.
On Mon, Mar 5, 2018 at 1:11 PM, Andy
> On Mar 5, 2018, at 10:57 AM, Jon Evans wrote:
>
> Hi all,
>
> Since my day job involves a lot of engineering planning/timelines/etc, I've
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
>
> I am using Google drive because that's what
> On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh wrote:
>
> I was thinking one level of abstraction higher where I just input my
> design requirements and it spits out a schematic, full simulation to
> match the design requirements, and a completed board layout. That would
> make my job a *lot*
One thing that may be of more interest to board designers is an
automatic footprint placement algorithm that minimizes the number of air
wire crossings. Not so much to place the footprints but to orient them.
A few years ago someone proposed using a chemical reaction stability
algorithm where the
Hi all,
Since my day job involves a lot of engineering planning/timelines/etc, I've
had this rolling around in my head...
I started brainstorming some proposed changes to the roadmaps.
I am using Google drive because that's what is easiest for me to play with;
I'm happy to send patches against th
Hi Jon,
another small issue: if only enabled layer is In1.Cu, THT pads are
visible, but footprint cannot be selected.
I think that breaks your visible=selectable rule.
Fragment of code from D_PAD::ViewGetLOD that may help here:
if( ( GetAttribute() == PAD_ATTRIB_STANDARD || GetAttribute()
Yes, I have also heard that from my hard-core board design colleagues. No
one uses auto-routers anymore, they instead use interactive routers that
have gotten very good lately.
We should continue to push the KiCad interactive (PNS) router to add
capabilities (multi-net routing, via array styles,
I like this change! I've never liked the fact that objects on invisible
layers get selected. Has anyone else had a chance to test this? If
there are no objections, I recommend that this patch get merged for rc2.
On 2/26/2018 10:11 PM, Jon Evans wrote:
> This patch changes the selection logic fo
I was thinking one level of abstraction higher where I just input my
design requirements and it spits out a schematic, full simulation to
match the design requirements, and a completed board layout. That would
make my job a *lot* easier. ;)
All kidding aside, I was told by a very highly skilled b
Ha!
Sounds like a job for Alpha Zero to me.
-S
2018-03-05 9:09 GMT-08:00 Tomasz Wlostowski :
> Ladies and gentlemen, there's a lot of work for us ahead!
>
> https://www.reddit.com/r/AskElectronics/comments/
> 815fz2/what_eda_is_really_the_best_out_there_for_macos/
>
> Cheers,
> Tom
>
>
Actually the second point in that post is a gem (rerouting of tracks when
you move a component) It is a feature of some super-high end packages
(Xpedition, Allegro I think) but missing from lots of paid tools (Altium,
Zuken, etc).
It's on my list of things I want to add to KiCad at some point (if
Ladies and gentlemen, there's a lot of work for us ahead!
https://www.reddit.com/r/AskElectronics/comments/815fz2/what_eda_is_really_the_best_out_there_for_macos/
Cheers,
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad
Thanks, everyone. I think it’s more sensitive to a trackpad than mouse, but I
merged a fix yesterday anyway.
> On 5 Mar 2018, at 16:41, Wayne Stambaugh wrote:
>
> I see it now. I was moving the cursor too fast. You have to move it
> very slowly to see the issue. Hmm, never noticed that befo
hauptmech,
I tested this on windows and it doesn't seem to break anything that I
can see so I merged it. Thank you for your contribution to KiCad.
Cheers,
Wayne
On 2/25/2018 8:49 PM, hauptmech wrote:
>
> Attached
>
> On 26/02/18 11:15, Wayne Stambaugh wrote:
>> hauptmech,
>>
>> Would you ple
I see it now. I was moving the cursor too fast. You have to move it
very slowly to see the issue. Hmm, never noticed that before.
On 3/5/2018 11:39 AM, Andrey Kuznetsov wrote:
> I notice the jerkiness on WIndows!
>
> When you start panning, very slowly, by a little bit, there is a period
> whe
I notice the jerkiness on WIndows!
When you start panning, very slowly, by a little bit, there is a period
when it looks like the view window tries to center itself, so it jumps back
and forth between where it used to be and where the mouse is going, until
it's far enough and it snaps out of it an
The problem with this branching method is that virtually no one else but
the developer who is working in a feature branch actually tests the code
in the feature branch. If you are lucky, one other person developer
will test it. That is why I don't really like this model. Our
development branch g
Diego,
I merged your patch. Thank you for your contribution to KiCad.
Cheers,
Wayne
On 2/25/2018 3:17 PM, Diego Herranz wrote:
> Thanks for your replies. I think there's a consensus that this needs
> improving and restructuring, but given your emails, it sounds like a big
> task :)
>
> In the
Thanks! Sorry for the noise.
On 3/5/2018 10:18 AM, Jeff Young wrote:
> He he… reading our mail out of order, are we? ;)
>
> (Already reviewed. Already merged.)
>
> Cheers,
> Jeff.
>
>
>> On 5 Mar 2018, at 14:33, Wayne Stambaugh wrote:
>>
>> This patch looks fine to me but would one of our m
He he… reading our mail out of order, are we? ;)
(Already reviewed. Already merged.)
Cheers,
Jeff.
> On 5 Mar 2018, at 14:33, Wayne Stambaugh wrote:
>
> This patch looks fine to me but would one of our macos devs please take
> a look at this to make sure it is correct.
>
> As for the symlin
This happened last stable release. Users wait to the last minute and
then make a request for a new feature. If this would have been proposed
six months ago, it probably would be part of the v5 release. The
feature itself is a good idea but it will have to be deferred to some
later version. We r
There is no formal process. It's primarily based on discussion on the
mailing list and me making the final decisions. The road maps live in
the kicad source repo in the /Documentation/development/ folder. They
definitely need updated. I just haven't gotten around to updating them.
I was going
Do we have a process or workflow for proposing changes to the roadmap? A
number of the things from the V5 roadmap didn't happen, so it might make
sense to move some things around to V6 (and possibly a V5.1) roadmaps
-Jon
On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh
wrote:
> Jon,
>
> The v6
This patch looks fine to me but would one of our macos devs please take
a look at this to make sure it is correct.
As for the symlink names, I don't know that the capitalization is all
that important unless it's a macos-centric thing. I don't have an
opinion on this one way or the other.
On 3/4/
On windows builds using msys, openmp 4.5, gcc 7.3.0
On 3/4/2018 1:36 PM, Bernhard Stegmaier wrote:
> Hi all,
>
> could please anybody test the following on a Windows/Linux OpenMP version?
>
> I have a PCB with only components placed (via “Update from Schematic”),
> no routing done yet.
> Make su
Jon,
The v6 road map is here:
http://docs.kicad-pcb.org/doxygen/v6_road_map.html
I was planning on working on the schematic object but I wouldn't be
offended if you want to implement it. If you do decide to work on this,
please keep me in the loop. I have some things that I definitely want
imp
I can certainly help check it. I think Wayne would have to make a call as
to whether or not it's too big a change to introduce now.
-Jon
On Mon, Mar 5, 2018 at 7:59 AM, hauptmech wrote:
> While testing version 5 I realized that clearances are still not settable
> (like track width or via size)
I'm not seeing this on my windows 7 builds. The panning after zoom
extents works smoothly. I even tried resizing the main frame several
times but I still didn't notice it.
On 3/4/2018 5:00 PM, Jeff Young wrote:
> There is actually code in there to make them always on, but there seems
> to be som
While testing version 5 I realized that clearances are still not settable
(like track width or via size) and my life is going to be miserable if I
have to continue with my current work flow which is to change the default
netclass clearance to the desired clearance constantly as I lay down
different
It is not possible for me to make any kind of accurate time predictions
about when v6 might be released. KiCad development does not move at a
constant pace. Right now, we are at an all time high with developer
involvement but that may not last. We have had a number of developers
come and go over
59 matches
Mail list logo