On 6/5/19 11:55 AM, Seth Hillbrand wrote:
> On 2019-06-05 10:09, jp charras wrote:
>> Le 05/06/2019 à 15:40, Wayne Stambaugh a écrit :
>>> On 6/5/19 7:20 AM, jp charras wrote:
>>>> Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit :
>>>>> On 6/4/19 4:25 P
On 6/3/19 12:25 PM, Steven A. Falco wrote:
> On 6/3/19 10:42 AM, Wayne Stambaugh wrote:
>> Hi Steve,
>>
>> Your patch no longer applies cleanly as there has been some serious
>> refactoring and legacy code removal. I think your patch is a good idea
>> but it
On 6/4/19 12:31 PM, Tomasz Wlostowski wrote:
> On 04/06/2019 17:11, Tomasz Wlostowski wrote:
>
>> Hi Wayne,
>>
>> It looks like I screwed up the exception handler under KiCad windows
>> shell. Will fix soon.
>
> Fixed in my github branch.
>
> T.
>
As soon as I get home on Sunday, I will test
or 2
On 6/4/19 10:12 AM, Jeff Young wrote:
> 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….
>
>> On 4 Jun 2019, at 14:53, jp charras > <mailto:jp.char...@wanadoo.fr>> wrote:
>
On 6/3/19 5:30 PM, Seth Hillbrand wrote:
> 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
I'm getting the following build failure on linux using commit 1fe848f3:
[ 97%] Linking CXX executable qa_pcbnew
/usr/bin/ld: ../../common/libpcbcommon.a(pcb_base_frame.cpp.o): in
function `PCB_BASE_FRAME::Get3DViewerFrame()':
/home/wayne/src/kicad-trunk/pcbnew/pcb_base_frame.cpp:117: undefined
to increase this by one for the board
editor. The board editor has far greater precision than the schematic
editor.
Thanks,
Wayne
On 5/24/19 9:55 AM, Steven A. Falco wrote:
> On 5/23/19 1:59 PM, Wayne Stambaugh wrote:
>> Hey Steve,
>>
>> Adding "grid" to th
On 5/31/19 4:23 PM, Tomasz Wlostowski wrote:
> On 30/05/2019 21:12, Wayne Stambaugh wrote:
>> Nothing was displayed. I was running from the project manager. I even
>> crashed the project manager. I'm using msys2 to create mingw32 and
>> mingw64 debug builds of KiCad. I'm
On 5/30/19 4:53 PM, Seth Hillbrand wrote:
> On 2019-05-30 15:00, jp charras wrote:
>> Le 29/05/2019 à 21:31, Seth Hillbrand a écrit :
>>> 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.
On 5/30/19 2:49 PM, Tomasz Wlostowski wrote:
> On 30/05/2019 16:46, Wayne Stambaugh wrote:
>> Hey Tom,
>>
>> On 5/29/2019 7:59 PM, Tomasz Wlostowski wrote:
>>> On 30/05/2019 00:35, Wayne Stambaugh wrote:
>>>> A `git pull` from https://github.com/twlos
Hey Tom,
On 5/29/2019 7:59 PM, Tomasz Wlostowski wrote:
> On 30/05/2019 00:35, Wayne Stambaugh wrote:
>> A `git pull` from https://github.com/twlostow/kicad-dev.git says I'm up
>> to date.
>>
>> A note to the lead dev team, please do not push your personal
>>
nd also the eemodern branch? I think they are confusing,
> lets just have feature branches in personal 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,
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 like the implementation a lot!
>>
>>
Thanks Frank!
On 5/29/2019 9:22 AM, Frank Severinsen wrote:
> Hi Wayne
>
> Im guessing this one
> https://github.com/twlostow/kicad-dev/tree/tom-crash-reporter-may27
>
>
> Den 29. maj 2019 kl. 15.00.19 +02.00, skrev Wayne Stambaugh
> :
>> Tom,
>>
>>
Tom,
On 5/28/2019 12:13 PM, Tomasz Wlostowski wrote:
> On 27/05/2019 17:39, Seth Hillbrand wrote:
>> 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
Seth,
On 5/25/19 12:27 PM, Seth Hillbrand wrote:
> 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
Because SQL and databases in general are not good storage mediums for
libraries. KiCad libraries are plain text files that are easy to parse
and format, portable, human readable, and do not require any additional
dependencies. Databases are none of these. I don't think corporate
inventory
On 5/27/19 11:11 AM, Seth Hillbrand wrote:
> 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
Seth,
I'm fine with this approach. I like your idea of deriving a new
UNIT_BINDER object so that it doesn't impact the other frames that do
not use ORIGIN_TRANSFORMS.
Cheers,
Wayne
On 5/26/19 4:15 PM, Seth Hillbrand wrote:
> Hi All-
>
> If Reece can separate this so that it doesn't affect
Jon,
I've asked Reece to make Seth's recommended change to lower the merge
impact so it will probably be a while until thus is completed. Go ahead
and cherry-pick the backlog from 5.1.
Thanks,
Wayne
On 5/26/19 3:54 PM, Jon Evans wrote:
> Hi Reece, Wayne, Seth,
>
> Can you clarify the path
Reece,
I hate to ask you to rebase again but there has been so much activity
recently that several of you original patches no longer apply cleanly.
Please rebase and resubmit the original patch set when you get a chance.
Lead Devs,
Let's try to be kind to Reece so I can get this merged. As
Just as an FYI in case it wasn't obvious, Seth's proposal uses library
IDs to define the symbol and footprint. This means that in order for
the atomic libraries as proposed to be portable, the symbol, footprint,
and 3D model would have to be available on the host machine. Otherwise,
any missing
Ian,
I typically use Debian stable (Stretch) as a benchmark for dependency
versions which has version 3.5.3 of Python3. Seeing that Debian old
stable (Jessie) has Python3 version 3.4.2 and Ubuntu 16.04 (xenial) is
3.5.1, I would think 3.4 would be an acceptable minimum version of
Python 3 to
John,
On 5/22/19 5:39 AM, John Beard wrote:
> On 20/05/2019 23:48, Frank Severinsen wrote:
>
>> When using clang-format on the entire file, it more or less changed
>> every line in one way or another.
>> should this be committed as well or is git clutter worse than
>> codingstyle issues?
>
>
On 5/22/19 4:38 AM, John Beard wrote:
> Hi Wayne,
>
> On 21/05/2019 18:26, Wayne Stambaugh wrote:
>> John,
>>
>> If this is not acceptable, would an option that allows the user to turn
>> this feature on or off be an acceptable solution. In some
John,
On 5/23/19 2:36 PM, John Beard wrote:
> On 23/05/2019 19:05, Wayne Stambaugh wrote:
>
>> /home/wayne/src/kicad-trunk/include/bitmap_base.h:34:1: error:
>> declaration
>> conflicts with target of using declaration already in scope
>> class COLOR4D;
>
Fat fingered:
On 5/23/19 2:04 PM, Wayne Stambaugh wrote:
> I just got this:
>
[ 27%] Building CXX object
common/CMakeFiles/legacy_wx.dir/legacy_wx/eda_draw_frame.cpp.o
In file included from
/home/wayne/src/kicad-trunk/common/legacy_wx/eda_draw_frame.cpp:70:
In file included from
/home/way
I just got this:
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Hey Steve,
Adding "grid" to the coordinates in the status bar is not correct.
These are the cursor coordinates not the grid coordinates. To add the
current grid size to the status bar, you would need to add another pane
to status bar and fetch the current grid setting from the current SCREEN
Thanks Seth!
On 5/23/19 1:08 PM, Seth Hillbrand wrote:
> 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 pat
We are getting a decent set of bug fixes in the 5.1 branch so we should
seriously start thinking about a 5.1.3 stable release by the end of
June. What I would like to see is push to fix some of the outstanding
5.1 bugs[1] and then do a string freeze in the middle of June. If you
see a bug that
Hey Nick,
This was on my list but if you want to take it on, I'm fine with that.
I agree that it should be a separate developer document in markdown
format. I also recommend that we link this document on the bug squad
page[1].
There needs to be section on when and how set the various bug
d be reasonable to expand only as far as the LIBID nodes.
>
> Cheers,
>
> John
>
> On 2 May 2019 17:22:12 BST, Wayne Stambaugh wrote:
>
> Hey Henner,
>
> On 5/2/19 12:18 PM, Henner Zeller wrote:
>
> On Tue, 30 Apr 2019 at 20:24, Hen
Hey Reece,
I tested your patch set and everything seems to work as advertised. I
have a few minor comments:
The ORIGIN_TRANSFORMS references should be passed as const in all places
where they are used internally by another object that doesn't modify them.
It's not necessary to add '1' to the
Unless we can figure out how to set the grid origin using a single
origin, I don't see how we can get rid of it. One thing we have done a
poor job of is providing an easy way to clear the grid origin. I would
like to see a reset grid origin menu entry.
On 5/18/19 2:22 PM, Jeff Young wrote:
> I
On 5/16/19 4:52 PM, Seth Hillbrand wrote:
> 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
>&g
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 code was wr
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 layer line widths instead of the
line width defined
John,
On 5/9/19 6:49 PM, John Beard wrote:
> On 24/04/2019 13:38, John Beard wrote:
>
>> I have here a couple of patches that enable unit tests in eeschema's
>> library code.
>
>> this is a proposal to merge the changes attached, at the cost of
>> another heavy link. However, having a working
Seth,
On 5/16/19 1:29 PM, Seth Hillbrand wrote:
> 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
ng v6 we plan
to officially support for keep out zones and edge cut layers in
footprints so we should add version support to the footprint library
file format at that time.
>
>>
>> Am 2019-05-16 09:02, schrieb Wayne Stambaugh:
>>> Hey Seth,
>>>
>>> I'
gt; -Seth
>
> Am 2019-05-16 08:40, schrieb Wayne Stambaugh:
>> Rene,
>>
>> It's probably a bit late now but Jeff's assessment is correct. I
>> understand your concern but technically this doesn't change the file
>> format when spaces are used in string
Rene,
It's probably a bit late now but Jeff's assessment is correct. I
understand your concern but technically this doesn't change the file
format when spaces are used in strings it just makes it obvious that the
information in the file is used as a string. I'm not opposed to
changing the file
Seth,
On 5/15/19 8:06 PM, Seth Hillbrand wrote:
> 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
Hey Tom,
On 5/14/19 4:34 AM, Tomasz Wlostowski wrote:
> On 13/05/2019 17:46, Wayne Stambaugh wrote:
>> I guess I should weigh in on this issue. I would prefer we exhaust all
>> other options before bumping opengl to some later version.
>
> Hi Wayne,
>
> I think JP'
Hey Henner,
I merged your patch into the master and 5.1 branches.
Thanks,
Wayne
On 5/14/19 12:36 AM, Henner Zeller wrote:
> On Thu, 9 May 2019 at 13:06, Wayne Stambaugh wrote:
>>
>> Hi Henner,
>>
>> On 5/1/19 9:44 AM, Henner Zeller wrote:
>>> On Wed, 1
Nick,
It already has been merged in the master and 5.1 branches. The commit
in master is 5685174808f5ca973e916a10f9f93660ee4dc4f2.
Wayne
On 5/14/19 3:47 AM, Nick Østergaard wrote:
> @Wayne Stambaugh any impediments to getting this merged?
>
> On Fri, 10 May 2019 at 21:37, Steven
y to
> retrieve it and fix the problem tonight. Sorry for the inconvenience.
>
> Cheers,
> Orson
>
> On 5/10/19 9:03 PM, Wayne Stambaugh wrote:
>> Is the KiCad janitor sleeping on the job again? I push a fix[1] for
>> lp:1828214 a couple of hours ago and it st
I guess I should weigh in on this issue. I would prefer we exhaust all
other options before bumping opengl to some later version. In the end,
we may have to abandoned older systems to get our performance to an
acceptable level with complex designs. I consider it more important to
serve our
Is the KiCad janitor sleeping on the job again? I push a fix[1] for
lp:1828214 a couple of hours ago and it still has not updated the bug
tracker status. Generally it doesn't take this long.
Cheers,
Wayne
[1]
https://git.launchpad.net/kicad/commit/?id=ae54f34392407cfd9d4628cf3087f07f239cebb2
Mark,
I merged your patch into the master and 5.1 branches. Thank you for
your contribution to KiCad.
Cheers,
Wayne
On 5/9/19 3:58 AM, mdoes...@xs4all.nl wrote:
> Sorry about that, here's the patch
>
>
>
>
> ___
> Mailing list:
ppy to run
> qa tests - is there a "make" target for them? I've never run them before...
>
> Steve
>
> On 5/10/19 1:21 PM, Wayne Stambaugh wrote:
>> Hi Steve,
>>
>> Did you actually test and confirm that the python scripting is working?
>> I ran
uld have mentioned that rawhide is using swig 4.0.0.
>
> On Fri, May 10, 2019, 1:06 PM Steve Falco <mailto:stevenfa...@gmail.com>> wrote:
>
> I am now able to build on rawhide with this patch. It works for me.
>
> Steve
>
> On Fri, M
Has anyone with swig 4 tested this patch yet. I tested it and it
appears not to break anything with swig < 4. If it works for swig 4, we
should get this merged so platforms using swig 4 wont have to downgrade
to build KiCad.
Wayne
On 5/9/19 3:58 AM, mdoes...@xs4all.nl wrote:
> Sorry about
Jeff,
You proposal doesn't seem to meet the objectives we discussed about
allowing the user to chose the hotkey behavior for actions that can
perform an action at the current cursor position but maybe I'm missing
something. Also, don't forget about Jon's proposal for chained key
combinations. I
Hi Henner,
On 5/1/19 9:44 AM, Henner Zeller wrote:
> On Wed, 1 May 2019 at 06:14, John Beard wrote:
>>
>> On 01/05/2019 13:57, Mário Luzeiro wrote:
>>> Hi John,
>>>
>>> yeah the Morton code is to improve cache hits.
>>>
>>> Regarding the speed test, since OS are multi-tasking there could be some
wrote:
>>
>> It's down for me.
>>
>> On Wed, May 8, 2019 at 6:20 AM Wayne Stambaugh wrote:
>>>
>>> Can anyone else get to the developers doc web page? I still getting a
>>> 504 Gateway Time-out error since yesterday afternoon. I am in the
>&g
Marco,
On 4/10/19 2:35 AM, Marco Ciampa wrote:
> On Tue, Apr 09, 2019 at 08:58:48PM +0200, Tomasz Wlostowski wrote:
>> On 09/04/2019 18:43, Kerusey Karyu wrote:
>>> Guys
>>>
#: pcbnew/exporters/export_hyperlynx.cpp:190
m_reporter->Report(
_( "File contains pad shapes that
Thomas,
On 2/23/19 7:53 AM, Thomas Pointhuber wrote:
> Hi,
>
> out of curiosity I'm currently trying to register a new tool, but no
> success for now.
>
> I noticed that "tool-framework.md" is no longer up-to-date (referring to
> the Tutorial):
>
> For example:
>
> * "SetTransitions" is now
Can anyone else get to the developers doc web page? I still getting a
504 Gateway Time-out error since yesterday afternoon. I am in the
process of finishing up the v6 road map along with some other developer
doc updates and I wanted to see if anything else needed updating. Any
help would be
Tom,
On 5/7/2019 9:36 AM, Tomasz Wlostowski wrote:
> On 07/05/2019 07:47, Wayne Stambaugh wrote:
>>
>> On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote:
>>> On 06/05/2019 09:48, Jeff Young wrote:
>>>> 1) I hate the coroutines. They truncate backtraces in the deb
On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote:
> 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
Simon,
I've tested your patch and it works fine but I would prefer that this be
a config option so that it can be disabled just in case there are issues
with using SIMD support on certain platforms. I'm fine if the default
config is enabled.
Cheers,
Wayne
On 4/28/2019 5:49 PM, Simon Richter
John,
On 5/6/2019 8:11 AM, John Beard wrote:
> On 03/05/2019 19:28, Wayne Stambaugh wrote:
>>
>> I'm guessing John used a later version of clang-format when he wrote the
>> commit hooks. John, any ideas how to fix this or do we force devs to
>> use clang-format > 3.
github issue.
>>
>> On Wed, 1 May 2019 at 20:33, Wayne Stambaugh wrote:
>>>
>>> Jeff,
>>>
>>> I think that was a different issue. My issue was link problem due to
>>> msys2 upgrading boost to 1.70 which apparently now uses CMake instead of
&
Looks good John, feel free to push the change.
Thanks,
Wayne
On 5/6/2019 5:35 PM, John Beard wrote:
> On 06/05/2019 22:12, Wayne Stambaugh wrote:
>> On 5/6/2019 5:11 PM, John Beard wrote:
>>> I still suggest to change it to false be default and allow developers to
>&
John,
On 5/6/2019 5:11 PM, John Beard wrote:
>
>
> On 06/05/2019 21:46, Wayne Stambaugh wrote:
>> John,
>>
>> On 5/6/19 4:09 PM, John Beard wrote:
>>> On 06/05/2019 17:51, Reece R. Pollack wrote:
>>>> John,
>>>>
>>>&g
John,
On 5/6/19 4:09 PM, John Beard wrote:
> On 06/05/2019 17:51, Reece R. Pollack wrote:
>> John,
>>
>> I've already jumped to clang-format 6.0, which is one of the optional
>> installs for Mint 18. That works, once you get all the symlinks fixed,
>
> Good to know, thanks for the update.
>
>>
ce that would allow KiCad to look
> for a
> > set of Python scripts inside a particular folder to allow us to
> perform
> > a certain set of checks that would return result objects that KiCad
> > could later show.
> >
> > Is this approach bett
Jeff,
On 5/6/19 10:48 AM, Jeff Young wrote:
> 1) I hate the coroutines. They truncate backtraces in the debugger.
I'm not a big fan either but apparently they were the best solution for
the P router design. I don't know if that is still the case or if we
even tried a different solution at the
That was quick! Thanks Jeff.
On 5/6/19 10:32 AM, Jeff Young wrote:
> Fixed. (d12eee9c9876062e0463148a57f3b33ab016205f)
>
>> On 6 May 2019, at 13:48, Jeff Young wrote:
>>
>> No need. Reproduces for me. I’m on it.
>>
>>> On 6 May 2019, at 13:47, Wayne S
The sheet tool is broken. The first click starts drawing the sheet as
expected. The second click does not complete the sheet and show the
sheet properties dialog and the sheet being drawn disappears. I can
file a bug report if your prefer.
Wayne
On 5/5/19 4:32 PM, Michael Kavanagh wrote:
>
Seth,
On 5/3/19 8:20 PM, Seth Hillbrand wrote:
> 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
one. But
> remember not to burn yourself out, just the opportunity to take a
> break from kicad in your "spare" time then :)
>
> On Sat, 27 Apr 2019 at 20:05, Wayne Stambaugh wrote:
>>
>> For those you who haven't heard yet, I made the announcement yesterday
>>
own libraries won't be atomic. There's no need to engage, we
will send your positive message there, namely that all workflows will
always be fully supported. Right?
Eeli Kaikkonen
la 4. toukok. 2019 klo 0.14 Wayne Stambaugh (stambau...@gmail.com
<mailto:stambau...@gmail.com>) kir
On 5/3/2019 4:59 PM, Rene Pöschl wrote:
> On 03/05/19 22:48, Eeli Kaikkonen wrote:
>> I was just trying to find this discussion in the video, can you give
>> the time?
>>
>> The link to the video is here, for the future generations of internet
>> search engine users who find this thread:
>>
On 5/3/2019 4:08 PM, Jeff Young wrote:
> Hi Seth,
>
> Thanks for the feedback!
>
>> - Right-click inside a subsheet should have exit sub sheet as the first
>> option
>
> Really? This sort of presumes the most likely thing to do after entering a
> sheet is to leave it again. (It is in the
On 5/3/2019 11:27 AM, Dick Hollenbeck wrote:
> On 5/3/19 9:41 AM, Wayne Stambaugh wrote:
>> There is a secondary goal of removing wxWidgets from our low level
>> objects. Maybe some day we can build the low level KiCad non-ui
>> libraries sans wxWdigets. My thinking is that
supplied _clang-format file.
I'm guessing John used a later version of clang-format when he wrote the
commit hooks. John, any ideas how to fix this or do we force devs to
use clang-format > 3.8?
>
> -Reece
>
>
> On 5/2/19 7:56 AM, Wayne Stambaugh wrote:
>> Hi Reece,
>&
It seems like this is macos specific. Don't we have our own custom
wxwidgets builds for macos? Maybe we should change the build flags.
On 5/3/2019 12:34 PM, Jeff Young wrote:
> This is the only bug I could find in the database:
> https://bugs.launchpad.net/kicad/+bug/1822678. Note that the
The reason I haven't even considered a tabbed UI is that wxAui in wx3.0
is still not reliable enough. wxAui would allow us to have tabs that
can be torn from the main window and placed on multiple monitors. We
could just use "dumb" tabs now but in the long run, it will just be
additional
shes that we seem
to have.
>
> @Jon & @Tom, I know you guys have also fixed some of these crashes.
> What platform did you find them on? The ones I’ve fixed have been
> encountered on OSX (which is the only platform I have).
>
>> On 3 May 2019, at 15:41, Wayne Stambaugh &
On 5/3/19 5:22 AM, Jeff Young wrote:
> Hi Dick,
>
>>> h) What is the list of deficiencies with current string usage?
>
> I only have one issue with the current use of wxString, but it’s a big
> one: it crashes (unpredictably) when used multi-threaded in UTF8 mode.
I thought it was wxString
Dick,
On 5/2/19 6:32 PM, Dick Hollenbeck wrote:
> On 4/30/19 4:36 AM, Jeff Young wrote:
>> We had talked earlier about throwing the wxWidgets UTF8 compile switch to
>> get rid of our wxString re-entrancy problems. However, I noticed that the
>> 6.0 work packages doc includes an item for
On 5/2/19 9:34 PM, Jon Evans wrote:
> Neat idea, Russell!
>
> In theory, this is possible. In practice, there are many challenges to
> overcome.
>
> The internal representation of the schematic does not resemble the
> netlist that is given to PcbNew.
> So, a PcbNew netlist (whether generated
I should have some time to take it for a test spin tomorrow.
Wayne
On 5/2/19 4:51 PM, Jeff Young wrote:
> 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
Reece,
It sounds like you are describing DFM not DRC. There is some overlap
between the two concepts but they not the same thing. This is also
something different that what Jon's survey is attempting to determine.
The new constraint system planned for v6 will support import/export and
should
I don't have any issues with additional feedback. @Jon, are you OK with
that.
Wayne
On 5/2/19 1:50 PM, Adam Wolf wrote:
> Do you mind if we share this to other KiCad users?
>
> Adam
>
> On Thu, May 2, 2019 at 11:55 AM Jon Evans wrote:
>>
>> Hi all,
>>
>> The development team would like
Hey Henner,
On 5/2/19 12:18 PM, Henner Zeller wrote:
> 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.
>>
Hey Tom,
I finally got around to testing this. I could not get it to build on
windows or linux. I'm getting the following compiler error on both 32
and 64 bit windows and linux builds:
E:/msys64/home/Wayne/src/kicad-lp-clone/common/debug_report.cpp: In
member function 'void
Hi Reece,
Just a few comments on top of Jeff's reply since this will be your first
patch submission:
Please follow the coding style policy[1]. It saves a lot of back and
forth. There is also a git commit hook[2] which you can use to verify
your coding style is correct. You will have to have
hter.eu/view/KiCad%20Status/
>>
>> What is the error? And when did it go wrong?
>>
>> Cheers,
>>
>> John
>>
>> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>>> Anyone else having build issues on windows? I'm getting link errors for
>>&
> msys2?
>
> Also it seems that other people are struggling:
> https://github.com/msys2/MINGW-packages/issues/5233
>
> Nick
>
> On Wed, 1 May 2019 at 15:41, Wayne Stambaugh wrote:
>>
>> On 5/1/2019 8:53 AM, John Beard wrote:
>>> On 01/05/2019 13:36, Wa
On 5/1/2019 8:53 AM, John Beard wrote:
> On 01/05/2019 13:36, Wayne Stambaugh wrote:
>> On 5/1/2019 8:27 AM, John Beard wrote:
>>> On 01/05/2019 12:53, Jeff Young wrote:
>>>> Someone on the forums had to turn off the qa tests on Linux to get it
>>>
On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
>>
>> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> This bit, right?
>
>
On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
>>
>> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> This bit, right?
>
>
On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
>>
>> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> This bit, right?
>
>
Clean build fails as well. I did upgrade msys2 yesterday so maybe
something is borked with msys2.
On 5/1/2019 7:53 AM, Wayne Stambaugh wrote:
> Hey John,
>
> I'll try a clean build to see if that fixes it. I rarely have to do
> that. I haven't done a windows build in a while so
ins Msys2 and MSVC builds. In fact,
> it's green across the board:
>
> https://jenkins.simonrichter.eu/view/KiCad%20Status/
>
> What is the error? And when did it go wrong?
>
> Cheers,
>
> John
>
> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>> Anyone else h
Anyone else having build issues on windows? I'm getting link errors for
the qa s-expr tests on both 32 and 64 bit builds.
Wayne
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
601 - 700 of 5421 matches
Mail list logo
