Hi Jeff,
On Wed, Jul 03, 2019 at 09:23:05PM +0100, Jeff Young wrote:
> It’s a search path issue. The lexer.h files are now generated in the local
> directory, but they need to be deleted out of include/ or the local ones
> won’t be found.
Yes. If you are using git, "git clean -fdx" will pick
Hi,
FWIW, the commit message probably needs
Fixes: lp:1831643
* https://bugs.launchpad.net/kicad/+bug/1831643
Fixes: lp:1832357
* https://bugs.launchpad.net/kicad/+bug/1832357
Fixes: lp:1833851
* https://bugs.launchpad.net/kicad/+bug/1833851
at the end.
Pushed as "deps" branch below
This changes make_lexer() so that it no longer generates a custom target
but instead attaches the generated files to an existing one (so the first
argument now is the name of an existing library or executable, and it needs
to come after the add_library/add_executable call).
The generated source
Hi,
since I haven't heard any negative reports since yesterday, I believe this
is either a complete fix or at least a significant improvement, so it's
ready for inclusion.
Simon
Simon Richter (1):
Fix build order for generated headers and sources
CMakeModules/Functions.cmake
Hi,
On Tue, Jul 02, 2019 at 11:42:30AM -0400, Seth Hillbrand wrote:
> Instead of banging on this dependency, I could push option #2 from
> my previous e-mail. This was creating a separate target to rebuild
> the generated files and checking them into the source tree. Then we
> don't try to
just
the initial test now.
Simon
commit 46697882c3c35b7cff13bf917d26a53f8f1b1544
Author: Simon Richter
Date: Mon Jul 1 17:02:40 2019 +0200
Fix build order for generated headers and sources
This changes make_lexer() so that it no longer generates a custom target
but instead
Hi,
On Tue, Jul 02, 2019 at 09:18:23AM -0400, Brian Piccioni wrote:
> When I click this linkhttps://git.launchpad.net/~sjr/kicad/msvc-new . I
> get Invalid request
> I assume there is an MSVC KiCad repos out there and I’m sure like to try it.
Hmm, apparently the URL format for Launchpad
Hi,
> What is the minimum version of MSVC required for building this?
I use 2017 Build Tools. It should probably work with 2012 and 2015 as well.
Simon
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Hi Seth,
On Mon, Jul 01, 2019 at 12:33:43PM -0400, Seth Hillbrand wrote:
> [ 38%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/widgets/symbol_tree_pane.cpp.o
> /home/seth/code/kicad/kicad_bare/eeschema/dialogs/panel_sym_lib_table.cpp:29:10:
> fatal error:
Hi Wayne,
On Mon, Jul 01, 2019 at 09:22:15AM -0400, Wayne Stambaugh wrote:
> We already have a string comparison function that handles this. Take a
> look at StrNumCmp()[1] in common/string.cpp[2]. We use this function in
> many places for mixed text and number comparisons so I see no reason
This changes make_lexer() so that it no longer generates a custom target
but instead attaches the generated files to an existing one (so the first
argument now is the name of an existing library or executable, and it needs
to come after the add_library/add_executable call).
The generated source
Hi,
this might fix the lexer problems. Please test extensively.
Simon
Simon Richter (1):
Fix build order for generated headers and sources
CMakeModules/Functions.cmake | 27
CMakeModules/TokenList2DsnLexer.cmake | 2 +-
common/CMakeLists.txt
Hi,
> +if( USE_WX_OVERLAY OR APPLE )
> +add_definitions( -DUSE_WX_OVERLAY )
> +endif()
> +
That is a merge error, I'll remove that.
Simon
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
We want to be somewhat standards compliant if we can.
There is a small complication, which we work around:
gcc sets __STRICT_ANSI__ in "c++11" mode (the non-strict mode would be
"gnu++11"), which causes the "strdup" definition to go away. If wx < 3.1 is
compiled with GNU extensions, it just
---
pcbnew/pcb_edit_frame.h | 3 ++-
pcbnew/pcbnew_config.cpp | 12 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/pcbnew/pcb_edit_frame.h b/pcbnew/pcb_edit_frame.h
index 705f5f7f4..dadb6cba0 100644
--- a/pcbnew/pcb_edit_frame.h
+++ b/pcbnew/pcb_edit_frame.h
@@
All compilers need this in standards-compliant mode.
---
CMakeLists.txt | 4
1 file changed, 4 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee43d9eb9..c73c86a29 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -245,6 +245,10 @@ if( WIN32 )
# define UNICODE
Windows headers assume min/max to be macros, but we set NOMINMAX to hide
the macro definitions. This pulls in an alternative implementation.
---
common/gal/cairo/cairo_print.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/common/gal/cairo/cairo_print.cpp
Defines:
- inhibit generation of #pragma comment(lib, ...) from boost
- inhibit warnings about "unsafe" containers
- inhibit warnings about "unsafe" C functions
- inhibit warnings about "deprecated" POSIX functions
- ask for macros from math.h
- suppress min/max macros from windows.h
---
CMakeModules/FindOpenSSL.cmake | 342 -
1 file changed, 342 deletions(-)
delete mode 100644 CMakeModules/FindOpenSSL.cmake
diff --git a/CMakeModules/FindOpenSSL.cmake b/CMakeModules/FindOpenSSL.cmake
deleted file mode 100644
index de91787c1..0
This uses the Windows native Fiber API.
---
common/system/libcontext.cpp | 66
include/system/libcontext.h | 16 ++-
include/tool/coroutine.h | 8 --
3 files changed, 87 insertions(+), 3 deletions(-)
diff --git
so we need to
decide if we want it). The other patches are fairly straightforward.
Including probably makes sense everywhere, not just in the files
where we need strncasecmp.
Simon
Simon Richter (6):
Set _USE_MATH_DEFINES on Windows
Turn off compiler extensions
Remove own copy of FindOpenSSL.cm
---
include/lib_tree_item.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/lib_tree_item.h b/include/lib_tree_item.h
index 5ad5ef4bd..28f69b7c0 100644
--- a/include/lib_tree_item.h
+++ b/include/lib_tree_item.h
@@ -27,7 +27,7 @@
#include
#include
-
+#include
---
eeschema/sim/ngspice.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp
index fa1d3e3a9..4b173ef7a 100644
--- a/eeschema/sim/ngspice.cpp
+++ b/eeschema/sim/ngspice.cpp
@@ -28,6 +28,7 @@
#include "ngspice.h"
#include "spice_reporter.h"
Hi,
> The background is the GNU make is not intelligent about parallel
> builds and doesn't merge generated targets.
FWIW we have the same problem on MSBuild. The problem we have is that we
use the same generated file from two different projects, and CMake's
paradigm is that generated files
Hi,
I've rebased[1] Tom's adaptation of my MSVC branch on top of current
master, seems to compile still[2], except for the usual dependency problems
with the generated lexers[3].
In this branch, we have an assembler based libcontext (taken over from
boost) that is in a later commit replaced by
Hi Wayne,
On Tue, Jun 25, 2019 at 12:36:36PM -0400, Wayne Stambaugh wrote:
> I guess I should comment on this seeing that I am the project leader. I
> am fine with refactoring as long as it's an improvement over existing
> code.
The main improvement is going to be that we can dump the
Hi,
On Mon, Jun 24, 2019 at 12:43:47AM -0400, Seth Hillbrand wrote:
> 1) a double-joint in the final connection
Hm, that might be an interesting creation mode: draw the outline as if it
were a trace.
I'm not entirely convinced that there are many use cases for that though.
Simon
Hi,
On Fri, Jun 21, 2019 at 10:54:04PM -0400, Reece R. Pollack wrote:
> Just for discussion, let's assume the replacement for wxPoint is
> named KiPoint. The result of subtracting two KiPoint objects would
> be another object called KiDelta. Adding two KiPoint objects should
> be undefined, and
Hi,
I just stumbled across
/* Please NOTE the different sign due to Y-axis flip */
start.x = centre.x + KiROUND( cosdecideg( radius, -StAngle ) );
start.y = centre.y + KiROUND( sindecideg( radius, -StAngle ) );
at common/plotters/plotter.cpp:164.
Is that comment obsolete, or is
Hi,
> I’ve changed the probably-offending line back to a static_cast, but I can’t
> say I’m terribly happy about it. dynamic_cast would be safer….
We have a few more of these in the codebase, around GetElem() calls.
common/project.cpp:FP_LIB_TABLE* tbl = (FP_LIB_TABLE*) GetElem(
Hi,
we have some intermittent build failures that I've tried to debug today. As
parallelism is involved, I now want to set everything on fire.
Symptom: if we have enough CPUs, the lexer generation is started multiple
times in parallel for the same outputs. The first platform where we saw
this
Hi,
this enables FP exceptions everywhere in Debug mode, and disables them in
Release mode. This is for testing only, and should *not* yet go into
mainline.
Still needed:
- signal handler that complains and allows continuing
- context library handling
- tests
Simon
---
Hi,
I just got a notification that bug #1821758 expired. I'd rather not ignore
this, because I can see that there are likely to be two issues here:
- Context code not setting up the floating point environment correctly on
POWER
- Some floating point operation running into an exception
Hi,
Am 24/05/2019 um 13:32 schrieb Wayne Stambaugh:
Just as an FYI in case it wasn't obvious, Seth's proposal uses library
IDs to define the symbol and footprint.
Yes, so would mine, on any level that is more detailed than "footprint".
The main problem I see with atomic libraries is that
Hi,
On Thu, May 23, 2019 at 03:41:20PM -0400, Seth Hillbrand wrote:
> After some discussion, we are trying to decide whether implementing
> a basic atomic library support would be useful during v6 or would
> cause more headache than worth while trying to work with the
> solution.
I have a
Hi,
On 07.05.19 03:02, Tomasz Wlostowski wrote:
> How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
> Windows? I have working implementation of the latter already in the MSVC
> branch. Are there any reasons to not use ucontext under Linux/OSX?
Technically, these APIs are
Hi Mário,
On 29.04.19 23:49, Mário Luzeiro wrote:
> I was checking the commit, it is a commit by Cirilo from some of my
> indications for includes and he copied the file at that state.
> I checked my log where that changes come from and there was also noting
> useful there.
> So it may was
Hi Wayne,
On 29.04.19 20:15, Wayne Stambaugh wrote:
> Rather than remove it completely, how about build option to disable the
> SIMD on platforms that don't support it. Even better, there is probably
> a way to query the compiler to check if it supports SIMD and
> enable/disable accordingly.
This is a bit of a trade-off between compile-time optimizations through
constexpr, and run-time optimizations through SIMD intrinsics.
The difference is probably not relevant, except that in C++11 mode, gcc
(correctly) treats constexpr member functions as implicitly const, which
causes an
Hi,
it appears we can avoid running into the "constexpr" problem with GLM
0.9.9.3 by either
- deleting "#define GLM_FORCE_PURE" from include/plugins/3dapi/xv3d_types.h
or
- switching to C++14 mode
Do we actually need the GLM_FORCE_PURE? The commit where it was
introduced doesn't explain
Hi,
since 5813164d1 "SHAPE_ARC: fixed polyline conversion bug introduced in
e312e2b286" we get test failures in the ArcToPolyline tests:
[Error] - check chain.CPoint( 0 ) == c.m_geom.m_start_point has failed
[[ 10 | 0 ] != [ -10 | 0 ]]Semicircle
== [File] -
Hi Nick,
the main showstoppers are:
1. chroots
On the old Jenkins, we just built on the host system, which meant the
build environment was available instantly. The current system uses
chroots, which have to be unpacked every time. Presumably this could be
solved with Docker, where the unpacking
---
eeschema/sch_pin.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/eeschema/sch_pin.cpp b/eeschema/sch_pin.cpp
index 62e5d48c6f..0e9facd35d 100644
--- a/eeschema/sch_pin.cpp
+++ b/eeschema/sch_pin.cpp
@@ -50,6 +50,7 @@ SCH_PIN& SCH_PIN::operator=( const SCH_PIN& aPin )
m_libPin =
Hi,
Jenkins reports test failures for commit 8cc3c6f15 "Prevent iteration
over empty polygon":
Running 67 test cases...
/var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(179):
error: in "SPSCollision/CollideVertex": check
This is not technically correct (the Boost dependency is introduced through
libcommon), but less invasive as it doesn't pull in libcommon on the linker
command line.
---
utils/kicad2step/CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi John,
On 16.04.19 00:13, John Beard wrote:
> What is the policy for minor string changes going into 5.1.2?
In this case, not a problem, as chamfered pads are not in the 5.1 branch.
Simon
signature.asc
Description: OpenPGP digital signature
---
pcbnew/dialogs/dialog_pad_properties_base.cpp | 2 +-
pcbnew/dialogs/dialog_pad_properties_base.fbp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/pcbnew/dialogs/dialog_pad_properties_base.cpp b/pcbnew/dialogs/dialog_pad_properties_base.cpp
index 6b981b6832..b94732a3d8
Some translations may need this.
---
eeschema/netlist_object.cpp | 2 +-
eeschema/tools/sch_editor_control.cpp | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/eeschema/netlist_object.cpp b/eeschema/netlist_object.cpp
index c800401210..a077956eb8 100644
---
Hi,
On Sat, Apr 06, 2019 at 11:31:27PM -0400, Seth Hillbrand wrote:
> I'd like to suggest spinning out 5.1.1 soon and pushing the existing
> 5.1.1 bugs to 5.1.2.
>
> Thoughts?
I'd like to use this opportunity and add ten random package GUIDs to the
"uninstall before" list in the Windows
Hi,
Jenkins reports failing tests on Linux since commit 5ac96c612 "More
mutex locking for SCH_FIELDs.":
https://jenkins.simonrichter.eu/job/linux-kicad-head/2681/testReport/
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing
Hi,
On 31.03.19 15:55, Seth Hillbrand wrote:
> I use git bisect frequently. Please do not push commits that do not
> compile. This has been done previously and it added hours to fixing a
> single bug in 5.0.1.
It's probably trivial:
commit f67d243c368659798828dde87d9cf562c9176694
Author: Jon
Hi Wayne,
On 30.03.19 21:30, Wayne Stambaugh wrote:
> Is this the last of it? If so, I will attempt to get this merged tomorrow.
Compiles fine on msys2 and msvc. Not all intermediate commits compile,
but I'm not sure anyone does git-bisect anyway.
Simon
signature.asc
Description:
Hi Jon,
On 30.03.19 19:23, Jon Evans wrote:
> Rebased my branch (like I mentioned before, JP's usability concerns have
> been addressed for the moment by disabling immediate update until I can
> come up with a better long-term fix)
Fails to build on MSVC, because there is an
Hi,
On 30.03.19 17:27, Jon Evans wrote:
> I have fixed a few issues, but since I can't be sure there are not still
> performance issues in some situations, I have disabled real-time
> connectivity updates for now so that this issue won't hold up the merge.
> I will revisit this after any other
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
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 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.
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 :
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 on
pc
- 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
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
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
-
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:
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
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
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
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
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
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
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
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,
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
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 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
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
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 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 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
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: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
---
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 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&)'
>
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).
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
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 +--
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 |
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
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
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
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,
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
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
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
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
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,
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
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
---
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
---
), 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 coordinate sys
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
>
101 - 200 of 898 matches
Mail list logo
