On 2019-06-04 11:07, Steven A. Falco wrote:
I think I just hit the builder race condition that was discussed a few
days ago. I've attached a copy of template_fieldnames_lexer.h. At
line 184 there is an #endif, and then part of the file appears to
repeat. Thus, I wind up with an unmatched
On 2019-06-04 03:09, Andrew Lutsenko wrote:
Hi Seth,
Another patch that fixes some bugs in scripting and restores previous
dlist behavior.
Regards,
Andrew
Thanks Andrew! A couple questions:
- Do we need to check the existence of Cast() for the BOARD_ITEMS?
- Does the next() method work for
On 2019-06-04 05:58, Marco Ciampa wrote:
msgid "Filo %s da (%s, %s) a (%s, %s)"
Without any comment in the code it is difficult to translate that
string
in a meaningful and/or correct way until you try to use it and find the
results, that is not always possible, pratical.
Hi Marco-
This
On 2019-05-28 10:51, Simon Richter wrote:
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
Thanks Andrew! Good catch.
-Seth
On 2019-06-01 21:40, Andrew Lutsenko wrote:
Hi Seth,
I tried to pull netlist into completely empty board today and got a
crash that I tracked down to
this commit
https://github.com/KiCad/kicad-source-mirror/commit/d1877d7c1b531dee2f4e35304a1d6b33a34c5fff
On 2019-05-29 05:47, Maciej Suminski wrote:
If everything works as expected, then you should be able to see your
reports in my test project bug tracker [1]. The crash reporter should
receive link to the new bug report in the HTTP response, so I guess it
could be shown to the user.
Once we are
repos.
On Wed, 29 May 2019 at 22:11, Wayne Stambaugh
wrote:
Hey Tom,
On 5/29/2019 9:56 AM, Tomasz Wlostowski wrote:
On 29/05/2019 06:07, Seth Hillbrand wrote:
On 2019-05-28 12:13, Tomasz Wlostowski wrote:
Done (tom-crash-reporter-may27 on my Github)!
Tom
Hi Tom-
This looks very nice. I
On 2019-05-29 10:33, jp charras wrote:
Attached a patch that modify the way filled areas (solid polygons) are
built in copper areas.
Currently, solid polygons are slightly smaller than the exact area, and
the polygon outlines have a thickness to fill the exact area.
With this patch, polygon
.
https://bugs.launchpad.net/kicad-git-test/+bugs?field.tag=crash-reporter=-id=0
On 5/29/19 6:07 AM, Seth Hillbrand wrote:
On 2019-05-28 12:13, Tomasz Wlostowski wrote:
Done (tom-crash-reporter-may27 on my Github)!
Tom
Hi Tom-
This looks very nice. I like the implementation a lot!
Here
On 2019-05-28 12:13, Tomasz Wlostowski wrote:
Done (tom-crash-reporter-may27 on my Github)!
Tom
Hi Tom-
This looks very nice. I like the implementation a lot!
Here are a couple minor bits:
1) The force crash dialog says "Clicking on OK will crash KiCad" but the
buttons say "Yes/No"
2)
On 2019-05-02 17:41, Tomasz Wlostowski wrote:
On 02/05/2019 07:06, Wayne Stambaugh wrote:
By chance did you build with OCC instead of OCE which is what I am
using? Please fix this when you get a chance, I would like to get
this
merged but I need to be able to test.
Why did your remove the
On 2019-05-27 11:05, Tomasz Wlostowski wrote:
On 27/05/2019 16:46, Jeff Young wrote:
Hi Seth,
The Eeschema has one advantage that if you mess it up you get too many
undo steps rather than too few. But it is somewhat crankier code to
get right.
I agree that we should have only one scheme.
Hi Devs-
We have two different paradigms for undo/redo stacks. The eeschema
paradigm and the pcbnew paradigm. In Eeschema, we add things directly
to the undo stack, optionally appending to the last item. In Pcbnew, we
queue an undo step in the frame until all items are added and then push
Agreed. We should have FPE on for debug. That said, I _think_ they are
as I just fixed an Eagle import bug that was choking on one. Of course,
I might be mistaken and only seen the exception because I was in gdb.
If the code isn't explicit in CMake, we should probably have the "enable
in
Hi All-
If Reece can separate this so that it doesn't affect eeschema, cvpcb,
pagelayout_editor, gerbview or libedit, I'm fine with merging as is and
refactoring more later. If we merge this as is, it become much more
difficult to fix it later.
Since these are all GetMsgPanelInfo() calls,
On 2019-05-26 11:01, Reece Pollack wrote:
Trust me, I'm not excited about passing the ORIGIN_TRANSFORMS
reference as a parameter. The patch files that do nothing except add
this parameter to the GetMsgPanelInfo() and GetSelectMenuText()
methods are the two biggest in the set, at 1673 and 1488
transform class to EDA_DRAW_FRAME from PCB_BASE_FRAME.
But I don't think that there's anything pcb-specific about offset/sign
transform, so moving it to the shared class should not be problematic.
Best-
Seth
On 2019-05-25 22:57, Seth Hillbrand wrote:
Hi Reece-
I've had a chance to test this a bit
Hi Reece-
I've had a chance to test this a bit. It works really nicely. Thanks
for the good idea here.
I only noticed one spot where it wasn't transformed so far: the
Measurement tool. When used, it displays a sign with the distance,
which doesn't match the increasing/decreasing
Hi Devs-
I've committed a proposed checklist format to my branch[1] on launchpad.
This is the outline of a proposed checklist for KiCad releases that we
can use to verify consistent (i.e. fewer regressions) behavior before
tagging new versions. This currently documents just the main window.
p crashing outright on them.
On 24 May 2019, at 21:39, Seth Hillbrand wrote:
Hi Jeff-
I actually pushed a fix for this (7058b79bf) just before. The
bitfield in GAL has been fully replaced by LSET, so the assert
shouldn't throw anymore.
-S
Am 2019-05-24 16:26, schrieb Jeff Young:
I threw a g
Hi Jeff-
I actually pushed a fix for this (7058b79bf) just before. The bitfield
in GAL has been fully replaced by LSET, so the assert shouldn't throw
anymore.
-S
Am 2019-05-24 16:26, schrieb Jeff Young:
I threw a good wrench in the works by adding a layer ID which was
evidently in the
compared to the new part specifier. Should the result be a
union of both sets of properties or should only the part properties be
used?)
On 23/05/19 21:41, Seth Hillbrand wrote:
Hi All-
After some discussion, we are trying to decide whether implementing a
basic atomic library support would
Am 2019-05-24 02:36, schrieb Sergey A. Borshch:
Major limitation is that your proposal still does not provide mapping
between symbol pins and footprints pins, so user has to keep separate
footprints for, say, sot23 bipolar, FET, Zenner and IC which differ in
pins names only.
Hi Sergey-
Can
a linked footprint and a hash to
verify that the footprint is correct.
Cheers
Russ
On Fri, 24 May 2019, 9:29 am Seth Hillbrand,
wrote:
Hi Rene-
That's a fair critique. The main benefits are ones that could be
incorporated as separate tools (import/export, ability to switch
between
atomic
that allows bom specific things to be more easily included in
the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more
powerful
option in this regard anyways.)
On 23/05/19 21:41, Seth Hillbrand wrote:
Hi All-
After some
Hi All-
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.
Background: "Atomic" libraries are ones that have unique names for
It looks like this was the same one that went to the bug tracker.
I tested it and pushed earlier this morning.
-Seth
Am 2019-05-23 12:55, schrieb Wayne Stambaugh:
JP,
This patch looks correct to me but this is your code so please take a
look at this to see if it makes sense to you when you
Am 2019-05-19 19:27, schrieb Seth Hillbrand:
Am 2019-05-19 15:28, schrieb jp charras:
It also could be worth to commit the work on Removing segment
hard-coding, because zone filled polygons optimization also include
circle to segments optimization.
I think the consensus was to make
Am 2019-05-21 10:21, schrieb Wayne Stambaugh:
4. I did not touch the Bezier coordinates because it appears this is
not fully implemented in Pcbnew and I couldn't figure out how I
would test such changes.
I thought we did go live with this recently so Bezier coordinates will
need to be
Am 2019-05-20 18:48, schrieb Frank Severinsen:
Hi Guys
I'm currently attempting to add a smarter way of doing via
stitching/fill.
Hi Frank-
This is a useful patch! I haven't looked at it in detail but it looks
like a good improvement on the current via placement. Before you go too
far
Am 2019-05-19 15:28, schrieb jp charras:
It also could be worth to commit the work on Removing segment
hard-coding, because zone filled polygons optimization also include
circle to segments optimization.
I think the consensus was to make the acceptable error size configurable
and store it in
Hi Folks-
Windows nightlies seem to be down for the past couple days. Looking at
[1] seems to show a build issue rather than code issue.
-S
[1] https://jenkins.simonrichter.eu/job/windows-kicad-msys2-pipeline/
___
Mailing list:
Am 2019-05-18 08:13, schrieb Tomasz Wlostowski:
On 13/05/2019 12:58, jp charras wrote:
Perhaps also adding a parameter like (circle_optimization [low,
normal,
high] to optimize shapes with arc/circle items (perhaps useful in
microwave applications)
I'm OK with it. Seth?
Yes. Since the
Am 2019-05-16 16:44, schrieb Wayne Stambaugh:
On 5/16/19 4:31 PM, Seth Hillbrand wrote:
Am 2019-05-16 16:24, schrieb Wayne Stambaugh:
I'm fixing a bug[1] in the Eagle plugin in Pcbnew when loading stand
alone Eagle footprint libraries. The fix is easy enough but I'm not
sure why the original
Am 2019-05-16 16:31, schrieb Seth Hillbrand:
Am 2019-05-16 16:24, schrieb Wayne Stambaugh:
I'm fixing a bug[1] in the Eagle plugin in Pcbnew when loading stand
alone Eagle footprint libraries. The fix is easy enough but I'm not
sure why the original code was written this way. When the Eagle
Am 2019-05-16 16:24, schrieb Wayne Stambaugh:
I'm fixing a bug[1] in the Eagle plugin in Pcbnew when loading stand
alone Eagle footprint libraries. The fix is easy enough but I'm not
sure why the original code was written this way. When the Eagle plugin
in loads a board, it uses the board
Am 2019-05-16 13:35, schrieb Jon Evans:
Hi Seth,
If we need to store the value to control plotting as part of board
settings (option 2), which makes sense to me, what is the advantage of
storing a different value in user settings (3)?
Hi Jon-
If there is a mismatch between a computer's video
Am 2019-05-16 08:44, schrieb Seth Hillbrand:
Am 2019-05-16 08:31, schrieb Wayne Stambaugh:
Seth,
I took a look at this and it looks fine to me. Refresh my memory, is
this change to reduce the number of arc segments to help address the
performance issues on complex boards or is this change
sight is always 20/20. I will not make
that
mistake with the new schematic and symbol library file formats.
Wayne
On 5/16/19 8:47 AM, Seth Hillbrand wrote:
Hi Wayne-
What about a "sub-version" tag? KiCad can write it to the file but
doesn't need to parse it. We reset it to 0 with
Am 2019-05-16 06:29, schrieb mdoes...@xs4all.nl:
I've seen the following problem for some time when wxpython is enabled:
[xcb] Unknown sequence number while processing reply
[xcb] Most likely this is a
Hi Wayne-
What about a "sub-version" tag? KiCad can write it to the file but
doesn't need to parse it. We reset it to 0 with each file version
update and then increment the subversion anytime we need to change the
file formatting. External parsers that care about formatting can use
it.
Am 2019-05-16 08:31, schrieb Wayne Stambaugh:
Seth,
I took a look at this and it looks fine to me. Refresh my memory, is
this change to reduce the number of arc segments to help address the
performance issues on complex boards or is this change for some other
reason?
Correct, this reduces
Am 2019-05-14 20:04, schrieb Seth Hillbrand:
Hi All-
I pushed a branch that removes the remaining hard-coded segment counts
to my kicad fork[1]. It touches many things, so I'd love to get some
testing before merging.
It has the side effect of needing to decouple the remaining
tool_manager
Hi All-
I pushed a branch that removes the remaining hard-coded segment counts
to my kicad fork[1]. It touches many things, so I'd love to get some
testing before merging.
It has the side effect of needing to decouple the remaining tool_manager
interfaces from pcbnew. I noticed a couple
Am 2019-05-11 06:22, schrieb Martin McNamara:
Hi,
I've been a user and fan of Kicad for the last two years, I enjoyed
the presentations from Kicon on the Contextual Electronics YouTube
channel and particularly the talk from Jon Evans has spurred me on to
try help.
The attached patch address a
Am 2019-05-10 12:33, schrieb Tomasz Wlostowski:
Hi,
I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex
Am 2019-05-06 21:02, schrieb Tomasz Wlostowski:
On 06/05/2019 09:48, Jeff Young wrote:
1) I hate the coroutines. They truncate backtraces in the debugger.
Hi,
How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
Windows? I have working implementation of the latter already in
Am 2019-05-05 18:18, schrieb Wayne Stambaugh:
Seth,
On 5/3/19 8:20 PM, Seth Hillbrand wrote:
This looks good Ian. I had been meaning to get around to this but you
beat me to it! Nice work. Thank you for your contribution!
I don't think we need to push this to 5.1 but it's nice to have
+1
Am 2019-05-05 13:33, schrieb Jon Evans:
+1
Merge it and get more testing. It's already worlds better than the
status quo.
On Sun, May 5, 2019 at 12:12 PM Jeff Young wrote:
I think this is ready to merge. Any objections?
___
Mailing list:
Am 2019-05-03 14:04, schrieb Ian McInerney:
This patch series removes the last uses of MUTEX and MUTLOCK from the
code base, so now everything is using std::mutex and std::lock_guard
instead of the Boost provided classes. I have also removed the
ki_mutex.h header file since this is no longer
Am 2019-05-03 11:09, schrieb Jeff Young:
While I wasn’t able to reproduce these, I have “fixes” in for them:
1) Tom’s dereference of freed memory
2) Seth’s place image crash (and disappearing image issue)
These were reproducible, so I’m a bit more sure that they're are fixed:
3) Seth’s
Am 2019-05-03 08:05, schrieb Brian Piccioni:
Hello Devs
This is well beyond my capabilities, but I have been wondering if
having tabbed schematics is a viable feature for eeSchema?
Currently you have to open another instance of eeSchema or click
through to sheets in order to see other sheets.
Am 2019-05-02 16:51, schrieb Jeff Young:
The eeschema modern toolset is “finished”.
It can be found at origin/eemodern. A bit of testing before merging
might be in order….
Cheers,
Jeff.
Note: this is just the schematic editor. The symbol editor will
follow.
Awesome work here Jeff! This
Am 2019-05-02 12:37, schrieb Henner Zeller:
On Thu, 2 May 2019 at 09:31, Henner Zeller wrote:
On Thu, 2 May 2019 at 09:25, Seth Hillbrand
wrote:
>
> Hmmm... cache will be local to each core, so the we'll probably get
> speed up by dividing the image into quadrants based on t
Am 2019-05-02 12:18, schrieb Henner Zeller:
On Tue, 30 Apr 2019 at 20:24, Henner Zeller wrote:
Hi,
so here one digit patch.
Problem Symptom: in the schematic symbol chooser, if you search for an
exact match of a component with multiple units, it is not selected.
For instance, search for
Am 2019-04-30 12:49, schrieb Jeff Young:
You are correct that you also can’t do it with UTF32 strings, but
I’m not suggesting those. I’m suggesting *unicode* strings.
That’s 1 code-point per character. So myString[3] still works.
Sorry Jeff, I'm being slow here and must be missing an
Am 2019-04-30 12:22, schrieb John Beard:
Even with UTF-32, you can only do an O(1) lookup of the n'th *code
point* or *code unit* (the same in UTF-32, not in UTF-8), not the n'th
*encoded character*.
+1 here. I'd be in favor of standardizing on a clean,
standards-compliant string library for
Am 2019-04-29 14:39, schrieb Wayne Stambaugh:
On 4/26/19 6:01 PM, Michael Kavanagh wrote:
Ha, thanks!
On that note, there are a lot of old bugs marked as "Fix Committed",
but
because they were never associated to a milestone (or some other
reason)
the Janitor never cleaned them up to "Fix
Am 2019-04-28 17:47, schrieb Simon Richter:
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
Am 2019-04-22 08:43, schrieb Wayne Stambaugh:
I will tag the source repo to 5.1.2 this evening when I get home from
work so please tag the other repos for 5.1.2 at the same commit as
5.1.1. Hopefully we can get this version released.
Can we get a 5.1.3 target on the bug tracker as well?
-S
Am 2019-04-16 21:52, schrieb Simon Richter:
Hi,
Jenkins reports test failures for commit 8cc3c6f15 "Prevent iteration
over empty polygon":
Should be fixed. Thanks Simon!
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Am 2019-04-14 18:50, schrieb Tomasz Wlostowski:
Dear all,
The attached patchset introduces a builtin crash reporter for Kicad -
that is a window that pops up in case of a segmentation fault/other
serious error, kindly apologizes to the user and lets him/her submit
(anonymously) a bug report to
Am 2019-04-09 14:56, schrieb Adam Wolf:
Hi folks!
If someone is looking for something to do (ha!) some of our macOS
builds are broken right now due to an issue between a recent boost
update in Homebrew and CMake. It doesn't look like the community is
making much traction, but this may just be
Am 2019-04-08 14:57, schrieb Adam Wolf:
Hi folks!
Anyone having issues like this recently?
08:58:06 default:
/vagrant/build/kicad/src/kicad/qa/eeschema/eeschema_test_utils.cpp:28:23:
error: no member named 'getenv' in namespace 'std'; did you mean
simply 'getenv'?
08:58:06 default:
Looks like your build tree is out of date. Might need to do a make
clean first.
See d259459a14f5d3cee00afc25354f82e2ab87853b for details.
-S
Am 2019-04-07 17:41, schrieb Christopher Buckley:
I've made some mods in the following files pulled about 48hrs ago.
/common/colors.cpp
Am 2019-04-07 09:00, schrieb Wayne Stambaugh:
Seth,
I was actually considering this but I was holding off for one last high
priority bug[1] to be fixed. I'm fine with pushing the low and medium
priority bugs to 5.1.2. Any one have time to take a stab at fixing
this
bug? I could take a look
Hi All-
I'd like to suggest spinning out 5.1.1 soon and pushing the existing
5.1.1 bugs to 5.1.2.
There have been a few critical bugs (4 + 5 high priority) that are fixed
from 5.1 and should be out in a stable release. While there are a
number of medium priority bugs outstanding, we will
Am 2019-04-06 19:06, schrieb Jeff Young:
The keep text upright feature works poorly with left- or
right-justified text (it flips around the anchor point).
This is difficult to fix because it’s done at display time (so if the
code is changed it will change the layout of existing boards).
We
Hi Jeff-
The major downside to our using UTF-16 is that it is not
endian-independent. Unless we drop support for big-endian platforms,
we'll need to handle both cases. I needn't tell you what a pain that
would be.
Maybe we can just not return wxString references? Enforce a
getter/setter
ot opposed to it but there is a possibility that it's incomplete. I'm
surprised that there any of these board files still around. This bug
was not in the field very long so the number of boards with this bug
should be fairly small.
Cheers,
Wayne
On 4/1/2019 1:25 PM, Seth Hillbrand wrote:
-1-0/16077
[2] http://kicad-pcb.org/help/upgrading/
[3] https://drive.google.com/open?id=10OaglGiBMD_WUY20AFWRhoditUtiCax4From 4bafeef8922369173b130b41935c6684a7dad23d Mon Sep 17 00:00:00 2001
From: Seth Hillbrand
Date: Mon, 1 Apr 2019 06:17:32 -0700
Subject: [PATCH] pcbnew: Handle old stable
iew a bit
> > easier. I could squash everything into one huge commit if you'd
> prefer.
> >
> > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand <s...@hillbrand.org
> s...@hillbrand.org>
> > s...@hillbrand.org s...@hillbran
Am 2019-03-30 17:33, schrieb Simon Richter:
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.
Am 2019-03-25 17:33, schrieb Ouabache Designworks:
In Kicad an arc is defined by Center point X and Y, Radius, Start and
End angles in 10ths of a degree and Start and End points X and Y.
This is overkill since the polar representation fully defines the Arc
and the Cartesian start and end
points
Am 2019-03-24 13:23, schrieb Jon Evans:
Hi all,
Another question from this forum thread:
https://forum.kicad.info/t/before-giving-up-on-kicad-one-last-attempt-erc-misery/15933/67
timestamp_t is defined as "long", with a note that swig can't handle
int32_t.
I don't understand this comment.
Am 2019-03-22 16:51, schrieb Seth Hillbrand:
adjust but I'm seeing show stoppers.
** not ** seeing show stoppers.
-S
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https
Am 2019-03-12 17:11, schrieb Jon Evans:
https://code.launchpad.net/~craftyjon/kicad/+git/kicad/+merge/364346
On Tue, Mar 12, 2019 at 4:32 PM Seth Hillbrand
wrote:
Am 2019-03-11 18:03, schrieb Jon Evans:
Rebased branch is located here:
https://github.com/craftyjon/kicad/tree
Am 2019-03-21 19:41, schrieb Tomasz Wlostowski:
Hi all,
In the thread [1] on the forum, someone is having hard time trying to
edit a schematic with off-grid wires. Does anyone here remember if
older
versions of Kicad used the mouse or cursor position for grabbing
objects? Is there a chance
Hi Christopher-
Am 2019-03-20 21:53, schrieb Christopher Buckley:
Hello, I'm new to the dev team and am experimenting with an
improvement.
I've done a successful build with provided sources and have revised
the modules I believe are applicable.
My initial build took about 3 hours...which is
OT: I'm reminded of watching a Yankees game the first time they
broadcast in high definition and feeling really bad for Joe Torre's
dermatologist. That is to say I second Jeff's take; some things look
better blurry.
That said, if you pixel align these icons, we can require pixel
alignment
Am 2019-03-17 20:11, schrieb Jon Evans:
Hi all,
I want to change the color system in PcbNew so that transparency is
tied to object type rather than board layer. Color would still be set
by layer, but transparency would be settable for things like tracks,
component pads, zones, etc.
Hi Jon-
Folks, I merged a removal of an older workaround prior to the intended
merge time. This was the -Bsymbolic patch from [1]. It looks like it
was a bug in the linker that no longer exists but it also looks like we
never got a full resolution on it. I removed it because it prevents
throwing
Am 2019-03-14 16:02, schrieb BERTRAND Joël:
Maybe we have to use my patch with some other directives ($config and
$if for example). Indeed, following example doesn't work as expected :
Hi Joël-
You may find better application with a patch to the ngspice repository.
We'll end up
Am 2019-03-14 12:18, schrieb Brian:
Wayne,
wxIsdigit is reported as an undefined symbol when compiling
eeschema/pin_numbers.cpp.
One possible solution is to add
#include
to eeschema/pin_numbers.cpp
Patch attached.
Thanks Brian. Patch pushed with minor modification to get the crt.h
Am 2019-03-12 15:21, schrieb BERTRAND Joël:
Hello everyone,
I have written a patch for Spice netlist exporter. I spend a lot of
time when I want to switch from .AC analysis to .TRAN or .NOISE. This
patch allows spice exporter to use different configurations with two
new
instructions
Am 2019-03-11 18:03, schrieb Jon Evans:
Rebased branch is located here:
https://github.com/craftyjon/kicad/tree/bus_upgrades_merge
I've also attached a patchset for convenience.
-Jon
Hi Jon-
Any chance you could you make a launchpad branch with a merge request
for this? I'd like to ask
Am 2019-03-12 13:49, schrieb Wayne Stambaugh:
Hey Seth,
On 3/11/2019 6:12 PM, Seth Hillbrand wrote:
Why make new plugin registry that is different from the plugin
registry
that is used in pcbnew? And if we do need a new version for schematic
type plugins, can we unify them to avoid having
Am 2019-03-12 11:37, schrieb Brian:
I think some discussion is in order to decide on which ideas
should make it into a unified plugin registry (something I'm
definitely in favor of and would be happy to contribute to the
project).
Thanks for looking into this Brian!
1. What's the right
Am 2019-03-11 17:46, schrieb Brian:
-- Registry mechanism
This one's a bit more involved and I welcome comment and discussion.
Refer to eeschema/sch_io_plugin_registry.h/cpp.
A new class called SCH_IO_PLUGIN_REGISTRY is a singleton which
maintains a few indices of plugins. In order to
On Mon, Mar 11, 2019 at 9:59 AM Brian wrote:
Hello everyone,
tl;dr - hi, I'm new here and I'd like to suggest a couple small
changes
to make maintaining my private fork a little easier. Presuming I can
present a concise patch that adheres to the coding standard, what's
the
right way to
Am 2019-03-07 07:46, schrieb Jeff Young:
I’d like to move the “old” netlist stuff to an Import/Export paradigm
(since the “normal” Kicad method is now Update Board from Schematic).
This entails removing the Read/Write Netlist icons from the toolbar
and moving the menu items from Tools to File >
Am 2019-03-06 12:17, schrieb Tomasz Wlostowski:
Hi,
This patchset enables building KiCad in MS Visual Studio (version 2017,
not tested on earlier versions).
Thank you Tom! I would love it if, after testing, we could consider
switching our official MSW builds to MSVC. While the mingw
Am 2019-03-01 01:28, schrieb cedric.dew...@telfort.nl:
How does an earlier version of Kicad handles a file that has been
created by a newer version of Kicad?
It doesn't. And it can't between major releases (e.g. 4-5, 5-6)
Altium opens files that have been created by a newer version, and
Am 2019-02-27 15:59, schrieb Wayne Stambaugh:
On 2/27/2019 3:30 PM, Seth Hillbrand wrote:
Am 2019-02-27 14:57, schrieb Wayne Stambaugh:
Hey Adam,
I'm guessing the impact of not supporting 10.11 would not be that
great
but I'm not a mac user so I cannot be certain. Are there any mac
users
Am 2019-02-27 14:57, schrieb Wayne Stambaugh:
Hey Adam,
I'm guessing the impact of not supporting 10.11 would not be that great
but I'm not a mac user so I cannot be certain. Are there any mac users
opposed to this? I'm fine with this if there is no uproar from the mac
user community.
This
Am 2019-02-27 11:52, schrieb Seth Hillbrand:
Am 2019-02-26 12:11, schrieb Simon Richter:
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
Am 2019-02-26 12:11, schrieb Simon Richter:
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
Am 2018-12-11 12:16, schrieb Maciej Sumiński:
Recently KiCad Janitor had been rather unreliable, mostly due to my
capricious Internet connection, so a few minutes ago he has got a new
home at one of CERN servers. It used to work as a webhook, but in order
to improve robustness I have switched it
Am 2019-02-22 09:29, schrieb Wayne Stambaugh:
Once v6 is started, I'd like to freeze the v5 parsers and make a copy
of
the parsers for v6. This would mean that all new format features
would
be implemented in a separate parser while any changes to underlying
structures would require updates in
Am 2019-02-21 15:21, schrieb Wayne Stambaugh:
Since we are nearing the 5.1.0 release, I want to get an idea of what
major merges are ready to go once 5.1 is branched. I know Jon's
netlist
code is ready to merge and I'm pretty sure that should be the first big
merge. Does anyone else have any
401 - 500 of 975 matches
Mail list logo
