Hi Steven,
On 06.11.2018 15:45, Steven A. Falco wrote:
> I've done a little research, and apparently, the concern is that "env" may
> find a locally installed python interpreter that doesn't work the same as the
> system python interpreter, and that can result in subtle bugs. Of course the
>
ixels), zoom factors
(pixels/nm) and angles/rotation. Most of what is needed will turn up only
when I start actually replacing "wxPoint" with "point".
Questions? Comments?
Simon
Simon Richter (2):
New coordinate framework
Compatibility functions for new coordinat
---
CMakeLists.txt| 4
common/base_units.cpp | 13 +
include/base_units.h | 10 ++
include/point.h | 30 ++
4 files changed, 57 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 982209910..08fe26918 100644
--- a/C
file mode 100644
index 0..b6a910cfc
--- /dev/null
+++ b/include/length.h
@@ -0,0 +1,105 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2018 Simon Richter
+ * Copyright (C) 2018 KiCad Developers, see AUTHORS.txt for contributors
Hi,
On 21.11.2018 16:24, Mark Roszko wrote:
> Shouldn't the "length" class be called "coordinate"?
> Otherwise reading point::point(length nx, length ny) as an constructor
> is pretty weird.
Then I'd have to replicate the entire logic of "number + length unit"
for coordinates and sizes, which I
Hi Wayne,
On 21.11.2018 17:37, Wayne Stambaugh wrote:
> If that is the end
> goal of these changes, I'm all for it. If not, I would prefer that this
> be part of the redesign. This should allow us to put the base units in
> a kicad shared object.
Yes, that is the main point of these changes, a
Hi,
On 21.11.2018 20:02, jp charras wrote:
> what do you mean by:
> "that the entire code uses nanometers as internal units
That would be the goal, to use the same internal unit everywhere.
Nanometers make the most sense, because of the metric/imperial
conversion issues you mention.
> In Pcbnew,
Hi,
On 26.11.18 17:52, Steven A. Falco wrote:
> Since I am one of the packagers for KiCad for Fedora, I get "abort" reports
> that Fedora has collected from users.
> I'm forwarding one of the reports to see if there is any interest in this
> data by any KiCad developers. Please let me know if
Hi Marco,
On 15.12.18 17:24, Marco Ciampa wrote:
> tools->Load netlist...
> and the button called
> "Read netlist"
It would make sense to change the button to "Load Netlist" then, I think.
We cannot really use the same string though, because the UI convention
to use an ellipsis to indicate th
Hi,
On 27.12.18 05:19, Seth Hillbrand wrote:
> OK, I'll confirm that KiCad runs as expected in qemu-mips64el with this
> patch. I see minimal issues (mostly around support) with this patch.
> That said, as long as Jiaxun can pitch in for bug reports from Loongson
> platforms, I see no issues he
Hi Wayne,
On 01.01.19 20:59, Wayne Stambaugh wrote:
> I have updated and published the symbol file format[1] for comment.
> Hopefully there isn't too much to change. The only thing to really
> finalize is the internal units.
This would be an artificial unit for the file format, not necessarily
Hi Wayne,
On 02.01.19 23:20, Wayne Stambaugh wrote:
>> This would be an artificial unit for the file format, not necessarily
>> the true internal unit (which I want to unify across the entire program
>> as soon as feasible, but that should be independent from the file formats).
> I'm not sure ex
Hi,
On 03.01.19 19:06, José Ignacio wrote:
> I
> think useful comments to the proposed format should see beyond the
> actual low level representation of the data and talk about the overall
> model being used to store it.
tl;dr: That's a separate discussion.
There are two schools of thought here
Hi Wayne,
On 07.01.19 18:40, Wayne Stambaugh wrote:
> For those of you who don't know, the last few years at FOSDEM we have
> had a KiCad dinner on Saturday evening which was open to all.
I'd like to join.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
On 19.01.19 15:30, John Beard wrote:
> 1) These kinds of utilities are wanted at all, or are they adding
> maintenance overhead for tools no-one ever uses? I'd understand that
> perspective, as I appreciate developer time is highly limited and
> cross-platform breakage is so easy to perpetrat
Automated code analysis says that these cannot throw exceptions and can be
marked "noexcept".
---
3d-viewer/3d_cache/3d_cache.cpp | 4 +-
3d-viewer/3d_cache/3d_cache.h | 2 +-
3d-viewer/3d_cache/3d_cache_wrapper.h | 2 +-
3d-viewer/3d_cache/3d_plugin_manager.cpp | 2
Automated code analysis says that these cannot throw exceptions and can be
marked "noexcept".
---
3d-viewer/3d_canvas/cinfo3d_visu.h | 13 +
3d-viewer/3d_canvas/eda_3d_canvas.h| 9 --
3d-viewer/3d_canvas/status_text_reporter.h | 4 +--
3d-view
Hi,
On 23.01.19 23:37, Seth Hillbrand wrote:
> I think that these make sense. However, I've been bitten by automated
> suggestions in the past and would feel more comfortable if we apply
> these after v5.1 is out. Can you resend these patches once the v6
> development is open?
Sure, none of th
Hi,
On 28.01.19 18:22, Tomasz Wlostowski wrote:
> I'm asking because despite our efforts to improve Kicad's UX, the
> library configuration is still quite difficult, even for experienced PCB
> designers who are switching to KiCad from proprietary tools (see recent
> posts on the Kicad Forum). I'd
Hi,
On 30.01.19 11:21, jp charras wrote:
> E:/kicad-launchpad/testing_git/qa/unit_test_utils/include/unit_test_utils/geometry.h:18:
> multiple definition of `operator<<(std::ostream&, BOX2 >
> const&)'
> CMakeFiles/qa_common_gerbview.dir/objects.a(test_shape_arc.cpp.obj):E:/kicad-launchpad/testin
---
qa/qa_utils/CMakeLists.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/qa/qa_utils/CMakeLists.txt b/qa/qa_utils/CMakeLists.txt
index 20fed4511b..c282640e0e 100644
--- a/qa/qa_utils/CMakeLists.txt
+++ b/qa/qa_utils/CMakeLists.txt
@@ -38,8 +38,9 @@ include_directories(
Hi,
On 31.01.19 16:01, John Beard wrote:
> I'm not really sure. I suppose it depends on the benefits it brings (and
> in future with shared common libs, perhaps it won't matter as much?)
I doubt it makes much of a difference — the biggest hot spots in compile
time are:
- waiting for pcbnew_wra
Hi,
On 31.01.19 16:29, Wayne Stambaugh wrote:
> I didn't have any problem creating a 32 bit build using msys2. It maybe
> your CMake version. I'm using CMake 3.12.4. I also did a clean build
> so that could the issue. This change works pretty well so I hope it's
> not a CMake version issue.
Hi,
On 31.01.19 16:11, jp charras wrote:
> "CMake Error at pcbnew/CMakeLists.txt:645 (target_link_libraries):
> Object library target "pcbnew_kiface_objects" may not link to anything."
By the way, why are we even linking pcbnew twice? The python module and
the kiface are bitwise identical on m
Hi Wayne,
On 31.01.19 17:49, Wayne Stambaugh wrote:
> I would prefer that we create a base units object and then derived
> application level units objects as needed. These objects would be
> small, compile quickly, and could be included in the common library so
> they are available everywhere.
Hi,
On 31.01.19 18:11, Simon Richter wrote:
>> I would prefer that we create a base units object and then derived
>> application level units objects as needed. These objects would be
>> small, compile quickly, and could be included in the common library so
>> they
Hi,
in case anyone finds them useful, wxFormBuilder packages for Debian can
be found in
http://www.simonrichter.eu/debian/
These are unofficial packages, so the source and changes file aren't
signed (because that would allow anyone to upload them to Debian). To
verify the files, get wxformbu
Hi,
On 11.02.19 16:39, Jean-Samuel Reynaud wrote:
> Please find attached a patch to adding missing support for Linux
> platform on arch PPC and PPC64.
> It's proposed by an external user who need that...
Looks promising, but needs a copyright statement.
If it is from Boost, we can include and
Hi,
in case anyone is interested in the current translation status[1]:
LANGTRANSLATED FUZZY UNTRANSLATED
bg 126730011325
ca 27481860 985
cs 27602206 627
de 5583 10
Hi,
On 21.02.19 21:21, Wayne Stambaugh wrote:
> Please let me know what
> you have in the queue so I can get an idea of how we should proceed with
> the merges.
I have a few refactoring branches that add "const", "constexpr",
"noexcept" and smart pointers to various places. These are mostly
auto
Hi Seth,
On 22.02.19 18:11, Seth Hillbrand wrote:
> It should be easier for new features as they don't need the wrap the
> parsing in versioning checks; especially for semantic changes. It may
> be more effort when changing underlying structures that are shared
> between parsers.
Would it make
Hi Cedric,
On 26.02.19 06:55, cedric.dew...@telfort.nl wrote:
> I'm opposed to any program that modifies a file when I open it.
> In my opinion the file should only change when I press the
> "save" button.
Of course, we'd have to ask first. The advantage would be that you
Hi,
On 26.02.19 21:31, Vesa Solonen wrote:
> Anyone here with access to IBM POWER9 hardware and some KiCad testing?
> Talos II workstation is greatly interesting...
I have a TalosII, but setting up an autobuilder for testing has been
fairly low priority so far.
Simon
signature.asc
Descrip
Hi Seth,
On 27.02.19 17:52, Seth Hillbrand wrote:
> Would something similar address your concerns?
From the UI perspective, sure.
The main reason I proposed splitting version upgrade and load/save code
is that it might be easier to maintain in the long run as we pick up
more features and as a r
Hi Tom,
On 06.03.19 18:17, Tomasz Wlostowski wrote:
> This patchset enables building KiCad in MS Visual Studio (version 2017,
> not tested on earlier versions).
Awesome!
Patch 5/9 "msvc: enable parallel builds, remove unused compiler
parameters" basically undoes patch 3/9 "MSVC support for exte
Hi Seth,
On 06.03.19 20:16, Seth Hillbrand wrote:
> Thank you Tom! I would love it if, after testing, we could consider
> switching our official MSW builds to MSVC.
At the moment, MSVC builds lack Python support, so that's a no go, also
we'd have to redo the entire packaging as that is msys2 ba
Hi Tom,
On 06.03.19 18:17, Tomasz Wlostowski wrote:
> - prebuilt environment [1], containing the right versions of libraries
> and tools (CMake & CMake modules). The supplied libraries currently
> support only debug x86_64 targets.
BTW, I also have
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WOR
On 07.03.19 13:46, Jeff Young wrote:
> The tools menu then looks a little scattered, so I’ve moved Set Layer Pair…
> to the Route menu. (Another location for it might be the Edit… menu, but I
> think I prefer Route.)
Route is good — most likely people use the toolbar instead of the menu
anyway
Hi,
the documentation failed to compile for me last night:
https://jenkins.simonrichter.eu/job/any-kicad-doc-head/569/
Is that just me, or is something broken?
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list: http
Hi,
since the topic of library management came up: Would it make sense to
collect library contents along the library search path?
The search path would always be
- project libraries (stored in the project folder)
- user libraries (stored in the user home)
- organization libraries
- distribut
Hi Rene,
On 12.03.19 09:51, Rene Pöschl wrote:
> Hi again, I thought about it a bit more. I am less and less convinced
> this will make it easier for users to understand the library setup overall.
That's why I'm asking here. :)
> This also brings up the question how would you integrate merged p
- Isola FR408
https://www.isola-group.com/wp-content/uploads/data-sheets/fr408.pdf
- Isola 370HR
https://www.isola-group.com/wp-content/uploads/data-sheets/370hr.pdf
- Rogers RO4003C
https://www.rogerscorp.com/documents/726/acm/RO4000-Laminates---Data-sheet.pdf
- Rogers RO4350B
(a
Hi,
On 15.03.19 22:01, Simon Richter wrote:
> No text changes
> .../dialogs/pcb_calculator_frame_base.fbp | 42474
> +--
> 1 file changed, 21237 insertions(+), 21237 deletions(-)
It seems this patch hasn't made it to the list. I just ran dos2unix
No text changes
---
.../dialogs/pcb_calculator_frame_base.fbp | 42474 +--
1 file changed, 21237 insertions(+), 21237 deletions(-)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.l
Hi Wayne,
On 19.03.19 16:06, Wayne Stambaugh wrote:
> I wasn't aware we were converting all wxFormbuilder file line endings to
> unix.
wxFormBuilder did that automatically for me, and I split the conversion
and format upgrade into separate commits so it's more obvious what is
happening. Regenera
Hi Wayne,
On 19.03.19 19:05, Wayne Stambaugh wrote:
>> wxFormBuilder did that automatically for me, and I split the conversion
>> and format upgrade into separate commits so it's more obvious what is
>> happening. Regenerating this dialog avoids a few deprecation warnings.
> I can do this since
Hi Jon,
On 23.03.19 22:57, Jon Evans wrote:
> I would start with the schematic ERC since that's where my head is at
> right now, but what I do should be able to carry over to PcbNew in case
> it ends up working well.
> Any thoughts on this?
I think the main roadblock is that we have no change n
Hi,
On 13.08.2015 12:00, Blair Bonnett wrote:
> * No developer responses on the mailing list, including to a message
> three months ago [1] asking if the project was still active.
Hm, when I filed a bug asking for wxDataViewColumn support, that was
added quickly.
Simon
signature.asc
Descr
Hi,
small cleanup: there are a few unnecessary casts because the covariant
return already does the right thing. Where we get the screen object only in
order to get the active layer, use the accessor function directly.
Simon
---
include/wxBasePcbFrame.h | 4 ++--
Hi,
I'm trying to figure out who is owning the *_SCREEN object pointed to by
EDA_DRAW_FRAME::m_currentScreen.
In EDA_DRAW_FRAME::~EDA_DRAW_FRAME(), the object pointed to is deleted,
which suggests to me that the draw frame has some sort of ownership,
however this will only delete the last object
SCREEN objects are typically owned by the DRAW_FRAME they are attached to.
SCH_SCREEN objects may additionally be shared between one DRAW_FRAME, and
multiple SCH_SHEET objects, so they are reference counted.
To make this distinction more obvious, and avoid potential errors, move the
pointer into
Hi,
CMake provides a readymade test for the GCC/CLang -fvisibility= flag. This
removes our own test and uses the result from CMake.
I've left the test for "NOT APPLE" in place -- is there a particular reason
why we do that?
Simon
---
CMakeLists.txt | 16
Hi,
On 06.09.2015 13:11, Mário Luzeiro wrote:
> what is the c++ standard? that kicad is building? Please make a X in one of
> the following options:
Currently we appear to be using C++98, with a number of nonstandard GNU
extensions.
C++11 would be nice. C++14 is too new, compiler support is st
Hi,
this is an improved version of the earlier patch, using the visibility
handling in CMake 3.3, and falling back to changing the global CXXFLAGS on
previous versions.
As CMake 3.3 attempts to be compatible with earlier versions, the new
behaviour needs to be explicitly enabled until 3.3 becomes
Hi,
CMake provides a simple declarative statement to enable PIC, so no compiler
dependent handling is required. There is also no need to tell Boost to
build with -fPIC, their build system is smart enough.
Simon
---
CMakeLists.txt| 13 -
CMakeModules/download_b
Hi,
this updates our copy of FindwxWidgets.cmake to a state that is fairly
close to what is in the CMake repository. The remaining improvements over
their version are
- version check
- forward compatibility with 3.1 (looking for wx-config-3.1)
- handling for the "webview" component
These thre
Hi,
CMake's test for OpenMP is generic enough to work anywhere, so there is no
good reason to make it conditional on gcc/clang.
This moves the OpenMP handling to the CMakeLists.txt toplevel.
Simon
---
CMakeLists.txt | 33 +++--
1 file changed, 19 insertions(+), 1
Hi,
As boost::polygon is gone, we can drop the workaround for older gcc.
Simon
---
CMakeLists.txt | 15 ---
1 file changed, 15 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6e79fc9..b76c48d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -171,21 +171,6 @@ i
Hi,
probably an oversight after removing debug code. This is not needed, and in
the middle of a source file, between functions.
Simon
---
pcbnew/autorouter/rect_placement/rect_placement.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/pcbnew/autorouter/rect_placement/rect_placement.cpp
Hi,
this allows to undo the grouping in the pin table, by right clicking on the
column header of the currently active grouping column -- this allows you to
go back to a fully flat table.
Simon
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 d
The C++ specification disallows this to permit implementations that use
the address-of operator and sizeof to calculate the address of the first
argument inside the ellipsis; sizeof(foo &) gives the size of the "foo"
class rather than the space taken up by the reference.
---
pcbnew/specctra.cpp |
netlist_reader.h is also used by pcbcommon, so a dependency is necessary.
---
common/CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index 2b558c4..2d843cf 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -388,6 +38
Hi,
this adds a number of missing includes. On gcc, other system includes use
these internally, but that is not guaranteed.
Simon
---
common/gal/graphics_abstraction_layer.cpp | 2 ++
common/grid_tricks.cpp | 2 ++
common/selcolor.cpp|
Hi,
this is an actual problem with VS 2015, which uses different name mangling
rules for "struct" and "class". This makes all instances use "struct".
Simon
---
pcbnew/dialogs/dialog_track_via_properties.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pcbnew/dialogs/dial
Hi,
On 13.09.2015 17:55, Lorenzo Marcantonio wrote:
> I suppose that is talking about the implementation of va_start: address
> of last+sizeof of last gives the starting point of the va_list (in the
> 'correct' stack direction, obviously); am I correct?
Indeed. The standard is written so va_* ca
Hi,
> Looks ok to me, except that the naming of the _git_LONG_HASH_ORIGIN
> variable does not match what it is, it should have been
> _git_LONG_HASH_LOCAL instead.
This completely fails to compile for me:
| [ 11%] Generating version string header
| -- Using Git to determine build version string.
Hi,
On 13.09.2015 20:29, Simon Richter wrote:
> This completely fails to compile for me:
Okay, when I wipe my local repository and repeat the checkout, it works.
Having a fallback to origin/master and/or more graceful handling of a
missing origin/HEAD reference would be great though.
Si
Hi,
On 14.09.2015 04:28, Mark Roszko wrote:
> Now anyone using the newer git-remote-bzr is in for fun as well
> because there is no such thing as "origin/HEAD".
origin/HEAD is automatically created with git-remote-bzr, but not
restored if lost.
You can recreate it via
echo "ref: refs/remotes/o
Hi,
while investigating an internal compiler error[1] in MSVC, I ran across
this function.
My feeling is that it is broken:
For int:
top_left = std::numeric_limits::min() / 2 +
std::numeric_limits::epsilon();
size = std::numeric_limits::max() -
st
Hi,
On 14.09.2015 19:10, Mark Roszko wrote:
> Weird, its supposed to be 0 for ints.
> http://en.cppreference.com/w/cpp/types/numeric_limits/epsilon
I was referring to the bit where it says "It is only meaningful if
std::numeric_limits::is_integer == false". I think it's not a big
problem for in
Hi,
Am 14.09.2015 um 23:58 schrieb Adam Wolf:
[.deb packages]
> Isn't that what's in the reynauld PPA?
No, that's for Ubuntu -- they happen to use the same package format, but
packages are generally not expected to be compatible.
Simon
signature.asc
Description: OpenPGP digital signatur
Hi,
On 19.09.2015 23:05, Wayne Stambaugh wrote:
> No such document but basically gcc on linux and windows and clang on
> osx. The official policy on MS VS is that we will not support it.
VS 2015 is broken to the extent that it fails to compile some of the
template code in VECTOR2<> and BOX<>, g
Hi,
this should get us over the next three months.
Simon
---
copyright.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/copyright.h b/copyright.h
index 79a50ec..4110151 100644
--- a/copyright.h
+++ b/copyright.h
@@ -12,8 +12,8 @@ may choose to document this correspon
Hi,
Am 05.11.2015 um 03:45 schrieb Mark Roszko:
>> I have repeatedly asked that devs do incremental changes so I can
>> easily review them.
> It's hard to do refactoring when your one commit has to throw out the
> kitchen sink.
However, it is often possible to submit multiple commits of the for
This simply moves the OpenMP handling code out of the gcc specific block
with no code changes. This is safe because OpenMP detection is portable.
---
CMakeLists.txt | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.
CMake 3.0 defines two new variables,
* CMAKE_CXX_VISIBILITY_PRESET and
* CMAKE_VISIBILITY_INLINES_HIDDEN
to control whether symbols not explicitly tagged for export are implicitly
exported. Because only version 3.3 and following also applies that to
static libraries when in 3.3 mode, compatibi
CMake provides a simple declarative statement to enable PIC, so no compiler
dependent handling is required. There is also no need to tell Boost to
build with -fPIC, their build system is smart enough.
---
CMakeLists.txt| 13 -
CMakeModules/download_boost.cmake | 2
Hi,
On 01.12.2015 07:52, Ike Shields wrote:
> I am having trouble printing the last part (print to copper. it is the
> printed to photo paper then laminated onto Copper) when I print all I
> get is the small drill holes and solder pads no tracks.
Could it be that some of the "Layer" or "Render
Hi,
On 01.12.2015 07:52, Ike Shields wrote:
> I did an update and it back that I was up to date?
Also, I just noticed. The bzr 4027 version is ancient. The 4.0.0 version
is not contained in Debian stable, and will not be included there
either, as Debian never updates stable releases.
I believe
As boost::polygon is gone, we can drop the workaround for older gcc.
---
CMakeLists.txt | 15 ---
1 file changed, 15 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ec89978..cd3e1bc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -171,21 +171,6 @@ if( CMAKE_COMPIL
Hi,
On 01.12.2015 09:07, jp charras wrote:
>> As boost::polygon is gone, we can drop the workaround for older gcc.
> boost::polygon is gone, not the gcc bug.
> This is likely a gcc bug, not a boost::polygon bug.
Indeed, but the code that triggered the bug is gone, so it shouldn't
affect us any
Hi,
Am 03.12.2015 um 20:11 schrieb Jon Neal:
> With this patch when you add new layers in pcbnew they will be selected
> by default for plotting.
that is LP#1507822. -- https://bugs.launchpad.net/kicad/+bug/1507822
Simon
signature.asc
Description: OpenPGP digital signature
___
Hi,
Am 04.12.2015 um 06:46 schrieb Ike Shields:
> In the print screen on R/H side;
>
> Under Copper layers Tick is on “B.cu”
In the main window, on the right hand side, there are two tabs, "Layers"
and "Render". The former is overridden by the layer selection in the
print dialog, but the latter
Hi,
I've made a backport of RC1 to Debian jessie -- release backports will
happen once the release has hit unstable. The same packages have been
uploaded to Debian, so if you have jessie-backports configured in your
sources.list, your system should silently switch over to the release
package after
Hi,
On 08.12.2015 22:52, Wayne Stambaugh wrote:
> I asked Simon if he could figure out how to make it less noisy. I
> haven't heard back from him yet.
>>> CMake Warning (dev) at utils/idftools/CMakeLists.txt:17 (add_executable):
>>> Policy CMP0063 is not set: Honor visibility properties for a
Hi,
> - set( BOOST_CFLAGS "cflags=${PIC_FLAG}" )
> - set( BOOST_CXXFLAGS "cxxflags=${PIC_FLAG}" )
> because cmake will only set -fpic in CFLAGS but the entire cmake file
> uses BOOST_CFLAGS and never passes the plain CFLAGS
The Boost build knows on its own that it needs -fPIC -- except if you
li
Hi,
I'm thinking about adding some support for pin and unit swapping. To
make it maximally useful, I'd like to generate a list of alternative
mappings inside the netlist, and add the actual swap functionality
inside pcbnew -- so if it turns out that the layout becomes easier if
two pins are swappe
Hi Wayne,
On 11.12.2015 20:23, Wayne Stambaugh wrote:
> Not until after the new schematic and symbol library file formats are
> implemented. Support for pin and unit swapping will be built in to the
> new symbol library file format.
That would be fairly orthogonal to what I'm suggesting -- I'd
Hi,
Am 14.12.2015 um 16:01 schrieb Mark Roszko:
> Stupid question, doesn't this change remove -O2 entirely for all gcc
> builds? Previously it defaulted to -O2 if the bug wasn't present. Now
> it never optimizes as -O0 is the default.
The default depends on the build type -- if your source tree
Hi,
> Just a quick heads up. I just made my travel arrangements for FOSDEM
> 2016. That always makes it feel official to me. Please try to attend
> if you can manage it. I would like to meet as many of the KiCad
> developers as possible. I can tell you that EDA dev room dinner
> Saturday even
Hi,
On 21.12.2015 08:35, Lorenzo Marcantonio wrote:
> After this I'm *not* advocating a binary format, there would be no
> advantage for it in pcbnew. There are no performance restraints in
> either speed or space for kicad files so just use whatever is easier for
> you to manage (i.e. structured
For pin numbers ending in digits, consecutive numbers are collapsed to
ranges for a better overview.
---
eeschema/pin_number.cpp | 49 +++--
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/eeschema/pin_number.cpp b/eeschema/pin_number.cp
Hi,
this patch set implements a summary line for the pin table, listing the
currently defined pins, to quickly check whether any pins have been
forgotten.
If pins 1,2,3,4,5,6,8,9,10,11,12 are defined, the status bar then reads
"1-6,8-12".
Simon
Simon Richter (5):
Split off
s = PinNumbers::Compare( str1, str2 );
if( res == 0 )
res = ( aItem1.GetID() < aItem2.GetID() ) ? -1 : 1;
diff --git a/eeschema/pin_number.cpp b/eeschema/pin_number.cpp
new file mode 100644
index 000..9f5f9ea
--- /dev/null
+++ b/eeschema/pin_number.cpp
@@ -0,0 +1,134 @@
+/*
+ *
Below the pin table, display which pins are currently defined, in order to
find gaps.
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 27 +++
eeschema/dialogs/dialog_lib_edit_pin_table.h | 2 +
.../dialogs/dialog_lib_edit_pin_table_base.cpp | 3 +
.../dialogs/dialog_lib_e
This class wraps the comparison function in a way that is compatible with
std::map and std::set. This, too is generally useful, so it should be moved
to the generic header.
At the same time, the criterium for less-than is changed from "equal to -1"
to "smaller than 0", because technically the com
The "set of pin numbers" functionality is also useful outside the pin table
dialog, so create a wrapper class that exposes the relevant interfaces.
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 2 +-
eeschema/pin_number.h | 21 +
2 files change
Hi,
this removes two leftover references to KICAD_SKIP_BOOST.
Simon
---
CMakeModules/download_avhttp.cmake | 9 +
Documentation/development/compiling.md | 8
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/CMakeModules/download_avhttp.cmake b/CMakeModules/
Hi Wayne,
On 04.01.2016 00:50, Wayne Stambaugh wrote:
> I forgot to delete download_avhttp.cmake and the avhttp source zip file
> so this patch wont be necessary.
There is still a paragraph on KICAD_SKIP_BOOST in the documentation.
Simon
signature.asc
Description: OpenPGP digital signatu
Hi,
On 04.01.2016 04:50, Jon Neal wrote:
> Is there any chance that the CMAKE_BUILD_TYPE flag could be changed from
> Product to Debug by default? It is the only flag I have to include when
> I run cmake now and I often forget to set it.
The goal is to make it easy for the people who want to ins
401 - 500 of 939 matches
Mail list logo
